nghttp2 is a fundamental open-source C library that implements the HTTP/2 protocol. It is widely integrated into critical Internet infrastructure, including web servers (such as Apache and NGINX), content delivery networks (CDNs), load balancers, and application proxies. The library’s ubiquity means that a vulnerability can have a widespread impact on the web.

This vulnerability represents a high risk for any organization managing public-facing services that use the nghttp2 library. A successful exploit allows an unauthenticated remote attacker to trigger a Denial of Service (DoS), causing critical web applications and APIs to crash. The complexity of the attack is low, requiring only the ability to send specially crafted HTTP/2 traffic.

This flaw is a variant of the “HTTP/2 CONTINUATION Flood” attack technique, which has been publicly disclosed and is the subject of active discussion among security researchers. Although no specific public exploit kit has been confirmed, the simplicity of the attack vector indicates a high probability of weaponization and potential exploitation in real-world environments. All Internet-exposed systems using a vulnerable version of the library must be considered at immediate risk.

Technical Summary

The root cause of this vulnerability is classified as CWE-400: Uncontrolled Resource Consumption. It stems from how the nghttp2 library handles incoming HTTP/2 HEADERS frames that exceed the limits configured on the server.

The technical sequence of the attack is as follows:

1. The attacker establishes an HTTP/2 connection with a target server running a vulnerable version of the nghttp2 library.
2. The attacker sends a continuous stream of HEADERS frames, intentionally violating preconfigured flow limits.
3. The library correctly recognizes the violation and prepares to send a 413 Payload Too Large error response. However, to generate this response, it begins buffering the incoming headers, which are excessive.
4. The attacker’s client deliberately avoids reading the server’s response. This keeps the connection open and allows the client to continue sending an unlimited number of headers.
5. The server-side buffer within the nghttp2 library grows without limit as it queues the attacker’s headers, leading to uncontrolled memory allocation.
6. This rapid and continuous memory allocation eventually exhausts all available memory for the server process, causing it to be terminated by the operating system and resulting in a definitive Denial of Service.

Affected versions: All versions of nghttp2 prior to the corrective releases are vulnerable. Consult specific vendor advisories for products that include the library.

Corrective versions: The vulnerability has been resolved in the most recent versions of the nghttp2 library. Administrators must update to the latest secure release provided by their respective upstream vendors.

Recommendations

• Apply the patch immediately: Update all systems using the nghttp2 library to a corrected version. Consult software vendor advisories (e.g., web server providers, operating system distributors) to obtain the appropriate security updates.

• Mitigations:

  • If an immediate update is not possible, consider applying rate-limiting rules at the network perimeter (e.g., WAF, load balancer) to limit the number of new HTTP/2 connections or the rate of incoming data from a single IP address.
  • As a last resort for critical systems, temporarily disabling the HTTP/2 protocol and reverting to HTTP/1.1 can mitigate this specific threat, although it may have performance implications.

• Threat Hunting and Monitoring:

  • Monitor memory usage on web-exposed servers for sudden and unexplained spikes. Correlate these spikes with the server process handling HTTP/2 traffic.
  • Analyze network traffic to identify an abnormally high rate of HTTP/2 HEADERS frames originating from a single IP address without correlated data or stream completion.
  • Check web server or application logs for patterns of connections that are opened but never closed properly.

• Incident Response:

  • If a DoS attack is suspected, immediately implement a temporary block of the involved source IP addresses via the firewall or WAF.
  • Before restarting the crashed service, if possible, acquire a memory dump of the process, as it can be useful for forensic analysis.
  • Retain network packet captures and relevant server logs from the time of the incident for further investigation.

• Defense in Depth:

  • Ensure critical services are configured with automatic restart capabilities (e.g., via systemd or other service managers) to minimize downtime in the event of a crash.
  • Implement resource usage monitoring and alerting systems to provide early warning in the event of memory exhaustion attacks.

[Callforaction-THREAT-Footer]