Summary

  • HTTP/2 Rapid Reset turned an ordinary protocol capability—the rapid creation and cancellation of streams—into a cross-implementation denial-of-service exposure because the work triggered on servers could exceed the attacker’s cost.
  • The public record connects disclosure to coordinated vendor remediation and later HTTP Working Group review, but it does not establish that every deployment received a fix or that the final exposure disappeared.

The central accountability question is not whether the IETF “caused” the attack. The record supports a narrower and more useful question: once a protocol behavior becomes a systemic failure pathway, which institution controls each stage of detection, review, remediation and proof of closure?

A failure hidden inside normal protocol behavior

HTTP/2 was designed to multiplex many request streams over one connection. RFC 9113 defines the stream and frame behavior, including RST_STREAM, the frame used to terminate a stream. The specification predates the public disclosure of CVE-2023-44487, so it describes the relevant protocol surface without describing Rapid Reset or providing its post-disclosure mitigation. The HTTP/2 specification is therefore evidence of the starting condition, not evidence that the later vulnerability was known or resolved.

Rapid Reset exploited the difference between what a client could ask a server to do and what the server had to do before the cancellation took effect. The CVE record and CERT/CC describe a denial-of-service condition affecting HTTP/2 implementations through repeated rapid stream resets. The CVE record identifies CVE-2023-44487. In operational terms, an attacker could create streams, trigger request-processing and stream-management work, then cancel those streams quickly. The active-stream count could remain comparatively low while the server repeatedly paid the cost of starting and abandoning work.

That mechanism mattered because it crossed product boundaries. CVE-2023-44487 was not a defect confined to one vendor’s codebase. The public vulnerability records describe a condition affecting multiple HTTP/2 implementations, while provider and vendor accounts describe different observations and mitigations. The CVE record and vulnerability databases identify the issue; CERT/CC’s coordinated advisory describes the attack and the need for implementation-specific remediation.

Google, Cloudflare and Akamai each explained the pattern in operational language: repeated stream creation and cancellation can produce disproportionate server-side work. Google’s security analysis describes the observed attack mechanism and operational impact. Their telemetry and attack measurements are important but bounded. Google’s observations are from Google’s environment; Cloudflare’s attack sizes and defensive signals come from Cloudflare’s network; Akamai’s controls reflect its edge architecture. Google’s account, Cloudflare’s technical breakdown and Akamai’s analysis show how the mechanism appeared in real services, but they do not measure the prevalence of vulnerable systems across the public Internet.

The distinction is essential. A provider can demonstrate that the attack is practical and severe without being able to say how many unrelated operators remain exposed. Conversely, the absence of a public incident report from an operator does not prove that the implementation was safe. Detection, exposure and public reporting are different propositions.

Disclosure creates a coordination problem, not a single owner

The public record describes coordinated disclosure involving researchers, service providers, CERT/CC and affected vendors. That pathway is a form of institutional repair: a technical behavior is translated into a vulnerability identifier, vendors assess their products, and operators receive guidance. But coordination is not the same as unified control.

The IETF HTTP Working Group controls neither every HTTP/2 implementation nor every network running one. Its authority is concentrated in the technical specification process. Vendors control source code, release branches and product advisories. Distribution maintainers may backport a fix without changing an upstream major version. Operators control which packages, proxies, gateways and application paths they actually run, and whether they impose compensating limits or monitor for attack patterns.

CERT/CC’s guidance makes that separation visible. It recommends vendor updates alongside controls such as limits on concurrent streams, request rates or reset behavior where supported. Those controls can reduce exposure, but a generic limit is not equivalent to a vendor patch. A configuration change may protect one edge path while leaving another HTTP/2 stack, product branch or internally bundled library unchanged. CERT/CC’s advisory supports the distinction between a coordinated response and a universal remedy.

This is where responsibility can become difficult to audit. “The vulnerability was disclosed” says something about awareness. “A patch was released” says something about a vendor’s remediation activity. “The package contains the fix” says something more precise about one distribution and version. “The service is no longer exposed” requires still more: the correct package must be deployed on the relevant path, the protocol must be enabled or disabled as intended, and the controls must behave as expected under load.

Standards review can change the rule without changing every system

After public disclosure, HTTPbis draft and issue material recorded review of Rapid Reset and possible protocol-level responses. That material is useful because it shows the standards process confronting the gap between protocol behavior and operational risk. It can distinguish a proposed normative change from a vendor-specific safeguard and show how technical participants debated the appropriate response.

But a draft is not a final RFC, and an issue comment is not a deployment record. The HTTPbis draft and the working-group issue discussion provide evidence of post-disclosure review and proposed responses; they do not establish that a particular proposal became final normative text, nor that deployed products adopted it.

