NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

django-allauth does not reject access tokens for inactive usersGHSA-qhmc-3mvr-f2j4

MEDIUMFix: pennersr/django-allauth@39f4a4c

GHSA-qhmc-3mvr-f2j4 is a medium-severity (CVSS 5.4) CWE-613 vulnerability in django-allauth. A fix is available for django-allauth — see the affected versions and patch details below.

Also known asCVE-2025-65430PYSEC-2025-110
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-qhmc-3mvr-f2j4.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk-0.00%
Lower risk than most CVEs6th percentile — riskier than 6% of all scored CVEsHighest risk
0.00%0.22%0.44%0.66%0.0%0.2%May 26Sep 26Nov 26

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

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐍django-allauth

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

An issue was discovered in allauth-django before 65.13.0. IdP: marking a user as is_active=False after having handed tokens for that user while the account was still active had no effect. Fixed the access/refresh tokens are now rejected.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIdjango-allauthall versions65.13.0pip install --upgrade 'django-allauth==65.13.0'

Affected Products

1 product · 1 configurations
Application
allauthallauth
< 65.13.0
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

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

  2. Fix

    Update django-allauth to 65.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qhmc-3mvr-f2j4 is resolved across your whole dependency graph.

  3. 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

An issue was discovered in allauth-django before 65.13.0. IdP: marking a user as is_active=False after having handed tokens for that user while the account was still active had no effect. Fixed the access/refresh tokens are now rejected.
O3 Security · Impact-Aware SCA

Is GHSA-qhmc-3mvr-f2j4 in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
GHSA-qhmc-3mvr-f2j4: django-allauth — Fixed in 65.13.0