CVE-2026-34874

What it actually does

CVE-2026-34874 is a remotely triggerable denial-of-service flaw in Mbed TLS distinguished name parsing. When vulnerable versions parse a malformed X.509 distinguished name, the parser can dereference a NULL pointer and attempt to write to address 0. In typical deployments this causes the process using Mbed TLS to crash. Because the CVSS vector is network-accessible, low-complexity, unauthenticated, and requires no user interaction, any service that accepts attacker-controlled certificates or certificate-like input may be exposed if it links to Mbed TLS through 3.6.5 or 4.x through 4.0.0.

Why it matters to the business

Systems, appliances, embedded devices, agents, gateways, and applications that rely on affected Mbed TLS versions may be crashed remotely by malformed certificate data, causing outages or degraded availability. This is especially relevant for internet-facing TLS, mutual-TLS, VPN, IoT, update, messaging, or API components that parse peer certificates. Although EPSS is currently low and there is no known CISA KEV listing or ransomware association, the bug is simple to trigger once an exposed parsing path is identified, and the broad reuse of Mbed TLS in embedded and downstream products can make inventory and patch coordination operationally challenging.

How an attack unfolds

An attacker first identifies a network service, device, or application that uses a vulnerable Mbed TLS library and parses X.509 distinguished names from untrusted input. The attacker then supplies a specially malformed certificate, certificate chain, certificate signing request, or other ASN.1/X.509 structure containing a crafted distinguished name. During parsing, vulnerable Mbed TLS code reaches the NULL pointer dereference condition and attempts to write to address 0. The operating system or runtime normally terminates the affected process, resulting in service interruption. Repeated attempts can keep the service unavailable if it automatically restarts and continues accepting the malformed input.

How to fix it

Upgrade Mbed TLS to a vendor-fixed release as soon as one is available for the affected branch, or apply the relevant upstream or product-vendor patch when published. The affected range is Mbed TLS through 3.6.5 and 4.x through 4.0.0. If a directly fixed version is not yet available in the package manager or product firmware, obtain mitigation guidance from the product or library maintainer and prioritize packages that expose X.509 parsing to untrusted network input. Rebuild and redeploy statically linked applications, firmware images, containers, and appliances that bundle Mbed TLS; updating only the system library is insufficient for statically linked binaries. As interim mitigations, restrict access to certificate upload, enrollment, mutual-TLS, VPN, management, and provisioning endpoints; disable optional client-certificate parsing where feasible; require upstream filtering or authentication before certificate parsing; and rate-limit or isolate services that automatically restart after crashes.

How to confirm the fix worked

Confirm exposure by inventorying Mbed TLS versions in operating-system packages, containers, firmware, SBOMs, static application builds, and vendor advisories. Verify that no deployed component reports or embeds Mbed TLS through 3.6.5 or 4.x through 4.0.0 unless the vendor has backported the fix. For dynamically linked software, check the installed library version and package changelog for the security fix. For statically linked software, confirm the application or firmware was rebuilt against a fixed library. After remediation, perform controlled negative testing in a non-production environment with malformed X.509 distinguished-name inputs to confirm the process rejects invalid data without crashing. Monitor service restart counters and crash logs before and after patching to ensure the crash condition no longer occurs.

Typical attack path

1. Identify a reachable service or product that uses Mbed TLS through 3.6.5 or 4.x through 4.0.0.
2. Determine whether the service processes attacker-controlled X.509 certificate material, such as during TLS client authentication, certificate upload, provisioning, enrollment, or validation workflows.
3. Send a malformed certificate or X.509 object containing a crafted distinguished name to the vulnerable parser.
4. Trigger the NULL pointer dereference and attempted write to address 0.
5. Cause the dependent process, daemon, appliance function, or application component to crash.
6. Repeat the request if necessary to sustain a denial of service.

How to detect it

Look for evidence of unexplained crashes or restarts in applications, daemons, appliances, or containers that use Mbed TLS and accept X.509 certificate data. Useful sources include application logs, TLS gateway logs, certificate enrollment or provisioning logs, system journal logs, kernel crash messages, container runtime events, core dump metadata, watchdog or supervisor restart records, load balancer health-check failures, and network telemetry showing repeated TLS handshakes or certificate upload attempts immediately before crashes. Focus on patterns where malformed certificate parsing errors, ASN.1/X.509 distinguished-name errors, segmentation faults, NULL pointer dereference messages, or writes to address 0 precede service termination. If core dumps are available, inspect backtraces for Mbed TLS X.509 or distinguished-name parsing functions. Network captures may show repeated failed handshakes, client-certificate negotiation failures, or requests carrying certificate/CSR material followed by connection resets or service unavailability. There are no public named threat actors or known exploitation campaigns in the provided intelligence, so detection should emphasize crash correlation with certificate-processing activity rather than actor-specific infrastructure.

• mbedtls_x509_get_name
• mbedtls_x509_dn_gets
• mbedtls_x509_crt_parse
• mbedtls_x509_csr_parse
• mbedtls_asn1_get_tag
• distinguished name
• X.509 distinguished name
• NULL pointer dereference
• null pointer dereference
• write to address 0
• address 0x0
• Segmentation fault
• segfault at 0
• SIGSEGV
• core dumped
• mbedtls
• x509
• asn1
• certificate parse failed
• failed to parse certificate
• bad certificate
• malformed certificate
• client certificate verification failed
• TLS handshake failed

What your security team should do

• Prioritize asset discovery for internet-facing, remotely reachable, or high-availability services that use Mbed TLS and process peer certificates or uploaded certificate material.
• Ask product owners and vendors for confirmation of Mbed TLS versions and whether fixes are backported, especially for embedded devices, appliances, firmware, agents, and containers.
• Patch or upgrade affected products when fixed releases become available; rebuild statically linked applications and redeploy dependent images rather than relying only on host library updates.
• Apply temporary exposure reduction for certificate-parsing endpoints, including access controls, segmentation, rate limiting, and disabling optional client-certificate workflows where acceptable.
• Add monitoring for repeated crashes, segmentation faults, watchdog restarts, and malformed certificate parsing errors in services that use Mbed TLS.
• Because the issue is not currently in CISA KEV, has no known ransomware association, and EPSS is low and flat, prioritize based on exposure and service criticality rather than broad emergency response.