CVE-2024-6119

What it actually does

The flaw is an invalid memory read in OpenSSL certificate name-checking logic. Applications that use OpenSSL to verify an expected DNS name, email address, or IP address against an X.509 certificate subjectAltName can crash when the certificate contains a specially formed otherName subject alternative name. Basic certificate-chain validation, such as signature and validity-date checks, is not affected. The practical result is process termination and denial of service for affected TLS clients or other software performing explicit certificate identity checks. TLS servers are generally less exposed because they rarely perform this type of reference-identifier name check on client certificates. OpenSSL FIPS modules in the 3.3, 3.2, 3.1, and 3.0 lines are not affected.

Why it matters to the business

Successful exploitation can interrupt applications that initiate TLS connections or validate certificates, causing service outages, failed integrations, broken API calls, job failures, or loss of availability in software that depends on vulnerable OpenSSL builds. The vulnerability has a high availability impact and a high EPSS score, so internet-facing clients, automated service-to-service connectors, monitoring tools, package fetchers, webhooks, and other systems that connect to attacker-controlled or compromised TLS endpoints should be prioritized even though it is not currently listed in CISA KEV and has no confirmed ransomware association.

How an attack unfolds

An attacker positions a TLS endpoint, mail endpoint, API endpoint, proxy, or other certificate-presenting service where a vulnerable application will connect, or compromises a legitimate endpoint already trusted by business workflows. The attacker presents an X.509 certificate containing a crafted otherName subject alternative name. When the vulnerable application performs certificate identity verification using an expected DNS name, email address, or IP address, OpenSSL compares that expected name against the crafted otherName value and may read an invalid memory address. The exception or segmentation fault terminates the calling process, producing a denial of service. The attacker does not need authentication or user interaction if they can cause the vulnerable application to connect to the malicious certificate-presenting service.

How to fix it

Upgrade OpenSSL to a fixed vendor release or build from a source tree that includes commit 05f360d9e849a1b277db628f1f13083a7f8dd04f. Because many products statically link or bundle OpenSSL, update both operating-system packages and application-embedded copies. Restart dependent services after patching so running processes load the corrected library. Where immediate patching is not possible, reduce exposure by preventing vulnerable clients from connecting to untrusted TLS endpoints, enforcing allowlists for outbound destinations, placing certificate validation behind patched intermediaries where appropriate, and monitoring/restarting critical processes. Do not treat FIPS module status alone as sufficient protection unless the actual application path uses only unaffected FIPS-module code and the linked OpenSSL library has been assessed.

How to confirm the fix worked

Inventory OpenSSL versions used by system packages, containers, appliances, and statically linked applications. Confirm that the installed or bundled OpenSSL source includes commit 05f360d9e849a1b277db628f1f13083a7f8dd04f or a vendor advisory that maps to the fixed code. Validate running processes after patching by checking loaded libraries, rebuilding containers and images, and restarting services. For representative applications, test certificate validation behavior against a controlled certificate containing an otherName SAN and confirm the application fails safely rather than crashing. Review crash telemetry before and after remediation for reductions in certificate-validation-related segmentation faults or abnormal process exits.

Typical attack path

1. Identify applications that use affected OpenSSL versions and perform TLS or X.509 certificate name checks against remote certificates.
2. Set up or compromise a TLS-enabled service that the target application is likely to contact.
3. Configure the service to present a crafted X.509 certificate containing a malformed or unexpected otherName subjectAltName.
4. Wait for or induce the vulnerable application to connect and perform certificate identity validation.
5. Trigger the invalid memory read during comparison of the expected DNS name, email address, or IP address with the crafted otherName SAN.
6. Cause the application process to crash, resulting in denial of service until it is restarted or the input is no longer encountered.

How to detect it

Look for evidence of abnormal application termination during or immediately after TLS connections, especially when the peer certificate contains a subjectAltName otherName entry. Relevant sources include application logs, system logs, service manager logs, endpoint detection telemetry, core dump records, crash reporters, container termination events, load balancer or egress proxy logs, and TLS inspection metadata if available. Prioritize crashes in processes known to use OpenSSL certificate verification APIs and correlate timestamps with outbound connections to new, unusual, or attacker-controlled endpoints. For Linux systems, review journald, syslog, kernel logs, coredumpctl output, and application supervisor events for SIGSEGV, segmentation fault, abort, or core-dump entries that reference OpenSSL, libcrypto, libssl, X509_check_host, X509_check_email, X509_check_ip, or GENERAL_NAME handling. If core dumps are available, inspect stack traces for OpenSSL X.509 name-checking functions. In network telemetry, look for TLS certificates with subjectAltName values of type otherName presented shortly before client-side process crashes. Absence of these artifacts does not prove non-exploitation because a crash may leave limited logs and the crafted certificate may not be retained unless TLS metadata or packet capture was enabled.

• X509_check_host
• X509_check_email
• X509_check_ip
• X509_VERIFY_PARAM_set1_host
• GENERAL_NAME
• GEN_OTHERNAME
• otherName
• subjectAltName=otherName
• subjectAltName = otherName
• libcrypto.so
• libssl.so
• Segmentation fault
• segfault
• SIGSEGV
• core dumped
• AddressSanitizer: SEGV
• AddressSanitizer:DEADLYSIGNAL
• openssl
• certificate verify failed
• certificate name check
• 05f360d9e849a1b277db628f1f13083a7f8dd04f

What your security team should do

• Prioritize patching OpenSSL in applications that make outbound TLS connections to external or user-controlled destinations, including API clients, agents, scanners, crawlers, webhooks, package managers, and service integrations.
• Search for bundled or statically linked OpenSSL copies in containers, third-party applications, language runtimes, and appliances rather than relying only on operating-system package inventory.
• Upgrade or rebuild affected software using OpenSSL code containing commit 05f360d9e849a1b277db628f1f13083a7f8dd04f, then restart all dependent services.
• Add monitoring for sudden crashes of TLS client processes, especially crashes occurring immediately after outbound TLS handshakes or certificate validation failures.
• Restrict outbound connections from high-value services to approved destinations where feasible to reduce opportunities for malicious certificate presentation.
• Coordinate with vendors for products that embed OpenSSL and request explicit confirmation that their builds include the fixed certificate name-checking code.
• Because EPSS is elevated despite no KEV listing, treat externally exposed client-side validation paths as time-sensitive rather than deferring solely because exploitation is denial-of-service only.