CVE-2026-48990: joserfc Python Library DOS Vulnerability

CVE-2026-48990 Overview

CVE-2026-48990 is a resource exhaustion vulnerability in joserfc, a Python library implementing JSON Object Signing and Encryption (JOSE) standards. The flaw affects versions 1.3.4 through 1.6.5. The library fails to enforce JWSRegistry.max_payload_length on RFC7797 b64=false JSON Web Signature (JWS) payloads. Compact and flattened JSON JWS paths correctly reject oversized payloads with ExceededSizeError, but the unencoded payload paths skip this check. Applications relying on joserfc to bound untrusted JWS content during verification face an availability risk. The issue is fixed in version 1.6.7.

Critical Impact
Attackers can submit oversized RFC7797 unencoded JWS payloads that bypass max_payload_length enforcement, consuming memory and CPU resources on services that verify lower-trust JWS values.

Affected Products

joserfc versions 1.3.4 through 1.6.5
Python applications using joserfc for JWS verification with RFC7797 b64=false support
Services accepting compact or flattened JSON JWS tokens from lower-trust sources

Discovery Timeline

2026-06-17 - CVE-2026-48990 published to NVD
2026-06-17 - Last updated in NVD database
Fix released - joserfc version 1.6.7 published on GitHub. See GitHub Release 1.6.7 and GitHub Security Advisory GHSA-wphv-vfrh-23q5.

Technical Details for CVE-2026-48990

Vulnerability Analysis

The joserfc library implements RFC 7515 JSON Web Signature and RFC 7797 unencoded payload option support. RFC 7797 allows JWS payloads to carry raw, non-base64url-encoded content using the b64=false header parameter. The library exposes JWSRegistry.max_payload_length to let applications enforce a maximum payload size during verification. This control protects services from processing arbitrarily large tokens supplied by untrusted clients.

The normal compact serialization and flattened JSON serialization deserialization paths validate payload length and raise ExceededSizeError when the limit is exceeded. The RFC 7797 unencoded payload handling code paths omit this size check. A signed JWS that includes the b64=false critical header therefore passes through deserialization regardless of how large the payload is.

This weakness aligns with [CWE-400] Uncontrolled Resource Consumption. The impact is limited to availability, as confirmed by the vector showing no confidentiality or integrity impact.

Root Cause

The RFC 7797 code paths in joserfc do not invoke the same payload-size guard used in the encoded payload branches. Size validation logic is duplicated rather than centralized, so the unencoded branch silently accepts payloads exceeding JWSRegistry.max_payload_length.

Attack Vector

An attacker submits a valid b64=false compact or flattened JSON JWS containing a payload larger than the application's configured max_payload_length. The verifier accepts and processes the oversized payload, consuming memory and CPU. Repeated submissions amplify the resource pressure and can degrade service availability. The attack requires no authentication and is delivered over the network.

No verified public proof-of-concept code is available. Refer to the GitHub Security Advisory GHSA-wphv-vfrh-23q5 for technical details on the affected code paths.

Detection Methods for CVE-2026-48990

Indicators of Compromise

Inbound JWS tokens carrying the b64 header parameter set to false from untrusted clients.
Unusually large request bodies on endpoints that verify JWS tokens using joserfc.
Spikes in process memory or CPU on services performing JWS verification without corresponding traffic volume increases.

Detection Strategies

Inventory Python services and dependencies to identify use of joserfc versions 1.3.4 through 1.6.5.
Inspect JWS protected headers at the application or proxy layer for the b64 parameter and crit extension entries referencing it.
Add application logging to record payload sizes processed by JWSRegistry and alert on values approaching or exceeding the configured max_payload_length.

Monitoring Recommendations

Monitor request size distributions on JWS verification endpoints and alert on outliers.
Track memory growth and garbage collection pressure in worker processes handling token verification.
Correlate authentication failures and timeouts with bursts of large b64=false token submissions.

How to Mitigate CVE-2026-48990

Immediate Actions Required

Upgrade joserfc to version 1.6.7 or later in all Python services that verify JWS tokens.
Audit dependency manifests (requirements.txt, pyproject.toml, Pipfile.lock) to confirm no transitive pin holds the vulnerable range.
Add a request body size limit at the reverse proxy or web framework layer in front of any JWS verification endpoint.

Patch Information

The maintainers fixed the issue in joserfc1.6.7. The release applies the JWSRegistry.max_payload_length check to RFC 7797 b64=false code paths so oversized payloads raise ExceededSizeError consistently. See the GitHub Release 1.6.7 notes and the GitHub Security Advisory GHSA-wphv-vfrh-23q5 for the upstream advisory.

Workarounds

Enforce a strict maximum request body size at the HTTP server, ingress, or API gateway layer.
Reject incoming JWS tokens whose protected header contains b64=false if RFC 7797 support is not required.
Run JWS verification workers with strict memory limits and process restart policies to contain resource pressure until patching completes.

bash

# Upgrade joserfc to the fixed release
pip install --upgrade 'joserfc>=1.6.7'

# Verify the installed version
python -c "import joserfc, importlib.metadata; print(importlib.metadata.version('joserfc'))"