Skip to content

TF-PSA-Crypto

By Arm Ltd Bug bounty on Sorona

Accepting reports KYC to get paid open-source
Top reward
$20,000
Top severity paid
Critical
Assets in scope
8
Public CVEs
76
Last change
No changes yet

At a glance

What to know before you start testing.

Pays up to $20,000
for critical bugs.
Partial safe harbor
Some legal protection; read the terms.
Payment
Proof of identity needed to get paid.
Publish after a fix
Coordinate the timing with the company.

Rewards

What Sorona lists as the payout for each severity.

Severity Reward
Critical $20,000
High $10,000
Medium $3,000
Low $1,000
Safe harbor
Partial 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.

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Scope

8 assets you may test, 8 excluded.

Web 1

  • https://www.trustedfirmware.org/projects/mbed-tls

Products and areas 7

  • 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 here is TF-PSA-Crypto, which the brief describes as a submodule of Mbed TLS, and the vulnerability has to be exploitable through the PSA Cryptography API. Reports run against the main branch or a currently supported LTS branch
  • Asymmetric operations: key generation, signature and verification, key agreement and asymmetric encryption across RSA and the supported elliptic curves
  • Key import, export and format parsing, plus key derivation and the policy checks that decide what a key may be used for
  • Symmetric operations end to end, cipher, AEAD, hash and MAC, including the multi-part operation state machines
  • The PSA Cryptography API surface in full: the core dispatch layer, key management and the key store, key policies, and the driver interface beneath them
  • The random generator and the entropy plumbing the library depends on
  • The software implementations sitting under the PSA layer, including the bignum, elliptic-curve and RSA code a call actually lands in
Out of scope (8)
  • "Attacks that are outside the scope of the project's threat model", which for a crypto library rules out a good deal of theoretical side-channel work
  • "Compliance, hardening, missing zeroization issues, etc. are not in scope", so a missing wipe with no demonstrated exploit path will not be paid
  • 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
  • Mbed TLS bugs with no path through the PSA Cryptography API. "Attacks against Mbed TLS that don't impact TF-PSA-Crypto" are excluded by name, and the live brief no longer lists Mbed TLS as an in-scope project at all
  • Self-attacks from an already-compromised caller, and findings whose whole impact is loss of availability
  • 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
  • "Vulnerabilities identified in code marked as experimental, test code or other non-production code e.g. support tooling"
  • "Vulnerabilities in modifications or customisations of Trusted Firmware that do not exist in official Trusted Firmware repos", including the vendored copies inside RTOS distributions

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.

While testing

  • Submit through sorona.xyz first.
  • The vulnerability must be exploitable using the PSA Cryptography API
  • A proof-of-concept demonstrating that the issue is exploitable and causes meaningful security impact is required
  • The bug has to reproduce for Arm on either the main branch or a currently supported LTS branch, in code intended for production deployment
  • Reporters must be 18 or over, must clear sanctions screening, and must not be employed by a Trusted Firmware member company

Not accepted

  • Compliance, hardening, missing zeroization issues, etc. are not in scope
  • Vulnerabilities identified in code marked as experimental, test code or other non-production code e.g. support tooling
  • Attacks that are outside the scope of the project's threat model
  • Vulnerabilities in modifications or customisations of Trusted Firmware that do not exist in official Trusted Firmware repos
  • Self-attacks from an already-compromised caller
  • Findings whose whole impact is loss of availability
  • Findings Arm already knew about from its own testing
  • Duplicates
  • Zero-days reported within 14 days of a public patch

Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original

Changes

Tracked since 11 Nov 2026. Last checked 1 hour ago.

No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.

Public CVEs

Published vulnerabilities in this vendor's products, from the NVD.

Sorona credits this project with 76 CVEs, 15 of them recent. The individual records appear here after the next sync.

