CVE-2026-27205

What it actually does

Flask versions 3.1.2 and below can fail to add the `Vary: Cookie` response header when application code accesses the session only through certain key-check patterns, such as using the Python `in` operator. `Vary: Cookie` tells shared caches that responses differ based on the requester’s Cookie header. Without it, a reverse proxy, CDN, or other shared cache may incorrectly reuse a response generated for one user and serve it to another user. The flaw does not directly allow code execution, authentication bypass, or data modification; its impact is limited to potential disclosure of user-specific response content under specific caching and application-code conditions.

Why it matters to the business

The primary risk is accidental exposure of logged-in or user-specific pages to the wrong person when Flask applications are deployed behind shared caching infrastructure. This can expose personal data, account details, internal workflow information, or other sensitive page content, potentially causing privacy incidents, regulatory reporting obligations, customer trust loss, and operational cleanup. Risk is conditional: exploitation generally requires affected Flask versions, session access patterns that trigger the bug, cacheable authenticated responses, and a cache that does not already avoid storing responses associated with cookies. The issue is not in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS likelihood, and has no public exploit maturity noted, but Flask’s broad ecosystem use makes configuration review important for internet-facing applications.

How an attack unfolds

An attacker identifies a Flask application behind a shared cache such as a CDN, reverse proxy, or caching gateway. The vulnerable route must access the Flask session in a way that does not cause Flask to emit `Vary: Cookie`, for example by checking whether a session key exists without reading or modifying the session value. If the route returns user-specific content and does not set protective cache directives such as `Cache-Control: private` or `no-store`, the shared cache may store the response without associating it with the original user’s cookie. The attacker then requests the same URL, potentially after a victim has visited it, and receives a cached copy of the victim-specific response. Successful exploitation depends heavily on cache behavior, route design, and whether authenticated responses are otherwise marked non-cacheable.

How to fix it

Upgrade Flask to version 3.1.3 or later. For source-based deployments using the Pallets Flask Git repository, ensure the code includes commit `22d924701a6ae2e4cd01e9a15bbaf3946094af65` or a later fixed revision. As defense in depth, configure authenticated and user-specific responses to include explicit cache controls such as `Cache-Control: private, no-store` or `Cache-Control: no-cache, private` as appropriate for the application. Review CDN, reverse proxy, and application gateway rules to ensure responses containing session cookies or personalized content are not stored in shared caches unless explicitly designed to be safely varied. Where caching is required, ensure cache keys include relevant cookie or authorization context and that `Vary: Cookie` is preserved end to end. Avoid relying solely on framework defaults for sensitive pages; set route-level or middleware-level cache policies for logged-in content.

How to confirm the fix worked

Confirm the deployed Flask version is 3.1.3 or later, or that the Flask source includes fixed commit `22d924701a6ae2e4cd01e9a15bbaf3946094af65`. Exercise routes that access `session` using key-existence checks such as `'key' in session` and verify responses include `Vary: Cookie` when session state is accessed. For authenticated or personalized routes, verify response headers include appropriate cache protection, such as `Cache-Control: private`, `no-store`, or equivalent organization-approved directives. Test through the full production-like path, including CDN and reverse proxy layers, because intermediaries may add, remove, or normalize headers. Use two separate sessions against the same URL and verify that a response generated for one session is not served from cache to the other. Inspect cache debug headers such as `X-Cache`, `CF-Cache-Status`, `Age`, or vendor-specific equivalents to ensure user-specific responses are not shared-cache hits across different cookies.

Typical attack path

1. Reconnoiter a Flask-based web application deployed behind a CDN, reverse proxy, or shared HTTP cache.
2. Identify authenticated or personalized routes that are cacheable and do not consistently return `Vary: Cookie`.
3. Wait for or induce an authenticated user to request the affected route so the shared cache stores a personalized response.
4. Request the same URL without the same session context or with a different session cookie.
5. Receive a cached response that may contain content intended for the authenticated user.
6. Extract exposed user-specific data from the cached page or API response.

How to detect it

Investigate CDN, reverse proxy, web server, and application access logs for evidence that authenticated or personalized Flask responses were served from a shared cache. Focus on routes that require login, read session state, or render user-specific content. Look for cache-hit indicators on requests carrying `Cookie` headers, responses that also set or depend on session cookies, and responses lacking `Vary: Cookie` or protective `Cache-Control` headers. Compare cache keys, URLs, response sizes, ETags, request IDs, and timestamps to identify the same cached object being served to different Cookie values, users, source IPs, or authorization contexts. Review application logs around session-dependent routes that use key-existence checks, and correlate with CDN/proxy logs showing `HIT` responses. If available, inspect cache metadata for objects stored from authenticated requests. There are no known attacker-specific payloads or malware artifacts for this issue; detection is primarily based on unsafe cache behavior and possible cross-user response reuse.

• X-Cache: HIT
• X-Cache: Hit from cloudfront
• CF-Cache-Status: HIT
• Fastly-Cache: HIT
• X-Cache-Hits: 1
• Age:
• Cache-Control: public
• s-maxage=
• Surrogate-Control:
• Set-Cookie: session=
• Cookie: session=
• Vary: Cookie

What your security team should do

• Inventory Flask applications and prioritize externally reachable applications behind CDNs, reverse proxies, API gateways, or shared HTTP caches.
• Upgrade affected Flask deployments to 3.1.3 or later, or confirm inclusion of fixed commit `22d924701a6ae2e4cd01e9a15bbaf3946094af65`.
• Audit authenticated and personalized routes for explicit `Cache-Control` protections and ensure sensitive responses are not publicly cacheable.
• Validate that `Vary: Cookie` is present when Flask session state is accessed and that the header is preserved by all intermediary infrastructure.
• Review CDN and reverse proxy caching rules for unsafe overrides that cache responses with `Set-Cookie`, `Cookie`, or authenticated content.
• Search historical CDN, proxy, and application logs for shared-cache hits on authenticated routes and for the same cached object served to requests with different Cookie headers.
• Because current exploitation indicators are low and the issue is not KEV-listed, prioritize remediation based on exposure: internet-facing, cached, authenticated applications first.