How severe is GHSA-97r5-pg8x-p63p?

No CVSS score has been assigned to GHSA-97r5-pg8x-p63p yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-97r5-pg8x-p63p?

GHSA-97r5-pg8x-p63p affects the following packages: flask-security-too (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-97r5-pg8x-p63p?

Update flask-security-too to 5.8.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-97r5-pg8x-p63p is resolved across your whole dependency graph.

How do I detect GHSA-97r5-pg8x-p63p in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flask-security-too, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-97r5-pg8x-p63p if there is no patch (or I can't update yet)?

Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Is GHSA-97r5-pg8x-p63p actively exploited in the wild?

No public exploit code has been indexed for GHSA-97r5-pg8x-p63p yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-97r5-pg8x-p63p?

GHSA-97r5-pg8x-p63p has an EPSS (Exploit Prediction Scoring System) score of 0.5%, placing it in the 40th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-97r5-pg8x-p63p?

GHSA-97r5-pg8x-p63p is classified as Improper Authentication (CWE-287). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-97r5-pg8x-p63p published, and has it been updated?

GHSA-97r5-pg8x-p63p was published on May 22, 2026 and was last updated on July 13, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

Not in CISA KEV

GHSA-97r5-pg8x-p63p — flask-security-too

GHSA-97r5-pg8x-p63p is a Improper Authentication vulnerability in flask-security-too. A fix is available for flask-security-too — see the affected versions and patch details below.

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

Also known asCVE-2026-46715PYSEC-2026-2478

Published

May 22, 2026

Updated

Jul 13, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 4, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-97r5-pg8x-p63p.

EPSS Exploitation Probability

via FIRST.org ↗

0.5%probability of exploitation in next 30 days

Lower Risk+0.21%

Lower risk than most CVEs40th percentile — riskier than 40% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐍flask-security-too

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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: [email protected]
OAuth verified user: [email protected]
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:

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 [email protected]. 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 [email protected].
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
   [email protected].
6. Confirm the session is still for [email protected], 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": "[email protected]",
  "oauth_verify_response_status": 302,
  "post_bypass_change_username_status": 200,
  "final_email": "[email protected]",
  "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"].

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`flask-security-too`	≥ 5.8.0&&< 5.8.1	5.8.1`pip install --upgrade 'flask-security-too==5.8.1'`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flask-security-too, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update flask-security-too to 5.8.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-97r5-pg8x-p63p is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### 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_respo

O3 Security · Impact-Aware SCA

Is GHSA-97r5-pg8x-p63p in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works