CVE-2026-31789, OpenSSL Heap Overflow on 32-Bit Systems

OpenSSL disclosed CVE-2026-31789 on April 7, 2026, as a heap buffer overflow in its hexadecimal conversion logic. The flaw affects specific OpenSSL 3.x releases running on 32-bit platforms when an application converts an excessively large OCTET STRING from an X.509 certificate into printable hexadecimal text. A successful trigger may crash the process, corrupt heap memory, or, under favorable and highly environment-dependent conditions, permit attacker-controlled code execution. OpenSSL assigned the issue Low severity because the necessary certificate would need to exceed 1 GB, the vulnerable operation is unusual, and 64-bit platforms are not affected. (openssl-library.org)ations matter. CVE-2026-31789 is not a general break in TLS, certificate signatures, or OpenSSL encryption. Simply running an affected OpenSSL release does not prove exploitability. A realistic exposure requires a 32-bit process, an attacker-controlled certificate of extraordinary size, and an application path that prints or logs the relevant certificate extension rather than merely validating the certificate.

The distinction is especially important because vulnerability databases currently present sharply different severity signals. OpenSSL rates the issue Low. NVD displays a 9.8 Critical vector attributed to NVD and a separate 5.8 Medium vector from CISA-ADP. Siemens published a 7.0 High vector in an affected-product advisory. These ratings encode different assumptions about reachability, complexity, interaction, and impact. None of them should replace application-specific analysis. (NVD)dern 64-bit web servers, CVE-2026-31789 is a routine patching issue rather than an emergency remote-code-execution event. For a legacy 32-bit certificate-analysis service that accepts large uploads and logs every extension, the same vulnerability deserves much faster attention.

CVE-2026-31789 at a Glance

Feld	Verified information
CVE	CVE-2026-31789
OpenSSL title	Heap Buffer Overflow in Hexadecimal Conversion
Publication date	April 7, 2026
OpenSSL severity	Niedrig
Schwäche	CWE-787, out-of-bounds write
Affected architecture	32-bit platforms
Vulnerable operation	Converting an excessively large binary buffer to hexadecimal text
Relevant X.509 data	OCTET STRING values such as Subject Key Identifier and Authority Key Identifier
Required data size	More than approximately 1 GB in the relevant certificate value
Likely result	Crash, heap corruption, undefined behavior, or possible environment-dependent code execution
OpenSSL 3.6 fix	3.6.2
OpenSSL 3.5 fix	3.5.6
OpenSSL 3.4 fix	3.4.5
OpenSSL 3.3 fix	3.3.7
OpenSSL 3.0 fix	3.0.20
OpenSSL 1.1.1	Not affected according to the OpenSSL advisory
OpenSSL 1.0.2	Not affected according to the OpenSSL advisory
FIPS modules	Not affected because the vulnerable code is outside the module boundary
Ordinary TLS handshake	Not a realistic delivery path for the required certificate size
Public exploitation signal	CISA-ADP recorded exploitation as none on April 9, 2026

The affected ranges and fixed versions come directly from the OpenSSL vulnerability record and the project’s April 7 security advisory. The advisory states that OpenSSL 3.6, 3.5, 3.4, 3.3, and 3.0 are affected within the specified ranges, while OpenSSL 1.1.1 and 1.0.2 are not affected. (openssl-library.org)Is in Certificate Presentation, Not Cryptographic Verification

The most useful way to understand CVE-2026-31789 is to separate certificate processing into stages.

An application may receive a DER- or PEM-encoded certificate, decode its ASN.1 structure, inspect extensions, build a trust chain, verify signatures, evaluate validity dates, apply certificate policies, and finally produce human-readable output. These operations use different OpenSSL functions and follow different code paths.

CVE-2026-31789 concerns the last category. It is reached when binary certificate data is converted into hexadecimal text for display or logging. The vulnerable arithmetic lives in OpenSSL’s buffer-to-hexadecimal conversion helper, not in the core signature-verification algorithm.

That distinction changes the threat model. A service that validates an ordinary peer certificate during a normal TLS handshake does not automatically reach the affected function. An administrative application that receives certificate files and calls text-printing APIs may reach it. A vulnerability scanner that logs every decoded extension may reach it. A PKI portal that renders uploaded certificates in a web interface may reach it. A security product that extracts and stores full extension contents may reach it.

OpenSSL’s documentation for X509V3_EXT_print() confirms that extension-printing APIs parse and print X.509 extension information to a BIO or file stream. The openssl x509 command can also print certificate extensions in text form. These are legitimate and widely useful capabilities, but they illustrate why parsing and printing are separate from trust validation. (OpenSSL Documentation) application therefore needs more than OpenSSL and an X.509 certificate. It must process the malicious object through a presentation path that expands binary bytes into textual hexadecimal output.

Why OCTET STRING Values Matter

ASN.1 uses the OCTET STRING type to represent an arbitrary sequence of bytes. X.509 relies on ASN.1 extensively, and several certificate structures contain values represented as OCTET STRING data.

Two examples identified by OpenSSL are the Subject Key Identifier and Authority Key Identifier.

The Subject Key Identifier, commonly abbreviated as SKID or SKI, helps identify the public key associated with a certificate. The Authority Key Identifier, or AKID, helps identify the public key corresponding to the private key that signed a certificate. RFC 5280 describes the authority key identifier as a mechanism for distinguishing an issuer’s signing key, particularly when an issuer has multiple keys or is transitioning between keys. (RFC-Editor)ertificates, these identifiers are compact. They are intended to identify keys, not carry gigabytes of arbitrary application data. CVE-2026-31789 depends on an intentionally abnormal certificate in which an OCTET STRING becomes extraordinarily large.

The vulnerability does not imply that the mathematical meaning of SKID or AKID is broken. It does not let an attacker forge a certificate signature or make one key identifier cryptographically equal to another. The weakness appears later, when OpenSSL converts the raw bytes to a textual form.

A short identifier might be rendered as:

6A:91:7F:2C:08:1D:BB:40:5A:32:CB:91:10:48:60:73:8E:14:70:2F

Every source byte becomes two hexadecimal characters. When separators are included, a colon or another separator is also added. That output expansion is the source of the dangerous size calculation.

The Integer Overflow Behind CVE-2026-31789

The vulnerable logic must determine how much memory to allocate before creating the hexadecimal string.

With a separator between bytes, the required size is approximately:

output length = input length × 3

