Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain physical access to target device
-
DeliveryProgram malicious non-secure firmware
-
ExploitSupply crafted pointer targeting secure memory at mailbox init
-
ExecutionBypass TrustZone-M boundary validation
-
PersistRead or corrupt Secure Processing Environment
-
ImpactExfiltrate keys or compromise secure boot integrity
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Ownership verification
|
| Exploitation Conditions | Exploitation requires all of the following: (1) The target device must be a PSOC64 or RP2350 platform running Trusted Firmware-M versions 2 through 2.3.0 - other TF-M platforms are not identified as vulnerable. (2) The attacker must control or influence the non-secure firmware running on the device, as reflected by AV:P (physical access or ability to program the NS side) and PR:L (low privilege in the non-secure world). (3) The crafted pointer must be in place before or during the mailbox initialization phase at boot - this is a one-time initialization window, not a continuously exploitable interface. Exploitation is constrained by the physical attack vector (purely network-based exploitation is not indicated), high attack complexity (precise pointer crafting and initialization-phase timing), and the requirement to execute code in the non-secure execution environment. Default network-exposed configurations of PSOC64 or RP2350 devices are not directly exploitable without first gaining control of non-secure firmware. |
| Impact | The CVSS 7.0 base score (AV:P/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) captures a physically-accessed, high-complexity attack with a full scope change into the secure world - severe in consequence but tightly constrained in reach. AV:P means the attacker must have physical access to the device or the ability to program the non-secure firmware, eliminating purely remote exploitation paths. AC:H further reflects the precision required to craft the pointer and trigger the vulnerable code path during the mailbox initialization window. No EPSS data was provided, no CISA KEV listing exists, and no public proof-of-concept has been identified, all consistent with the embedded/physical attack profile. Despite these limiting factors, the S:C/C:H/I:H/A:H combination signals complete compromise of the secure enclave if exploited - a catastrophic outcome for devices storing keys or performing secure boot attestation. Real-world risk is highest in supply-chain tampering or insider-threat scenarios where an adversary programs non-secure firmware before device deployment on PSOC64 or RP2350 hardware. |
| Exploit ScenarioDerived | An attacker with the ability to program or modify non-secure firmware on a PSOC64 or RP2350 device - for example through supply chain tampering, physical device access, or an insider threat - crafts non-secure code that provides a pointer referencing a secure world memory region during mailbox initialization. At next boot, TF-M's mailbox initialization accepts the unvalidated pointer, allowing the attacker-controlled non-secure code to read cryptographic keys or attestation material from the SPE, corrupt secure state, or crash secure services entirely. No public exploit code or proof-of-concept has been identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 26, 2026
Mailbox initialization in Trusted Firmware-M (TF-M) versions 2 through 2.3.0 on PSOC64 and RP2350 platforms fails to validate a pointer supplied by non-secure world code, allowing a low-privileged attacker with physical access to supply a crafted pointer that crosses the TrustZone-M hardware security boundary. Successful exploitation yields full read, write, and denial-of-service capability over the Secure Processing Environment (SPE), collapsing the hardware-enforced isolation TF-M is designed to guarantee - including potential exposure of cryptographic keys, attestation credentials, and secure boot state. No public exploit code exists and this vulnerability is absent from the CISA KEV catalog; the physical attack vector and high complexity substantially constrain opportunistic exploitation, but the full C/I/A scope change makes targeted supply-chain or insider-threat scenarios consequential.
RemediationAI
The primary fix is to update Trusted Firmware-M to a build incorporating commit 00d1b3e or later, which introduces validation of the non-secure-supplied pointer during mailbox initialization on PSOC64 and RP2350 platforms. The security advisory and patch details are documented at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/53051/1/docs/security/security_advisories/missing_ns_pointer_validation_mailbox_init.rst#58. A formally released patched version number has not been independently confirmed from available data - consumers should verify their build against commit hash 00d1b3e. As a compensating control where patching is not immediately possible, enforcing cryptographic code-signing on non-secure firmware and implementing supply-chain controls that prevent unauthorized NS firmware loading reduces the attacker's ability to supply the crafted pointer, since exploitation requires control over non-secure code executed at boot time.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Trusted Firmware-M is the reference implementation of the Arm Platform Security Architecture (PSA) Certified framework for Cortex-M microcontrollers, providing a Trusted Execution Environment (TEE) through TrustZone-M hardware isolation. The mailbox subsystem is the inter-process communication channel between the Non-Secure Processing Environment (NSPE) and the Secure Processing Environment (SPE), used to relay service requests across the security boundary. During mailbox initialization, TF-M versions 2 through 2.3.0 (CPE: cpe:2.3:a:trustedfirmware:trusted_firmware-m) accept a pointer sourced from non-secure code without verifying that the pointer targets a legitimate NSPE memory region. CWE-283 (Unverified Ownership) describes this root cause precisely: the secure world accepts a resource reference from an untrusted principal without asserting that principal's right to supply it. This flaw is platform-specific, affecting the PSOC64 (Infineon dual-core Cortex-M4/M0+) and RP2350 (Raspberry Pi dual-core Cortex-M33) targets - both implement TrustZone-M-based isolation as the trust anchor for their embedded security model.
Know when Trusted Firmware M gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:P/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Physical access required to program NS firmware; high complexity for initialization-phase pointer injection; scope crosses TrustZone-M boundary into SPE with full impact.
Primary rating from Vendor (mitre).
CVSS VectorVendor: mitre
Lifecycle Timeline
2DescriptionCVE.org
On the Trusted Firmware-M (TF-M) 2 through 2.3.0 platform before 00d1b3e, mailbox initialization on PSOC64 and RP2350 accepts a non-secure, unvalidated, supplied pointer.
Executive ViewAI
Trusted Firmware-M (TF-M) versions 2.0-2.3.0 on embedded platforms (PSOC64, RP2350) contain a pointer validation bypass that compromises the TrustZone-M security boundary, enabling unauthorized access to cryptographic keys, secure boot state, and attestation credentials. Organizations using these TF-M versions in production devices face elevated supply-chain and insider-threat risk, as exploitation requires only physical access and low privilege to extract or manipulate critical security assets.
No vendor-released patch identified at time of analysis. Interim mitigations include: enforce strict physical access controls on devices running affected TF-M versions; implement continuous secure boot verification and re-attestation to detect state tampering; isolate affected devices to controlled environments with network monitoring; prioritize firmware updates the moment vendor patches become available. These measures reduce but do not eliminate risk to the TrustZone-M boundary.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Trusted Firmware M
View allIn Arm Trusted Firmware M through 1.2, the NS world may trigger a system halt, an overwrite of secure data, or the print
Trusted Firmware M 1.4.x through 1.4.1 has a buffer overflow issue in the Firmware Update partition. Rated high severity
In Trusted Firmware-M through 1.3.0, cleaning up the memory allocated for a multi-part cryptographic operation (in the e
In Trusted Firmware-M through TF-Mv1.8.0, for platforms that integrate the CryptoCell accelerator, when the CryptoCell P
Trusted Firmware-M (TF-M) 1.4.0, when Profile Small is used, has incorrect access control. Rated medium severity (CVSS 5
An issue was discovered in Trusted Firmware-M through 2.0.0. Rated medium severity (CVSS 4.7). No vendor patch available
EUVD-2026-66233
GHSA-mv67-8j6q-2cx5
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB