Trusted Firmware-M

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical (CVSS 9.0 - 10.0) │ $20,000 │ $21,000 High (CVSS 7.0 - 8.9) │ $10,000 │ $11,000 Medium (CVSS 4.0 - 6.9) │ $3,000 │ $3,750 Low (CVSS 0.1 - 3.9) │ $1,000 │ $1,250 Submit a vulnerability CVE history 1 Last 12 months 9 Lifetime Access control 30 % Memory safety 30 % Parsing/validation 20 % Info disclosure 15 % Latest advisories Loading the feed Overview Trusted Firmware-M implements the Secure Processing Environment for Armv8-M and Armv8.1-M parts, the Cortex-M23/M33/M55/M85 generation that has become the default for new IoT and industrial microcontroller designs, and it is the PSA Certified reference implementation, so anything chasing PSA Certified Level 1, 2 or 3 on an Armv8-M part is very likely running TF-M or a vendor fork of it. It ships inside silicon-vendor SDKs from Nordic, STMicroelectronics, NXP, Infineon, Renesas, Microchip and Silicon Labs, and it is the SPE that Zephyr builds against on TrustZone-M targets, which puts it inside smart meters, medical wearables, industrial sensors, building controls, automotive body-domain MCUs and the secure elements of consumer IoT. Nine numbered TFMV advisories have been published against it, one in the last twelve months. Arm Limited pays it on the Intigriti Trusted Firmware program, where every in-scope project shares one bounty tier running from $1,000 to $20,000 for anything scoring CVSS 9.0 or above, and because all four assets are open source that top band is reachable from the repository itself. sorona.xyz adds 1.25× on top of whatever Arm awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Arm's program names four Trusted Firmware projects and takes reports on all of them: TF-A, TF-M, OP-TEE and TF-PSA-Crypto. The asset record describes TF-M as the Secure Processing Environment for Armv8-M and Armv8.1-M parts and for dual-core platforms, and reports run against the main branch or a currently supported LTS branch The Secure Processing Environment as a whole: the Secure Partition Manager, partition scheduling, the isolation levels TF-M implements, and its own secure boot stage and image validation The SPE and NSPE interface: secure function veneer entry points, the non-secure callable region, the PSA client API and the IPC model behind it PSA Secure Storage in both forms, Internal Trusted Storage and Protected Storage, along with the crypto binding and the filesystem layer beneath them The PSA Crypto service, its key store, and key-identifier ownership across partitions The PSA Firmware Update partition, its image validation and its manifest parsing The Initial Attestation service and token generation Mailbox and inter-processor message handling on dual-core platforms Arm-owned platform code under /platform/ext/target/arm/* and the common platform layer above it Out of scope Non-Arm silicon ports: code in the /platform/ext/target/* directory other than /platform/ext/target/arm/* is out, which removes the vendor board support most real TF-M deployments actually ship Experimental, test and example code, along with support tooling, none of which counts as intended for production deployment Attacks outside the project's threat model, and physical or glitching attacks against the part itself Vulnerabilities in modifications or customisations that do not exist in the official Trusted Firmware repositories, including the vendor forks bundled into silicon SDKs Compliance-only, hardening-only and missing-zeroization findings, which Arm states plainly are not in scope Trusted Firmware projects the program does not list, which go to the Trusted Firmware incident handling process, and Trusted Firmware's web estate, which Linaro handles under its own disclosure process Unvalidated LLM output, which the program closes on sight, and reports asserting that software is out of date without a proof-of-concept Findings Arm already knew about from its own testing, closed as duplicates, and zero-days reported within 14 days of a public patch, which are usually not paid Most-valued findings A break in the SPE and NSPE boundary that gives non-secure code read or write access to secure memory or to a secure service it should not reach, the CVSS 9-plus shape that pays $20,000 Key-identifier confusion in the PSA Crypto service that lets one partition use or extract another partition's keys. Access control is the joint-largest class in the TFMV record at 30% Memory corruption in a secure function veneer entry point or in IPC and mailbox message handling, where a non-secure caller controls a pointer or a length crossing the boundary A Protected Storage or Internal Trusted Storage flaw that exposes one partition's data to another, or defeats the storage protection entirely Firmware Update accepting an image whose manifest or signature validation should have failed, giving persistent secure-world code execution Attestation token generation that can be driven to report a device state that is not real, breaking the trust downstream services place in it Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. A proof-of-concept demonstrating a full exploit chain on a supported platform is required, using existing supported platform code rather than a board port you wrote yourself The bug has to reproduce for Arm on either the main branch or a currently supported LTS branch, in code intended for production deployment Unvalidated LLM or AI output is closed, as are reports that assert software is out of date without a proof-of-concept Zero-days found within 14 days of the public release of a patch or mitigation may be reported but are usually not eligible for a bounty Reporters must be 18 or over, must clear sanctions screening, and must not be employed by a Trusted Firmware member company Disclosure Coordinated through Arm PSIRT and the TrustedFirmware.org security team, which publish a numbered TF-M advisory (TFMV-n) once a fix has shipped and downstream silicon vendors have had a chance to pick it up. Arm's terms forbid discussing or disclosing vulnerability information, including proof-of-concept videos, without prior written consent, so publication timing is Arm's call. sorona.xyz holds your finding until the advisory is out. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability