CVE-2026-119283: 
Python vulnerability analysis and mitigation

CVE-2026-119283 is a Denial of Service vulnerability in joserfc, a Python library implementing JSON Object Signing and Encryption (JOSE) standards. Prior to version 1.7.5, the joserfc.jwe.decrypt_json() function accepts a JWE General JSON Serialization recipients array of unbounded length and performs one RSA private-key decryption operation (decrypt_cek()) per entry, with no cap on recipient count. An unauthenticated network attacker can craft a JWE with an arbitrarily large recipients array to force excessive CPU consumption on the target service. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is CWE-400 (Uncontrolled Resource Consumption) combined with CWE-606 (Unchecked Input for Loop Condition). In src/joserfc/_rfc7516/json.py, the extract_general_json() function iterates over data["recipients"] without any upper-bound check, appending a Recipient object for every entry. Subsequently, _perform_decrypt() in message.py calls decrypt_recipient() — which dispatches to a real RSA private-key operation via RSAAlgModel.decrypt_cek() — for every recipient unconditionally. Critically, the verify_all_recipients=False option does not mitigate this because the decrypt loop processes all recipients before that flag is ever consulted, as confirmed by PoC testing showing statistically identical decrypt times regardless of the flag's value (GitHub Advisory, Fix Commit).

Successful exploitation causes CPU exhaustion on the target service, rendering it unavailable to legitimate users — a pure availability impact with no effect on confidentiality or integrity. The attack is highly asymmetric: request size grows linearly at approximately 396 bytes per recipient, while server-side RSA-2048 decryption time scales in lock-step (e.g., a ~1.2 MB request with 3,000 recipients forced ~3.8 seconds of decryption in testing). Repeated or concurrent requests of this shape can exhaust all available CPU/worker capacity, causing a full denial of service for any application exposing a decrypt_json() endpoint with an RSA key-management algorithm (GitHub Advisory).

No public proof-of-concept exploit code has been released, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack requires no authentication, no special privileges, and no user interaction — only the ability to submit a JWE to an exposed endpoint and knowledge of the victim's RSA public key (which is inherently public for JWE encryption) (GitHub Advisory, Feedly).

1. Reconnaissance: Identify services that accept JWE General JSON Serialization input and use joserfc versions prior to 1.7.5 with an RSA key-management algorithm (e.g., RSA-OAEP or RSA1_5). Obtain the target service's RSA public key, which is legitimately public.
2. Craft malicious JWE: Using the victim's RSA public key, construct a JWE General JSON Serialization object with an arbitrarily large recipients array (e.g., 1,000–3,000+ entries), each entry being a valid RSA-OAEP recipient wrapping a small plaintext. Request size grows at ~396 bytes per recipient.
3. Submit the crafted JWE: Send the malicious JWE document to the target endpoint via HTTP POST (or equivalent). No authentication is required.
4. Force CPU exhaustion: The server's decrypt_json() call iterates over every recipient and performs a full RSA private-key decryption for each, consuming CPU proportional to the recipient count (e.g., 1,500 recipients → ~1.87 seconds per request).
5. Repeat for DoS: Send multiple concurrent or rapid sequential requests with oversized recipients arrays to exhaust all available CPU/worker capacity, denying service to legitimate users (GitHub Advisory).

• Network: Inbound HTTP requests with unusually large JSON bodies (hundreds of KB to several MB) targeting JWE decryption endpoints; request bodies containing a recipients array with a large number of entries (e.g., >16 entries, which is the new default cap in v1.7.5).
• Logs: Application or web server logs showing repeated large POST requests to JWE-processing endpoints from the same or rotating source IPs; elevated request processing times or timeouts on those endpoints.
• Process/System: Sustained high CPU utilization on the application server process (Python interpreter) without a corresponding increase in legitimate traffic; worker process exhaustion or queue buildup in application servers (e.g., gunicorn, uWSGI).

The primary remediation is to upgrade joserfc to version 1.7.5 or later, which introduces a max_recipients field on JWERegistry (defaulting to 16) and validates recipient count before processing begins (joserfc Release 1.7.5, Fix Commit). If immediate upgrade is not possible, implement rate limiting on JWE decryption endpoints and monitor CPU usage for anomalous patterns. Note that setting verify_all_recipients=False does not mitigate this vulnerability in affected versions, as the decrypt loop runs before that flag is consulted (GitHub Advisory).

The vulnerability was reported by researcher useworld via EQSTLab and published as a GitHub Security Advisory by the joserfc maintainer (lepture) on October 6, 2026. The fix was released promptly in version 1.7.5. Red Hat tracked the issue via Bugzilla (Bug 2563713) with high severity, and the CVE was noted on Mastodon/infosec.exchange shortly after disclosure (GitHub Advisory, Red Hat Bugzilla).