Each input byte becomes two hexadecimal characters plus one separator. Depending on the exact formatting path, the function may also account for a terminator or handle the final separator specially.

Without a separator, the calculation is approximately:

output length = 1 + input length × 2

The problem is not multiplication itself. The problem is multiplying without first proving that the result can be represented by the destination integer type.

On a typical 32-bit platform:

SIZE_MAX = 4,294,967,295
SIZE_MAX / 3 = 1,431,655,765

If the input length is 1,431,655,766 bytes and the program calculates the separator-formatted output size in 32-bit arithmetic, the true mathematical result is:

1,431,655,766 × 3 = 4,294,967,298

That value is three greater than 4,294,967,295. It cannot be represented in an unsigned 32-bit size_t, so it wraps around to:

2

A program may then allocate only two bytes while continuing as though it has enough space to write more than four billion bytes of hexadecimal output. The subsequent writes run beyond the allocated heap object.

This is a classic allocation-size integer overflow followed by an out-of-bounds write. The source data is large, the arithmetic wraps to a small number, the allocator satisfies the unexpectedly small request, and the conversion loop writes according to the original input length.

OpenSSL’s official patch addresses the error before the multiplication occurs. The fix checks whether the input is greater than SIZE_MAX / 3 when a separator is present. For the no-separator branch, it checks against (SIZE_MAX - 1) / 2. If the conversion cannot be represented safely, OpenSSL raises CRYPTO_R_TOO_MANY_BYTES and returns without allocating or writing the output. (GitHub)t structure of the patched logic is equivalent to:

if (has_separator) {
    if (input_length > SIZE_MAX / 3)
        return error;
} else {
    if (input_length > (SIZE_MAX - 1) / 2)
        return error;
}

required_length = has_separator
    ? input_length * 3
    : 1 + input_length * 2;

This is the correct defensive pattern. Checking whether the result is smaller than the input after multiplication is weaker and easier to get wrong. The safe approach derives the maximum permitted input from the maximum representable output and rejects the input before performing the arithmetic.

Why the Vulnerability Is Limited to 32-Bit Processes

On a 64-bit platform, size_t can represent values far larger than four gigabytes. Multiplying a little more than one gigabyte by three does not approach SIZE_MAX for a 64-bit process.

That does not mean a 64-bit process should willingly process multi-gigabyte certificate extensions. It may still exhaust memory, consume excessive CPU time, fill logs, trigger application-specific limits, or create a separate denial-of-service condition. It does mean that the particular integer wraparound described by CVE-2026-31789 does not occur at the same input length.

The architecture of the running process is what matters. The kernel architecture alone is insufficient.

A 64-bit Linux kernel may execute a 32-bit application through compatibility support. A container may carry a 32-bit user space while running on a 64-bit host. A commercial appliance may use a 32-bit executable even when the underlying processor supports 64-bit operation. An application may statically link an old 32-bit OpenSSL build and ignore the host’s current shared library.

The following command is useful, but not conclusive:

uname -m

It reports the kernel or machine architecture. It does not prove that every application is a 64-bit process.

Check the OpenSSL command-line program itself:

command -v openssl
file "$(command -v openssl)"
openssl version -a

On an ELF-based system, inspect the binary class:

readelf -h "$(command -v openssl)" | grep 'Class'

Expected results include:

Class:                             ELF32

or:

Class:                             ELF64

For the actual service binary, replace the command-line utility with the service path:

file /opt/example/bin/certificate-service
readelf -h /opt/example/bin/certificate-service | grep 'Class'

For a dynamically linked application:

ldd /opt/example/bin/certificate-service \
  | grep -E 'libssl|libcrypto'

For a running Linux process:

PID=1234

file "/proc/$PID/exe"

grep -E 'libssl|libcrypto' "/proc/$PID/maps"

The process map is often stronger evidence than the library files present on disk because it shows what the running process has actually loaded. A patched library installed at noon does not protect a daemon that has kept the vulnerable library mapped since the previous week.

Static linking requires a different investigation. ldd may report that the binary is not dynamically linked or show no OpenSSL libraries. In that case, search build manifests, software bills of materials, embedded strings, vendor documentation, and source dependencies. Rebuilding the executable may be necessary even after the operating system package has been updated.

Affected and Fixed OpenSSL Versions

OpenSSL lists the following upstream version ranges as affected. (openssl-library.org)ranch	Affected upstream releases	First fixed upstream release
3.6	3.6.0 through 3.6.1	3.6.2
3.5	3.5.0 through 3.5.5	3.5.6
3.4	3.4.0 through 3.4.4	3.4.5
3.3	3.3.0 through 3.3.6	3.3.7
3.0	3.0.0 through 3.0.19	3.0.20
1.1.1	Not affected by this CVE	Nicht anwendbar
1.0.2	Not affected by this CVE	Nicht anwendbar

OpenSSL 3.1 and 3.2 deserve careful wording. The advisory says that only currently supported releases were analyzed and that OpenSSL 3.1 and 3.2 were already out of support. Their absence from the affected list is not equivalent to a security guarantee. Organizations still running those branches should migrate to a supported release rather than trying to infer safety from silence. (openssl-library.org) lifecycle also matters in July 2026. OpenSSL’s published release strategy lists OpenSSL 3.3 as supported only until April 9, 2026. OpenSSL 3.0 receives security support until September 7, 2026. OpenSSL 3.4 is supported until October 22, 2026, and 3.6 until November 1, 2026. OpenSSL 3.5 is an LTS branch supported until April 8, 2030. (openssl-library.org)tion applying the 3.0.20 fix should therefore also plan its move away from the 3.0 branch. An organization running 3.3.7 may have the CVE fix but still be on an upstream branch that has reached end of support. Vulnerability remediation and lifecycle management are related but separate controls.

Why a Normal TLS Handshake Is Not the Expected Attack Path

The word “certificate” can make CVE-2026-31789 sound like an ordinary malicious TLS server could send the payload during an HTTPS connection. The protocol limits make that interpretation unrealistic.

TLS 1.3 defines each X.509 cert_data field as:

opaque cert_data<1..2^24-1>;

The complete certificate list is also bounded by a 24-bit length. Each certificate is therefore limited to less than 2²⁴ bytes, or slightly under 16 MiB. (IETF Datatracker)s the same basic 24-bit upper bound for each ASN.1 certificate and for the certificate list:

opaque ASN.1Cert<1..2^24-1>;

