CVE-2026-89319 in KeyPont
Summary
by MITRE • 10/23/2026
`JweDirectDecryptorBlock.Decrypt` read a 64-bit plaintext length from the `_thales_aad` protected-header field and used it without any validation. A truncated field panics `binary.BigEndian.Uint64`, an oversized value drives an unbounded allocation, and a value larger than the decrypted block panics with a slice-bounds error.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability in question resides within the JweDirectDecryptorBlock.Decrypt function of a cryptographic library, specifically involving the handling of authentication data associated with Thales protected headers. The core technical flaw is an absence of input validation for the plaintext length field extracted from this header. During the decryption process, the system reads a 64-bit integer representing the expected size of the decrypted output directly from the _thales_aad field without performing any sanity checks on its magnitude or consistency with other parameters. This design decision creates multiple distinct failure modes depending on the value provided by an attacker-controlled input stream.
When the protected header is truncated, causing insufficient data to read a full 64-bit integer, the underlying binary.BigEndian.Uint64 function triggers a panic due to index out of bounds errors during byte slice access. This represents a classic denial-of-service vector where malformed or incomplete headers cause immediate application termination rather than graceful error handling. In scenarios where the header is complete but contains an excessively large value for the plaintext length, the system proceeds to allocate memory based on this unvalidated size. Because there are no upper bounds enforced before allocation, this leads to an unbounded memory allocation that can rapidly exhaust available system resources, resulting in a denial of service through resource exhaustion or out-of-memory conditions.
Furthermore, even if the initial read succeeds and memory is allocated, subsequent operations may fail catastrophically if the specified length exceeds the actual size of the decrypted block data. In such cases, attempts to access slice elements beyond their valid bounds trigger runtime panics with slice-bounds errors. These multiple panic points indicate a systemic lack of defensive programming practices regarding input validation in cryptographic contexts. The vulnerability allows an attacker who can influence or inject protected header fields to destabilize the application through various mechanisms including memory exhaustion and unhandled exceptions, effectively compromising availability guarantees.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation as the root cause lies in the failure to verify that input data meets expected constraints before processing. The resulting denial of service conditions correspond to CWE-400 Uncontrolled Resource Consumption and CWE-789 Uncontrolled Memory Allocation. In terms of attack patterns, this vulnerability facilitates availability attacks consistent with ATT&CK technique T1499 Endpoint Denial of Service, where attackers leverage software flaws to disrupt normal operations without necessarily gaining unauthorized access to data or system controls.
Mitigation strategies must focus on implementing rigorous input validation prior to any cryptographic operations involving external headers. Developers should enforce strict upper bounds on the plaintext length field based on known maximum message sizes for the specific encryption algorithm and key size in use. Additionally, all reads from protected header fields should be wrapped with error handling that gracefully manages truncated or malformed data rather than allowing runtime panics to propagate. It is critical to validate that the declared length does not exceed the actual available decrypted bytes before attempting any slice operations. Implementing these checks ensures that maliciously crafted headers result in controlled rejection of invalid inputs rather than application crashes, thereby maintaining service availability and integrity against exploitation attempts targeting this specific implementation flaw.