That boundary is not a weakness in the IETF process. It is its institutional role. The standards process can clarify interoperability requirements, document safer behavior and give implementers a common technical reference. It cannot inspect every running server or compel an operator to install a release. The process is accountable for what it documents and how it handles technical review; implementation and operational actors remain accountable for the systems they control.

The Rapid Reset case therefore tests institutional legitimacy in a practical way. A standards body is credible not because it can claim ownership of the entire Internet, but because its authority is accurately bounded. If a revised specification is presented as proof that the public Internet is repaired, the claim exceeds the evidence. If the specification is treated as one control surface in a chain that includes code, packages, configuration and monitoring, the division of responsibility becomes clearer.

The patch is a product fact, not a deployment fact

Implementation records show why remediation must be checked at several levels. Envoy’s version history identifies fixes and configuration changes relevant to Rapid Reset mitigation. NGINX describes product-specific impact and guidance. Red Hat tracks the CVE across products and can address vulnerabilities through backported patches. Envoy’s release documentation, NGINX’s guidance and Red Hat’s advisory demonstrate that “fixed” is not a single universal state.

For an operator, the relevant question is not simply whether a vendor has announced a patch. It is whether the exact service path uses an affected implementation, which release branch it runs, whether the distribution backported the fix, whether an intermediary terminates HTTP/2, and whether the update reached production. A visible version string may not answer all of those questions. A downstream package can contain a security fix while retaining the upstream version number. An application may bundle its own library. A proxy may be patched while an origin or alternate listener remains exposed.

This creates a chain of evidence:

  1. The vulnerability identifier establishes what issue is being tracked.
  2. The protocol and technical analysis establish how the behavior can create risk.
  3. The vendor or distribution record establishes what release or configuration addresses a product’s exposure.
  4. The operator’s inventory and change record establish whether that release reached the relevant systems.
  5. Testing and telemetry establish whether the intended control works on the live path.

The first three steps can often be documented publicly. The last two usually depend on operator records, independent testing or carefully scoped measurement. A public advisory cannot, by itself, certify the state of an unrelated deployment.

What counts as closure?

The public evidence can support a strong conclusion about the mechanism and the existence of coordinated remediation. It cannot support a universal percentage of remaining vulnerable HTTP/2 systems. Nor can it prove that every patch was installed, every mitigation was configured correctly or every attack path was eliminated.

CISA’s Known Exploited Vulnerabilities catalog is useful for prioritization when a vulnerability is included in the cited snapshot. It supports the conclusion that the issue was treated as exploited in the wild and can trigger remediation obligations for covered federal agencies. It does not measure how much of the public Internet remains vulnerable. The CISA catalog is an operational prioritization record, not a prevalence survey.

A durable closure claim should therefore be narrower than “the Internet was fixed.” It might say that a named product release contains a mitigation, that a specified fleet was upgraded, or that a measurement campaign found no vulnerable behavior under defined conditions. Each claim needs its own evidence. The stronger the scope—one product, one operator, one sector or the whole Internet—the stronger and more independent the evidence must be.

The most useful operational test is a control loop rather than a publication date:

  • identify every HTTP/2 termination point and embedded implementation;
  • map each point to an affected version, backport status or compensating control;
  • deploy the selected fix or restriction;
  • test cancellation and concurrency behavior under controlled conditions;
  • monitor for the traffic pattern and resource exhaustion signal;
  • retain evidence that alternate paths, rollback procedures and future upgrades are covered.

This loop also reveals who can prove what. The IETF can publish and revise technical text. A vendor can document a product fix. A distribution can document package status. An operator can demonstrate deployment and monitoring. An independent assessor can test a defined target. No single record substitutes for the others.

A bounded lesson for Internet governance

Rapid Reset does not show that standards failed, nor that publication is irrelevant. It shows that publication is one stage in a longer repair pathway. The protocol supplied a behavior that implementations had to manage. Attackers demonstrated a damaging sequence. Coordinated disclosure made the risk legible across vendors. The standards community reviewed possible changes. Vendors and distributions produced product-level remedies. Operators still had to decide what ran on their networks and prove that the fix reached the relevant paths.

That division is easy to lose when an institutional label compresses many actors into one subject. The directory entry IETF–W3C is a relationship record, not a claim that one institution operates the Internet or owns every downstream implementation. In this case, the more accurate accountability map follows the mechanism: protocol semantics, working-group review, product release, package maintenance, operator deployment and independent observation.

The unresolved question is not whether the ecosystem responded. The evidence shows that it did. The unresolved question is how broadly and durably the response reached systems outside the organizations that publicly described the attack. Until deployment records and appropriately scoped measurements answer that question, the responsible conclusion remains limited: Rapid Reset was documented, reviewed and mitigated across parts of the ecosystem, but public evidence does not establish universal closure.