struct {
    ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;

(IETF Datatracker)cate needed for CVE-2026-31789 must contain a relevant value exceeding approximately 1.33 GiB when the separator-based multiplication crosses the 32-bit boundary. A standards-compliant TLS 1.2 or TLS 1.3 Certificate message cannot carry an object remotely close to that size.

Consequently, an affected 32-bit HTTPS client is not ordinarily exploitable merely because it connects to an attacker-controlled TLS server. An affected HTTPS server is not ordinarily exploitable merely because it requests a client certificate. The TLS wire format rejects the required size long before OpenSSL could perform the vulnerable text conversion.

This limitation is one of the strongest reasons OpenSSL rated the issue Low.

It does not eliminate every remote scenario. Certificates are often transported outside the TLS handshake:

• A PKI portal may accept certificate uploads over HTTP.
• A certificate-inspection API may accept base64 or multipart input.
• A management server may import certificates from an archive.
• A security scanner may retrieve certificate files from object storage.
• An email gateway may examine attached certificate bundles.
• A messaging system may deliver certificate objects to an analysis worker.
• A custom protocol may use a 32-bit or 64-bit length field.
• An operator may open an untrusted file with a command-line inspection tool.
• A malware-analysis platform may automatically render certificate metadata.
• An endpoint agent may log embedded signer certificates from executable files.

In those cases, HTTPS may transport the upload as ordinary application data. The TLS certificate-size limit does not constrain the HTTP request body. The application’s own upload limits and parsing workflow become the relevant controls.

Reachability Matrix

Szenario	CVE-2026-31789 reachability	Reason
Ordinary TLS 1.2 server certificate	Effectively blocked by protocol size	A single certificate is limited to less than 2²⁴ bytes
Ordinary TLS 1.3 server certificate	Effectively blocked by protocol size	cert_data is limited to less than 2²⁴ bytes
TLS client certificate authentication	Effectively blocked by protocol size	The client certificate is carried in the same bounded structure
Web upload of a certificate file	Potentially reachable	HTTP body size may exceed TLS certificate-message limits
PKI certificate import API	Potentially reachable	Depends on application size limits and printing behavior
Offline openssl x509 -text processing	Relevant on affected 32-bit builds	The command prints certificate content
Certificate inventory scanner	Potentially reachable	Risk exists if untrusted files are printed or logged
SIEM enrichment worker	Potentially reachable	Full extension rendering may enter the conversion path
Custom binary protocol	Potentially reachable	Depends on the protocol’s length limits
64-bit certificate processor	Not affected by this CVE’s wraparound	The relevant multiplication does not overflow at the required size
32-bit processor with a 10 MiB upload limit	Practically blocked	The attacker cannot supply the required input length
32-bit processor that only stores a certificate hash	Likely not reachable	It does not convert the oversized OCTET STRING to hex text

The table shows why a banner scan cannot establish exposure. Network scanners can sometimes identify an OpenSSL-backed service, but they generally cannot prove the process architecture, the actual linked library, the application’s certificate-upload limits, or whether the service prints attacker-controlled extensions.

The Full Attack Preconditions

A realistic CVE-2026-31789 attack requires a chain of conditions.

The target must run vulnerable OpenSSL code

The relevant process must use an affected upstream version or a downstream package that has not received the backported fix. An OpenSSL package merely present on the filesystem is not enough. The application must load or statically include the vulnerable code.

The process must use a 32-bit address model

The calculation needs a 32-bit size_t for the documented overflow threshold. A 64-bit process is not vulnerable to CVE-2026-31789 under the conditions described by OpenSSL.

The attacker must control an X.509 certificate

The application must ingest an attacker-supplied or attacker-influenced certificate. Certificates generated exclusively by a trusted internal CA and delivered over controlled channels may produce little practical attack surface.

The relevant OCTET STRING must be extraordinarily large

OpenSSL says the certificate must exceed 1 GB. A normal certificate is several orders of magnitude smaller. The payload is therefore conspicuous and expensive to transmit, store, parse, and log.

The application must accept the data

Reverse proxies, API gateways, web frameworks, message brokers, file scanners, and application logic may each impose size limits. Any one of them can prevent the object from reaching OpenSSL.

The application must print or log the extension

Parsing and validating the certificate are not sufficient. The affected hexadecimal conversion path must be reached.

This can occur in a successful processing path, an administrative display, an audit record, or an error handler. Error-path logging deserves special attention because developers sometimes log more detail when parsing or validation fails.

The process must survive long enough to reach the overflow

A 32-bit process has a constrained virtual address space. Reading and representing a certificate larger than 1 GB may fail before the vulnerable conversion occurs. Memory allocation limits, address-space fragmentation, resource controls, parser limits, and the operating system’s out-of-memory behavior may terminate processing first.

That does not make the bug harmless. It means exploit development is highly dependent on the specific application and memory layout.

The overflow must produce a useful outcome

A heap out-of-bounds write can produce code execution in principle. In practice, the result may be an immediate allocator abort, segmentation fault, watchdog restart, or denial of service. Turning this particular overflow into reliable code execution would require control over the overwritten data, useful heap placement, compatible allocator behavior, and a way around platform mitigations.

OpenSSL therefore uses appropriately cautious language: a crash, possibly attacker-controlled code execution, or other undefined behavior. It does not claim reliable remote code execution across affected systems. (NVD)Severity Scores Disagree

Die NVD record for CVE-2026-31789 currently displays more than one CVSS assessment.

The NVD vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Base score: 9.8 Critical

The CISA-ADP vector displayed on the same page is:

CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:H
Base score: 5.8 Medium

The CISA-ADP enrichment also records:

Exploitation: none
Automatable: no
Technical impact: total

(NVD)d another vector in its product advisory:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
Base score: 7.0 High

(Siemens Cert Portal)ot minor differences. They represent fundamentally different threat models.

The 9.8 NVD score treats the vulnerability as network reachable, low complexity, unauthenticated, interaction-free, and capable of high impact to confidentiality, integrity, and availability. That vector does not reflect the most restrictive facts in the OpenSSL advisory: 32-bit execution, a certificate larger than 1 GB, and a print or log operation.

The CISA-ADP vector models local access, high complexity, and required user interaction. That may be too narrow for an internet-accessible certificate-upload service, but it better reflects the substantial triggering constraints.

The Siemens vector models a network attack with high complexity and high availability impact. That is plausible for a network-accessible affected product whose application layer can receive the oversized object.

CVSS is a standardized abstraction, not a substitute for reachability analysis. It has no direct field for “requires a certificate larger than one gigabyte,” “only affects a 32-bit process,” or “must enter a certificate-printing helper after parsing.”

A defensible remediation priority should answer five questions:

1. Is the running process 32-bit?
2. Is its OpenSSL code actually vulnerable?
3. Can an untrusted party submit certificate data outside a bounded TLS Certificate message?
4. Can the relevant object exceed the overflow threshold?
5. Does the application print or log the attacker-controlled extension?

A “yes” to all five is more meaningful than selecting whichever CVSS score is largest.

A Safe Toy PoC for the Arithmetic Error

The following program demonstrates the integer wraparound without creating a certificate, allocating a large buffer, invoking OpenSSL, or performing an out-of-bounds write.

It is safe because it only calculates integer values and prints them. It cannot exploit a target or corrupt memory.

#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>

int main(void)
{
    /*
     * Model a 32-bit size_t without allocating memory.
     *
     * UINT32_MAX / 3 is the largest input whose
     * multiplication by 3 still fits in uint32_t.
     */
    uint32_t input_length = UINT32_MAX / 3U + 1U;

    /*
     * Vulnerable-style calculation performed in 32-bit arithmetic.
     * The mathematical result is larger than UINT32_MAX,
     * so the value wraps around.
     */
    uint32_t wrapped_length = input_length * 3U;

    /*
     * Calculate the true result in a wider integer type.
     */
    uint64_t true_length = (uint64_t)input_length * 3ULL;

    printf("32-bit maximum:      %" PRIu32 "\n", UINT32_MAX);
    printf("Input length:        %" PRIu32 "\n", input_length);
    printf("Wrapped allocation:  %" PRIu32 "\n", wrapped_length);
    printf("True output length:  %" PRIu64 "\n", true_length);

    /*
     * Safe precondition used by the repaired design.
     */
    if (input_length > UINT32_MAX / 3U) {
        puts("Safe result: reject before multiplication");
        return 0;
    }

    puts("Safe result: multiplication can proceed");
    return 0;
}

Compile and run it locally:

cc -Wall -Wextra -O2 integer_wrap_demo.c -o integer_wrap_demo
./integer_wrap_demo

Expected output is similar to:

32-bit maximum:      4294967295
Input length:        1431655766
Wrapped allocation:  2
True output length:  4294967298
Safe result: reject before multiplication

The dangerous mismatch is visible without any memory corruption:

Allocated according to wrapped value: 2 bytes
Data the conversion expects to emit:   4,294,967,298 bytes

In a vulnerable implementation, the output loop still follows the original input length. The allocator follows the wrapped output length. The disagreement creates the heap overflow.

This demonstration intentionally stops before allocation. It should not be modified to create a giant buffer or reproduce the OpenSSL write. Defenders do not need a crashing certificate to confirm that an affected 32-bit version requires an update.

Safe Exposure Validation Without a Malicious Certificate

A production-safe assessment should prove the exposure conditions rather than trigger memory corruption.

Step 1 — Identify the executable

Find the program that accepts or processes certificates. Do not assume that the system openssl command and the application use the same library.

systemctl status example-certificate-service
systemctl show -p ExecStart example-certificate-service

For containers:

docker inspect example-container \
  --format '{{json .Config.Entrypoint}} {{json .Config.Cmd}}'

For Kubernetes:

kubectl get deployment certificate-service -o yaml

Step 2 — Confirm process architecture

file /opt/example/bin/certificate-service
readelf -h /opt/example/bin/certificate-service | grep 'Class'

For a running process:

PID="$(pgrep -n certificate-service)"
file "/proc/$PID/exe"

Record whether the executable is ELF32 or ELF64. Do not infer the answer from the host kernel alone.

Step 3 — Identify the loaded OpenSSL library

ldd /opt/example/bin/certificate-service \
  | grep -E 'libssl|libcrypto'

For the running process:

grep -E 'libssl|libcrypto' "/proc/$PID/maps" \
  | sort -u

Resolve package ownership:

dpkg-query -S /usr/lib/i386-linux-gnu/libcrypto.so.3

or:

rpm -qf /usr/lib/libcrypto.so.3

The path differs across distributions and architectures. Use the path observed in ldd oder /proc/PID/maps.

Step 4 — Determine whether the package contains a backport

On Debian or Ubuntu:

dpkg-query -W -f='${Package} ${Version}\n' openssl libssl3 libssl3t64 2>/dev/null
apt-cache policy openssl libssl3 libssl3t64 2>/dev/null

On RPM-based systems:

rpm -qa | grep -E '^openssl|^libopenssl'
rpm -q --changelog openssl-libs | grep -i 'CVE-2026-31789'

A downstream package may retain an older upstream base version while incorporating the security patch. Compare the package against the operating-system vendor’s advisory, not only the upstream semantic version.

Step 5 — Map certificate entry points

Search application configuration and code for:

• Certificate upload endpoints
• Certificate import functions
• Trust-store management interfaces
• S/MIME or document-signature ingestion
• Executable-signature extraction
• Archive analysis
• Certificate inventory jobs
• API fields containing PEM or DER data
• Message-queue topics carrying certificates
• Calls to X509_print, X509_print_ex, oder X509V3_EXT_print
• Logging of SKID, AKID, or complete extension values
• Shell execution of openssl x509 -text

A software-composition scanner may identify OpenSSL, but source or runtime inspection is required to prove the dangerous path.

Step 6 — Measure size limits

Record the smallest applicable limit across the entire data path:

• CDN request-body limit
• Reverse-proxy limit
• Web-server limit
• Framework multipart limit
• API gateway limit
• Message-broker limit
• Object-store policy
• Application-level file limit
• Decompressed archive limit
• In-memory parser limit

If the maximum accepted certificate is 10 MiB, the documented CVE threshold cannot be reached through that interface. Preserve the configuration as evidence rather than merely stating that “large files are blocked.”

Step 7 — Confirm printing behavior safely

Use an ordinary small lab certificate. Enable application tracing or inspect source code to determine whether the certificate reaches text-printing functions.

A normal certificate can prove code-path reachability without attempting the overflow. The test should answer:

• Is the certificate decoded?
• Are extensions printed?
• Is the complete SKID or AKID converted to hex?
• Is output written to a log, database, report, or user interface?
• Does the path run for rejected certificates as well as accepted ones?

Step 8 — Patch and restart

Install the vendor-provided update, rebuild static applications, or deploy a fixed container image. Restart the process so that it maps the repaired library.

Step 9 — Verify the running state

Repeat the architecture, package, library-map, and process-start-time checks. A good remediation record proves what is running now, not what a package manager downloaded.

Evidence That Supports a Defensible Finding

Beweise	Strong collection method	Häufiger Fehler
Process architecture	Datei und readelf on the real executable	Reporting only uname -m
OpenSSL version	Package metadata plus loaded-library path	Running only openssl version
Runtime library	/proc/PID/maps or equivalent runtime inspection	Inspecting an unused library on disk
Input reachability	Documented upload, API, queue, or file path	Assuming TLS exposure proves reachability
Maximum object size	Gateway and application configuration	Testing only the front-end limit
Printing path	Source review, trace, or ordinary-certificate test	Assuming parsing automatically prints
Patch state	Vendor advisory and package changelog	Comparing only upstream version strings
Restart state	Process start time and current memory maps	Installing a patch without restarting
Remediation proof	Before-and-after evidence bundle	Writing “updated successfully” without artifacts

A high-quality CVE-2026-31789 finding should avoid claims such as:

The server uses OpenSSL 3.0 and is vulnerable to remote code execution.

That statement omits the decisive conditions.

A better finding is:

A 32-bit certificate-processing worker loads an unpatched
OpenSSL 3.0 package. The worker accepts certificate files
through an authenticated import API, permits request bodies
larger than 1.5 GiB, and renders complete X.509 extension
values into an audit report.

The configuration satisfies the publicly documented
preconditions for CVE-2026-31789. No destructive proof of
concept was executed. Upgrade to the vendor-fixed package,
restart the worker, and enforce a substantially smaller
certificate-size limit before parsing.

That language is specific, reproducible, and proportionate.

Detection Signals

CVE-2026-31789 does not have a universal exploit URI, shell command, network signature, or certificate fingerprint. Detection depends on application context.

Oversized input

Look for:

• Certificate uploads measured in hundreds of megabytes or gigabytes
• Large DER objects
• PEM files with unusually large base64 bodies
• Large PKCS#7 or certificate-bundle attachments that ultimately contain X.509 objects
• Rapid repeated uploads that stop just below application limits
• Compressed archives with extreme expansion ratios
• Queue messages or object-store records containing abnormally large certificate data

A size alert is not proof of exploitation. It is a useful signal because normal X.509 certificates are nowhere near the documented threshold.

Printing and logging anomalies

Watch for:

• Sudden log growth associated with certificate inspection
• Audit records containing enormous key identifier fields
• Timeouts while rendering certificate details
• Truncated extension output
• Certificate-analysis jobs that consume large amounts of memory after parsing
• Repeated attempts to view or export the same certificate
• Log-pipeline backpressure following certificate imports

Process crashes

Relevant events may include:

• SIGSEGV
• SIGABRT
• Heap-corruption messages
• Allocator consistency-check failures
• Watchdog restarts
• Container OOMKilled events
• Core dumps produced by certificate-processing workers
• Exceptions occurring immediately after X.509 import or display

A crash may happen before the overflow because the application cannot hold the input in a 32-bit address space. That still represents a denial-of-service concern, but it is not proof that CVE-2026-31789 reached the vulnerable write.

Stack traces

When symbols are available, investigate crashes involving:

ossl_buf2hexstr_sep
buf2hexstr_sep
X509V3_EXT_print
X509_print
X509_print_ex

The exact stack varies by OpenSSL branch, compiler optimization, application wrapper, and whether symbols were stripped. Absence of a recognizable symbol does not rule out the bug.

Post-patch rejection

The OpenSSL fix raises CRYPTO_R_TOO_MANY_BYTES when the requested conversion cannot be represented. Depending on how an application handles the OpenSSL error stack, defenders may observe an error message containing wording such as “too many bytes.” (GitHub)is expected defensive behavior after patching. It should not be suppressed and followed by a fallback formatter that recreates the same unsafe multiplication.

Incident Response for a Suspected Trigger

If a 32-bit certificate-processing service crashes while handling an abnormally large certificate, preserve evidence before repeatedly restarting or reopening the file.

Quarantine the input

Move the object to restricted storage without processing it through the affected tool. Preserve:

• Original filename
• File size
• Source account
• Source IP where available
• Upload or message identifier
• Reception timestamp
• Request headers
• Kontext der Authentifizierung
• Storage-object version
• Cryptographic hash

Calculate a hash using a tool that does not parse the certificate:

sha256sum suspicious-certificate.bin

Hashing treats the object as bytes and does not invoke X.509 printing.

Do not inspect it with an affected 32-bit OpenSSL command

Avoid commands such as:

openssl x509 -in suspicious-certificate.pem -text

when the command is an affected 32-bit build. That operation may enter the vulnerable display path.

Use an isolated, fully patched 64-bit analysis environment with strict resource limits. Even there, a multi-gigabyte certificate can cause memory or storage exhaustion unrelated to CVE-2026-31789.

Preserve the crash evidence

Collect:

• Core dump
• Service logs
• Kernel logs
• Container termination reason
• Process architecture
• Loaded OpenSSL library
• Package version
• Application build identifier
• Memory limits
• Stack trace
• Input-size limit configuration
• Process start time

Determine whether the input was intentional

Possible explanations include:

• Deliberate exploitation attempt
• Security-research testing
• Fuzzing against an exposed service
• Corrupt data generated by an internal system
• Archive decompression error
• Broken serialization
• Accidental submission of a non-certificate file
• Resource-exhaustion attack unrelated to the exact heap overflow

Look for repeated submissions, threshold probing, multiple accounts, changing extensions, or attempts against other certificate-processing endpoints.

Do not equate a crash with code execution

A segmentation fault proves loss of availability. It does not prove instruction-pointer control, arbitrary code execution, persistence, or data theft.

Escalate the incident when there is separate evidence of compromise, such as:

• Unexpected child processes
• Modified executable files
• New network connections from the service account
• Credential access
• Unexplained configuration changes
• Shell commands in audit logs
• Memory artifacts showing controlled execution

Patching CVE-2026-31789

The primary remediation is to install a fixed OpenSSL release or a vendor package containing the backported patch.

For upstream users:

OpenSSL 3.6 → upgrade to 3.6.2 or later
OpenSSL 3.5 → upgrade to 3.5.6 or later
OpenSSL 3.4 → upgrade to 3.4.5 or later
OpenSSL 3.3 → upgrade to 3.3.7, then migrate to a supported branch
OpenSSL 3.0 → upgrade to 3.0.20 or later and plan migration

The OpenSSL project announced all five fixed releases on April 7, 2026. Later security releases, including 3.6.3, 3.5.7, 3.4.6, and 3.0.21, also include the fix. (openssl-library.org)grade from a newer branch merely to reach the first listed fixed release. Install the latest supported security release approved by the software or operating-system vendor.

Restart long-running applications

Updating a shared library on disk does not replace the copy mapped into an existing process. Restart or redeploy:

• Web services
• PKI platforms
• Mail gateways
• Scanners
• Monitoring agents
• Certificate-management workers
• Containers
• Background jobs
• Long-running command servers
• Appliance services

Afterward, verify /proc/PID/maps, the process start time, and the package state.

Rebuild static applications

Static binaries include OpenSSL code in the executable. Updating /usr/lib does not repair them. Rebuild with a fixed dependency, retest, sign the new artifact where required, and redeploy it.

Update container base images

A running container does not automatically inherit updates installed on the host. Rebuild the image from a patched base, verify the package inside the resulting image, roll out new pods or containers, and remove the old replicas.

Follow appliance vendor instructions

For network, industrial, storage, and security appliances, do not replace OpenSSL manually unless the vendor explicitly supports that action. Use the vendor firmware or maintenance update. Manual library replacement can break signatures, dependencies, support contracts, or validated configurations.

Downstream Packages and Backports

Upstream version comparison is not enough for Linux distributions and commercial products.

Ubuntu’s April 8 security notice fixed CVE-2026-31789 in distribution-specific packages, including:

Ubuntu-Veröffentlichung	Fixed package example
Ubuntu 25.10	3.5.3-1ubuntu3.3
Ubuntu 24.04 LTS	3.0.13-0ubuntu3.9
Ubuntu 22.04 LTS	3.0.2-0ubuntu1.23

Those version strings remain below OpenSSL’s upstream first-fixed releases because Ubuntu backported the security change into its maintained package branches. (Ubuntu)d scanner that sees OpenSSL 3.0.13 and compares it only with 3.0.20 may report a false positive on a fully updated Ubuntu 24.04 system.

IBM published bulletins covering products that incorporate OpenSSL, including AIX and IBM cloud components. Siemens listed CVE-2026-31789 in an advisory for SIMATIC CN 4100 versions before V5.0. SUSE also maintains a distribution-specific CVE record. These advisories demonstrate that the issue propagated beyond a standalone OpenSSL installation, but product inclusion alone still does not prove that the vulnerable certificate-printing path is remotely reachable. (Siemens Cert Portal)eam products, collect:

• Vendor advisory identifier
• Product and firmware version
• Package release
• Backport status
• Required restart or reboot
• Service architecture
• Whether the affected feature is enabled
• Whether the input path is exposed

Temporary Mitigations

Compensating controls are useful when a patch cannot be deployed immediately, but they should not become permanent substitutes for the fix.

Enforce a small certificate-size limit

A limit measured in a few megabytes is already generous for ordinary X.509 certificates and remains far below the CVE threshold. Choose the value according to legitimate business requirements rather than copying a universal number.

Apply the limit before:

• Base64 decoding
• ASN.1 parsing
• Archive expansion
• Database insertion
• Queue publication
• OpenSSL function calls
• Certificate rendering

A limit enforced only after the complete object is held in memory may still permit resource exhaustion.

Stop logging full extension values

Logs rarely need every byte of every extension. Prefer:

• Extension OID
• Decoded type
• Byte length
• Bounded prefix
• Cryptographic hash
• Parsing result
• Status der Validierung

Zum Beispiel:

extension=subjectKeyIdentifier
length=20
sha256=7c2e...
display_truncated=false

For an abnormal object:

extension=subjectKeyIdentifier
length=1431655766
status=rejected
reason=size_limit

Do not attempt to convert the entire value to hex before recording its length.

Separate parsing from presentation

Run certificate parsing in a dedicated service with:

• A patched 64-bit runtime
• Memory limits
• CPU limits
• Execution timeout
• No shell access
• Restricted filesystem access
• Minimal network permissions
• Bounded output
• Crash isolation

The public-facing application can receive metadata from this service without handling the raw object in its main process.

Restrict certificate import privileges

If only administrators need to import trust anchors or client certificates, require strong authentication and authorization. This does not remove the vulnerability, but it reduces the population capable of reaching the path.

Disable unnecessary certificate rendering

A service that only needs a certificate fingerprint should not generate a complete text dump. Remove debug output, verbose audit modes, and automatic extension rendering where they are not operationally necessary.

The FIPS Boundary Does Not Make the Whole Application Safe

OpenSSL states that the FIPS modules in the affected 3.x branches are not affected because the vulnerable code is outside the FIPS module boundary. (openssl-library.org)ent has a precise meaning. The validated cryptographic module does not contain the faulty certificate-to-hex conversion code.

It does not necessarily mean that every application configured to use an OpenSSL FIPS provider is immune. An application may use FIPS-approved algorithms for cryptographic operations while still relying on surrounding non-module libcrypto code to parse and print certificates. If that surrounding library is an affected 32-bit build and the application reaches the printing path, the FIPS configuration does not repair the integer arithmetic.

A correct assessment should therefore say:

The OpenSSL FIPS module is outside the affected code path.
The surrounding OpenSSL library and application still require
version, architecture, and reachability review.

It should not say:

FIPS mode prevents CVE-2026-31789.

Related OpenSSL Memory-Safety Vulnerabilities

CVE-2026-31789 is easier to prioritize when compared with other OpenSSL memory-safety flaws.

CVE	Core problem	Primary input path	Important constraint	OpenSSL severity
CVE-2026-31789	Unsigned size overflow followed by heap out-of-bounds write	Hexadecimal printing of enormous X.509 OCTET STRING values	32-bit process, over 1 GB, printing or logging path	Niedrig
CVE-2026-7383	Signed integer overflow in ASN.1 multibyte string conversion	Conversion of extremely large ASN.1 character strings	Input around 2³⁰ characters	Niedrig
CVE-2025-15467	Stack buffer overflow in CMS AEAD parameter parsing	Untrusted CMS or S/MIME AuthEnvelopedData	Malicious oversized IV, overflow before authentication	Hoch
CVE-2024-9143	Out-of-bounds access with invalid binary-field elliptic-curve parameters	Low-level GF²ᵐ APIs with exotic explicit parameters	Uncommon API and parameter representation	Niedrig

CVE-2026-7383

OpenSSL disclosed CVE-2026-7383 on June 9, 2026. It concerns a signed integer overflow while sizing Unicode output in ASN1_mbstring_ncopy(). The input must reach around 2³⁰ characters, making practical triggering difficult. Like CVE-2026-31789, it shows why apparently simple format-conversion functions need explicit overflow checks before allocating output buffers. (openssl-library.org)ity is conceptual rather than identical. CVE-2026-31789 expands arbitrary bytes into hexadecimal text and depends on 32-bit size arithmetic. CVE-2026-7383 expands ASN.1 character data into another string encoding and uses signed arithmetic. Both are examples of output-size calculations becoming security boundaries.

CVE-2025-15467

CVE-2025-15467 is a more reachable and more severe OpenSSL memory-corruption issue. Malicious CMS AuthEnvelopedData or EnvelopedData can provide an oversized AEAD initialization vector that is copied into a fixed-size stack buffer before authentication. OpenSSL rated it High and identified untrusted CMS, PKCS#7, and S/MIME processing as relevant exposure paths. (openssl-library.org) require a certificate larger than 1 GB, a 32-bit process, or a later printing operation. That difference explains why two vulnerabilities that both mention possible code execution deserve different operational priorities.

CVE-2024-9143

CVE-2024-9143 affects low-level GF²ᵐ elliptic-curve APIs when applications accept unusual explicit field-polynomial parameters. OpenSSL noted that common certificate and protocol encodings could not represent the problematic input, reducing the likelihood of a vulnerable application despite the possibility of out-of-bounds writes. (openssl-library.org)lesson is that impact class alone is not enough. “Out-of-bounds write” describes what happens after the vulnerable code is reached. It does not describe how easy reaching that code is.

Prioritization for Different Environments

Modern 64-bit internet-facing web servers

Priority is generally routine.

Confirm that the worker processes are 64-bit, apply normal OpenSSL security updates, and avoid reporting CVE-2026-31789 as a remotely exploitable TLS flaw. Other OpenSSL CVEs in the same update may have different reachability and may deserve higher priority.

Legacy 32-bit appliances

Priority depends on functionality.

An appliance that imports certificates, displays full certificate details, or accepts certificate bundles from remote management clients deserves prompt investigation. Firmware availability and vendor support may determine the remediation path.

Public certificate-inspection websites

Priority is elevated if the back end is 32-bit and upload limits are unusually high.

These services intentionally accept untrusted certificates and render them. They should patch, enforce strict size limits, isolate parsing, and avoid printing unbounded fields.

PKI administration systems

Priority depends on who can submit objects.

An internal PKI portal restricted to a small administrator group presents less external exposure, but a compromised administrator account or malicious tenant may still reach the path. Certificate import should remain bounded and isolated.

Malware-analysis and code-signing platforms

Priority may be elevated.

These products routinely extract and display certificates from untrusted files. The attacker may not submit a standalone certificate; the certificate may be embedded in another object that the platform automatically analyzes.

Email and document gateways

Review whether the software extracts and renders signer certificates from S/MIME, PKCS#7, signed documents, or executable files. The relevant object may enter as an attachment rather than through TLS authentication.

Industrial and embedded environments

Inventory should focus on management services, firmware-signature analysis, device onboarding, and certificate provisioning. Even when an industrial protocol itself cannot carry a one-gigabyte certificate, a management station or update utility may import certificate files through another channel.

Common Assessment Mistakes

Treating every OpenSSL installation as vulnerable

An affected library installed on a 64-bit host does not satisfy the architecture condition. An affected library that no running process loads does not establish exposure. An affected process that never prints untrusted X.509 extensions may not reach the flaw.

Treating every TLS endpoint as remotely exploitable

Standard TLS Certificate messages cannot carry the documented payload size. Ordinary HTTPS certificate exchange is not the expected vector. (IETF Datatracker)g only the operating-system architecture

A 64-bit kernel can host a 32-bit application. Inspect the executable and running process.

Checking only the openssl command

The application may load another shared library, bundle OpenSSL privately, or statically link it.

Ignoring downstream backports

Ubuntu and other vendors may fix the vulnerability without changing to the upstream first-fixed version number. Use vendor package status. (Ubuntu)g FIPS mode blocks the flaw

The FIPS module is not affected, but the vulnerable utility code is outside that boundary. Review the complete application.

Calling the issue guaranteed RCE

OpenSSL says code execution is possible, not guaranteed. The documented conditions make reliable exploitation highly environment dependent.

Ignoring the issue because it is Low

A public 32-bit certificate-rendering service with no meaningful upload limit is a materially different environment from a 64-bit TLS server. Official severity is a starting point, not a waiver.

Installing the patch without restarting

Long-running processes may continue using the old library.

Running a destructive PoC in production

A crash test adds little value when architecture, version, input limits, and printing behavior can be established safely.

Building a Scalable Validation Workflow

Large organizations may have OpenSSL in operating-system packages, embedded agents, third-party appliances, containers, static utilities, developer tools, and industrial systems. The useful unit of analysis is not “host has OpenSSL.” It is an evidence chain:

Asset
→ executable
→ process architecture
→ loaded library
→ package or build provenance
→ untrusted certificate entry point
→ maximum accepted size
→ printing or logging behavior
→ patch and restart state

Automation can collect much of this evidence, but it should preserve uncertainty. A system should not convert a software-composition match directly into a Critical RCE finding.

For authorized environments, an evidence-oriented platform such as Sträflich can help coordinate asset checks, tool execution, validation steps, and remediation evidence. The output still needs to state the decisive facts: whether the process is 32-bit, which OpenSSL code is loaded, whether an attacker can supply an oversized certificate, and whether the application prints the relevant extension.

The same reachability-first reasoning applies to other OpenSSL memory errors. Penligent’s analysis of CVE-2025-15467 provides a useful contrast: that CMS flaw enters a parsing path before authentication and does not depend on a one-gigabyte certificate-printing operation.

A Practical Remediation Checklist

Aktion	Required result
Inventory OpenSSL consumers	Identify actual applications, not only packages
Check executable architecture	Confirm ELF32, ELF64, or platform equivalent
Inspect loaded libraries	Record runtime libcrypto und libssl paths
Review static binaries	Rebuild any application containing vulnerable code
Confirm package status	Use upstream or downstream vendor advisory
Map certificate inputs	Identify uploads, APIs, queues, archives, and local files
Measure maximum size	Verify every layer before OpenSSL processing
Identify printing paths	Check extension rendering and verbose logging
Apply update	Install fixed upstream or vendor package
Restart or redeploy	Remove vulnerable code from running memory
Add size limits	Reject unreasonable objects before decoding
Reduce logging	Store bounded metadata rather than complete values
Retest safely	Use ordinary certificates and configuration evidence
Preserve artifacts	Record before-and-after versions and process maps

Useful Source Material

Die OpenSSL April 7, 2026 security advisory is the primary source for affected branches, fixed versions, architecture restrictions, expected impact, and the project’s Low severity classification. (openssl-library.org)L fix commit](https://github.com/openssl/openssl/commit/a24216018e1ede8ff01a4ff5afff7dfbd443e2f9) shows the exact pre-multiplication checks added to the hexadecimal conversion functions. (GitHub)try](https://nvd.nist.gov/vuln/detail/CVE-2026-31789) is useful for CWE mapping, CPE ranges, the conflicting CVSS vectors, CISA-ADP enrichment, and downstream references. (NVD) Certificate structure in RFC 8446 explains why a standards-compliant TLS handshake cannot carry the certificate size required by the OpenSSL advisory. (IETF Datatracker) Can CVE-2026-31789 be exploited through a normal HTTPS connection?

• A standard TLS 1.2 or TLS 1.3 Certificate message cannot carry a certificate larger than 2²⁴ minus 1 bytes.
• OpenSSL says the vulnerable certificate would need to exceed 1 GB.
• Ordinary server-certificate and client-certificate exchange therefore cannot deliver the documented trigger.
• A web application can still be exposed if it accepts a giant certificate as an HTTP upload and later prints its extensions.
• Treat certificate-upload and certificate-analysis features separately from the TLS handshake itself. (IETF Datatracker)penSSL versions are affected?
• OpenSSL 3.6.0 before 3.6.2 is affected.
• OpenSSL 3.5.0 before 3.5.6 is affected.
• OpenSSL 3.4.0 before 3.4.5 is affected.
• OpenSSL 3.3.0 before 3.3.7 is affected.
• OpenSSL 3.0.0 before 3.0.20 is affected.
• OpenSSL 1.1.1 and 1.0.2 are not affected according to the official advisory.
• OpenSSL 3.1 and 3.2 were out of support and were not analyzed in the advisory. (openssl-library.org)I determine whether an application is 32-bit?
• ausführen. Datei against the actual service executable.
• On ELF systems, use readelf -h and check whether the class is ELF32 or ELF64.
• For a running Linux process, inspect /proc/PID/exe.
• Do not rely only on uname -m.
• Check containers, compatibility environments, and statically linked binaries separately.
• Preserve the output in the remediation record.

Is OpenSSL 1.1.1 vulnerable to CVE-2026-31789?

• OpenSSL’s April 7 advisory says OpenSSL 1.1.1 is not affected.
• Do not confuse this finding with other OpenSSL vulnerabilities that do affect 1.1.1.
• OpenSSL 1.1.1 is outside normal public support, so continued use creates broader lifecycle risk.
• Commercially supported or vendor-maintained variants should be checked against their supplier’s advisory. (openssl-library.org)enSSL FIPS mode prevent the heap overflow?
• The OpenSSL FIPS modules are not affected because the vulnerable code is outside their module boundary.
• An application using a FIPS provider may still call vulnerable non-module certificate-printing code.
• Confirm the surrounding OpenSSL library version and process architecture.
• Do not close a finding solely because the application uses FIPS-approved cryptography. (openssl-library.org)defenders run a public crashing PoC?
• A destructive PoC is not required to confirm exposure.
• Verify architecture, loaded OpenSSL code, accepted input size, and printing behavior.
• Use the arithmetic toy example to understand the integer wraparound.
• Use ordinary certificates to confirm that an application prints extensions.
• Never open a suspected giant certificate with an affected 32-bit OpenSSL tool.
• Restrict crash testing to an isolated lab that the tester owns and is authorized to disrupt.

Which systems should be checked first?

• Public certificate-upload and certificate-inspection services
• Legacy 32-bit PKI management systems
• Industrial and network appliances with certificate-import features
• Malware-analysis platforms that render signer certificates
• Mail or document gateways that extract certificate details
• Vulnerability scanners and inventory products that log full X.509 extensions
• Static 32-bit applications that bundle OpenSSL
• Services with unusually large request-body or object-size limits

How can a team prove that remediation worked?

• Record the fixed package or application build.
• Restart or redeploy the affected process.
• Confirm the new process start time.
• Recheck the loaded libcrypto path and package ownership.
• Confirm the executable architecture.
• Verify that unreasonable certificate sizes are rejected before parsing.
• Confirm that logs use bounded metadata instead of complete extension dumps.
• Preserve before-and-after command output, configuration, and deployment identifiers.

Final Assessment

CVE-2026-31789 is a genuine heap buffer overflow, but its practical risk is constrained by an unusual combination of conditions. The target must use vulnerable OpenSSL 3.x code in a 32-bit process, accept an attacker-controlled X.509 object larger than 1 GB, and convert a huge OCTET STRING to printable hexadecimal text.

Those conditions make the flaw fundamentally different from a remotely reachable TLS parser bug. Standard TLS certificate messages cannot transport the required object size. Modern 64-bit web servers are outside the affected architecture. Many applications impose file-size or request-body limits that stop the trigger before OpenSSL processes it.

The narrow attack surface does not justify ignoring the update. Legacy appliances, certificate-analysis services, PKI portals, security products, and other 32-bit applications may ingest certificates outside the TLS handshake and automatically print their extensions. In those environments, a process crash may be operationally serious, and heap corruption should not be dismissed merely because reliable code execution has not been demonstrated.

The correct response is evidence-driven: identify 32-bit processes, inspect the OpenSSL code they actually load, map untrusted certificate inputs, verify size limits, locate extension-printing paths, install vendor fixes, restart affected services, and retain proof that the repaired code is running.