Description

When a server is configured to support unencrypted HTTP/2, it reads a few bytes from each new connection to see if they contain the HTTP/2 client preface. ReadHeaderTimeout is unexpectedly not being applied when doing this.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-13T22:17:22.093Z",
  "pubdate": "2026-08-13T22:17:22.093Z",
  "executiveSummary": "This vulnerability involves a failure to apply the ReadHeaderTimeout mechanism when a server is configured to support unencrypted HTTP/2 connections.\nThe vulnerability type is a timeout enforcement bypass, which impacts server availability and resource management across affected systems and products that process unencrypted HTTP/2.\nThe risk implications include susceptibility to resource exhaustion attacks, specifically denial of service conditions through slowloris-style connection holding.\nAttacker capabilities involve the ability to initiate network connections and send partial or delayed byte sequences without triggering configured timeout protections.\nExploitation requirements are limited to network exposure where unencrypted HTTP/2 is enabled and supported by the server configuration.",
  "technicalDetails": "The root cause of the vulnerability stems from the initialization logic for new network connections when unencrypted HTTP/2 is enabled. Specifically, the server reads an initial sequence of bytes from each incoming connection to inspect for the presence of the HTTP/2 client preface.\nDuring this initial inspection phase, the configured ReadHeaderTimeout is unexpectedly bypassed and not enforced.\nThe vulnerable component is the connection handling and timeout enforcement logic responsible for managing early-stage connection byte reads.\nNetwork exposure is present wherever servers are configured to accept unencrypted HTTP/2 traffic.\nAuthentication requirements and privilege requirements are none, as unauthenticated remote attackers can initiate raw TCP connections to the listening service.\nThe step-by-step attack flow begins when an attacker establishes a new TCP connection to the target server supporting unencrypted HTTP/2.\nInstead of completing the handshake or sending a valid HTTP/2 client preface followed by standard requests, the attacker sends data slowly, incompletely, or pauses entirely after initiating the connection.\nBecause the server reads the initial bytes to check for the HTTP/2 client preface without enforcing ReadHeaderTimeout, the connection remains open indefinitely while waiting for the remaining expected bytes or headers.\nAn attacker can scale this behavior by opening numerous concurrent connections, exhausting the server maximum connection limit or thread pool.\nThe post-exploitation impact results in a denial of service (DoS) condition, preventing legitimate users from establishing new connections or interacting with the application due to resource exhaustion."
}