CVE-2022-36083 is a vulnerability classified under CWE-400 (Uncontrolled Resource Consumption) affecting the 'panva jose' library, a widely used implementation for JSON Object Signing and Encryption (JOSE) standards in JavaScript environments such as Node.js, browsers, Cloudflare Workers, Electron, and Deno. The vulnerability arises from the handling of the PBKDF2-based Password-Based Encryption Scheme 2 (PBES2) key management algorithms used in JSON Web Encryption (JWE). Specifically, the JOSE Header Parameter 'p2c' (PBES2 Count) controls the number of PBKDF2 iterations to derive the Content Encryption Key (CEK). This parameter is intended to slow down brute-force attacks by increasing computational cost. However, when JWEs are received from untrusted sources without proper restrictions, an attacker can specify an excessively high 'p2c' value, causing the decryption process to consume an unreasonable amount of CPU resources. This leads to a denial-of-service (DoS) condition by exhausting CPU cycles on the victim’s environment. The vulnerability affects versions prior to 1.28.2, 2.0.6, 3.20.4, and 4.9.2 of the jose library. Mitigations introduced in these versions include limiting the maximum PBKDF2 iteration count to 10,000 by default, with an adjustable 'maxPBES2Count' option. For users unable to upgrade, it is recommended to either disable acceptance of PBKDF2-based algorithms via the 'keyManagementAlgorithms' decryption option or pre-validate the 'p2c' header to enforce iteration count limits before decryption. Exploitation requires the victim to process JWEs from untrusted parties without such restrictions, and no authentication or user interaction is necessary beyond receiving the malicious JWE payload.

The primary impact of this vulnerability is a denial-of-service condition caused by excessive CPU consumption during JWE decryption. For European organizations relying on the panva jose library in their applications—especially those processing encrypted data from external or untrusted sources—this can lead to service degradation or outages. This is particularly critical for high-availability services, APIs, or cloud-based applications where jose is used for secure token handling or encrypted communications. The vulnerability does not directly compromise confidentiality or integrity but can disrupt availability, potentially affecting business continuity and user experience. Organizations in sectors such as finance, healthcare, telecommunications, and government services, which often handle encrypted tokens or messages, may face operational risks if the vulnerability is exploited. Additionally, the CPU exhaustion could increase operational costs due to resource overuse and may trigger cascading failures in dependent systems. Since exploitation does not require authentication or user interaction, automated or large-scale attacks are feasible if attackers can deliver malicious JWEs to vulnerable endpoints.

1. Upgrade the panva jose library to versions 1.28.2, 2.0.6, 3.20.4, or 4.9.2 or later, which enforce a default maximum PBKDF2 iteration count of 10,000 and provide the 'maxPBES2Count' option for customization. 2. If upgrading is not immediately possible, explicitly configure the 'keyManagementAlgorithms' decryption option to disable acceptance of PBKDF2-based JWE key management algorithms, thereby preventing processing of potentially malicious JWEs using these algorithms. 3. Implement pre-decryption validation of the JOSE header to inspect the 'p2c' parameter and reject JWEs with iteration counts exceeding a safe threshold, ensuring that untrusted inputs cannot trigger excessive CPU usage. 4. Employ rate limiting and input validation at the application or API gateway level to restrict the volume and size of incoming encrypted tokens from untrusted sources. 5. Monitor CPU usage and application performance metrics to detect abnormal spikes that may indicate exploitation attempts. 6. Educate development and security teams about the risks of accepting untrusted JWEs without algorithm restrictions and encourage secure default configurations in cryptographic libraries.