joserfc EUVD-2026-37805

Exploitation requires that the target application accepts JWS tokens bearing the RFC7797 'b64=false' critical header parameter from untrusted or lower-trust callers, and that it relies on joserfc's JWSRegistry.max_payload_length enforcement to bound payload size rather than applying an independent size check before token deserialization. Applications that process only default Base64URL-encoded JWS tokens are not affected; the vulnerability is exclusive to the unencoded-payload code path. The CVSS PR:N/UI:N metrics indicate no attacker authentication or user interaction is required, but effective exploitation is bounded by whether the application exposes an endpoint that processes b64=false JWS input from external sources. Deployments with HTTP body size limits enforced at a proxy or load balancer layer upstream of joserfc reduce the practical risk even on affected library versions.

The CVSS 3.1 base score of 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L correctly characterizes this as a remotely reachable, low-complexity denial-of-service issue limited to availability impact. No EPSS score was provided in the input data, so relative exploitation probability cannot be quantified. The vulnerability is not listed in the CISA KEV catalog and no public exploit code has been referenced. The practical blast radius is narrower than the PR:N CVSS metric suggests: only applications that (1) actively accept JWS tokens carrying the RFC7797 b64=false header from lower-trust or external callers, and (2) rely exclusively on joserfc's internal size limit enforcement, are exposed. Deployments that enforce payload size at the HTTP or application gateway layer before invoking joserfc are effectively unaffected. The A:L (Limited) availability rating suggests degraded performance or increased resource consumption rather than immediate process termination, reducing urgency relative to a crash-inducing flaw at the same CVSS score.

An attacker targeting an application that accepts externally supplied JWS tokens - such as a token-validated API endpoint - crafts a syntactically valid JWS with the RFC7797 b64=false header and a multi-megabyte unencoded payload, then submits it repeatedly or with maximum size. Because joserfc's RFC7797 deserialization path omits the max_payload_length check, the server allocates memory proportional to the payload on each verification call, leading to elevated memory consumption or CPU saturation. No public exploit code is known, but the attack requires only knowledge of the JWS format and the ability to reach the endpoint.