CVE-2026-34871

What it actually does

CVE-2026-34871 is a cryptographic weakness in Mbed TLS before 3.6.6, Mbed TLS 4.x before 4.1.0, and TF-PSA-Crypto before 1.1.0 where a pseudo-random number generator may be seeded predictably. If an attacker can satisfy the local, high-complexity exploitation conditions and infer or influence the seed state, cryptographic outputs that rely on that PRNG may become guessable. Depending on how the library is used, this can undermine confidentiality and integrity by weakening generated keys, nonces, IVs, session secrets, signatures, or other security-critical random values. Availability is not directly affected.

Why it matters to the business

Systems and products that depend on affected Mbed TLS or TF-PSA-Crypto versions may produce weaker cryptographic material than expected, creating risk that protected communications, credentials, device identities, firmware trust chains, or signed transactions could be compromised under specific conditions. The CVSS score is medium-high and the EPSS score is very low with no observed 30-day increase, and it is not listed in CISA KEV or associated with ransomware campaigns, so broad exploitation is not currently indicated. However, because cryptographic flaws can have long-lived consequences when keys or device identities are generated with weak randomness, organizations should prioritize upgrades for products that generate persistent keys, provision embedded or IoT devices, handle regulated data, or use Mbed TLS in authentication, TLS, signing, or secure boot workflows.

How an attack unfolds

An attacker first identifies a target application, appliance, firmware image, or embedded product that uses an affected Mbed TLS or TF-PSA-Crypto release. Because the attack is local and high complexity, the attacker generally needs access to the target runtime, build/provisioning workflow, device, or execution context where random values are generated, or a way to closely observe environmental inputs used for seeding. The attacker then attempts to determine, constrain, or reproduce the PRNG seed and predict future or past PRNG outputs. If successful, the attacker can derive or narrow the search space for cryptographic material generated by the vulnerable component, such as private keys, TLS secrets, authentication tokens, nonces, or signing parameters. The practical outcome depends heavily on product integration: in the most serious cases, predictable randomness could enable impersonation, decryption of protected traffic, forgery of signatures, or compromise of device or service identity. There is currently no public exploit maturity reported, no KEV listing, and no named threat actor activity provided for this CVE.

How to fix it

Upgrade affected cryptographic libraries to fixed releases: Mbed TLS 3.6.6 or later, Mbed TLS 4.1.0 or later for 4.x deployments, and TF-PSA-Crypto 1.1.0 or later. Where operating system, firmware, SDK, or vendor packages bundle these libraries, apply the vendor-provided update rather than only updating source dependencies. Rebuild and redeploy statically linked applications and firmware images, because vulnerable Mbed TLS code may be compiled directly into binaries. For products that generated long-lived keys, certificates, device credentials, signing keys, or provisioning secrets using affected versions, assess whether those materials should be rotated or regenerated after patching. If immediate upgrade is not possible, reduce exposure by limiting local access to devices and build/provisioning systems, disabling nonessential cryptographic operations that generate persistent secrets, ensuring the platform entropy source is correctly configured, and applying vendor hardening guidance. Mitigations should be treated as temporary because the defect is in cryptographic randomness generation.

How to confirm the fix worked

Confirm exposure by inventorying dependency manifests, package manager records, firmware SBOMs, build artifacts, and statically linked binaries for Mbed TLS versions earlier than 3.6.6, Mbed TLS 4.x versions earlier than 4.1.0, and TF-PSA-Crypto versions earlier than 1.1.0. Validate remediation by confirming the runtime or compiled library version reports a fixed version, reviewing build logs and SBOMs for updated components, and ensuring all statically linked applications or firmware images were rebuilt after the library update. For embedded products, verify vendor firmware release notes and binary component analysis where version reporting is unavailable. For high-value systems, consider regenerating keys or certificates created during the vulnerable period and verify new materials were generated only after fixed libraries were deployed. Functional validation should include TLS handshakes, certificate generation, key provisioning, signing, and authentication workflows that depend on the updated library.

Typical attack path

1. Identify software, firmware, or devices using Mbed TLS before 3.6.6, Mbed TLS 4.x before 4.1.0, or TF-PSA-Crypto before 1.1.0.
2. Obtain local access, device access, provisioning access, or a comparable position to observe or influence conditions around PRNG seeding.
3. Analyze the application’s use of the vulnerable cryptographic library and determine which keys, nonces, tokens, or protocol secrets depend on the affected PRNG.
4. Reconstruct, predict, or reduce the entropy of the PRNG seed under the target’s runtime conditions.
5. Use predicted PRNG output to recover or guess cryptographic values generated by the application.
6. Leverage recovered cryptographic material to decrypt data, impersonate a service or device, forge signatures, bypass authentication, or weaken secure communications.

How to detect it

There are no unique network indicators for this vulnerability because exploitation targets cryptographic randomness rather than a specific request pattern or command. To determine whether it may have already been exploited, focus on asset exposure and forensic signs of misuse of cryptographic material. Review software composition data, firmware SBOMs, package inventories, build logs, and binary analysis results to identify affected library versions used during key, certificate, token, or device identity generation. Examine certificate issuance logs, device provisioning logs, authentication logs, TLS termination logs, VPN logs, API gateway logs, signing service logs, and key management system audit logs for unusual key generation events, unexpected certificate creation, duplicate or suspiciously patterned public keys, unexplained authentication from new locations, failed signature validations, or anomalous use of credentials created while vulnerable versions were deployed. On build and provisioning systems, review local access logs, shell history, process execution telemetry, and file integrity data for unauthorized access around periods when cryptographic material was generated. Because successful exploitation may leave no direct artifact, detection should combine dependency exposure timelines with evidence of credential, certificate, key, or device identity misuse.

• Mbed TLS before 3.6.6
• Mbed TLS 4.x before 4.1.0
• TF-PSA-Crypto before 1.1.0
• mbedtls_version_get_string
• MBEDTLS_VERSION_STRING
• libmbedtls.so
• libmbedcrypto.so
• libmbedx509.so
• libtfpsacrypto.a
• tf-psa-crypto
• mbedtls
• mbedcrypto

What your security team should do

• Inventory all applications, appliances, firmware images, SDKs, containers, and embedded products that include Mbed TLS or TF-PSA-Crypto, including statically linked copies.
• Prioritize patching systems that generate long-lived cryptographic keys, device identities, certificates, authentication tokens, or signing material.
• Upgrade to Mbed TLS 3.6.6 or later, Mbed TLS 4.1.0 or later, and TF-PSA-Crypto 1.1.0 or later as applicable, and rebuild dependent binaries and firmware.
• Request vendor confirmation or updated firmware for third-party products that bundle the affected libraries.
• Assess whether cryptographic material generated with affected versions should be rotated, especially for sensitive services, embedded device fleets, provisioning systems, and certificate authorities.
• Restrict local access to devices, development workstations, build systems, and provisioning environments until remediation is complete.
• Add SBOM and software composition analysis checks for vulnerable Mbed TLS and TF-PSA-Crypto versions in CI/CD and firmware release pipelines.
• Monitor for advisories from product vendors that may ship Mbed TLS or TF-PSA-Crypto indirectly, even if the libraries are not explicitly deployed by name.
• Treat the risk as lower immediate exploitation urgency because EPSS is very low, unchanged over 30 days, and there is no KEV or public exploit maturity, but avoid delaying fixes where persistent cryptographic secrets are involved.