CVE-2026-53938 in cjose
Summary
by MITRE • 09/09/2026
OpenIDC/cjose is a C library implementing the Javascript Object Signing and Encryption (JOSE). Prior to version 0.6.2.5, cjose's JWE decryption path for the AES Key Wrap key-management algorithms (`alg` = `A128KW`, `A192KW`, `A256KW`) does not validate the length of the attacker-supplied `encrypted_key` (JWE Encrypted Key) before unwrapping it into a fixed-size, heap-allocated Content Encryption Key (CEK) buffer. A remote, unauthenticated attacker who can submit a crafted JWE to an application that decrypts it with an AES-KW symmetric key can trigger an out-of-bounds heap write, corrupting the heap. This leads at minimum to a crash (denial of service) and, depending on the heap layout and allocator, may be leverageable for further memory-corruption impact. `cjose_jwe_import()` / `cjose_jwe_decrypt()` are pre-authentication entry points: they parse and process fully attacker-controlled input. Upgrade to cjose 0.6.2.5 to receive a patch. If upgrading is not immediately possible, reject the AES Key Wrap algorithms (`A128KW`/`A192KW`/`A256KW`) for untrusted JWEs at the application layer.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability resides within cjose, a C library designed to implement the Javascript Object Signing and Encryption standards defined by JOSE. Specifically, this flaw affects the decryption path used when processing JSON Web Encryption payloads that utilize AES Key Wrap algorithms for key management, including A128KW, A192KW, and A256KW. The core technical deficiency is a missing input validation check regarding the length of the encrypted_key field contained within the JWE structure. When an application invokes functions such as cjose_jwe_import or cjose_jwe_decrypt to process incoming data, these entry points parse the attacker-controlled input without verifying that the provided encrypted key matches the expected size for the specific algorithm being used. This lack of validation allows a remote, unauthenticated actor to supply a malformed JWE with an encrypted_key value whose length exceeds the fixed-size buffer allocated on the heap for storing the Content Encryption Key.
Upon processing this crafted payload, the library proceeds to unwrap the key into the pre-allocated memory space without bounds checking. This results in an out-of-bounds heap write operation where data is written beyond the boundaries of the intended buffer. Such a memory corruption event poses significant risks to system stability and security integrity. The immediate operational impact typically manifests as a crash, leading to a denial of service condition for any application relying on this library for decryption services. However, depending on the specific heap layout and the underlying memory allocator implementation, an attacker may be able to leverage this out-of-bounds write to overwrite adjacent metadata or data structures. This potential for further exploitation means that beyond simple disruption, the vulnerability could potentially lead to arbitrary code execution if the attacker can carefully control the overwritten content and trigger a subsequent use of corrupted pointers or function return addresses.
From a classification perspective, this issue aligns with CWE-120, which describes buffer copy without checking size limits, leading to heap-based buffer overflow conditions. In terms of adversarial tactics, this vulnerability facilitates exploitation techniques associated with memory corruption attacks often seen in the ATT&CK framework under categories related to execution and privilege escalation via binary vulnerabilities. The attack vector is remote and requires no prior authentication, making it particularly dangerous for services that accept JWE payloads from external sources without strict pre-validation layers.
To mitigate this risk, organizations should prioritize upgrading cjose to version 0.6.2.5 or later, as the patch includes necessary validation logic to ensure the encrypted key length matches expectations before unwrapping. For environments where immediate upgrade is not feasible due to dependency constraints or testing requirements, a defensive configuration change at the application layer is recommended. Specifically, applications should be configured to reject any JWE payloads that utilize AES Key Wrap algorithms such as A128KW, A192KW, and A256KW when processing untrusted input. This workaround effectively neutralizes the attack surface by preventing the vulnerable code path from being executed with maliciously crafted inputs until a permanent fix can be deployed.