CVE-2026-59903 in Netty
Summary
by MITRE • 08/17/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified within the Netty framework represents a critical flaw in how HTTP caching headers are managed during Cross-Origin Resource Sharing operations, specifically affecting the CorsHandler component. Prior to versions 4.1.137.Final and 4.2.17.Final, the implementation of the setVaryHeader method contained logic that inadvertently overwrote existing Vary header values with a static Origin value rather than appending to or preserving them. This behavior deviates from standard HTTP caching protocols which require servers to indicate all request-header fields that can affect response content in order for caches to make correct decisions about how to serve future requests. By replacing headers such as Authorization and Cookie with only the Origin header, the framework fails to signal to intermediate caching devices like CDNs or reverse proxies that the response is dependent on user-specific authentication credentials.
From a technical perspective, this flaw exploits the assumptions made by HTTP/1.1 compliant caches regarding cache key generation. When a Vary header lists specific fields, caches must store separate versions of the resource for each unique combination of those field values. However, when the server incorrectly sets the Vary header to only include Origin, caching proxies assume that responses are identical across different users as long as they originate from the same domain or origin. Consequently, if an authenticated user requests a protected resource and receives a response with sensitive data, a subsequent request from another unauthenticated user originating from the same site may be served the cached version of the first user's response without re-authentication checks at the application layer. This effectively bypasses access controls enforced by the backend application because the caching infrastructure serves stale or misattributed content based on flawed header directives.
The operational impact of this vulnerability is severe, primarily centering on unauthorized data disclosure and session hijacking scenarios. Attackers can exploit this behavior to retrieve sensitive information belonging to other users, including personally identifiable information, financial records, or private communications, by simply triggering a request that matches the cached parameters. In environments where authentication tokens are stored in cookies or headers, an attacker could potentially access resources intended for privileged accounts if those responses were previously cached and served incorrectly. This undermines the confidentiality integrity of web applications relying on Netty for high-performance network communication, particularly in multi-tenant SaaS platforms or any system handling sensitive user data behind a CDN or reverse proxy layer that respects Vary headers but not application-level session validation for every request.
This issue aligns with CWE-524 which describes the use of cacheable authentication credentials, and falls under MITRE ATT&CK technique T1078 valid accounts where an attacker leverages improperly cached authenticated sessions to gain unauthorized access. To mitigate this risk, organizations must upgrade Netty dependencies immediately to version 4.1.137.Final or later for the legacy branch or 4.2.17.Final and above for newer releases. These updated versions correct the logic within CorsHandler to properly preserve existing Vary headers rather than replacing them, ensuring that caching proxies accurately distinguish between responses intended for different authenticated users. Additionally, developers should audit their infrastructure configurations to ensure that CDNs are configured with appropriate cache-control directives such as no-store or private where sensitive data is involved, providing a defense-in-depth strategy against header-based caching attacks even if framework updates face deployment delays.