CVE-2026-59903: 
Java vulnerability analysis and mitigation

CVE-2026-59903 is a cache poisoning and information disclosure vulnerability in Netty's CorsHandler component, classified as Moderate severity with a CVSS v3.1 base score of 6.5. The flaw affects all Netty versions prior to 4.1.137.Final (4.1.x branch) and versions 4.2.0.Final through 4.2.16.Final (4.2.x branch). It was reported by researcher violetagg, fixed in patches merged on August 4–6, 2026, and publicly disclosed via GitHub Advisory GHSA-8c42-7qj2-3j46 on August 7, 2026 (GitHub Advisory).

The root cause is classified as CWE-524 (Use of Cache Containing Sensitive Information). The vulnerable method io.netty.handler.codec.http.cors.CorsHandler#setVaryHeader uses response.headers().set(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN), which unconditionally replaces all existing Vary headers with Vary: Origin. If a backend application had set Vary: Authorization or Vary: Cookie to instruct caching proxies to differentiate responses per authenticated user, the CorsHandler silently overwrites these, causing CDNs and caching proxies to treat requests from different users as cache-equivalent. The fix modifies the handler to only set the Vary: Origin header if no Vary header already exists (GitHub Advisory, Netty PR #17213).

An unauthenticated attacker positioned to make requests through a shared caching proxy or CDN can receive cached HTTP responses originally intended for authenticated users, potentially exposing session tokens, authorization credentials, or other user-specific sensitive data. The vulnerability impacts confidentiality (rated High) and has a minor integrity impact (rated Low), with no availability impact. Only applications that use CorsHandler, set their own Vary headers for cache isolation, and are deployed behind a caching layer are affected (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires high attack complexity — specifically, the attacker must be able to make requests through the same caching proxy or CDN that serves the target application, and the application must be configured in a way that triggers the vulnerable code path (GitHub Advisory).

1. Reconnaissance: Identify a Netty-based web application using CorsHandler that is deployed behind a shared CDN or caching proxy, and that sets Vary: Authorization or Vary: Cookie headers to manage per-user cache isolation.
2. Trigger authenticated response caching: Observe or induce an authenticated user to make a request to a sensitive endpoint (e.g., a user profile or data API endpoint). Due to the bug, the response is cached by the proxy with only Vary: Origin — not Vary: Authorization or Vary: Cookie.
3. Replay request as unauthenticated user: Send an identical request (same URL and Origin header) from an unauthenticated or different-user context to the same caching proxy.
4. Receive cached authenticated response: The caching proxy serves the previously cached authenticated response to the attacker, disclosing sensitive user data such as session tokens, personal information, or authorization-gated content (GitHub Advisory).

• Network: Repeated requests to sensitive API endpoints from different source IPs or unauthenticated sessions receiving 200 OK responses with Age: headers greater than 0, indicating a cached hit; responses containing Vary: Origin only (missing Vary: Authorization or Vary: Cookie) on endpoints that should vary per user.
• Logs: CDN or proxy access logs showing cache HITs (X-Cache: HIT) for authenticated resource endpoints served to unauthenticated or different-user requests; application logs showing CORS-related header manipulation on sensitive routes.
• HTTP Headers: Responses from affected endpoints containing only Vary: Origin instead of the expected Vary: Authorization, Origin or Vary: Cookie, Origin combination.

Upgrade Netty to version 4.1.137.Final (for 4.1.x users) or 4.2.17.Final (for 4.2.x users), which fix the issue by only setting Vary: Origin if no Vary header is already present (Netty 4.1.137.Final Release, Netty 4.2.17.Final Release). As a short-term workaround prior to upgrading, configure your CDN or caching proxy to not cache responses from endpoints that require authentication, or add Cache-Control: no-store, private headers at the application or proxy layer for authenticated routes. Additionally, review all caching policies for Netty-based applications to ensure proper cache isolation between authenticated and unauthenticated responses (GitHub Advisory).