Listen to this Post
The vulnerability exists in Flask-Security-Too versions prior to fix, specifically in the OAuth reauthentication flow. When a user session becomes stale (not fresh), the application requires reauthentication before allowing sensitive actions like changing username. The flaw resides in the OAuth verification callback functions `_oauth_response_common()` and `oauth_verify_response()` in oauth_glue.py. The `_oauth_response_common()` resolves an OAuth provider identity to a Flask-Security user without validating that user matches the currently authenticated session user. Then `oauth_verify_response()` accepts any resolved user and updates the session freshness timestamp (fs_paa). An attacker who can control a stale, already-authenticated victim session (e.g., via stolen session cookie) can initiate OAuth verification using their own OAuth account (e.g., [email protected]). The victim session remains logged in as the victim, but the OAuth callback returns the attacker’s identity. Flask-Security-Too marks the victim session as fresh because it only checks that OAuth verification succeeded, not that the verified user matches the session user. Consequently, the attacker can then perform freshness-protected actions on the victim’s account. The provided PoC uses a minimal Flask app with OAuth enabled, a mock provider returning [email protected], and reproduces the bypass on the built-in `/change-username` route. The victim’s username is changed successfully, demonstrating direct impact. The missing check is that OAuth-resolved user must equal `current_user` before updating session["fs_paa"].
dailycve form:
Platform: Flask-Security-Too
Version: 5.8.0
Vulnerability: OAuth freshness bypass
Severity: Critical
date: 2026-05-22
Prediction: 2026-06-15
What Undercode Say:
Check installed version
pip show flask-security-too | grep Version
Simulate stale session test (requires Flask app)
export VICTIM_COOKIE="session=...;"
curl -X POST http://localhost:5000/change-username \
-H "Cookie: $VICTIM_COOKIE" \
-H "Content-Type: application/json" \
-d '{"new_username":"hacked"}' Should return 401 reauth_required
OAuth takeover using attacker identity (mock provider)
curl -X POST http://localhost:5000/login/oauth-verify-start/github \
-H "Cookie: $VICTIM_COOKIE"
After callback, retry change-username – succeeds
Exploit:
Attacker obtains victim’s stale session cookie (e.g., via XSS or network sniffing). Attacker sets up a local OAuth mock provider returning their own email. Using victim’s cookie, attacker initiates OAuth verification to any provider, intercepts callback, and completes with attacker’s identity. Victim session becomes fresh. Attacker then calls `/change-username` or any freshness-protected endpoint, modifying victim’s account.
Protection from this CVE
Upgrade to patched version (>=5.9.0) where `oauth_verify_response()` checks oauth_user == current_user. Alternatively, apply manual fix: in `oauth_glue.py` after resolving user, add if user != current_user: abort(401). Disable OAuth reauthentication for high-risk actions until patch.
Impact
Unauthorized account modification (username, password, email if protected). Attackers can bypass reauthentication, leading to account takeover, data tampering, and privilege escalation without ever knowing victim’s credentials.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow DailyCVE & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin
YesWiki, Unauthenticated SQL Injection, CVE-Pending (Critical)