CVE-2026-46715: Flask-Security-Too Auth Bypass Vulnerability

CVE-2026-46715 Overview

CVE-2026-46715 is an authentication vulnerability in Flask-Security-Too version 5.8.0. The flaw resides in the OAuth reauthentication flow, which can mark a session as fresh after verifying an OAuth account belonging to a different user. An attacker operating an already-authenticated but stale victim session can complete OAuth verification using their own OAuth identity. The victim session is then treated as recently reauthenticated, allowing freshness-protected account actions to proceed. The issue is tracked under advisory GHSA-97r5-pg8x-p63p and classified as improper authentication [CWE-287]. Flask-Security-Too version 5.8.1 contains the fix.

Critical Impact
An attacker with control of a stale but authenticated victim session can bypass reauthentication freshness checks by completing OAuth verification with an attacker-controlled OAuth identity, enabling sensitive account actions.

Affected Products

Flask-Security-Too version 5.8.0
Flask applications using the Flask-Security-Too OAuth /verify reauthentication flow
Deployments relying on session freshness for account-sensitive actions

Discovery Timeline

2026-07-20 - CVE-2026-46715 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-46715

Vulnerability Analysis

Flask-Security-Too extends Flask with authentication, authorization, and account management primitives. Version 5.8.0 introduced an OAuth reauthentication path handled in flask_security/oauth_glue.py. When a user attempts a freshness-protected action, the framework can request OAuth reverification through the /verify endpoint.

The defect is that the verification handler updates the session freshness timestamp based on a successful OAuth callback without confirming that the returned OAuth identity maps to the same user account currently authenticated in the session. Any successful OAuth login is treated as sufficient proof of freshness for the existing session subject.

The practical consequence is that an attacker who has obtained an authenticated but stale session for a victim can walk the OAuth reverification flow using their own OAuth account. The framework accepts the callback, marks the session fresh, and permits freshness-gated operations such as changing security settings.

Root Cause

The root cause is missing subject binding between the session principal and the OAuth identity returned by the provider. The verify handler did not resolve the OAuth account through get_identity_attribute and compare it against the currently logged-in user before promoting session freshness. This is a classic improper authentication weakness [CWE-287] applied to the session reauthentication step rather than initial login.

Attack Vector

Exploitation requires network access to the target Flask application and control of an authenticated but stale victim session. The attacker also needs a valid OAuth account with any provider supported by the target. The attacker triggers the /verify flow from the victim session, completes OAuth authentication under their own identity, and the framework marks the victim session as freshly reauthenticated.

python

     config_value as cv,
     do_flash,
     login_user,
+    get_identity_attribute,
     get_message,
     get_post_action_redirect,
     get_url,

Source: Flask-Security patch commit 8e69f3a

The patch imports get_identity_attribute into oauth_glue.py so the verify handler can resolve the OAuth response back to a user record and confirm it matches the session subject before promoting freshness.

Detection Methods for CVE-2026-46715

Indicators of Compromise

OAuth callbacks to the /verify endpoint where the returned OAuth identity does not match the currently authenticated session user.
Session freshness timestamps updated immediately after an OAuth callback from a provider account not linked to the session user.
Freshness-protected account actions such as password change or email change occurring shortly after an unlinked OAuth verification event.

Detection Strategies

Instrument the Flask-Security oauth_glue module to log the session user_id, the resolved OAuth provider identity, and whether they match on every verify callback.
Alert on any verify callback where the OAuth identity resolves to a different user record than the active session principal.
Review authentication logs for stale sessions that suddenly complete OAuth verification followed by sensitive account state changes.

Monitoring Recommendations

Enable structured logging on all /verify endpoint transitions, including provider name, subject identifier, and resulting freshness state.
Monitor for unusual patterns of OAuth verification events tied to accounts with long-lived sessions.
Track the installed Flask-Security-Too version across application inventories and alert on any deployment still pinned to 5.8.0.

How to Mitigate CVE-2026-46715

Immediate Actions Required

Upgrade Flask-Security-Too to version 5.8.1 or later, which contains the fix for GHSA-97r5-pg8x-p63p.
Audit application dependency manifests for any pin to Flask-Security-Too==5.8.0 and remove or update it.
Invalidate long-lived sessions in production after upgrading to remove any sessions that may have been promoted to a fresh state during exposure.

Patch Information

The fix is contained in commit 8e69f3a94a463c0e8ddc46e31743717559fd8d48, released in Flask-Security-Too 5.8.1. The change updates flask_security/oauth_glue.py to use get_identity_attribute when resolving the OAuth response, ensuring the verified OAuth identity is bound to the session user before freshness is granted. See the GitHub Security Advisory GHSA-97r5-pg8x-p63p for the full advisory.

Workarounds

Disable the OAuth reauthentication path if the application does not require it, forcing password-based reverification for freshness-protected actions.
Shorten session lifetime and freshness windows to reduce the exposure of stale but authenticated sessions.
Add an application-layer check that compares the OAuth subject returned by the provider against the current session user before allowing sensitive actions.

bash

# Upgrade Flask-Security-Too to the patched release
pip install --upgrade 'Flask-Security-Too>=5.8.1'

# Verify the installed version
pip show Flask-Security-Too | grep -i version