Mittel

Flask-Security-Too OAuth reauthentication freshness bypass via cross- user OAuth identity acceptance

  • Veröffentlicht: 22.05.2026
  • Aktualisiert: 11.10.2026 14:18

Summary

Flask-Security-Too 5.8.0's OAuth reauthentication flow can mark a session as fresh after verifying an OAuth account that belongs to a different user.

If an attacker can operate an already-authenticated but stale victim session, they 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. This was reproduced against the built-in /change-username route.

Details

The issue is in the OAuth verification callback.

_oauth_response_common() resolves the OAuth provider identity to a Flask-Security user:

  • flask_security/oauth_glue.py:101-108

oauth_verify_response() then accepts any resolved user and updates the current session freshness timestamp:

  • flask_security/oauth_glue.py:182-214
  • flask_security/oauth_glue.py:201-204

The missing check is that the OAuth-resolved user must match the current authenticated session user. In the failing case:

  • current session user: victim@example.com
  • OAuth verified user: attacker@example.com
  • session marked fresh: yes

So the attacker is not logging in as the victim, but they are satisfying the victim session's reauthentication requirement with a different account.

PoC

Tested version:

  • Flask-Security-Too 5.8.0
  • tag 5.8.0
  • commit 08288dff6907e413d848a16aaf43fc2c2b2a3b72

Used a minimal Flask app with:

python
SECURITY_OAUTH_ENABLE = True
SECURITY_OAUTH_BUILTIN_PROVIDERS = ["github"]
SECURITY_FRESHNESS = timedelta(seconds=1)
SECURITY_FRESHNESS_GRACE_PERIOD = timedelta(seconds=0)
SECURITY_USERNAME_ENABLE = True
SECURITY_CHANGE_USERNAME = True

The OAuth provider was replaced with a localhost mock provider
returning attacker@example.com. This avoids hitting a live third-party
provider while still exercising Flask-Security-Too's real OAuth
verification handler.

Reproduction steps:

1. Log in as victim@example.com.
2. Wait until the session is no longer fresh.
3. Confirm POST /change-username is blocked with 401 and
   reauth_required=true.
4. Start OAuth verification with POST /login/oauth-verify-start/
   github.
5. Complete the callback with an OAuth identity for
   attacker@example.com.
6. Confirm the session is still for victim@example.com, but fs_paa has
   been updated.
7. Retry POST /change-username.
8. The victim user's username is changed successfully.

Observed result:

{
  "pre_bypass_status": 401,
  "pre_bypass_reauth_required": true,
  "attacker_identity": "attacker@example.com",
  "oauth_verify_response_status": 302,
  "post_bypass_change_username_status": 200,
  "final_email": "victim@example.com",
  "final_username": "victimowned1777878574",
  "direct_impact_verified": true
}

Note: CSRF was disabled in the local harness only to keep the test
focused on the reauthentication check. This is not a CSRF bypass
report.

This bypasses Flask-Security-Too's freshness/reauthentication
boundary.

Applications using OAuth verification together with freshness-
protected account operations may allow a stale victim session to be
refreshed using a different user's OAuth account. In my test, this
allowed the victim account's username to be changed through Flask-
Security-Too's built-in /change-username route.

A likely fix is to reject OAuth verification unless the resolved OAuth
user matches current_user before updating session["fs_paa"].

Betroffene Software

Klicken Sie auf eine Technologie, um alle zugehörigen Schwachstellen anzuzeigen.

PlattformPaketAnfällige VersionenBehoben in
Python (PyPI) flask-security-too >= 5.8.0, < 5.8.1 5.8.1

Verweise

CVSS-Wert -
Schwäche (CWE)
CWE-287
Plattform
Python (PyPI)
Paket
flask-security-too
Veröffentlicht
22.05.2026
Aktualisiert
11.10.2026 14:18

Quellen und Lizenzen

OSV / GitHub Advisory Database - PYSEC-2026-2478 - PyPA Advisory Database; CC BY 4.0

OSV / GitHub Advisory Database - GHSA-97r5-pg8x-p63p - CC BY 4.0

Schwachstellenhistorie: flask-security-too

Alle veröffentlichten Schwachstellen dieses Pakets (Python (PyPI)), neueste zuerst. Zeigt, ob es ein einmaliger Ausrutscher ist oder ein Paket, das man im Auge behalten muss.

Einträge insgesamt
6
Erste → letzte
01.2021 07.2026
Ohne Fix
1
In Angriffen ausgenutzt
0

Verteilung nach Schweregrad

  • Hoch 1
  • Mittel 3
  • Niedrig 2

Veröffentlichungen pro Jahr

  1. 2021: 3
  2. 2022: 0
  3. 2023: 1
  4. 2024: 0
  5. 2025: 0
  6. 2026: 2
  1. Mittel ghsa-f66q-9rf6-8795 >= 5.8.0, <= 5.8.1 keine Korrektur
  2. Flask-Security-Too OAuth reauthentication freshness bypass via cross- user OAuth identity acceptance dieser Eintrag
    Mittel CVE-2026-46715 >= 5.8.0, < 5.8.1 5.8.1
  3. Niedrig · 3.1 CVE-2021-32618 < 4.1.0 4.1.0
  4. Niedrig ghsa-fxq4-r6mr-9x64 >= 3.2.0, < 3.4.5 3.4.5
  5. Hoch · 7.4 CVE-2021-21241 >= 3.3.0, < 3.4.5 3.4.5

Erkennen Sie Schwachstellen in Ihrer Anwendung

Mit der DockRay-Integration und aktivierter Softwareinventarisierung prüft DockRay gemeldete Komponentenversionen auf bekannte Schwachstellen und benachrichtigt Sie über bestätigte Treffer. Die Abdeckung hängt von der unterstützten Technologie und den verfügbaren Meldungen ab.

Anwendung verbinden
DockRay Newsletter

Anwendungssicherheit in Ihrem Postfach

Wichtige Schwachstellen, konkrete Empfehlungen und praktische Tipps für Ihre Anwendungen. Wählen Sie Ihre Technologien und verfolgen Sie, was für Ihr Projekt relevant ist.

  • Eine tägliche Zusammenfassung neuer Schwachstellen, auch kritischer.
  • Benachrichtigungen über wichtige Updates.
  • Praktische Tipps zur Sicherheit und Überwachung von Anwendungen.

Leer lassen, um Meldungen zu allen Technologien zu erhalten.

Kostenlos anmelden. In jeder E-Mail mit einem Klick abmelden.