GHSA-9pg5-8c7x-5hfx

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.

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