Flask, a popular Python WSGI web application framework, had a vulnerability identified as CVE-2026-27205 affecting versions up to 3.1.2. The vulnerability is classified under CWE-524, which concerns the use of caches containing sensitive information. When Flask's session object is accessed, it is supposed to set the HTTP 'Vary: Cookie' header to instruct caching proxies not to cache user-specific responses. This prevents sensitive session data from being stored in shared caches. However, the flaw lies in the fact that certain access methods to the session object, such as using the Python 'in' operator to check for keys without reading or modifying session values, do not trigger the setting of this header. Consequently, if the application is deployed behind a caching proxy that does not ignore responses with cookies and the application itself does not set appropriate Cache-Control headers (like 'private' or 'no-store'), sensitive session data could be cached and potentially served to other users. The risk is environment-dependent and requires specific caching configurations to be exploitable. The vulnerability was addressed in Flask version 3.1.3 by ensuring all session access patterns correctly set the 'Vary: Cookie' header, preventing sensitive information from being cached improperly. There are no known exploits in the wild, and the CVSS 4.0 base score is 2.3, reflecting low severity due to the limited scope and complexity of exploitation.

The primary impact of this vulnerability is the potential unintended caching of sensitive session information by intermediary caching proxies or CDNs, which could lead to information disclosure between users. This can compromise confidentiality by exposing session-specific data such as authentication tokens or user preferences. However, the impact is limited because exploitation requires a specific deployment scenario: the presence of caching proxies that do not respect cookie headers, absence of explicit Cache-Control headers marking responses as private or non-cacheable, and particular session access patterns in the application code. There is no direct impact on integrity or availability. Organizations using Flask versions prior to 3.1.3 and deploying behind caching proxies without proper cache control are at risk. The vulnerability could lead to privacy breaches and undermine user trust, especially in applications handling sensitive or personal data. Since no known exploits exist, the immediate risk is low, but the vulnerability should be addressed to prevent future exploitation.

To mitigate this vulnerability, organizations should upgrade Flask to version 3.1.3 or later, where the issue is fixed. Additionally, developers should audit their code to ensure that all session access patterns trigger appropriate cache-control headers. Application deployments should be reviewed to confirm that caching proxies or CDNs are configured to respect 'Vary: Cookie' headers and do not cache responses containing cookies. Explicitly setting Cache-Control headers such as 'private', 'no-store', or 'no-cache' on responses that include session data can further prevent caching of sensitive information. Security teams should verify that no caching occurs on authenticated or user-specific pages. Implementing security testing to detect caching of sensitive content and monitoring for unusual cache behavior can help identify misconfigurations. Finally, educating developers about secure session handling and cache control best practices will reduce the risk of similar issues.