CVE-2026-119284

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

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

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 RLIMIT_AS 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 deserialize_compact(),
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.