CVE-2026-34873

What it actually does

Mbed TLS 3.5.0 through 4.0.0 contains an authentication bypass in TLS 1.3 session resumption. In affected deployments that rely on mutual TLS or certificate-based client authentication, a resumed TLS 1.3 session may allow one client to be treated as another previously authenticated client. The flaw can break the binding between the resumed session and the original authenticated client identity, enabling client impersonation without valid credentials for the impersonated identity. The CVSS 9.1 rating reflects network reachability, low attack complexity, no required privileges, no user interaction, and high confidentiality and integrity impact.

Why it matters to the business

Systems using affected Mbed TLS versions for client authentication may incorrectly trust an attacker as a legitimate device, user, service, or workload. This can lead to unauthorized access to APIs, device management channels, service-to-service communications, administrative interfaces, or protected data. Organizations using embedded products, IoT devices, VPN-like components, gateways, agents, or appliances built on Mbed TLS should treat this as high priority even though EPSS is currently low, because exploitation could bypass a core trust boundary without needing stolen credentials. No CISA KEV listing or ransomware association is currently reported, and public exploit maturity is listed as none, but the impact is severe where TLS 1.3 session resumption and client authentication are enabled together.

How an attack unfolds

An attacker first identifies a service, device, or application using affected Mbed TLS versions with TLS 1.3 enabled and client authentication enforced. The attacker then interacts with the service in a way that causes TLS 1.3 session resumption to occur, such as by using session tickets or pre-shared key resumption behavior. Due to the flaw, the server or peer may associate the resumed session with the wrong previously authenticated client identity. If successful, the attacker obtains an authenticated connection as another client without possessing that client's private key or certificate. The attacker can then access data or perform actions permitted to the impersonated identity. Exploitation is most relevant against systems where authorization decisions are based on the TLS client certificate identity or the authenticated TLS peer identity.

How to fix it

Upgrade Mbed TLS to a version that contains the vendor fix as soon as one is available; no fixed version was provided in the input data. Until patched packages are available and deployed, mitigate by disabling TLS 1.3 session resumption, disabling session tickets, or disabling PSK-based TLS 1.3 resumption on affected services. If feasible, temporarily force TLS 1.2 for mutual TLS endpoints that depend on Mbed TLS and are exposed to untrusted clients, while ensuring this does not introduce weaker cipher suites or other policy regressions. Review products, firmware, SDKs, statically linked binaries, appliances, containers, and downstream dependencies that embed Mbed TLS, because library upgrades may require rebuilding and redeploying dependent software. Rotate TLS session ticket keys after remediation so potentially unsafe resumable sessions cannot continue to be accepted. Where client identity is security-critical, add an application-layer authorization check that independently validates the authenticated client identity and does not rely solely on resumed TLS state.

How to confirm the fix worked

Confirm whether Mbed TLS 3.5.0, 3.x releases after 3.5.0, or 4.0.0 are present in source dependencies, SBOMs, firmware images, statically linked binaries, containers, or vendor appliances. Validate runtime exposure by checking whether affected services negotiate TLS 1.3 and allow session resumption while also requiring client certificates or peer authentication. After mitigation, verify that TLS 1.3 session resumption is disabled or that the deployed Mbed TLS version is fixed. Use TLS test tooling to confirm that a second connection cannot resume a TLS 1.3 session in a way that bypasses fresh client authentication. Review server-side authentication logs to ensure resumed sessions are either rejected for client-authenticated endpoints or are consistently bound to the same authenticated client identity. Re-test after restarting services and rotating session ticket keys, because stale tickets may remain valid until expiry if not invalidated.

Typical attack path

1. Locate an exposed service, embedded product, agent, gateway, or API endpoint using Mbed TLS 3.5.0 through 4.0.0.
2. Confirm TLS 1.3 support and determine whether the endpoint uses client certificate authentication or mutual TLS.
3. Trigger or manipulate TLS 1.3 session resumption behavior using session tickets or PSK-based resumption.
4. Cause the affected implementation to resume a session while incorrectly binding the connection to another authenticated client identity.
5. Use the impersonated client identity to access protected resources, issue privileged requests, or retrieve sensitive data.
6. Maintain access by repeatedly abusing resumed sessions until TLS resumption is disabled, tickets expire, or the library is patched.

How to detect it

Retrospective detection is challenging because the attack abuses TLS protocol state rather than leaving a unique payload or file artifact. Focus on TLS termination logs, mutual TLS authentication logs, application authorization logs, API audit trails, device-management logs, reverse proxy logs, and network sensor metadata. Look for successful authenticated activity over TLS 1.3 resumed sessions where the client certificate identity, peer identity, account, device ID, service identity, or authorization context differs from the original full handshake associated with the same session ticket or resumption context. Investigate resumed TLS 1.3 connections that perform privileged or unusual actions without a nearby full client-certificate authentication event. Correlate source IPs, user agents where applicable, JA3/JA4 TLS fingerprints, session resumption indicators, client certificate subjects, certificate serial numbers, and request authorization identity. Pay particular attention to repeated resumed connections from unfamiliar networks, sudden identity switching, access outside normal device or service behavior, and failures or warnings related to client certificate verification around the same time. Because no public exploit maturity or named threat actor activity is reported, prioritize anomaly-based hunting over signature-based detection.

What your security team should do

• Inventory all software, firmware, containers, appliances, and third-party products that include Mbed TLS, especially versions 3.5.0 through 4.0.0.
• Prioritize internet-facing, partner-facing, device-management, API, and service-to-service endpoints that use mutual TLS or client certificate authentication.
• Disable TLS 1.3 session resumption, session tickets, or PSK-based resumption on affected endpoints until a fixed Mbed TLS release is deployed.
• Request vendor confirmation and patches for commercial or embedded products that bundle Mbed TLS, since statically linked copies may not appear in standard package inventories.
• Rotate TLS session ticket keys and restart affected services after applying mitigations or upgrades.
• Add detection logic for anomalous TLS client identity changes, repeated resumed sessions, and privileged actions performed immediately after resumed handshakes.
• Review authorization models that rely solely on TLS client identity and consider adding application-layer identity validation for sensitive operations.
• Monitor advisories for a fixed Mbed TLS version, public exploit publication, EPSS movement, and any future KEV listing; reassess urgency if exploitation is reported.