CVE-2026-46715: 
Python vulnerability analysis and mitigation

CVE-2026-46715 is an improper authentication vulnerability in Flask-Security-Too that allows an attacker to bypass the OAuth reauthentication freshness check by completing OAuth verification with their own identity while operating a victim's stale session. Affecting Flask-Security-Too versions >= 5.8.0 and < 5.8.1, the flaw causes the victim's session to be marked as freshly reauthenticated even though the OAuth identity belongs to a different user. It was published on May 17, 2026, and added to the GitHub Advisory Database on May 22, 2026. The vulnerability carries a Moderate severity rating (CVSS category estimate: Medium) (GitHub Advisory, Flask-Security Advisory).

The root cause is classified as CWE-287 (Improper Authentication): the oauth_verify_response() function in flask_security/oauth_glue.py (lines 182–214) updates the current session's freshness timestamp (session["fs_paa"]) without verifying that the OAuth-resolved user matches the currently authenticated session user. Specifically, _oauth_response_common() (lines 101–108) resolves the OAuth provider identity to any Flask-Security user, and oauth_verify_response() (lines 201–204) then unconditionally marks the session as fresh. The missing identity-match check means an attacker who controls a stale victim session can initiate an OAuth verification flow (POST /login/oauth-verify-start/<provider>) and complete it with their own OAuth account, causing the victim's session to satisfy freshness-protected route requirements. A PoC was demonstrated against the built-in /change-username route using a localhost mock OAuth provider (GitHub Advisory, Flask-Security Advisory).

Successful exploitation allows an attacker to perform freshness-protected account actions on behalf of a victim without knowing the victim's credentials or OAuth identity. In the demonstrated PoC, the attacker was able to change the victim's username via the /change-username route, confirming direct account integrity impact. The attacker does not gain full session takeover or access to the victim's credentials, but can execute any action gated solely by Flask-Security-Too's reauthentication freshness check, which may include sensitive account modifications depending on the application's configuration (GitHub Advisory, Flask-Security Advisory).

1. Prerequisite — Obtain a stale victim session: Gain access to an authenticated but stale Flask-Security-Too session for victim@example.com (e.g., via session fixation, a shared browser, or session token theft). The session must be past the SECURITY_FRESHNESS window so that freshness-protected routes return HTTP 401 with reauth_required=true.
2. Confirm freshness block: Send POST /change-username (or another freshness-protected route) using the victim's session cookie. Verify the response is HTTP 401 with reauth_required: true.
3. Initiate OAuth verification on the victim session: Using the victim's session cookie, send POST /login/oauth-verify-start/github (or the configured provider) to begin the OAuth reauthentication flow.
4. Complete OAuth callback with attacker's identity: Redirect the OAuth callback to return the attacker's own OAuth identity (attacker@example.com) — in a real attack this could be done by controlling the OAuth redirect or using a mock provider. Flask-Security-Too's _oauth_response_common() resolves this to the attacker's user record.
5. Session freshness updated: oauth_verify_response() updates session["fs_paa"] (the freshness timestamp) on the victim's session without checking that the resolved OAuth user matches current_user. The victim's session is now marked as fresh.
6. Execute freshness-protected action: Retry POST /change-username with the victim's session cookie. The request now succeeds (HTTP 200), and the victim's username is changed to the attacker-supplied value (GitHub Advisory, Flask-Security Advisory).

• Logs: Web server access logs showing POST /login/oauth-verify-start/<provider> followed shortly by a successful POST /change-username (HTTP 200) for the same session, where the OAuth callback identity differs from the session's authenticated user.
• Logs: Application logs recording an fs_paa session update for a user whose identity does not match the OAuth provider's returned identity.
• Network: OAuth callback requests (GET /login/oauth-authorized/<provider>) originating from unexpected IP addresses or using mock/localhost OAuth provider endpoints in non-development environments.
• Application Events: Unexpected username changes on accounts, particularly where the change was not initiated by the account owner and occurred after a period of session inactivity (GitHub Advisory).

Upgrade Flask-Security-Too to version 5.8.1, which contains the fix requiring the OAuth-resolved user to match current_user before updating session["fs_paa"]. No configuration-based workaround is available for version 5.8.0; the only remediation is upgrading to 5.8.1. Applications that do not use both SECURITY_OAUTH_ENABLE = True and freshness-protected routes simultaneously are not affected by this specific attack path (GitHub Advisory, Flask-Security Advisory).

The vulnerability was reported by security researcher 0xHunSec and published by Flask-Security-Too maintainer jwag956 on May 17, 2026. No significant broader media coverage or notable community commentary beyond the official advisory has been identified at this time (Flask-Security Advisory).