joserfc CVE-2026-119284

Exploitation requires that the application actually feed attacker-controlled bytes into joserfc's compact JWS path - deserialize_compact() / extract_rfc7515_compact() - i.e. an endpoint that verifies untrusted JWS tokens using joserfc ≤ the vulnerable version. No authentication, user interaction, or non-default configuration is needed once that code path is reachable (PR:N/UI:N). The key LIMITING factor is the ~1.0× amplification measured by the vendor: because the induced allocation is roughly proportional (not multiplicative) to the supplied token, the attacker must send large tokens and/or sustain concurrent requests to drive a worker toward MemoryError, making this a bandwidth-bound availability failure rather than a single-packet crash.

This is a medium-severity availability-only issue, not an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scoring 6.9 indicates a remote, low-complexity, unauthenticated trigger, but the only impact is availability (VA:L) - there is no confidentiality or integrity exposure (VC:N/VI:N). KEV status is not indicated in the input (treat as not listed), and no EPSS score was provided, so widespread-exploitation probability cannot be quantified from the data supplied. Critically, the vendor's own GHSA reproduction table shows amplification of roughly 1.0× (e.g. 64 MiB input → ~63.8 MiB peak RSS delta), meaning this is NOT a memory-amplification 'bomb': an attacker must transmit roughly as many bytes as the transient allocation they induce. That bandwidth-bound property materially lowers real-world DoS severity versus a classic resource-exhaustion amplifier. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a genuine but non-urgent fix priority. Note a fixed-version conflict across sources that should be verified (see confidence_notes).

An application exposes JWS verification on untrusted input and passes attacker-controlled compact serialization bytes to joserfc's deserialize_compact(). A remote unauthenticated attacker submits an oversized compact JWS token; before the aggregate size guard rejects it, Python's bytes.split(b'.') copies the header, payload, and signature segments, creating an additional token-sized allocation even though signature verification ultimately fails. A public reproduction/profiling script is referenced in the GHSA advisory but it is not verified as working weaponized exploit code.