CVE-2026-7383

What it actually does

CVE-2026-7383 is a heap buffer overflow in OpenSSL's ASN1_mbstring_copy() and ASN1_mbstring_ncopy() routines. When these functions size a destination buffer for Unicode output, the size calculation uses a signed int and can overflow for extremely large attacker-controlled strings, especially BMPSTRING, UNIVERSALSTRING, or UTF8STRING conversions. In the worst case, the computed allocation can wrap to a very small value while the subsequent copy writes a much larger amount of data, potentially causing process crashes, memory corruption, undefined behavior, or, in favorable conditions, code execution. Standard OpenSSL X.509 certificate processing is not expected to reach the vulnerable condition because common certificate paths apply type and length restrictions; exposure is mainly in applications that directly call the affected ASN.1 string-copy APIs or register custom ASN.1 string types using attacker-controlled, very large inputs. OpenSSL FIPS modules are not affected because the vulnerable code is outside the FIPS module boundary.

Why it matters to the business

For most organizations this is a low-likelihood but high-consequence OpenSSL issue: widespread OpenSSL usage increases the need to inventory exposure, but exploitation requires a non-standard application path and very large attacker-controlled input, making broad internet-scale exploitation unlikely based on currently available information. If an affected application does expose these APIs to untrusted input, successful exploitation could crash critical services or potentially allow compromise of the process running the vulnerable code. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, so remediation should be prioritized behind actively exploited OpenSSL issues unless an organization has custom ASN.1 handling or direct use of the vulnerable APIs.

How an attack unfolds

An attacker first identifies an application using OpenSSL in a way that directly invokes ASN1_mbstring_copy() or ASN1_mbstring_ncopy(), or that registers a custom string type through ASN1_STRING_TABLE_add() and then processes attacker-supplied ASN.1 string content. The attacker then supplies an unusually large string, on the order of hundreds of megabytes to approximately 2^30 characters or more, crafted so the destination buffer size calculation overflows during Unicode conversion. Because the allocation is based on the wrapped integer value, OpenSSL may allocate a much smaller buffer than required. During the copy operation, the process writes beyond the allocated heap buffer, resulting in memory corruption. The most likely observable result is a denial-of-service crash; in a highly controlled memory layout, attacker-controlled code execution may be possible, although no public exploit maturity or active exploitation is currently reported.

How to fix it

Upgrade OpenSSL to a vendor-provided version that includes the fix when available for the affected package or platform. Because no exact fixed versions were provided in the input, use the relevant operating system, container base image, appliance, language runtime, or application vendor advisory as the source of truth. Rebuild or redeploy statically linked applications after updating OpenSSL, since replacing the system library alone may not fix embedded copies. Where immediate upgrade is not possible, mitigate by auditing code for direct use of ASN1_mbstring_copy(), ASN1_mbstring_ncopy(), and ASN1_STRING_TABLE_add(); enforce strict maximum input sizes before ASN.1 string conversion; reject unusually large ASN.1 string values; and avoid exposing custom ASN.1 string handling to untrusted network input. Standard certificate validation paths are not expected to be exploitable, but custom ASN.1 parsing should be treated as higher risk.

How to confirm the fix worked

Confirm the OpenSSL version and vendor package release on all systems, containers, appliances, and statically linked applications that include OpenSSL. Review software bills of materials, dependency manifests, package manager output, and binary linkage to identify OpenSSL copies. Validate that applications do not directly expose ASN1_mbstring_copy(), ASN1_mbstring_ncopy(), or custom ASN1_STRING_TABLE_add() handling to untrusted input, or that they enforce conservative size limits before those calls. After patching, rerun package scans and container image scans to confirm the vulnerable OpenSSL build is no longer present. For custom code, add regression tests with oversized ASN.1 string inputs and verify they are rejected before OpenSSL conversion routines are invoked.

Typical attack path

1. Find an application or service using OpenSSL ASN.1 string handling in a non-standard way, such as direct calls to ASN1_mbstring_copy() or ASN1_mbstring_ncopy().
2. Confirm the application accepts attacker-controlled ASN.1 string input without strict size limits.
3. Send a very large crafted BMPSTRING, UNIVERSALSTRING, or UTF8STRING value capable of overflowing the signed destination-size calculation.
4. Trigger OpenSSL to allocate an undersized heap buffer based on the wrapped size value.
5. Cause the subsequent string-copy operation to write past the heap allocation.
6. Achieve a process crash or, in a more advanced scenario, attempt to shape heap memory for controlled code execution.

How to detect it

Retrospective detection should focus on application crashes, abnormal memory corruption, and unusually large ASN.1-related inputs rather than network signatures, because exploitation depends on application-specific use of OpenSSL APIs and there is no standard protocol path known to trigger the bug. Review application logs, crash dumps, core files, endpoint telemetry, sanitizer output, and service supervisor logs for crashes with stack traces containing ASN1_mbstring_copy(), ASN1_mbstring_ncopy(), ASN1_STRING_set_by_NID(), ASN1_STRING_TABLE_add(), OPENSSL_malloc(), or heap-buffer-overflow messages. Investigate requests, uploaded files, messages, or protocol payloads immediately preceding crashes where payload sizes are hundreds of megabytes or larger and contain ASN.1 string encodings such as BMPSTRING, UNIVERSALSTRING, or UTF8STRING. For internet-facing services, correlate large inbound transfers with service restarts, segmentation faults, out-of-memory events, or heap corruption messages. Absence of these artifacts does not prove non-exploitation, especially if logs do not retain request sizes, crash traces, or core dumps.

• ASN1_mbstring_copy
• ASN1_mbstring_ncopy
• ASN1_STRING_TABLE_add
• ASN1_STRING_set_by_NID
• OPENSSL_malloc
• heap-buffer-overflow
• heap corruption
• malloc(): corrupted top size
• malloc(): invalid size
• double free or corruption
• segmentation fault
• SIGSEGV
• AddressSanitizer: heap-buffer-overflow

What your security team should do

• Inventory all OpenSSL usage, including container images, appliances, embedded libraries, and statically linked binaries.
• Prioritize remediation for applications that perform custom ASN.1 parsing or directly call ASN1_mbstring_copy(), ASN1_mbstring_ncopy(), or ASN1_STRING_TABLE_add() with untrusted input.
• Apply vendor OpenSSL updates as they become available and rebuild applications that bundle or statically link OpenSSL.
• Add input-size limits around ASN.1 string handling, especially for BMPSTRING, UNIVERSALSTRING, and UTF8STRING conversion paths.
• Do not treat normal TLS certificate processing alone as proof of exploitability; focus review on custom ASN.1 handling paths.
• Monitor for crashes or sanitizer reports involving ASN1_mbstring_copy(), ASN1_mbstring_ncopy(), OPENSSL_malloc(), or heap-buffer-overflow conditions.
• Track vendor advisories because exact fixed versions may vary by distribution and packaged OpenSSL branch.