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:

python

                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

bash

# 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;
}