Crypt::OpenSSL::X509 CVE-2026-58102
CRITICALSeverity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
A single crafted certificate parsed by the app triggers it (AV:N/AC:L/PR:N/UI:N); heap disclosure justifies C:H, while an over-read only sometimes crashes, so A:L not A:H and no integrity impact.
Primary rating from Vendor (CPANSec).
CVSS VectorVendor: CPANSec
Lifecycle Timeline
5DescriptionCVE.org
Crypt::OpenSSL::X509 versions before 2.1.3 for Perl allow a heap out-of-bounds read via a long certificate extension OID in hv_exts.
When building the extension hash (via extensions(), extensions_by_long_name(), extensions_by_oid(), or has_extension_oid()), the code passes OBJ_obj2txt()'s return value as the hash-key length; because that value is the OID's full text length rather than the bytes written to the fixed-size buffer (129 bytes), an OID whose text is longer than the 129-byte buffer causes a read past the allocation, exposing adjacent heap memory as the returned hash key. extensions_by_name() uses the static shortname path and is not affected.
Articles & Coverage 1
AnalysisAI
Heap out-of-bounds read in the Crypt::OpenSSL::X509 Perl module (versions before 2.1.3) lets a crafted X.509 certificate leak adjacent heap memory to an application that enumerates certificate extensions. When code calls extensions(), extensions_by_long_name(), extensions_by_oid(), or has_extension_oid(), a certificate extension whose textual OID exceeds the fixed 129-byte buffer causes the returned hash key to include bytes read past the allocation, exposing process memory and risking a crash. No public exploit is identified at time of analysis and it is not in CISA KEV, but the fix is confirmed in release 2.1.3 and the flaw is trivially triggerable by any attacker who can supply a certificate.
Technical ContextAI
Crypt::OpenSSL::X509 is a widely-used CPAN binding (XS/C glue over OpenSSL) that lets Perl programs parse and inspect X.509 certificates. The bug lives in the hv_exts() routine in X509.xs, which builds a Perl hash of certificate extensions. It calls OpenSSL's OBJ_obj2txt() to render each extension's object identifier (OID) into a fixed 129-byte stack/heap buffer, but OBJ_obj2txt() returns the FULL textual length the OID would require, not the number of bytes actually written to the buffer. That return value is then passed to hv_store() as the key length, so for an OID whose text is longer than the buffer, hv_store() reads bytes beyond the allocation. This is a classic CWE-125 Out-of-bounds Read: a length/size confusion between 'bytes written' and 'bytes needed'. The affected code path is limited to functions that use the numeric/long OID path; extensions_by_name(), which uses the static OpenSSL short-name path, is explicitly not affected. Per the CPE cpe:2.3:a:jonasbn:crypt::openssl::x509, all versions prior to 2.1.3 are impacted.
RemediationAI
Vendor-released patch: upgrade to Crypt::OpenSSL::X509 version 2.1.3 or later, which sizes the key buffer to the length reported by OBJ_obj2txt() and stores strlen() of the written key instead of the return value (fix commit https://github.com/dsully/perl-crypt-openssl-x509/commit/757289bfce095455c104d4adfe9312e7b339620f.patch; release notes at https://metacpan.org/release/JONASBN/Crypt-OpenSSL-X509-2.1.3/source/Changes.md). Update via your CPAN client (e.g. cpanm Crypt::OpenSSL::X509@2.1.3) or your OS/distro package once it ships 2.1.3. If you cannot upgrade immediately, the concrete compensating control is to avoid the affected code paths on untrusted input: do not call extensions(), extensions_by_long_name(), extensions_by_oid(), or has_extension_oid() on attacker-supplied certificates, and where you only need name-based lookups use extensions_by_name(), which uses the static short-name path and is not affected (trade-off: you lose access to arbitrary/long-OID extensions). Alternatively, pre-validate or reject certificates before parsing (e.g. via a hardened OpenSSL preprocessing step), accepting the added processing overhead. See the oss-security advisory at https://seclists.org/oss-sec/2026/q3/129 for details.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto
Same weakness CWE-125 – Out-of-bounds Read
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today