CVE-2026-119284: joserfc: Compact JWS size guard allocates attacker-controlled segments before rejection
Summary
joserfc 1.7.4 defines compact-JWS header, payload, and signature limits, but calls value.split(b".") before validating them. Python bytes.split() copies the attacker-controlled segments, so the current guard allocates roughly one complete payload before rejecting it.
Reproduction
bash .venv-research/bin/python 06-practical-testing/preauth-memory-profile.py
The input is resident before a fork-isolated verifier runs, and every signature is invalid.
| Input | Peak RSS delta | Amplification | Result | |---:|---:|---:|---| | 1 MiB | 1.11 MiB | 1.11× | size rejected | | 4 MiB | 4.04 MiB | 1.01× | size rejected | | 8 MiB | 8.04 MiB | 1.01× | size rejected | | 16 MiB | 16.04 MiB | 1.00× | size rejected | | 32 MiB | 31.74 MiB | 0.99× | size rejected | | 64 MiB | 63.80 MiB | 1.00× | size rejected |
The unconstrained profile is the primary evidence: joserfc allocates an additional attacker-sized object before producing its intended ExceededSizeError. A separate baseline-plus-headroom stress test raises MemoryError when that copy cannot fit, but this report does not characterize an absolute RLIMITAS value as a realistic worker memory budget.
Security Argument
The issue is not that joserfc can prevent the transport layer from receiving a large header. The issue is narrower: once bytes reach deserializecompact(), the library's existing size guard cannot fulfill its allocation-limiting purpose because attacker-controlled segment copies are created first.
This differs from GHSA-frfh-8v73-gjg4, which concerned embedding already-loaded oversized segments in exception and log messages. Here, the current implementation itself creates an additional payload-sized allocation before its fixed size exception.
Recommended Fix
Check len(value) against a maximum compact-serialization size before split(). If per-segment diagnostics are needed, locate delimiters with bounded find() operations or memory views, validate offsets and lengths, and only then materialize acceptable segments.
Other sources
joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.6, joserfc compact JWS deserialization calls bytes.split() before enforcing the existing aggregate segment-size limits. When attacker-controlled compact serialization bytes reach deserializecompact(), the split creates copies of the header, payload, and signature segments before ExceededSizeError rejects them, causing an additional allocation approximately proportional to the supplied token. Requests that exhaust available process memory can therefore cause an availability failure even though signature verification fails. This issue is fixed in version 1.7.6.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/joserfcto a version that resolves this vulnerability.Fixed in 1.7.7-1 - Upgrade
Upgrade
pip/joserfcto a version that resolves this vulnerability.Fixed in 1.7.6 - Upgrade
Upgrade
joserfcto a version that resolves this vulnerability.Fixed in 1.7.6
Event History
Frequently Asked Questions
What attacker access is required to trigger the memory consumption?
An attacker needs to supply a compact JWS value to code that processes it. The reproduced inputs used invalid signatures, so a valid signature is not required for the additional allocation to occur.
Are configured compact-JWS segment limits sufficient to prevent the allocation?
No. In joserfc 1.7.4, the input is split into copied segments before the header, payload, and signature limits are validated. The library then raises its intended ExceededSizeError, but only after allocating roughly another attacker-sized object.
How can this be identified during triage?
Affected processing may show a peak RSS increase approximately equal to the size of an oversized compact-JWS input, followed by a size rejection. Under constrained memory, the extra copy may instead cause MemoryError before the intended rejection completes.
Which release should be reviewed for remediation?
The provided references include the joserfc 1.7.6 release and the upstream fix commit. joserfc 1.7.4 is specifically identified as affected in the report.