CVE-2025-47278: Flask Authentication Bypass Vulnerability

CVE-2025-47278 Overview

CVE-2025-47278 is a cryptographic vulnerability in Flask 3.1.0, the popular Python WSGI web application framework. The vulnerability affects how fallback key configuration is handled during session signing operations. Due to incorrect list construction order, Flask was passing the signing key first rather than last to the itsdangerous library, resulting in sessions being signed with stale fallback keys instead of the current signing key.

Critical Impact

Sites using key rotation via SECRET_KEY_FALLBACKS are unexpectedly signing sessions with stale keys, impeding secure key transition workflows.

Affected Products

• Flask 3.1.0
• Applications using SECRET_KEY_FALLBACKS for key rotation
• Web applications relying on Flask session signing with itsdangerous

Discovery Timeline

• 2025-05-13 - CVE-2025-47278 published to NVD
• 2025-05-13 - Last updated in NVD database

Technical Details for CVE-2025-47278

Vulnerability Analysis

This vulnerability is classified under CWE-683 (Function Call With Incorrect Order of Arguments). The itsdangerous library, which Flask uses for cryptographic signing operations, expects a list of keys with the most recent (current) signing key positioned last in the list. However, Flask 3.1.0 was incorrectly constructing this list in reverse order, placing the signing key first instead of last.

When SECRET_KEY_FALLBACKS is configured for key rotation, the framework should use the current SECRET_KEY for signing new sessions while allowing older fallback keys to verify existing sessions during the rotation period. Due to the incorrect ordering, Flask was selecting the last fallback key (the oldest) for signing operations instead of the current key.

Root Cause

The root cause lies in how Flask constructed the key list for the itsdangerous signer. The library expects keys ordered from oldest to newest, with the signing key at the end of the list. Flask 3.1.0 passed this list in reverse order, causing itsdangerous to use the wrong key for signing operations. This is a classic function argument order error that affects the cryptographic key selection logic.

Attack Vector

This vulnerability has a local attack vector requiring high privileges to exploit. The issue primarily affects operational security rather than enabling direct attacks. An attacker would need to:

1. Identify that the target application uses Flask 3.1.0 with key rotation enabled
2. Understand that sessions are being signed with stale keys
3. Potentially leverage knowledge of older, potentially compromised keys to forge session tokens if those keys were previously exposed

While sessions remain cryptographically signed (no data integrity loss occurs), the security posture is weakened because the expected key rotation benefits are not realized.

// Patch from CHANGES.rst showing the fix
 
Unreleased
 
+   Fix signing key selection order when key rotation is enabled via
+    ``SECRET_KEY_FALLBACKS``. :ghsa:`4grg-w6v8-c28g`
-   Fix type hint for `cli_runner.invoke`. :issue:`5645`
-   ``flask --help`` loads the app and plugins first to make sure all commands
     are shown. :issue:5673`

Source: GitHub Commit Details

The documentation was also updated to clarify the expected key ordering:

// Documentation patch in docs/config.rst
 
.. py:data:: SECRET_KEY_FALLBACKS
 
-    A list of old secret keys that can still be used for unsigning, most recent
-    first. This allows a project to implement key rotation without invalidating
-    active sessions or other recently-signed secrets.
+    A list of old secret keys that can still be used for unsigning. This allows
+    a project to implement key rotation without invalidating active sessions or
+    other recently-signed secrets.
 
    Keys should be removed after an appropriate period of time, as checking each
    additional key adds some overhead.
 
+    Order should not matter, but the default implementation will test the last
+    key in the list first, so it might make sense to order oldest to newest.
+
    Flask's built-in secure cookie session supports this. Extensions that use
    :data:`SECRET_KEY` may not support this yet.

Source: GitHub Commit Details

Detection Methods for CVE-2025-47278

Indicators of Compromise

• Flask applications running version 3.1.0 with SECRET_KEY_FALLBACKS configured
• Session cookies being signed with keys other than the current SECRET_KEY
• Key rotation procedures not taking effect as expected
• Older fallback keys remaining valid longer than intended

Detection Strategies

• Audit Flask application configurations for SECRET_KEY_FALLBACKS usage
• Review application dependencies and verify Flask version is not 3.1.0
• Implement session token analysis to verify which key is being used for signing
• Use dependency scanning tools to flag vulnerable Flask versions

Monitoring Recommendations

• Monitor for Flask version 3.1.0 across your application inventory
• Track session signing behavior during key rotation events
• Set up alerts for applications using SECRET_KEY_FALLBACKS configuration
• Review cryptographic key management procedures for affected applications

How to Mitigate CVE-2025-47278

Immediate Actions Required

• Upgrade Flask to version 3.1.1 or later immediately
• Review SECRET_KEY_FALLBACKS configuration in affected applications
• Consider rotating secret keys again after upgrading to ensure proper key usage
• Audit session management to verify correct signing key is in use post-upgrade

Patch Information

Flask version 3.1.1 contains the fix for this vulnerability. The patch corrects the key list construction order so that itsdangerous receives keys in the expected order with the current signing key positioned last. For detailed patch information, see the GitHub Security Advisory GHSA-4grg-w6v8-c28g and the Flask 3.1.1 Release.

Workarounds

• If unable to upgrade immediately, temporarily disable key rotation by removing SECRET_KEY_FALLBACKS configuration
• Ensure only the current SECRET_KEY is configured until upgrade is possible
• Monitor session signing behavior manually to detect anomalies
• Consider implementing application-level validation of session signing keys

# Configuration example - Upgrade Flask to patched version
pip install --upgrade flask>=3.1.1

# Verify installed version
pip show flask | grep Version