Crypt::OpenSSL::PKCS12 EUVD-2026-30707

Exploitation requires that a Perl application use Crypt::OpenSSL::PKCS12 ≤1.94 AND pass a password containing at least one 0x00 byte before the intended end - in practice this means binary, KDF-derived, HMAC-derived, or hash-output passwords rather than human-typed ASCII passphrases. The attacker must additionally obtain the resulting PKCS12 file to mount an offline attack against the truncated keyspace; the bug itself is not directly network-triggerable despite the AV:N CVSS metric. ASCII-only passphrases that never contain embedded NULs are not impacted, and applications that encode binary key material (hex, base64) before passing it to the module are also unaffected.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H yields 9.8 Critical, but that score appears to substantially overstate real-world exploitability for this specific class of bug. The vulnerability is a silent truncation in a library that processes locally-supplied password material; there is no network-reachable attack surface inherent to the module itself, so AV:N is questionable and worth verifying with the reporter. There is no CISA KEV listing and no public exploit identified at time of analysis, and EPSS data was not supplied. The realistic risk is cryptographic: PKCS12 containers created by Perl applications that feed binary/KDF-derived passwords to this module have far lower effective key strength than developers believe, making offline brute-force or dictionary attacks against captured .p12 files dramatically cheaper. Priority should therefore be governed by whether downstream applications pass binary passwords (high impact) versus human-typed ASCII passphrases (negligible impact, since those rarely contain NULs).

A developer uses Crypt::OpenSSL::PKCS12 to wrap a private key in a .p12 file, protecting it with a 32-byte HKDF-derived key that happens to contain a 0x00 at offset 5; the module silently truncates the password to 5 bytes before key derivation. An attacker who later obtains the .p12 file (via backup theft, repo leak, or interception) performs an offline brute-force against the effective 5-byte keyspace and recovers the private key in minutes rather than the assumed astronomical time. No public exploit code is identified at time of analysis, but the truncation is trivially reproducible from the description alone.