Cloudanix VulnDB

CVE-2026-119284

None

CVSS

—

EPSS

0.2%

Published

Oct 29, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A bug in a Python library that handles secure web tokens can let attackers send specially crafted large tokens that crash the application by using up all its memory, so updating the library prevents the service from being knocked offline.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Library
Class
Denial of service
Remediation
Upgrade
Effort
Low
Patch risk
Low

What it actually does

In joserfc prior to 1.7.6, deserialize_compact performs bytes.split on attacker-supplied compact JWS data before aggregate segment-size limits are enforced, creating additional proportional allocations of header, payload, and signature segments that can exhaust process memory.

Why it matters to the business

Applications relying on joserfc for JWS processing can be forced into memory exhaustion, resulting in service unavailability even when signature verification ultimately fails; the low EPSS and recent publication indicate limited observed exploitation but still require prompt attention for availability-sensitive workloads.

How an attack unfolds

An unauthenticated attacker supplies an oversized compact JWS token to any code path invoking deserialize_compact; the split operation allocates copies of all three segments before ExceededSizeError is raised, allowing repeated requests to deplete available memory and trigger an availability failure.

How to fix it

Upgrade joserfc to version 1.7.6 or later, which enforces size limits prior to performing the split allocation; where immediate upgrade is not feasible, add input-size validation or request-rate limiting in front of any deserialize_compact call.

How to confirm the fix worked

Confirm the installed joserfc version is 1.7.6 or newer via package metadata; replay large token test cases and verify that memory usage remains bounded and ExceededSizeError is raised without excessive allocation.

Typical attack path

  1. Identify an endpoint or API that invokes joserfc deserialize_compact on untrusted compact JWS input
  2. Craft and send a compact serialization whose total size exceeds configured segment limits but triggers split allocation first
  3. Repeat requests to accumulate memory pressure until the process is terminated or degraded

How to detect it

Review application and system logs for memory-allocation failures or OutOfMemory errors coinciding with JWS deserialization calls; inspect request logs for unusually large compact JWS strings submitted to affected endpoints.

What your security team should do

  • Upgrade all instances of joserfc to 1.7.6 within the next maintenance window
  • Inventory code paths that call deserialize_compact and add defensive size checks if upgrade is delayed
  • Monitor process memory metrics for applications that process JWS tokens

The record

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.6, joserfc compact JWS deserialization calls bytes.split() before enforcing the existing aggregate segment-size limits. When attacker-controlled compact serialization bytes reach deserialize_compact(), the split creates copies of the header, payload, and signature segments before ExceededSizeError rejects them, causing an additional allocation approximately proportional to the supplied token. Requests that exhaust available process memory can therefore cause an availability failure even though signature verification fails. This issue is fixed in version 1.7.6.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities