CVE-2026-59903: Cache Poisoning and Information Disclosure via CorsHandler Vary Header Overwrite

The affected component is io.netty.handler.codec.http.cors.CorsHandler within the Netty asynchronous, event-driven network application framework. This handler is responsible for configuring and applying Cross-Origin Resource Sharing (CORS) rules to HTTP responses. In vulnerable configurations, this component exposes an attack surface where outgoing HTTP response headers can be modified in an insecure manner.\n\nThe vulnerability belongs to the class CWE-524 (Use of Cache Containing Sensitive Information). Specifically, when processing HTTP responses, the handler replaces any existing application-defined Vary headers with a single Vary: Origin header. This behavior completely overrides critical session-partitioning attributes such as Authorization or Cookie.\n\nAs a consequence, intermediate caching proxies, reverse proxies, and Content Delivery Networks (CDNs) fail to isolate cached content based on user session credentials. This behavior allows attackers to retrieve private, authenticated responses belonging to other users who share the same origin, resulting in potential information disclosure.

The root cause of this vulnerability lies in the implementation of the private setVaryHeader method within the CorsHandler.java source file. This method is executed to automatically append CORS-related headers to outbound HTTP responses to prevent cross-origin cache poisoning.\n\nThe method is implemented using Netty's HttpHeaders API. Specifically, it invokes response.headers().set(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN). Under Netty's API contract, calling set(CharSequence name, Object value) performs two operations: it first removes all existing values associated with the header name, and then sets the header to the single new value.\n\nBy calling .set() instead of an additive function, the handler discards any existing values previously set on the Vary header by upstream handlers or backend applications. If an application developer sets Vary: Authorization, Cookie to enforce cache key segregation based on user identity, this information is wiped out, and the header is rewritten to contain only Origin.

The vulnerable implementation of setVaryHeader in CorsHandler.java uses the destructive .set() method on the HTTP headers collection. This completely replaces existing multi-value headers:\n\njava\n// Vulnerable Implementation\nprivate static void setVaryHeader(final HttpResponse response) {\n response.headers().set(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN);\n}\n\n\nThe patch introduces conditional logic to inspect the current state of the headers map. It verifies whether the value Origin is already present before applying changes, using case-insensitive comparison:\n\njava\n// Patched Implementation\nprivate static void setVaryHeader(final HttpResponse response) {\n if (!response.headers().containsValue(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN, true)) {\n response.headers().add(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN);\n }\n}\n\n\nBy substituting .set() with .add(), the framework preserves all pre-existing entries associated with the Vary header. The resulting HTTP response retains both the application's original attributes (such as Authorization or Cookie) and the necessary Origin attribute, satisfying both CORS requirements and cache partitioning controls.

The exploitation of this vulnerability is passive and relies on the interaction between a vulnerable backend application and a downstream caching mechanism, such as a CDN or a reverse proxy. No specialized payloads are sent to the backend server to trigger execution.\n\nAn attacker first identifies a target endpoint that serves sensitive, user-specific data under active caching policies (e.g., public cache-control headers). If a victim user issues an authenticated request to this endpoint, the backend application generates a response containing the user's private data, accompanied by a Vary: Authorization header to isolate the cache. When the response passes through Netty's CorsHandler, the original Vary values are overwritten with Vary: Origin.\n\nThe caching proxy receives the response and parses Vary: Origin. It caches the response, indexing it solely by the URL and the client's Origin header. When the attacker subsequently sends a request to the same URL using the same origin, the caching proxy serves the cached response belonging to the victim, exposing sensitive data.

The security impact is classified as Medium with a CVSS base score of 6.5. Because the vulnerability is situated in the networking pipeline, it can be triggered remotely without authentication, leading to high confidentiality impacts.\n\nAn attacker exploiting this flaw can systematically harvest sensitive data, personal identifiable information (PII), and session tokens belonging to other users. This is particularly critical in architectures where Netty acts as an API gateway or a reverse proxy serving multiple microservices.\n\nBecause exploitation leaves no abnormal traces in application-level logs (as the traffic is served directly from the CDN or caching proxy cache), detecting active exploitation is difficult and relies on monitoring cache hit ratios or proxy-level logging.

Detecting this vulnerability requires auditing dependencies for affected versions of the netty-codec-http library. System administrators can run dependency analyzer plugins to identify the presence of io.netty:netty-codec-http versions prior to 4.1.137.Final or 4.2.17.Final.\n\nThe primary remediation is upgrading Netty dependencies to versions 4.1.137.Final or 4.2.17.Final. For systems where immediate upgrades are not viable, virtual patching can be implemented at the reverse proxy or CDN tier.\n\nFor example, Nginx can be configured to force cache-key partitioning using custom configuration variables that append authentication parameters to the proxy cache key. Additionally, developers can insert a custom channel handler downstream of CorsHandler in the Netty pipeline to re-insert the missing Vary values.