SEC2-045: django-allauth 65.19.5 is locked while 65.19.6-65.20.0 carry security fixes for MFA and lift the oauthlib advisory CI ignores #987

New issue

Closed

opened 2026-10-17 10:39:23 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-17 10:39:23 +00:00

Owner

Found on 2026-10-16 in a read-only security review of postulo at 56fc9d531, checked by a second, independent pass.

Severity: Medium · Category: Dependencies · Reference: CWE-1104 (Use of Unmaintained Third Party Components); OWASP A06:2021 (Vulnerable and Outdated Components)

Location:

uv.lock (packages django-allauth 65.19.5, oauthlib 3.3.1)
pyproject.toml:21 ("django-allauth[mfa,socialaccount]>=65.19")
.forgejo/workflows/ci.yml:614-626 (--ignore-vuln CVE-2026-49265 and its justification)
tests/test_security_audit.py:22-26 (the same ignore, with "every django-allauth release so far requires oauthlib<4")
src/postulo/config/settings/base.py:63-65, 305, 332-338, 364 (allauth.mfa, openid_connect, login by code, passkeys, TOTP; SOCIALACCOUNT_PROVIDERS)

Issue

The lock holds django-allauth 65.19.5 and oauthlib 3.3.1. allauth's ChangeLog records three later releases with Security notice sections (github.com/pennersr/django-allauth, ChangeLog.rst):

65.19.6 (2026-09-30): the socialaccount and idp-oidc extras now require oauthlib>=4.0.0, "which includes upstream security fixes"; Bitbucket and Pinterest identifiers (not used here).
65.19.7 (2026-10-01): Tumblr identifiers (not used here).
65.20.0 (2026-10-16): cancelling a multi-stage login left authentication records behind, which could mix records from different accounts in one session, now discarded on abort; the authorization state is bound to the provider that started the flow; non-ASCII MFA codes no longer cause a server error.

Postulo enables the multi-stage login (MFA with WebAuthn, TOTP and recovery codes; login by code), so the first 65.20.0 fix sits on a reachable path. The provider-binding fix is moot as shipped: SOCIALACCOUNT_PROVIDERS declares a single openid_connect app, so there is no other provider's callback. The oauthlib fix is the one CI still ignores by name: ci.yml:614-620 says "The fix is oauthlib 4, which no django-allauth release accepts yet (oauthlib<4)", and that stopped being true on 2026-09-30. tests/test_security_audit.py fails the day the lock holds oauthlib 4, so the flag cannot outlive its reason once the lock moves; nothing makes the lock move. postulo-templates and postulo-francetravail already lock django-allauth==65.19.7 and oauthlib==4.0.0.

Impact

