SEC2-054: SECURITY.md says a fresh library disclosure is noticed automatically, but the audit cannot see django-allauth's security releases #990

New issue

Closed

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

tiagoagueda commented

2026-10-17 10:39:37 +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: Informational · Category: Configuration · Reference: CWE-1104 (Use of Unmaintained Third Party Components); OWASP A06:2021 (Vulnerable and Outdated Components)

Location:

SECURITY.md:41-53
docs/THREAT-MODEL.md (row "A vulnerability disclosed in a dependency": "Dependencies are audited against the advisory databases on every push and weekly")
.forgejo/workflows/ci.yml:624-627 (pip-audit --strict with the default pypi vulnerability service)

Issue

pip-audit reads PyPI's vulnerability feed, which is OSV, which carries reviewed GitHub advisories and PYSEC entries. On 2026-10-17 OSV returns no entry for any version of django-allauth (queried 65.19.2 and 65.19.5), although the project published security notices in 65.19.6, 65.19.7 and 65.20.0: allauth's maintainer issues no advisory identifiers, so this class is invisible to the audit by construction, not by delay. For Django, the four CVEs fixed in 6.1.2 exist as GitHub advisories but are unreviewed, with no package or version data, so OSV and PyPI (/pypi/django/6.1.1/json → "vulnerabilities": []) cannot match them; the previous GIS CVE fixed in 6.1.1 took weeks to get a reviewed advisory. The two documents say the opposite: "a fresh disclosure in a library is noticed without anyone having to look".

Impact

Nobody is misled by the code, but an operator reading SECURITY.md believes a green audit means the framework and the authentication library are current, and for those two packages it does not. The window is the one SEC2-044 and SEC2-045 describe (ten days so far for Django, seventeen for allauth).

Fix

Land the version watch proposed in SEC2-044 (fail the weekly security job when PyPI holds a newer release of django or django-allauth inside the pyproject.toml range for more than seven days), then add one sentence to SECURITY.md and the threat-model row: the audit reads OSV, which does not cover libraries that issue no advisories, and the version watch covers Django and django-allauth by release instead. Done when: the sentence is in both documents and a test beside tests/test_security_audit.py asserts the version-watch step exists in ci.yml.

SEC2-044 - Django 6.1.2 unnoticed by the audit. SEC2-045 - django-allauth 65.20.0 unnoticed. #583 (closed) - widened what the audit exports. #323 (closed) - added the one ignore. Neither says what the audit cannot see.

Found on 2026-10-16 in a read-only security review of `postulo` at `56fc9d531`, checked by a second, independent pass. **Severity:** Informational · **Category:** Configuration · **Reference:** CWE-1104 (Use of Unmaintained Third Party Components); OWASP A06:2021 (Vulnerable and Outdated Components) **Location:** - `SECURITY.md:41-53` - `docs/THREAT-MODEL.md` (row "A vulnerability disclosed in a dependency": "Dependencies are audited against the advisory databases on every push and weekly") - `.forgejo/workflows/ci.yml:624-627` (`pip-audit --strict` with the default `pypi` vulnerability service) ## Issue `pip-audit` reads PyPI's vulnerability feed, which is OSV, which carries reviewed GitHub advisories and PYSEC entries. On 2026-10-17 OSV returns no entry for any version of django-allauth (queried 65.19.2 and 65.19.5), although the project published security notices in 65.19.6, 65.19.7 and 65.20.0: allauth's maintainer issues no advisory identifiers, so this class is invisible to the audit by construction, not by delay. For Django, the four CVEs fixed in 6.1.2 exist as GitHub advisories but are unreviewed, with no package or version data, so OSV and PyPI (`/pypi/django/6.1.1/json` → `"vulnerabilities": []`) cannot match them; the previous GIS CVE fixed in 6.1.1 took weeks to get a reviewed advisory. The two documents say the opposite: "a fresh disclosure in a library is noticed without anyone having to look". ## Impact Nobody is misled by the code, but an operator reading `SECURITY.md` believes a green audit means the framework and the authentication library are current, and for those two packages it does not. The window is the one SEC2-044 and SEC2-045 describe (ten days so far for Django, seventeen for allauth). ## Fix Land the version watch proposed in SEC2-044 (fail the weekly `security` job when PyPI holds a newer release of `django` or `django-allauth` inside the `pyproject.toml` range for more than seven days), then add one sentence to `SECURITY.md` and the threat-model row: the audit reads OSV, which does not cover libraries that issue no advisories, and the version watch covers Django and django-allauth by release instead. Done when: the sentence is in both documents and a test beside `tests/test_security_audit.py` asserts the version-watch step exists in `ci.yml`. ## Related SEC2-044 - Django 6.1.2 unnoticed by the audit. SEC2-045 - django-allauth 65.20.0 unnoticed. #583 (closed) - widened what the audit exports. #323 (closed) - added the one ignore. Neither says what the audit cannot see.

tiagoagueda added the

enhancement

security

labels

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

tiagoagueda added this to the 1.0.0 milestone

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

tiagoagueda referenced this issue

2026-10-17 10:41:23 +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