CVE-2026-34872

What it actually does

The flaw is an input-validation weakness in finite-field Diffie-Hellman (FFDH) handling in affected Mbed TLS 3.5.x and 3.6.x releases through 3.6.5, and TF-PSA-Crypto 1.0. A malicious peer, or in some protocol designs an active man-in-the-middle attacker, can provide crafted FFDH public values that cause the computed shared secret to fall into a small, attacker-influenced set rather than being fully contributed by both parties. This breaks the expected contributory behavior of Diffie-Hellman in protocols that rely on both sides adding entropy to the key agreement. The practical result can be loss of session key secrecy, weakened authentication assumptions, and potential compromise of confidentiality and integrity for affected non-TLS protocols. The advisory notes that standard TLS usage does not depend on this property in the same way and is not the primary impacted case.

Why it matters to the business

Applications, devices, SDKs, embedded products, and services using vulnerable Mbed TLS or TF-PSA-Crypto for non-TLS FFDH-based protocols may establish cryptographic keys that an attacker can significantly constrain or predict. This can expose sensitive communications, undermine trust between systems, and create integrity risks where encrypted or authenticated protocol messages are assumed to be secure. The CVSS score is high, but current public exploitation signals are low: EPSS is approximately 0.002 with no 30-day increase, there is no known CISA KEV listing, and no known ransomware association. Organizations should still prioritize inventory and remediation where these libraries are used in custom protocols, embedded products, remote management channels, IoT/OT devices, firmware, VPN-like protocols, or proprietary secure messaging flows that use FFDH outside normal TLS.

How an attack unfolds

An attacker first identifies a product, service, device, or protocol implementation that uses affected Mbed TLS or TF-PSA-Crypto versions for finite-field Diffie-Hellman key agreement in a context that requires contributory behavior. If the attacker is an authenticated or unauthenticated protocol peer, they initiate or respond to a handshake and send specially chosen FFDH public parameters or public values that are not properly rejected by the vulnerable library. If the protocol allows active network interception, the attacker can instead position themselves between two communicating parties and substitute malicious FFDH values during negotiation. Because the vulnerable implementation does not sufficiently validate the peer contribution, the resulting shared secret may be forced into a small set of possible values. The attacker can then derive or brute-force the resulting session key space, decrypt protected traffic, modify messages that rely on the compromised key material, or impersonate a party depending on how the higher-level protocol uses the negotiated secret. Exploitability is highly protocol-dependent: standard TLS use is not expected to be affected in the same way, while custom or proprietary FFDH protocols that assume both parties contribute fresh entropy are at higher risk.

How to fix it

Upgrade affected components to vendor-provided fixed versions as soon as they are available. The affected range includes Mbed TLS 3.5.x and 3.6.x through 3.6.5, and TF-PSA-Crypto 1.0. Because no exact fixed versions were provided in the input, organizations should consult Arm Mbed TLS and TF-PSA-Crypto release notes and security advisories for the first patched release and update all directly bundled, statically linked, vendored, and firmware-embedded copies. If immediate upgrade is not possible, reduce exposure by disabling or avoiding finite-field Diffie-Hellman in custom protocols where feasible, preferring validated elliptic-curve Diffie-Hellman or protocol constructions that do not rely on vulnerable FFDH contributory behavior. Add strict validation of peer FFDH public values at protocol boundaries where the application controls parameter handling. Review custom cryptographic protocols for assumptions that both parties contribute entropy to the resulting key. For embedded or appliance products, obtain updated firmware or SDKs from the vendor and verify that downstream products are not carrying vulnerable static library copies.

How to confirm the fix worked

Confirm remediation by producing a software bill of materials or dependency inventory showing that all Mbed TLS and TF-PSA-Crypto instances have been upgraded beyond the vulnerable release range, including vendored source, statically linked binaries, container images, firmware images, and SDK packages. Check build manifests, package manager output, binary strings, and source trees for Mbed TLS 3.5.x, Mbed TLS 3.6.0 through 3.6.5, and TF-PSA-Crypto 1.0. Validate that applications using the libraries do not enable vulnerable FFDH-based custom key exchange paths, or that peer FFDH public values are rejected according to the relevant group validation requirements. Where possible, run vendor regression tests or cryptographic conformance tests that exercise invalid or small-subgroup FFDH public inputs and confirm they fail closed. For deployed products, verify updated firmware or binaries are actually running rather than merely staged.

Typical attack path

1. Identify an exposed product, service, firmware, SDK, or application using affected Mbed TLS 3.5.x/3.6.x through 3.6.5 or TF-PSA-Crypto 1.0.
2. Determine whether the target protocol uses finite-field Diffie-Hellman outside standard TLS and depends on contributory behavior from both peers.
3. Act as a malicious peer, or obtain an active man-in-the-middle position if the protocol design permits handshake tampering.
4. Send crafted FFDH public values or parameters during key agreement that should be rejected but are accepted by the vulnerable implementation.
5. Force the derived shared secret into a limited set of possible values.
6. Derive, guess, or brute-force the reduced key space and recover session key material.
7. Use the recovered key material to decrypt communications, tamper with protected messages, or bypass protocol authentication assumptions where applicable.

How to detect it

Retrospective exploitation detection is difficult because this weakness occurs inside cryptographic key negotiation and may not produce crashes, authentication failures, file changes, or distinctive system logs. Review protocol, application, and network telemetry for unusual FFDH handshake behavior if the affected application logs cryptographic negotiation details. Useful sources include application debug logs, custom protocol handshake logs, reverse proxy or gateway packet captures, network IDS metadata, firmware/device logs, and authentication/session establishment logs. Look for repeated failed or abnormal key-exchange attempts, unexpected peer public values, invalid or borderline Diffie-Hellman parameters, excessive reconnects during negotiation, or sessions established immediately after anomalous handshake messages. For high-value systems, inspect packet captures or implement temporary protocol instrumentation to record and reject invalid FFDH public values. Also investigate any historical confidentiality or integrity anomalies in protocols known to use vulnerable FFDH paths, but do not assume absence of logs proves absence of exploitation.

What your security team should do

• Prioritize inventory of products, firmware, services, SDKs, and applications that bundle Mbed TLS or TF-PSA-Crypto, especially where libraries are statically linked and invisible to package scanners.
• Triage highest-risk uses first: internet-facing services, remote management interfaces, IoT/OT devices, proprietary secure channels, device-to-device protocols, and non-TLS FFDH key exchanges.
• Confirm whether affected deployments use finite-field Diffie-Hellman outside standard TLS; deprioritize standard TLS-only use if vendor guidance confirms it is not impacted.
• Upgrade to the first vendor-fixed Mbed TLS and TF-PSA-Crypto releases when available, and track downstream vendor firmware or appliance updates.
• Where upgrades are delayed, disable vulnerable FFDH code paths or migrate affected protocols to safer, validated key agreement mechanisms.
• Ask product vendors and internal development teams whether their implementations rely on Diffie-Hellman contributory behavior and whether FFDH public value validation has been tested.
• Add targeted review to cryptographic protocol threat models, because exploitation may leave little or no conventional system-level evidence.
• Monitor vendor advisories, package repositories, and exploit intelligence despite the currently low EPSS, because cryptographic flaws in widely embedded libraries can become more important as affected products are identified.