A class of denial-of-service exploits targeting the HTTP/2 protocol is drawing attention for its ability to generate outsized disruption from relatively small attack payloads — a technique being called the "HTTP/2 bomb." Healthcare organizations, which depend heavily on always-available web infrastructure for patient scheduling, clinical workflows, and telehealth delivery, are among the sectors researchers have flagged as particularly exposed.

How the exploit works

HTTP/2 introduced two features intended to reduce bandwidth consumption across high-traffic networks: header compression and server push. Both were designed to improve efficiency for legitimate traffic. Attackers have identified ways to turn those same mechanisms against the servers that implement them.

By crafting requests that trigger disproportionate processing or memory expansion on the receiving server, an attacker can exhaust server resources without sending the volume of traffic traditionally associated with a distributed denial-of-service campaign. The amplification effect is the operative concern: the ratio of attacker effort to defender impact is large enough to make these attacks accessible to threat actors without substantial infrastructure.

The technique does not require exploiting an implementation bug in a specific vendor's software. It targets behaviors that are part of the HTTP/2 specification itself, which means any server or load balancer that correctly implements the standard may be susceptible.

Why healthcare is specifically named

Healthcare's exposure is structural. Patient-facing portals, electronic health record interfaces, laboratory result delivery, and telehealth platforms all run over HTTP/2-capable infrastructure. Availability is a clinical dependency, not just a business-continuity preference — a portal that goes offline during peak hours delays prescription refills, lab communications, and appointment access.

Telecom carriers are also named in the research, and that overlap matters for healthcare: many organizations route clinical traffic and medical device telemetry through carrier-managed networks that share the same protocol stack. A successful amplification attack against a carrier's HTTP/2 endpoints could create downstream availability failures for healthcare clients who never saw themselves as the primary target.

Smaller independent practices are not insulated. If a practice relies on a cloud-hosted EHR or a third-party patient engagement platform, availability depends on that vendor's infrastructure controls, not the practice's own.

What this signals for infrastructure review

The disclosure follows a pattern in which protocol-level vulnerabilities — rather than application-layer code flaws — create broad horizontal exposure across industries simultaneously. Healthcare IT and compliance teams should treat this as a prompt to ask specific questions of their hosting providers and SaaS vendors rather than assuming the risk has been mitigated.

Relevant questions include whether HTTP/2 server push is enabled and whether it is operationally necessary, whether rate-limiting and request-size controls are applied at the network edge, and whether the organization's uptime service agreements address denial-of-service scenarios specifically.

Organizations running their own web-facing infrastructure — including on-premises patient portals or self-hosted scheduling systems — should confirm with their network operations contacts that HTTP/2 amplification mitigations have been evaluated and, where applicable, applied. NIST guidance on availability controls under the HIPAA Security Rule's technical safeguard requirements applies here: the rule's addressable specification for audit controls and integrity protections does not displace the broader obligation to protect system availability as a covered function.

Where independent practices should focus

For practices that do not manage their own servers, the most direct action is vendor inquiry. A written response from a SaaS vendor documenting its mitigation approach creates a record relevant to business associate risk management and is consistent with the Security Rule's requirement that covered entities evaluate the adequacy of safeguards their business associates maintain.

Practices that have not recently reviewed their contingency plans — specifically the portions addressing system unavailability — should check whether those plans account for extended outages of externally hosted systems. A portal or EHR that is unavailable for hours because of a sustained denial-of-service attack against a vendor's infrastructure is functionally equivalent to any other unplanned outage; the response procedures should be the same.