CVE-2025-47278

What it actually does

Flask 3.1.0 incorrectly orders the key list passed to itsdangerous when SECRET_KEY_FALLBACKS is configured for session signing key rotation. Instead of using the newest/current SECRET_KEY for newly signed session cookies, Flask may sign new sessions with the last fallback key, which is intended to be an older key used only for verification during rotation. Existing and new sessions remain cryptographically signed, so this is not a direct unsigned-cookie or arbitrary tampering vulnerability; the main technical impact is failed or delayed key rotation and continued dependence on a stale signing key. Risk is meaningful primarily for applications that enabled SECRET_KEY_FALLBACKS, especially if an older key was exposed or was intended to be retired.

Why it matters to the business

Affected applications may believe they have rotated session-signing secrets when they are actually continuing to use an older key, extending the operational risk window if that older key is weak, mishandled, or previously exposed. This can undermine incident response plans, delay safe retirement of compromised secrets, and cause avoidable session management disruption during key-rotation projects. The issue is not in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS likelihood, and has no known public exploit maturity, so it should generally be prioritized as a hygiene and cryptographic correctness fix rather than an emergency internet-wide exploitation event.

How an attack unfolds

An attacker cannot typically exploit this flaw remotely by sending a crafted request alone. The vulnerable condition exists when a Flask 3.1.0 application has opted into session key rotation using SECRET_KEY_FALLBACKS. In that state, Flask signs newly issued session cookies with a stale fallback key instead of the intended current key. If an attacker already has privileged local access, access to application configuration, or prior knowledge of an old session-signing key, the bug may extend the usefulness of that old key because the application continues to rely on it for newly signed sessions. Without prior compromise or access to signing secrets, the flaw does not provide a practical path to forge sessions or bypass authentication.

How to fix it

Upgrade Flask from 3.1.0 to Flask 3.1.1 or later. For source-based deployments, ensure the fix corresponding to pallets/flask commit 7fff56f5172c48b6f3aedf17ee14ef5c2533dfd1 is included. Review applications that define SECRET_KEY_FALLBACKS and confirm the newest/current key is set as SECRET_KEY and older keys are present only for temporary verification during rotation. After upgrading, complete the intended key rotation by removing stale fallback keys once the session transition window has passed. If any old signing key may have been exposed, force session invalidation, rotate SECRET_KEY again, and minimize or remove fallback acceptance where operationally possible.

How to confirm the fix worked

Confirm package inventory shows Flask 3.1.1 or later and not Flask 3.1.0. For Python environments, validate with commands such as python -m flask --version, python -c "import flask; print(flask.__version__)" where supported, pip show Flask, pip freeze, poetry show flask, or the organization’s software composition analysis tooling. Review configuration for SECRET_KEY_FALLBACKS; applications not using this setting are not affected by the key-ordering behavior. In a controlled non-production test, configure a current key and fallback key, issue a new session after upgrade, and verify that the cookie validates with the current key and not only with the stale fallback key. Also confirm stale fallback keys are removed after the approved rotation period.

Typical attack path

1. Identify or gain access to a Flask 3.1.0 application that uses client-side signed sessions and has SECRET_KEY_FALLBACKS configured.
2. Obtain knowledge of an older fallback signing key through a separate compromise, configuration leak, source exposure, backup exposure, or privileged local access.
3. Take advantage of the application continuing to sign new session cookies with the stale fallback key rather than the intended current key.
4. Use the stale key to analyze or potentially craft signed session data only if the application stores security-relevant state in the client-side session and the attacker has sufficient knowledge of the signing format and application behavior.
5. Maintain access until the application is upgraded and the old fallback key is removed or invalidated.

How to detect it

There are no widely reported exploitation campaigns or distinctive network indicators for this issue, and exploitation would generally depend on prior access to old signing keys rather than a recognizable request pattern. To assess whether the issue may have contributed to an incident, review application dependency inventories for Flask 3.1.0 and configuration repositories or runtime configuration for SECRET_KEY_FALLBACKS. Examine secret-management audit logs for reads, exports, or changes involving Flask SECRET_KEY values and fallback keys. Review source-control history, CI/CD logs, container images, deployment artifacts, backups, and crash/debug output for accidental exposure of SECRET_KEY or SECRET_KEY_FALLBACKS values. In application logs, investigate unusual session continuity after a key rotation, unexpected successful authentication using sessions that should have been invalidated, abnormal admin activity after secret rotation, or large numbers of session-cookie validation failures during rotation windows. Because Flask signed session cookies are normally client-side and validation failures may not be logged by default, additional application instrumentation may be required to distinguish cookies signed with old versus current keys.

What your security team should do

• Inventory Flask applications and prioritize those running Flask 3.1.0 with SECRET_KEY_FALLBACKS configured.
• Upgrade affected deployments to Flask 3.1.1 or later, or apply the upstream fix commit 7fff56f5172c48b6f3aedf17ee14ef5c2533dfd1 for source-pinned builds.
• Review secret-management records and incident history to determine whether any fallback session-signing key was previously exposed or should be considered untrusted.
• If an old key may be compromised, rotate SECRET_KEY after patching and invalidate active sessions rather than relying on fallback acceptance.
• Add dependency checks that flag Flask 3.1.0 and configuration checks that identify SECRET_KEY_FALLBACKS usage during application security reviews.
• Treat this as low exploitation urgency but important cryptographic hygiene, especially for applications with privileged admin sessions or sensitive account state stored in Flask sessions.