CVE-2026-27205: Flask Information Disclosure Vulnerability

CVE-2026-27205 Overview

Flask, a popular web server gateway interface (WSGI) web application framework, contains a vulnerability in its session handling mechanism. In versions 3.1.2 and below, when the session object is accessed using certain operations like the Python in operator, Flask fails to set the Vary: Cookie header properly, resulting in a Use of Cache Containing Sensitive Information vulnerability (CWE-524). This logic flaw instructs caches not to cache the response appropriately, potentially exposing information specific to logged-in users.

Critical Impact

Applications hosted behind caching proxies that don't ignore responses with cookies may inadvertently cache and serve session-specific content to unauthorized users, leading to potential information disclosure between user sessions.

Affected Products

• Palletsprojects Flask versions 3.1.2 and below

Discovery Timeline

• 2026-02-21 - CVE CVE-2026-27205 published to NVD
• 2026-02-24 - Last updated in NVD database

Technical Details for CVE-2026-27205

Vulnerability Analysis

The vulnerability exists in Flask's session access tracking mechanism. When a session is accessed, Flask is designed to set the Vary: Cookie header to prevent caching proxies from caching user-specific responses. However, certain forms of session access were overlooked in the implementation. Specifically, operations that only access session keys without reading values or mutating the session—such as using the Python in operator or len() function—did not trigger the session as "accessed," thereby failing to set the appropriate cache control headers.

The severity depends on a specific combination of factors: the application must be hosted behind a caching proxy that doesn't automatically ignore responses containing cookies, the application must not set its own Cache-Control header to mark pages as private or non-cacheable, and the session must be accessed in a way that only touches keys without reading values.

Root Cause

The root cause lies in incomplete session access tracking within Flask's session interface implementation. The session object's special methods for key-only operations (__contains__ for in operator, __len__ for length checks) were not marking the session as accessed. This oversight meant that the framework's automatic cache header injection logic was bypassed when developers used these common Pythonic patterns to check session state.

Attack Vector

An attacker could exploit this vulnerability by targeting applications where session membership checks occur without value reads. In a caching proxy environment, the first user's response could be cached and subsequently served to other users. This network-based attack requires user interaction (visiting a cached page) and specific environmental conditions to be exploitable.

The patch addresses this by ensuring the session is marked as accessed for operations that only access the keys but not the values. Below is the security patch applied to src/flask/app.py:

                for func in reversed(self.after_request_funcs[name]):
                    response = self.ensure_sync(func)(response)

-        if not self.session_interface.is_null_session(ctx.session):
-            self.session_interface.save_session(self, ctx.session, response)
+        if not self.session_interface.is_null_session(ctx._session):
+            self.session_interface.save_session(self, ctx._session, response)

        return response

Source: GitHub Commit Reference

Detection Methods for CVE-2026-27205

Indicators of Compromise

• HTTP responses lacking Vary: Cookie headers when session-dependent content is served
• Caching proxy logs showing cached responses for authenticated endpoints
• User reports of seeing other users' session-specific content
• Inconsistent application behavior when accessing session-protected resources

Detection Strategies

• Review application code for session access patterns using in operator or len() on session objects without subsequent value reads
• Audit HTTP response headers for missing Vary: Cookie on session-dependent endpoints
• Monitor caching proxy hit rates for authenticated endpoints that should not be cached
• Implement automated testing to verify proper cache headers are set when session is accessed

Monitoring Recommendations

• Configure application performance monitoring to alert on missing cache control headers for authenticated routes
• Set up caching proxy monitoring to detect unexpected cache hits on user-specific content
• Enable Flask debug logging during security audits to trace session access patterns
• Implement periodic security scans to identify endpoints with improper cache behavior

How to Mitigate CVE-2026-27205

Immediate Actions Required

• Upgrade Flask to version 3.1.3 or later immediately
• Review and audit application code for session access patterns using key-only operations
• Implement explicit Cache-Control: private or Cache-Control: no-store headers on all session-dependent endpoints as defense in depth
• Configure caching proxies to never cache responses containing Set-Cookie headers

Patch Information

The issue has been fixed in Flask version 3.1.3. The patch ensures that the session is marked as accessed for operations that only access the keys but not the values, such as in and len. Upgrade immediately by updating your dependency to flask>=3.1.3. For detailed information, see the GitHub Security Advisory GHSA-68rp-wp8r-4726 and the GitHub Release 3.1.3.

Workarounds

• Explicitly set Cache-Control headers on all routes that access the session to prevent caching
• Configure upstream caching proxies to bypass caching for responses containing session cookies
• Modify session access patterns to include a value read operation alongside key checks
• Implement middleware to automatically inject Vary: Cookie headers on all authenticated endpoints

# Configuration example for nginx to bypass caching on cookie-containing responses
# Add to your nginx proxy configuration

location / {
    proxy_pass http://flask_app;
    proxy_cache_bypass $http_cookie;
    proxy_no_cache $http_cookie;
    add_header Cache-Control "private, no-store" always;
}