CVE-2026-119283 in joserfc
Summary
by MITRE • 10/29/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified within the joserfc Python library constitutes a significant resource exhaustion risk rooted in the handling of JSON Object Signing and Encryption standards. Specifically, the flaw resides in the decrypt_json function which processes JWE General JSON Serialization structures. In versions prior to 1.7.5, this implementation fails to impose any limit on the number of recipients defined within the recipients array of a submitted JWE payload. This architectural oversight allows an unauthenticated attacker to craft malicious requests containing a disproportionately large number of recipient entries, thereby forcing the server to perform a corresponding number of private-key decryption operations for each incoming request.
From a technical perspective, the core issue is that the library iterates through every entry in the recipients array and invokes decrypt_cek for each one before evaluating any subsequent security flags or configuration options. The verify_all_recipients setting, which is intended to validate all recipient keys, does not mitigate this specific vector because it is consulted only after the decryption loop has already completed its work. Consequently, even if the application intends to reject invalid recipients later in the processing pipeline, the computational cost of attempting each RSA key-management algorithm operation has already been incurred by the server. This design flaw effectively decouples the validation logic from the resource consumption logic, creating a predictable and exploitable pattern for denial-of-service attacks.
The operational impact of this vulnerability is primarily centered on service availability rather than data confidentiality or integrity. By submitting multiple requests with large recipient arrays, an attacker can exhaust available CPU resources on the server hosting the joserfc implementation. This type of attack falls squarely under the category of resource exhaustion, where the goal is to degrade performance for legitimate users by consuming system capacity through computationally expensive cryptographic operations. Since RSA key management algorithms involve complex mathematical computations such as modular exponentiation with large integers, even a moderate number of recipients can cause significant latency or complete service unavailability if repeated at scale.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, and maps to the ATT&CK technique T1496, known as Resource Hijacking. The attack vector is classified as Network Access since it requires only network connectivity to submit the crafted JWE payload, and authentication is not required due to the unauthenticated nature of the exploit. To mitigate this risk, organizations must upgrade immediately to version 1.7.5 or later where the recipient count limit has been implemented. Additionally, defensive measures should include implementing rate limiting on endpoints that accept encrypted payloads, validating the size and structure of incoming JWE objects before processing them through cryptographic libraries, and monitoring for unusual spikes in CPU usage associated with decryption operations.