A class of denial-of-service attacks built around HTTP/2 protocol features is drawing fresh attention from security researchers, with healthcare organizations named alongside telecommunications providers as high-value targets. The technique, dubbed HTTP/2 bomb attacks, turns protocol-level compression and multiplexing features against the very infrastructure they were designed to protect, generating outsized disruption from a relatively small volume of malicious traffic.

The structural problem

HTTP/2 was developed to improve web performance by reducing bandwidth consumption. Two specific features — header compression (HPACK) and stream multiplexing — allow clients and servers to exchange data more efficiently than the older HTTP/1.1 standard. In the attack scenario described by Dark Reading, those same features become amplification mechanisms: a compact malicious request expands dramatically on the receiving server, consuming CPU and memory resources far beyond what the raw packet size would suggest.

The amplification effect is what makes this class of attack distinct from volumetric floods. Attackers do not need to generate gigabits of traffic to overwhelm a target. A modest stream of specially crafted HTTP/2 frames can produce a disproportionate processing burden, making it harder for organizations to detect or filter the attack based on traffic volume alone.

Why healthcare is a named target

Healthcare organizations present a particular combination of conditions that elevate their exposure. Patient portals, telehealth platforms, electronic health record web interfaces, and clinical API endpoints are increasingly HTTP/2-enabled, because the protocol's performance gains align with the sector's push toward real-time data exchange and mobile-friendly applications. Many of these endpoints are also time-sensitive: a portal that becomes unavailable during a patient intake window or a clinical API that drops connections mid-transaction creates operational and safety consequences beyond simple IT inconvenience.

Independent and community practices that rely on cloud-hosted EHR and scheduling systems are also exposed indirectly. If a vendor's shared infrastructure absorbs one of these attacks, every practice on that platform may experience degraded service simultaneously, with little visibility into the cause or timeline for recovery.

What this signals about protocol-level risk

The HTTP/2 bomb technique illustrates a recurring pattern in healthcare security: the attack surface expands not only through new software vulnerabilities but through the adoption of modern protocol standards that were engineered for efficiency rather than adversarial conditions. As healthcare technology stacks adopt newer transport and application-layer protocols — HTTP/2 is already giving way to HTTP/3 in some environments — the security implications of each protocol's design choices follow.

Defenders have a limited set of options at the network edge. Rate-limiting HTTP/2 streams, enforcing header size caps, and deploying application-layer inspection capable of parsing HTTP/2 frame structures are among the controls that can reduce exposure. Web application firewalls and content delivery configurations that do not account for HTTP/2-specific frame behavior may not provide meaningful protection against this technique even when they would catch equivalent HTTP/1.1 attacks.

Where independent practices should focus

For practice administrators and compliance officers, the near-term priority is understanding which patient-facing and clinical systems accept HTTP/2 connections, and whether the hosting or managed-service agreements for those systems include specific denial-of-service mitigation provisions. Contracts and business associate agreements that predate widespread HTTP/2 adoption may be silent on protocol-specific attack scenarios.

Practices should also confirm that their incident response plans address service availability events that are not the result of data exfiltration or ransomware. A portal outage caused by a DoS attack may not trigger a HIPAA breach notification obligation, but it can still constitute a security incident under the HIPAA Security Rule, requiring documentation and a workforce response. Availability is a defined component of the confidentiality, integrity, and availability triad that the Security Rule's technical safeguard standards are built around.