Original policy

Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.

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 15 Last 12 months 76 Lifetime Memory safety 35 % Parsing/validation 25 % Info disclosure 20 % Auth bypass 10 % Latest advisories Loading the feed Overview Mbed TLS is the default TLS and crypto stack of the embedded world, the implementation shipped inside Zephyr, Mbed OS, FreeRTOS and Espressif's ESP-IDF, which puts it in a very large share of Wi-Fi-enabled microcontrollers and consumer IoT, and TF-PSA-Crypto is its cryptography submodule and the reference implementation of the Arm PSA Crypto API that Arm is pushing across the whole Cortex-M secure ecosystem. The deployment footprint is measured in billions of endpoints that are rarely patched and often internet-reachable, which is why roughly seventy-six CVEs have been published against this codebase over its lifetime and around fifteen in the last twelve months. Arm Ltd pays it on the Intigriti Trusted Firmware program on one shared tier running from $1,000 to $20,000 for anything scoring CVSS 9.0 or above, with the important caveat that the in-scope asset is TF-PSA-Crypto rather than Mbed TLS as a whole: the vulnerability has to be exploitable through the PSA Cryptography API. 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 here is TF-PSA-Crypto, which the brief describes as a submodule of Mbed TLS, and the vulnerability has to be exploitable through the PSA Cryptography API. Reports run against the main branch or a currently supported LTS branch The PSA Cryptography API surface in full: the core dispatch layer, key management and the key store, key policies, and the driver interface beneath them Symmetric operations end to end, cipher, AEAD, hash and MAC, including the multi-part operation state machines Asymmetric operations: key generation, signature and verification, key agreement and asymmetric encryption across RSA and the supported elliptic curves Key import, export and format parsing, plus key derivation and the policy checks that decide what a key may be used for The random generator and the entropy plumbing the library depends on The software implementations sitting under the PSA layer, including the bignum, elliptic-curve and RSA code a call actually lands in Out of scope Mbed TLS bugs with no path through the PSA Cryptography API. "Attacks against Mbed TLS that don't impact TF-PSA-Crypto" are excluded by name, and the live brief no longer lists Mbed TLS as an in-scope project at all "Compliance, hardening, missing zeroization issues, etc. are not in scope", so a missing wipe with no demonstrated exploit path will not be paid "Vulnerabilities identified in code marked as experimental, test code or other non-production code e.g. support tooling" "Attacks that are outside the scope of the project's threat model", which for a crypto library rules out a good deal of theoretical side-channel work "Vulnerabilities in modifications or customisations of Trusted Firmware that do not exist in official Trusted Firmware repos", including the vendored copies inside RTOS distributions 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 Self-attacks from an already-compromised caller, and findings whose whole impact is loss of availability 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 Memory corruption in TF-PSA-Crypto reachable through a PSA Cryptography API call with attacker-influenced input. Memory safety is 35% of the recorded distribution and this is the shape that scores CVSS 9-plus and pays $20,000 Parsing and validation flaws in key import and format handling, where untrusted key material drives the parser into an out-of-bounds read or write Key-material disclosure through the key store or an API return path, in a library whose entire job is to keep that material opaque to the caller Signature or MAC verification that accepts a forged value as valid, since everything above it in an embedded stack treats that answer as authoritative Any of the above demonstrated through the PSA Cryptography API rather than through an Mbed TLS-only code path, which separates a paid report from an out-of-scope one 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. The vulnerability must be exploitable using the PSA Cryptography API — "Attacks against Mbed TLS that don't impact TF-PSA-Crypto" are excluded by name, so a wider Mbed TLS bug needs a demonstrated PSA-API path A proof-of-concept demonstrating that the issue is exploitable and causes meaningful security impact is required The bug has to reproduce for Arm on either the main branch or a currently supported LTS branch, in code intended for production deployment 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, who triage the Trusted Firmware assets jointly and publish once a fix has shipped and the downstream RTOS and SDK vendors that vendor this code have had time to pick it up. Arm's terms forbid discussing or disclosing vulnerability information without prior written consent, so publication timing is Arm's call. sorona.xyz holds your finding until it has been resolved and published. 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