Description

Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, io.netty.handler.codec.http.cors.CorsHandler setVaryHeader replaces application Vary headers such as Authorization or Cookie with Origin, allowing a caching proxy or CDN to reuse authenticated responses across users and disclose sensitive information. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-17T18:17:36.250Z",
  "pubdate": "2026-08-17T18:17:36.250Z",
  "executiveSummary": "An improper header management vulnerability exists within the io.netty.handler.codec.http.cors.CorsHandler component of the Netty asynchronous event-driven network application framework. The flaw specifically resides in the setVaryHeader implementation, which unconditionally replaces critical application-provided Vary headers such as Authorization or Cookie with solely the Origin header.\nThis improper handling of HTTP caching mechanics introduces severe security implications, notably facilitating cache poisoning and cross-user information disclosure. When applications utilizing vulnerable Netty versions are deployed behind upstream caching proxies, content delivery networks (CDNs), or intermediary load balancers, the compromised Vary header instructs these caches to disregard user-specific context when storing and serving responses.\nConsequently, authenticated or session-sensitive responses generated for one user can be improperly cached and subsequently served to unauthorized third-party users who supply a matching Origin header. The attack capability relies on inducing victims or intermediaries to process requests in a specific sequence, allowing unauthenticated attackers to harvest sensitive data or session tokens cached under shared response keys. The vulnerability affects Netty versions prior to 4.1.137.Final and 4.2.17.Final, necessitating immediate library upgrades to remediate the caching logic flaw.",
  "technicalDetails": "The vulnerability is rooted in the HTTP response header generation logic executed by the io.netty.handler.codec.http.cors.CorsHandler class, specifically within its internal mechanics responsible for managing the HTTP Vary header via the setVaryHeader function.\nIn HTTP protocol semantics, the Vary header dictates whether a cache can use a stored response to reply to a subsequent request without revalidation. Properly configured applications utilize Vary headers containing multiple directive tokens—such as Vary: Origin, Authorization, Cookie—to ensure that responses varying based on user authentication state or session identifiers are cached distinctly.\nIn vulnerable versions of Netty (prior to 4.1.137.Final and 4.2.17.Final), the setVaryHeader routine overwrites any pre-existing Vary header fields set by upstream application logic rather than appending or merging the Origin directive. By substituting application-defined security-critical headers with strictly Origin, the resulting HTTP response instructs intermediate caching infrastructure (CDNs, reverse proxies) to key cached responses solely on the Origin request header.\nThe attack flow proceeds as follows: First, an authenticated victim user issues an HTTP request to the vulnerable Netty-based server containing sensitive session credentials (e.g., Cookie or Authorization headers). The server processes the authenticated request and returns a sensitive response. The CorsHandler then applies the flawed setVaryHeader transformation, outputting a Vary: Origin response header. Upstream caching proxies intercept this response and store it mapped exclusively to the provided Origin value, completely ignoring the user-specific Authorization or Cookie context present during generation.\nSecond, an attacker or another unauthenticated user issues a subsequent request to the same endpoint providing the identical Origin header value. Because the intermediary caching proxy evaluates only the Origin header against its cache store due to the overwritten Vary directive, it retrieves and returns the previously cached authenticated response belonging to the victim.\nThis network-exposed vulnerability requires no prior authentication or elevated privileges for an external attacker to induce cache pollution, provided they can trigger requests that align with cached origin keys. The post-exploitation impact includes unauthorized cross-user data disclosure, potential session hijacking via leaked tokens, and compromise of confidentiality across multi-tenant or shared caching architectures."
}