A newly documented class of denial-of-service attack exploits built-in features of the HTTP/2 protocol to generate outsized traffic volumes against targeted servers, with healthcare organizations identified as among the sectors facing elevated exposure. The technique — being called an HTTP/2 "bomb" attack — does not rely on a traditional vulnerability but on the protocol working exactly as designed, which limits how quickly patches can address the underlying risk.

How the attack works

HTTP/2 introduced two features meant to reduce bandwidth consumption: header compression and server push. Both allow a client to trigger a disproportionate amount of server-side work relative to the size of the initiating request. Attackers exploiting these features can craft small, legitimate-looking requests that force a target server to expand and process far more data than the inbound traffic volume would suggest, producing an amplification effect.

Because the behavior is protocol-conformant rather than a coding error, network-layer rate limiting and conventional firewall rules that inspect only packet counts or byte volumes may not catch the attack at the connection level where the damage accumulates.

Why healthcare infrastructure is specifically at risk

Healthcare organizations have adopted HTTP/2 broadly as part of patient portal, telehealth, and health information exchange infrastructure — all services where availability is operationally critical and downtime carries patient-safety implications beyond the inconvenience a retail outage would cause.

A sustained denial-of-service event against a patient-facing portal or a clinical API gateway can delay medication refill requests, interrupt remote patient monitoring data flows, and block access to scheduling systems. For smaller independent practices that rely on cloud-hosted EHR or telehealth platforms rather than on-premises infrastructure they control directly, the exposure is largely in the hands of their vendors — but practices still carry reputational and operational risk when those services go dark.

The targeting of telcos noted in the original research also carries a secondary implication for healthcare: practices that depend on managed internet services or hosted communication platforms for care coordination inherit any availability degradation their telecom providers experience.

What independent practices should check

Practices with direct control over web-facing infrastructure should review how their HTTP/2 implementations handle header compression limits and server push policies. Specific areas worth examining with hosting or IT partners include:

• Connection-level request throttling — whether rate controls operate at the HTTP/2 stream layer, not just at the TCP connection or IP address layer.
• Server push configuration — whether server push is enabled and, if so, whether the implementation enforces limits on the volume of pushed resources per connection.
• Web application firewall rules — whether current rule sets include HTTP/2-specific behavioral analysis, not only signature-based detection.
• Vendor SLA and incident notification terms — for practices on shared or managed platforms, whether their agreements require timely disclosure of DoS events and describe mitigation response timelines.

What this signals about the next 12 months

Protocol-level amplification techniques have historically followed a pattern: once a viable mechanism is published, adversary groups probe healthcare targets within weeks because the sector's tolerance for downtime is low and the pressure to pay for rapid restoration — whether through ransom or emergency vendor support contracts — is high. The HTTP/2 bomb research fits that pattern.

HIPAA's Security Rule does not prescribe specific protocol configurations, but the requirement to implement technical safeguards that protect the availability of electronic protected health information applies regardless of attack vector. An availability disruption caused by a DoS event is a recognized operational risk that covered entities are expected to address in their risk analysis documentation. Practices that have not reviewed their risk analyses since broadly deploying HTTP/2-dependent services have an identifiable gap to close.