A class of denial-of-service attacks is exploiting built-in features of the HTTP/2 protocol to generate outsized traffic amplification, and healthcare organizations are among the sectors identified as at elevated risk. The technique, described by researchers as an "HTTP/2 bomb," does not require a large botnet or unusual tooling — it turns design decisions baked into the protocol against the servers that rely on it.
How the exploit works
HTTP/2 was designed to reduce bandwidth consumption by introducing two mechanisms: header compression and stream multiplexing. Both features allow a client to send a small amount of data that a server must expand and process at significantly greater cost.
In the amplification scenario, an attacker sends a compact, crafted request that the target server must decompress and handle at many times the original size. Multiplexing compounds the problem — an attacker can open numerous streams on a single connection, each carrying a compressed payload, forcing the server to process a burst of work from what appears to be minimal inbound traffic. The ratio between attacker effort and server burden is what earns the "bomb" label.
Why healthcare is a named target
Healthcare environments present a specific combination of factors that makes this class of attack consequential. Many clinical applications — patient portals, telehealth platforms, health information exchange endpoints, and EHR web interfaces — have migrated to HTTP/2 as part of routine infrastructure modernization. The protocol is also common in API layers that support interoperability mandates under ONC rules.
A successful denial-of-service against any of these layers does not need to exfiltrate data to cause harm. Service disruption to scheduling systems, e-prescribing endpoints, or clinical decision tools carries direct patient-care implications, and downtime events in healthcare have historically triggered HIPAA breach analysis when affected systems hold or transmit protected health information, even when no data was confirmed stolen.
What the technical exposure looks like for smaller practices
Independent practices and smaller health systems typically do not operate the internet-facing web servers directly — those are usually managed by their EHR vendor, telehealth platform, or cloud hosting provider. That shifts the immediate mitigation responsibility upstream, but it does not eliminate the operational risk.
- Vendor dependency review. Practices should confirm with their technology vendors whether HTTP/2-facing infrastructure has been patched or configured to limit header-decompression amplification and cap concurrent streams per connection.
- Availability terms in agreements. Business associate agreements and service contracts should specify uptime obligations and incident notification timelines. A DoS event that causes prolonged unavailability of a covered application may require breach risk analysis.
- Network monitoring baselines. Practices that host any on-premises web-facing infrastructure should verify that traffic anomaly detection is configured to flag connection-rate spikes, not just volumetric bandwidth thresholds — amplification attacks of this type can generate high server load from relatively low inbound traffic volumes.
What this signals about protocol-level risk
HTTP/2 bomb attacks reflect a broader shift in how adversaries approach infrastructure disruption: finding asymmetry in protocol design rather than raw traffic volume. HTTP/2 is not going away — it is embedded in modern web infrastructure across healthcare — and successor protocols including HTTP/3 introduce their own analogous features that researchers are already examining for similar misuse potential.
For compliance and operations teams, the relevant question is not whether to abandon modern web protocols but whether the organizations handling their data have implemented the server-side controls — connection limits, stream caps, decompression safeguards — that neutralize the amplification ratio the exploit depends on.