GHSA-wphv-vfrh-23q5 joserfc: b64=false RFC7797 JWS payloads bypass JWSRegistry payload-size limits during deserialization
RFC7797 b64=false JWS payloads bypass JWSRegistry payload-size limits during deserializationSummaryTesting revealed that `joserfc` accepts oversized RFC7797 `b64=false` JWS payloads without applying `JWSRegistry.max_payload_length`.The normal JWS compact and flattened JSON paths reject payloads above the configured payload-size limit with `ExceededSizeError`. The RFC7797 unencoded payload paths do not make the same check. A valid `b64=false` compact or flattened JSON JWS can therefore deserialize successfully with a payload larger than `JWSRegistry.max_payload_length`.This creates a moderate availability/resource-exhaustion risk for applications that accept lower-trust JWS values and rely on `joserfc` to reject oversized token content during verification.Affected ProductPackage: `joserfc`Ecosystem: `pip`Audited release: `1.6.5`Audit tag: `1.6.5`Audit commit: `881712980934fb601bed26fe3ae1ec0b7780e6f7`Tested affected releases: `1.3.4`, `1.3.5`, `1.4.2`, `1.6.2`, `1.6.3`, `1.6.4`, `1.6.5`Fixed release: none knownVulnerability DetailsIn `joserfc` 1.6.5, the default JWS registry has `max_payload_length = 128000` and exposes `validate_payload_size()`.The normal compact extraction path calls that check before base64url-decoding the payload. The RFC7797 compact path validates the header and signature segment sizes, then assigns the unencoded payload directly:The flattened JSON RFC7797 path has the same pattern:Neither branch calls `registry.validate_payload_size(payload_segment)` before accepting the unencoded payload.ReproductionThe proof below uses only local Python APIs. It signs a payload one byte over the default limit and then compares normal JWS behavior with RFC7797 `b64=false` behavior.Requirements:Run:Self-contained proof script:Expected output on `1.6.5` includes:Version ChecksI reproduced the same differential behavior on these releases:| Version | Normal JWS over limit | RFC7797 `b64=false` over limit |
| --- | --- | --- |
| 1.3.4 | `ExceededSizeError` | accepted |
| 1.3.5 | `ExceededSizeError` | accepted |
| 1.4.2 | `ExceededSizeError` | accepted |
| 1.6.2 | `ExceededSizeError` | accepted |
| 1.6.3 | `ExceededSizeError` | accepted |
| 1.6.4 | `ExceededSizeError` | accepted |
| 1.6.5 | `ExceededSizeError` | accepted |The exact earliest affected release may be broader. The versions above are the releases I directly tested where the JWS size-limit boundary exists and the RFC7797 path bypasses it.Relationship to Existing AdvisoriesI found two related public advisories for `joserfc`, but neither appears to cover this root cause.`GHSA-frfh-8v73-gjg4` / `CVE-2025-65015` describes oversized token parts being included in `ExceededSizeError` messages in older release ranges. The issue described here reproduces in `1.6.5` and is not about exception message content. The oversized RFC7797 payload is accepted instead of raising `ExceededSizeError`.`GHSA-w5r5-m38g-f9f9` / `CVE-2026-27932` describes unbounded PBES2 `p2c` iteration counts during JWE decryption. The issue described here is in JWS RFC7797 payload extraction and does not involve PBES2 or JWE decryption.WorkaroundsBefore a fixed release is available, affected applications can reduce exposure by rejecting oversized serialized JWS inputs before passing them to `joserfc`, disabling or disallowing RFC7797 `b64=false` tokens if not needed, and enforcing strict request/header/body size limits at the application or reverse-proxy layer.Suggested RemediationApply `registry.validate_payload_size(payload_segment)` to RFC7797 unencoded payloads before assigning them to the JWS object in both compact and flattened JSON extraction paths. Detached RFC7797 compact payloads supplied through the `payload` argument should be checked in the same way.
CVSS v3.1 score: 5.3