joserfc: Unbounded JWE General JSON `recipients` Array Leads to CPU Exhaustion (DoS) via Repeated RSA Private-Key Decryption
joserfc versions before 1.7.5 are affected when an application uses joserfc.jwe.decrypt_json() with an RSA-based key-management algorithm such as RSA-OAEP or RSA1_5. Fixed in 1.7.5.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- Fix
- Fixed in 1.7.5
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The joserfc Python library, which implements JOSE standards for JSON Web Encryption, is affected when it decrypts JWE General JSON messages using RSA key-management algorithms. An unauthenticated attacker who can send such a message to a service can force it to perform a large number of RSA private-key operations, consuming CPU and potentially causing a denial of service.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- authlib joserfc
fixed in 1.7.5
- joserfcPyPI
fixed in 1.7.5
References 3
GitHub · authlib/joserfc
Questions about CVE-2026-119283
What does this mean?
A JWE in General JSON Serialization can list an unlimited number of recipients, and the library performs an RSA private-key decryption for each one. A single request can therefore force many such operations and use up server CPU, causing denial of service.Source: github.com
Am I affected, and how do I check?
All joserfc versions before 1.7.5 are affected, but only where the application decrypts General JSON JWE with joserfc.jwe.decrypt_json() using an RSA-based key-management algorithm such as RSA-OAEP or RSA1_5. To check, compare the installed joserfc package version against 1.7.5 and search the code for decrypt_json() calls.Source: github.com
What should I do about it?
Upgrade joserfc to version 1.7.5 or later, which contains the fix.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data