Flask is a web server gateway interface (WSGI) web application framework. In Flask 3.1.0, the way fallback key configuration was handled resulted in the last fallback key being used for signing, rather than the current signing key. Signing is provided by the `itsdangerous` library. A list of keys can be passed, and it expects the last (top) key in the list to be the most recent key, and uses that for signing. Flask was incorrectly constructing that list in reverse, passing the signing key first. Sites that have opted-in to use key rotation by setting `SECRET_KEY_FALLBACKS` care likely to unexpectedly be signing their sessions with stale keys, and their transition to fresher keys will be impeded. Sessions are still signed, so this would not cause any sort of data integrity loss. Version 3.1.1 contains a patch for the issue.

The remote Fedora 42 host has a package installed that is affected by a vulnerability as referenced in the FEDORA-2025-55e69c9cea advisory.

    - Update to 3.1.2


Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Ubuntu 25.04 host has a package installed that is affected by a vulnerability as referenced in the USN-7534-1 advisory.

    It was discovered that Flask incorrectly handled key rotation. An attacker could possibly use this issue     to sign sessions with stale keys.

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - Flask is a web server gateway interface (WSGI) web application framework. In Flask 3.1.0, the way fallback
    key configuration was handled resulted in the last fallback key being used for signing, rather than the
    current signing key. Signing is provided by the `itsdangerous` library. A list of keys can be passed, and
    it expects the last (top) key in the list to be the most recent key, and uses that for signing. Flask was
    incorrectly constructing that list in reverse, passing the signing key first. Sites that have opted-in to
    use key rotation by setting `SECRET_KEY_FALLBACKS` care likely to unexpectedly be signing their sessions
    with stale keys, and their transition to fresher keys will be impeded. Sessions are still signed, so this
    would not cause any sort of data integrity loss. Version 3.1.1 contains a patch for the issue.
    (CVE-2025-47278)

ID	Name	Product	Family	Severity
261758	Fedora 42 : python-flask (2025-55e69c9cea)	Nessus	Fedora Local Security Checks	low
237264	Ubuntu 25.04 : Flask vulnerability (USN-7534-1)	Nessus	Ubuntu Local Security Checks	low
425966	SCA: security update for flask (GHSA-4grg-w6v8-c28g)	Tenable Cloud Security	SCA Checks	low
425966	SCA: security update for flask (GHSA-4grg-w6v8-c28g)	Tenable Self-Hosted Container Security	SCA Checks	low

Detections

Analytics

CVE-2025-47278

low

Tenable Plugins

low

low

low

low