A person who aborts an MFA or login-by-code flow and signs in again in the same browser session may carry authentication records of the earlier attempt into the new one (upstream's wording: records of different accounts mixed in one session). A non-ASCII MFA code returns a 500 rather than a refusal. The oauthlib PKCE timing issue stays accepted on the grounds of #323, which were right then and are moot now.

Fix

uv lock --upgrade-package django-allauth --upgrade-package oauthlib to 65.20.0 / 4.0.x; remove --ignore-vuln CVE-2026-49265 from ci.yml together with its comment (ci.yml:614-620) and the IGNORED entry and comment in tests/test_security_audit.py:22-26; keep test_postulo_never_runs_oauthlibs_provider_side as documentation. Done when: the lock holds allauth >= 65.20.0 and oauthlib >= 4.0.0, the ignore flag is gone, and the MFA and login-by-code tests in tests/security/ pass against the new release.

#323 (closed) - accepted the oauthlib advisory while no allauth release took oauthlib 4; that condition ended with 65.19.6, so the acceptance is stale. SEC2-044 - the same lag for Django. SEC2-054 - the audit cannot see allauth's security releases at all.

Found on 2026-10-16 in a read-only security review of `postulo` at `56fc9d531`, checked by a second, independent pass. **Severity:** Medium · **Category:** Dependencies · **Reference:** CWE-1104 (Use of Unmaintained Third Party Components); OWASP A06:2021 (Vulnerable and Outdated Components) **Location:** - `uv.lock` (packages `django-allauth 65.19.5`, `oauthlib 3.3.1`) - `pyproject.toml:21` (`"django-allauth[mfa,socialaccount]>=65.19"`) - `.forgejo/workflows/ci.yml:614-626` (`--ignore-vuln CVE-2026-49265` and its justification) - `tests/test_security_audit.py:22-26` (the same ignore, with "every django-allauth release so far requires `oauthlib<4`") - `src/postulo/config/settings/base.py:63-65, 305, 332-338, 364` (`allauth.mfa`, `openid_connect`, login by code, passkeys, TOTP; `SOCIALACCOUNT_PROVIDERS`) ## Issue The lock holds `django-allauth 65.19.5` and `oauthlib 3.3.1`. allauth's ChangeLog records three later releases with *Security notice* sections (github.com/pennersr/django-allauth, ChangeLog.rst): - 65.19.6 (2026-09-30): the `socialaccount` and `idp-oidc` extras now require `oauthlib>=4.0.0`, "which includes upstream security fixes"; Bitbucket and Pinterest identifiers (not used here). - 65.19.7 (2026-10-01): Tumblr identifiers (not used here). - 65.20.0 (2026-10-16): cancelling a multi-stage login left authentication records behind, which could mix records from different accounts in one session, now discarded on abort; the authorization state is bound to the provider that started the flow; non-ASCII MFA codes no longer cause a server error. Postulo enables the multi-stage login (MFA with WebAuthn, TOTP and recovery codes; login by code), so the first 65.20.0 fix sits on a reachable path. The provider-binding fix is moot as shipped: `SOCIALACCOUNT_PROVIDERS` declares a single `openid_connect` app, so there is no other provider's callback. The oauthlib fix is the one CI still ignores by name: `ci.yml:614-620` says "The fix is oauthlib 4, which no django-allauth release accepts yet (`oauthlib<4`)", and that stopped being true on 2026-09-30. `tests/test_security_audit.py` fails the day the lock holds oauthlib 4, so the flag cannot outlive its reason once the lock moves; nothing makes the lock move. `postulo-templates` and `postulo-francetravail` already lock `django-allauth==65.19.7` and `oauthlib==4.0.0`. ## Impact A person who aborts an MFA or login-by-code flow and signs in again in the same browser session may carry authentication records of the earlier attempt into the new one (upstream's wording: records of different accounts mixed in one session). A non-ASCII MFA code returns a 500 rather than a refusal. The oauthlib PKCE timing issue stays accepted on the grounds of #323, which were right then and are moot now. ## Fix `uv lock --upgrade-package django-allauth --upgrade-package oauthlib` to 65.20.0 / 4.0.x; remove `--ignore-vuln CVE-2026-49265` from `ci.yml` together with its comment (`ci.yml:614-620`) and the `IGNORED` entry and comment in `tests/test_security_audit.py:22-26`; keep `test_postulo_never_runs_oauthlibs_provider_side` as documentation. Done when: the lock holds allauth >= 65.20.0 and oauthlib >= 4.0.0, the ignore flag is gone, and the MFA and login-by-code tests in `tests/security/` pass against the new release. ## Related #323 (closed) - accepted the oauthlib advisory while no allauth release took oauthlib 4; that condition ended with 65.19.6, so the acceptance is stale. SEC2-044 - the same lag for Django. SEC2-054 - the audit cannot see allauth's security releases at all.

tiagoagueda added the

bug

security

labels

2026-10-17 10:39:23 +00:00

tiagoagueda added this to the 0.5.0 milestone

2026-10-17 10:39:24 +00:00

tiagoagueda referenced this issue

2026-10-17 10:41:22 +00:00

SEC2 index: security review of 2026-10-16 (86 issues across the core, plugins and extensions) #992

tiagoagueda referenced this issue from a commit

2026-10-17 14:57:51 +00:00