SEC2-056: The dev lock carries pyjwt 2.13.0 and urllib3 2.7.0, both with published advisories, and pins a core commit 210 behind #22

New issue

Closed

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

tiagoagueda commented

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

Owner

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

Severity: Low · Category: Dependencies · Reference: CWE-1395 (Dependency on Vulnerable Third-Party Component); OWASP A06:2021 (Vulnerable and Outdated Components)

Location:

pyproject.toml:54 (postulo @ git+...@925e3e9cd35a97617cc45b36ecdde862d04515b1)
pyproject.toml:49-52 (the comment still calls the pin "the 0.3.0 release line")
uv.lock:870-872 (postulo 0.4.0 at 925e3e9cd), and the lock's pyjwt 2.13.0, urllib3 2.7.0, oauthlib 3.3.1

Issue

pip-audit 2.10.1, run on 2026-10-16 against uv export --no-emit-project of the lock, reports
pyjwt 2.13.0 with fourteen advisories (PYSEC-2026-4140 to -4152 and -4183; fixed in 2.14.0 /
2.15.0), urllib3 2.7.0 with three (PYSEC-2026-4175, -4176, -4177; fixed in 2.8.0) and oauthlib
3.3.1 with PYSEC-2026-4114 (fixed in 4.0.0). The core's lock at 56fc9d531 holds pyjwt 2.15.1
and urllib3 2.8.0; it still holds oauthlib 3.3.1, an advisory the core accepts by name, so that
one is the core's own matter.

What is stale is the date the lock was resolved more than the core commit: postulo-templates
pins a core only one day newer (d28ef8384, 2026-10-11) and its lock already holds pyjwt 2.15.1
and urllib3 2.8.0. pyjwt and oauthlib arrive through the pinned core (django-allauth); urllib3 is
Apprise's own transport, through requests, and it is the library through which every webhook,
ntfy and Gotify line is sent and whose redirect handling #15 is about.

An instance is not what is exposed: a plugin is installed under the core's lock as a constraint
(wiki Dependencies; THREAT-MODEL row A plugin's dependencies), so it receives the core's
urllib3 2.8.0. What is exposed is every environment built from this lock (uv sync --locked in
CI, a developer's checkout), and the destination-policy tests prove Apprise against a urllib3
that is not the one shipped.

Impact

Developer and CI environments carry the advisories above; the suite's evidence about how the
locked Apprise sends does not describe what an instance runs. No effect on a running instance.

Fix

uv lock --upgrade-package pyjwt --upgrade-package urllib3 is the operative step; repinning the
dev group to the current core is the occasion for it, and #4 (the tests' patch point for the
resolver) must land in the same commit as that repin. Drop the "0.3.0 release line" comment or
make it true. Add the audit job #13 asks for, so the next drift is reported.

Done when: pip-audit --strict over uv export --no-emit-project of this lock finds nothing the
core's own lock does not also carry.

#13 (open) asks for the uv pin and an audit job but names no advisory; #4 (open) is the test
change the repin waits on. This issue records the advisories the lock holds today and the stale
"0.3.0" wording.

Found on 2026-10-16 in a read-only security review of `postulo-apprise` at `59e136b`, checked by a second, independent pass. **Severity:** Low · **Category:** Dependencies · **Reference:** CWE-1395 (Dependency on Vulnerable Third-Party Component); OWASP A06:2021 (Vulnerable and Outdated Components) **Location:** - `pyproject.toml:54` (`postulo @ git+...@925e3e9cd35a97617cc45b36ecdde862d04515b1`) - `pyproject.toml:49-52` (the comment still calls the pin "the 0.3.0 release line") - `uv.lock:870-872` (postulo 0.4.0 at `925e3e9cd`), and the lock's `pyjwt` 2.13.0, `urllib3` 2.7.0, `oauthlib` 3.3.1 ## Issue pip-audit 2.10.1, run on 2026-10-16 against `uv export --no-emit-project` of the lock, reports pyjwt 2.13.0 with fourteen advisories (PYSEC-2026-4140 to -4152 and -4183; fixed in 2.14.0 / 2.15.0), urllib3 2.7.0 with three (PYSEC-2026-4175, -4176, -4177; fixed in 2.8.0) and oauthlib 3.3.1 with PYSEC-2026-4114 (fixed in 4.0.0). The core's lock at `56fc9d531` holds pyjwt 2.15.1 and urllib3 2.8.0; it still holds oauthlib 3.3.1, an advisory the core accepts by name, so that one is the core's own matter. What is stale is the date the lock was *resolved* more than the core commit: postulo-templates pins a core only one day newer (`d28ef8384`, 2026-10-11) and its lock already holds pyjwt 2.15.1 and urllib3 2.8.0. pyjwt and oauthlib arrive through the pinned core (django-allauth); urllib3 is Apprise's own transport, through `requests`, and it is the library through which every webhook, ntfy and Gotify line is sent and whose redirect handling #15 is about. An instance is not what is exposed: a plugin is installed under the core's lock as a constraint (wiki *Dependencies*; THREAT-MODEL row *A plugin's dependencies*), so it receives the core's urllib3 2.8.0. What is exposed is every environment built from this lock (`uv sync --locked` in CI, a developer's checkout), and the destination-policy tests prove Apprise against a urllib3 that is not the one shipped. ## Impact Developer and CI environments carry the advisories above; the suite's evidence about how the locked Apprise sends does not describe what an instance runs. No effect on a running instance. ## Fix `uv lock --upgrade-package pyjwt --upgrade-package urllib3` is the operative step; repinning the dev group to the current core is the occasion for it, and #4 (the tests' patch point for the resolver) must land in the same commit as that repin. Drop the "0.3.0 release line" comment or make it true. Add the audit job #13 asks for, so the next drift is reported. Done when: `pip-audit --strict` over `uv export --no-emit-project` of this lock finds nothing the core's own lock does not also carry. ## Related #13 (open) asks for the uv pin and an audit job but names no advisory; #4 (open) is the test change the repin waits on. This issue records the advisories the lock holds today and the stale "0.3.0" wording.

tiagoagueda added the

bug

security

labels

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

tiagoagueda referenced this issue from Postulo/postulo

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-19 06:58:31 +00:00

Move the dev lock and the core pin forward, and pin and audit the CI tooling

tiagoagueda referenced this issue