CVE-2026-31789

What it actually does

This vulnerability is a heap buffer overflow in OpenSSL code that converts OCTET STRING values from X.509 certificate extensions into hexadecimal text. If a 32-bit build processes an excessively large OCTET STRING, such as a Subject Key Identifier or Authority Key Identifier, the required output buffer size is calculated using a multiplication by 3 that can wrap around. The application may then allocate a buffer that is too small and overwrite heap memory while rendering the value as hex. The most likely result is process crash and denial of service, but memory corruption can theoretically lead to attacker-controlled code execution depending on allocator behavior, compile-time hardening, and the vulnerable application’s execution context. OpenSSL FIPS modules are not affected because the vulnerable code is outside the FIPS module boundary.

Why it matters to the business

Affected services that run 32-bit OpenSSL and print or log untrusted X.509 certificate contents could be crashed remotely by a specially crafted, unusually large certificate. In a worst case, exploitation could allow compromise of the process handling certificates, potentially affecting confidentiality, integrity, and availability of the service. Practical exploitation is constrained because the certificate must contain very large extension data, reportedly over 1 GB, and the vulnerable conversion path must be reached, making broad opportunistic exploitation less likely despite the high theoretical CVSS score. EPSS is currently low and flat, it is not listed in CISA KEV, and there is no reported ransomware use, so prioritization should focus first on internet-facing or certificate-processing workloads that still use 32-bit OpenSSL builds.

How an attack unfolds

An attacker first identifies an application or service using a vulnerable 32-bit OpenSSL build that accepts untrusted X.509 certificates and prints, logs, audits, or otherwise renders certificate extensions as hexadecimal strings. The attacker then creates a malformed or intentionally oversized certificate containing a very large OCTET STRING in an extension such as Subject Key Identifier or Authority Key Identifier. When the target receives the certificate through a supported workflow, such as a TLS client-certificate exchange, certificate upload, S/MIME or PKI processing, or a diagnostic certificate-inspection function, the application invokes OpenSSL routines that convert the extension bytes to hex. On 32-bit platforms, the size calculation wraps, a too-small heap buffer is allocated, and subsequent writes overflow that buffer. The attacker’s practical outcome is usually a crash of the certificate-processing process; in favorable memory-layout conditions, the overflow may be shaped toward arbitrary code execution or other undefined behavior.

How to fix it

Upgrade OpenSSL to a vendor-provided version that includes the fix when available for the affected branch and platform. Because exact fixed versions were not provided in the input, track the OpenSSL project advisory and operating-system or appliance vendor security advisories for package-specific fixed builds. Where possible, migrate affected workloads from 32-bit OpenSSL builds to supported 64-bit builds, since the described overflow condition is specific to 32-bit platforms. Until patched, reduce exposure by rejecting or size-limiting unusually large certificates before OpenSSL extension rendering occurs, disabling verbose printing or logging of untrusted certificate extension contents, avoiding diagnostic commands that render untrusted certificates in production workflows, and placing resource limits around certificate-processing services. The OpenSSL FIPS modules in the listed 3.x branches are not affected, but applications using non-FIPS OpenSSL code paths still need assessment.

How to confirm the fix worked

Inventory systems and applications that use OpenSSL and determine whether they are built for 32-bit architectures. Confirm whether those applications accept untrusted X.509 certificates and whether they call certificate printing, logging, or inspection functionality for SKID, AKID, or other OCTET STRING extensions. Validate remediation by checking package manager metadata, OpenSSL library versions, vendor advisory status, and application linkage against the patched library. Confirm that certificate size limits or logging suppressions are enforced by attempting to process large but non-malicious test certificates in a controlled environment and verifying they are rejected before extension-to-hex conversion. Monitor for absence of repeat crashes in OpenSSL-consuming services after patching or mitigation.

Typical attack path

1. Find a target application or service using a vulnerable 32-bit OpenSSL build.
2. Confirm the target accepts untrusted X.509 certificates and logs, prints, or inspects certificate extensions.
3. Generate a crafted X.509 certificate containing an excessively large OCTET STRING in an extension such as SKID or AKID.
4. Deliver the certificate through a supported input path, such as TLS client authentication, certificate upload, mail or document processing, or certificate diagnostic tooling.
5. Trigger certificate rendering or logging that converts the OCTET STRING value to a hexadecimal string.
6. Cause 32-bit integer overflow during output-buffer size calculation, followed by heap buffer overflow.
7. Achieve denial of service through process crash, or potentially execute code if heap corruption is exploitable in the target process.

How to detect it

To determine whether exploitation was attempted or successful, review logs and telemetry from applications that accept or inspect X.509 certificates, especially TLS gateways, mutual-TLS services, PKI portals, mail gateways, document-processing systems, security scanners, and certificate-management tools. Look for abrupt process crashes, segmentation faults, heap corruption messages, watchdog restarts, or core dumps occurring immediately after certificate upload, TLS client-certificate negotiation, or certificate inspection. Focus on 32-bit systems using OpenSSL and on events involving unusually large certificate objects or SKID/AKID extension rendering. Inspect application logs for certificate parsing failures followed by process termination, and inspect system logs for malloc corruption, SIGSEGV, SIGABRT, or out-of-memory conditions near certificate-handling events. If core dumps are available, examine stack traces for OpenSSL certificate extension printing or buffer-to-hex conversion routines. Network telemetry may show abnormal TLS handshakes or certificate-transfer attempts with very large certificate payloads, but the exploit prerequisite is application-side rendering/logging, so host and application crash evidence is more reliable than packet signatures.

• OPENSSL_buf2hexstr
• ossl_buf2hexstr
• X509V3_EXT_print
• X509v3 Subject Key Identifier
• X509v3 Authority Key Identifier
• Subject Key Identifier
• Authority Key Identifier
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• malloc(): memory corruption
• malloc(): corrupted top size
• corrupted size vs. prev_size
• double free or corruption
• SIGSEGV
• SIGABRT
• openssl x509 -text

What your security team should do

• Prioritize discovery of 32-bit OpenSSL deployments, especially internet-facing services and applications that accept uploaded, remote, or client-supplied certificates.
• Patch OpenSSL through the operating-system, container, appliance, or application vendor as soon as fixed packages are available for the deployed branch.
• Move certificate-processing workloads to 64-bit supported platforms where feasible.
• Temporarily disable verbose certificate extension logging or printing for untrusted certificates until patched.
• Enforce maximum certificate and certificate-chain size limits at ingress points and application parsers.
• Review crash telemetry, core dumps, and service restart logs for OpenSSL-related failures involving certificate parsing or extension printing.
• Add detection logic for unusually large certificate inputs and repeated TLS or certificate-processing failures from the same source.
• Because EPSS is low, KEV is false, and exploit maturity is listed as none, handle as targeted remediation rather than emergency fleet-wide disruption unless vulnerable 32-bit exposure is confirmed.