CVE-2026-41565

Technical summary

The vulnerability is a stack-based buffer overflow (CWE-121) in CryptX's XS (Perl C extension) routines. The affected decrypt_verify helpers copy caller-supplied AEAD authentication tags into a fixed 144-byte stack buffer (MAXBLOCKSIZE) without validating the tag length. When a tag exceeding 144 bytes is provided, the memcpy or similar operation writes beyond the buffer boundary, corrupting the stack frame. This can overwrite return addresses, saved registers, or other stack-resident data structures. The overflow is triggered during the authentication tag verification phase of AEAD decryption operations. The vulnerability requires no authentication or special privileges—any code that calls these functions with attacker-controlled tag input is exposed.

Business impact

Applications relying on CryptX for authenticated encryption may experience denial of service if an attacker injects oversized authentication tags into encrypted messages. While the CVSS vector indicates availability impact rather than confidentiality or integrity compromise, stack corruption can also lead to information disclosure or code execution in some contexts, depending on how the stack is structured and what sensitive data resides there. For services processing encrypted data from untrusted sources—such as message brokers, APIs, or peer-to-peer communication layers—this could enable remote crashes. Perl-based infrastructure, including DevOps tools and automation platforms using CryptX, may be silently affected if their threat model hasn't accounted for malicious ciphertext input.

Affected systems

Any Perl application or system using CryptX versions before 0.088_001 is potentially affected. The vulnerability is most severe in those versions that do not include the length-check safeguards. Version 0.088 patched the gcm_decrypt_verify function but left ccm_decrypt_verify, chacha20poly1305_decrypt_verify, and eax_decrypt_verify unprotected until version 0.088_001. Organizations running CryptX should audit their module versions and check the impact of the four affected AEAD decrypt_verify functions in their codebase.

Exploitability

This vulnerability has a low barrier to exploitation. An attacker needs only to craft a message with an oversized authentication tag and transmit it to a system processing CryptX-encrypted data. No user interaction is required, and the attack can be conducted remotely over the network. The CVSS score of 7.5 (HIGH) reflects the network accessibility and lack of authentication requirements. However, practical exploitation depends on whether the application's threat model includes untrusted ciphertext as an input vector and whether the stack overflow reliably crashes the process or can be leveraged for code execution. The vulnerability is not currently listed in the Known Exploited Vulnerabilities (KEV) catalog, suggesting that active, widespread exploitation has not yet been documented.

Remediation

Upgrade CryptX to version 0.088_001 or later immediately. This version includes length-checking safeguards for all four affected AEAD decrypt_verify functions. Organizations should verify that the upgrade is compatible with their Perl version and other module dependencies. After patching, perform smoke tests on critical encrypted communication paths to ensure functionality is preserved. For systems unable to upgrade immediately, consider network-level input validation to reject messages with unusually large authentication tags, though this is a temporary mitigation only.

Patch guidance

Update CryptX from CPAN or your preferred Perl module repository to version 0.088_001 or later. Verify the patched version by checking the installed module version in your Perl environment (e.g., perl -MCryptX -e 'print $CryptX::VERSION'). If you are on version 0.088, be aware that this partially addresses the issue—only gcm_decrypt_verify is protected; upgrade to 0.088_001 to protect all four functions. Test the upgrade in a staging environment before rolling out to production, particularly if CryptX is a transitive dependency of other modules or if your code relies on specific behavior of the decrypt_verify functions.

Detection guidance

Monitor for crashes or denial of service in applications using CryptX, particularly in decryption or message-processing code paths. Look for segmentation faults or stack overflow exceptions in Perl interpreter logs. If you have access to application logs, watch for error messages related to cryptographic verification failures or unexpected crashes in code calling CryptX's AEAD functions. Network-level detection is challenging without deep packet inspection, but anomalously large authentication tags in encrypted protocol frames can be flagged as suspicious. Audit your codebase to identify which AEAD functions are being called and whether the authentication tag input comes from untrusted sources.

Why prioritize this

This vulnerability merits prompt attention due to its HIGH CVSS score (7.5), network exploitability, and lack of authentication requirements. While it does not currently appear in the KEV catalog, the ease of triggering a denial of service and the potential for stack corruption to lead to further compromise justify treating it as a priority. Organizations heavily dependent on Perl infrastructure for cryptographic operations should prioritize patching. However, the lack of widespread active exploitation and the requirement for the application to process untrusted AEAD-encrypted input means this can be scheduled in the near term rather than as an emergency zero-day response.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) is justified by the network vector (no special access required), low attack complexity (simple tag injection), and high availability impact (denial of service via crash). The vector indicates no confidentiality or integrity impact, suggesting that the overflow does not directly leak secrets or corrupt encrypted data, but rather causes process termination. However, stack-based buffer overflows can occasionally be chained with other weaknesses to achieve code execution; a defense-in-depth approach is warranted.

Frequently asked questions