CVE-2026-34875

What it actually does

This is a buffer overflow in Mbed TLS and TF-PSA-Crypto during public key export for finite-field Diffie-Hellman (FFDH) keys. If an application uses the affected library to export an attacker-influenced FFDH public key, the export routine can write beyond the intended buffer boundary. Depending on how the consuming application is built, linked, and sandboxed, this can lead to process crash, memory corruption, information disclosure, or potentially arbitrary code execution in the context of the affected process. The CVSS vector indicates network-reachable, unauthenticated, low-complexity exploitation with potential full confidentiality, integrity, and availability impact, but real-world exploitability depends on whether a product exposes the vulnerable key-export path to untrusted input.

Why it matters to the business

Products and services embedding affected versions of Mbed TLS through 3.6.5 or TF-PSA-Crypto 1.0.0 may be vulnerable if they process and export FFDH public keys from untrusted peers, messages, certificates, or protocol exchanges. A successful attack could crash services, disrupt embedded or IoT devices, compromise encrypted communications components, or allow execution of attacker-controlled code inside security-sensitive applications. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the high CVSS score warrants priority review because Mbed TLS is commonly embedded in appliances, firmware, SDKs, and downstream products where patch visibility may be limited.

How an attack unfolds

An attacker first identifies a service, device, library consumer, or protocol endpoint that embeds a vulnerable Mbed TLS or TF-PSA-Crypto version and reaches code that exports FFDH public keys. The attacker then supplies or causes the application to handle a crafted FFDH key or key-related structure that is later passed to the public key export routine. During export, the vulnerable code mismanages the destination buffer size or bounds and writes past the expected memory region. In a minimal case, this corrupts memory and terminates the process, producing a denial of service. In a more favorable target environment for the attacker, the overflow may be shaped to alter adjacent memory and hijack execution flow, potentially resulting in code execution with the privileges of the affected application. There are no currently identified threat actors, ransomware campaigns, or confirmed exploitation in the provided intelligence.

How to fix it

Upgrade affected products and embedded library builds to a vendor-fixed release as soon as one is available from TrustedFirmware or the downstream product vendor. The affected scope provided is Mbed TLS through 3.6.5 and TF-PSA-Crypto 1.0.0; no exact fixed versions were supplied, so track upstream advisories and downstream vendor security bulletins for corrected releases. For software you build directly, inventory static and dynamic links to Mbed TLS and TF-PSA-Crypto, rebuild applications against the fixed library, and redeploy firmware or containers that bundle vulnerable copies. If immediate patching is not possible, reduce exposure by disabling or restricting features that import/export FFDH public keys from untrusted sources, rejecting unsupported or unusually large FFDH parameters, enforcing strict key validation before export, isolating affected services with sandboxing and least privilege, and placing vulnerable network-facing components behind access controls until patched.

How to confirm the fix worked

Confirm exposure by checking software bills of materials, package manifests, firmware contents, container layers, and linked binaries for Mbed TLS versions through 3.6.5 or TF-PSA-Crypto 1.0.0. Validate remediation by confirming the affected library is no longer present in deployed artifacts, not merely upgraded in source repositories. For dynamically linked deployments, verify runtime library paths and loaded versions. For statically linked applications and firmware, rebuild and redeploy the consuming application and confirm the embedded library version or patched commit through vendor metadata, binary strings, or SBOM comparison. Functional validation should include regression testing of any FFDH public key import/export functionality and negative testing with malformed FFDH inputs to ensure the service rejects them without crashing or producing sanitizer findings.

Typical attack path

1. Identify a product, firmware image, service, or application that embeds Mbed TLS through 3.6.5 or TF-PSA-Crypto 1.0.0.
2. Determine whether the exposed functionality accepts, negotiates, imports, relays, or exports FFDH public keys based on untrusted input.
3. Craft a malformed or boundary-case FFDH key or key-handling workflow that triggers the vulnerable public key export path.
4. Send the crafted input through the reachable protocol, API, file, message, or handshake path.
5. Trigger public key export inside the vulnerable library.
6. Cause an out-of-bounds write, leading to crash, memory corruption, or possible code execution depending on exploit reliability and runtime protections.

How to detect it

There are no known public exploit indicators, named threat actors, KEV activity, or ransomware usage associated with this issue in the provided intelligence. To assess possible prior exploitation, review logs and telemetry from applications that embed Mbed TLS or TF-PSA-Crypto and expose FFDH key-handling paths. Useful sources include application crash logs, core dump indexes, system journals, container restart events, EDR process crash telemetry, web or protocol gateway logs, TLS termination logs, firmware watchdog resets, and memory-safety sanitizer output from pre-production or canary builds. Look for unexplained segmentation faults, aborts, heap corruption, stack smashing, or AddressSanitizer findings in processes linked to Mbed TLS around the same time as malformed cryptographic handshakes, key import/export operations, unusual certificate/key material, or repeated unauthenticated connection attempts. For forensic triage, preserve core dumps and inspect backtraces for Mbed TLS or TF-PSA-Crypto public key export routines, especially functions associated with PK write/export and FFDH handling. Network-only detection is unreliable because exploitation depends on the consuming protocol and application behavior, but repeated malformed key-exchange attempts followed by process crashes should be treated as suspicious.

• Mbed TLS 3.6.5
• TF-PSA-Crypto 1.0.0
• mbedtls_pk_write_pubkey_der
• mbedtls_pk_write_pubkey_pem
• mbedtls_ffdh
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: stack-buffer-overflow
• AddressSanitizer: global-buffer-overflow
• stack smashing detected
• corrupted size vs. prev_size
• double free or corruption
• malloc(): corrupted top size
• Segmentation fault
• SIGSEGV
• SIGABRT

What your security team should do

• Prioritize asset discovery for products, firmware, containers, and applications embedding Mbed TLS or TF-PSA-Crypto, especially internet-facing, appliance, IoT, VPN, gateway, and embedded use cases.
• Ask vendors and product owners whether their products include Mbed TLS through 3.6.5 or TF-PSA-Crypto 1.0.0 and whether FFDH public key export is reachable from untrusted input.
• Patch or update affected upstream libraries and downstream products when fixed releases are available; rebuild statically linked applications rather than relying only on OS package updates.
• Apply compensating controls for exposed services until patched, including access restriction, feature disablement for FFDH key export where feasible, protocol hardening, and process sandboxing.
• Increase monitoring for crashes or memory-corruption symptoms in services using Mbed TLS, particularly after malformed TLS, cryptographic protocol, or key-processing activity.
• Because KEV status is false, ransomware usage is not reported, EPSS is low, and exploit maturity is none, treat this as high-severity but currently not known exploited; prioritize based on exposure and reachability rather than panic patching alone.