A newly documented class of denial-of-service attack exploits design features built into HTTP/2, the protocol that carries the majority of modern web traffic, to generate outsized disruption with minimal attacker effort. Healthcare organizations, which depend on always-available patient portals, telehealth platforms, and clinical API connections, are among the sectors identified as materially exposed to the technique, which researchers have labeled HTTP/2 "bomb" attacks.
What the exploit actually does
HTTP/2 was designed in part to reduce bandwidth consumption. Two of its efficiency features — header compression and server push — allow a single client request to trigger a disproportionately large response from the server. The bomb attack turns that design intent against the target: a small, crafted inbound request causes the server to expend far more processing and memory than the attacker invested. The amplification ratio is what makes this category dangerous. Unlike volumetric flood attacks that require large botnets, amplification attacks allow a relatively modest source to saturate a target's resources.
The attack does not require the attacker to break authentication or steal credentials. It operates at the protocol layer, which means any public-facing HTTP/2 endpoint is a potential surface — including web-based EHR login pages, patient scheduling portals, and health information exchange gateways.
Why healthcare is a named target
Healthcare's exposure is structural. Clinical operations increasingly depend on continuous, low-latency connections: real-time lab result delivery, telehealth video sessions, e-prescribing handshakes, and prior-authorization API calls all break down under sustained availability pressure. A denial-of-service event that would be a nuisance for a retail site can trigger genuine care disruption in a clinical setting — delayed medication orders, inaccessible imaging, or severed remote patient monitoring feeds.
Telecommunications carriers are also named as high-risk targets in the research, and healthcare organizations sit downstream of that exposure. If a telco's infrastructure is degraded, the private circuits and cloud interconnects that hospitals and practices rely on may absorb collateral disruption even if the healthcare endpoints themselves are not the primary target.
What this signals for web infrastructure review
The HTTP/2 bomb technique is a reminder that protocol-level risks are distinct from application-level risks and require different mitigations. Several categories of control are relevant:
- HTTP/2 server configuration hardening. Server software and load balancers typically expose tunable limits on header table size, concurrent streams, and push promise behavior. Default settings are optimized for compatibility, not attack resistance, and should be reviewed against vendor security guidance.
- Rate limiting at the connection and request layer. Controls that throttle connections by source IP or penalize anomalous request patterns can reduce amplification headroom before server resources are exhausted.
- DDoS mitigation services with protocol-aware inspection. General volumetric scrubbing may not catch low-volume amplification attacks; organizations should confirm that their upstream protection understands HTTP/2 traffic at the frame level.
- Availability monitoring with clinical-impact thresholds. Healthcare-specific monitoring should trigger response at latency and error-rate thresholds calibrated to patient-facing service requirements, not generic uptime percentages.
Where independent practices carry unrecognized exposure
Smaller and independent practices rarely operate their own HTTP/2 infrastructure directly, but they are exposed through the vendors that host their patient portals, scheduling systems, and telehealth interfaces. A practice's primary availability risk in this scenario is a hosted platform going down, not its own servers. That shifts the relevant control from internal hardening to vendor risk management: business associate agreements should include availability and incident notification commitments, and practices should ask hosted-platform vendors what protocol-level protections are in place for public-facing endpoints. The answer — or the absence of one — is itself useful information about a vendor's security discipline.