Critical CVE-2025-65015 Vulnerability in joserfc Could Let Attackers Exhaust Server Resources via Oversized JWT Tokens

A widely used Python library implementing JOSE standards, joserfc, has disclosed a critical uncontrolled resource consumption vulnerability—tracked as CVE-2025-65015 with a CVSS score of 9.2—that can be triggered simply by logging an attacker-supplied, extremely large JWT payload.

At the center of this issue is how the library embeds parts of JWT tokens inside exception messages, which can create massive log entries under the right conditions.

According to the advisory, the problem appears when malformed or intentionally oversized JWTs pass through joserfc.jwt.decode() or its internal validation routines.

The adivsory explains: “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.”

Because the malicious JWT has already been fully loaded into memory before the library can reject it, logging the exception causes the entire forged payload to be written to:

application logs
external log ingestion systems
SIEM platforms
observability tools (e.g., Sentry)

This can overwhelm CPU, memory, disk I/O, or network-based log pipelines.

The vulnerability is not due to broken cryptography inside joserfc, but rather the absence of strict header-size enforcement in many Python deployments.

As the advisory warns, “An attacker may be able to send arbitrarily large bearer tokens in the HTTP request headers… Python logging or diagnostic tools may end up processing extremely large log messages.”

Crucially, these oversized requests are supposed to be rejected before they ever reach the Python application layer. But many modern stacks lack that protection.

Examples provided in the advisory include:

FastAPI/Starlette without uvicorn/gunicorn → no header-size enforcement
uvicorn/h11 → supports –h11-max-incomplete-event-size but cannot cap header-only size
vLLM serve → defaults to 4 MB, often increased for ML workloads
Apps not behind nginx or a reverse proxy → completely unprotected

The authors emphasize this design limitation: “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.”

If a system accepts oversized headers, simply decoding the JWT can trigger a cascade of failures.

The advisory states this can lead to: “Allocation of Resources Without Limits or Throttling (CWE-770), potentially impacting disk, memory, and CPU… as well as any external log storage, ingestion pipelines or alerting services.”

This means the vulnerability can be abused to:

crash application servers due to memory pressure
flood SIEM/log pipelines with massive entries
cause monitoring outages
trigger denial-of-service (DoS) conditions across distributed systems

Notably, the attack requires no authentication, just the ability to send HTTP requests containing large JWTs.

The joserfc library, which boasts over 7.7 million monthly downloads, has released patches in versions 1.3.5 and 1.4.2. Users running affected versions >=1.3.3 and <=1.4.1 are urged to upgrade immediately.

The fix removes the raw JWT payload from the ExceededSizeError exception messages so oversized tokens cannot expand into massive logs.

The advisory states: “This risk can be mitigated by removing the JWT payload from the logged content in some ExceededSizeError exception message occurrences.”

Additionally, the maintainers recommend updating documentation to strongly encourage users to deploy behind proper reverse proxies, such as nginx, which can enforce strict maximum header sizes.

Rate this post

Related Posts:

Found this helpful?

Leave a Reply Cancel reply