OP-TEE

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 14 Last 12 months 31 Lifetime Memory safety 40 % Access control 25 % Parsing/validation 20 % Info disclosure 10 % Latest advisories Loading the feed Overview OP-TEE is the reference TrustZone Trusted Execution Environment and runs as the secure world on a large fraction of Arm Linux and Android devices, set-top boxes, automotive head units and networking silicon. It is where device keys, DRM secrets, fingerprint templates and Android Keymaster/KeyMint operations actually live, so a TEE-boundary escape is a root-of-trust compromise that survives an OS reinstall, and it is very high-footprint code in a place almost nobody audits. Thirty-one CVEs have been published against it in total and fourteen landed in the last twelve months, an unusually high rate of published findings for a project this size, which says the bugs are there and findable. Arm Ltd pays it on the Intigriti Trusted Firmware program alongside TF-A, TF-M and TF-PSA-Crypto, on one shared tier running from $1,000 up to $20,000 for anything scoring CVSS 9.0 or above; every asset in that program is open source, so the top band is reachable from the repository. 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. OP-TEE sits on the same bounty tier as the other three, and the declaration covers its production code as a whole, on the main branch or a currently supported LTS branch The optee_os secure-world OS in full: core boot and initialisation, memory management, the thread and context model, scheduling, and the secure drivers it ships The SMC and RPC interfaces between Normal World and Secure World, which carry every argument the secure side has to treat as untrusted The GlobalPlatform TEE Internal Core API implementation, covering cryptographic operations, the key and key-object model, and the storage, arithmetic and time APIs Trusted Application handling end to end: loading, signature verification, the TA ABI, session and lifecycle management, and the shared-memory model a TA uses to talk to its normal-world client Isolation between Trusted Applications, and between any TA and the secure kernel Secure storage in full: object encryption, the key-blob layer, and the REE filesystem interface it persists through Platform code for Arm platforms, which the program keeps in scope while excluding the non-Arm ports around it Out of scope Self-attacks: a malicious Trusted Application, a signed secure partition or an already-compromised kernel producing no impact outside the originating component Availability-only findings, including boot failures, along with DoS, DDoS and brute-force attacks Code marked experimental, test code and non-production support tooling, none of which meets the program's production-deployment test Platform-specific code for non-Arm products, and "Vulnerabilities in modifications or customisations of Trusted Firmware that do not exist in official Trusted Firmware repos", which puts every vendor fork out "Compliance, hardening, missing zeroization issues, etc. are not in scope", so a missing wipe with no demonstrated exploit path will not be paid Attacks outside the project's threat model, and theoretical issues with no realistic exploit scenario 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 Physical access, glitching and man-in-the-middle attacks, and devices that no longer receive security updates 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 Normal World to Secure World escape: memory corruption in optee_os reachable across the SMC or RPC interface. Memory safety is 40% of the recorded distribution here and this is the CVSS 9-plus shape the $20,000 band exists for Trusted Application loading or signature verification flaws that let unsigned or modified code execute inside the TEE Cross-TA isolation breaks where one Trusted Application reaches another's key material, memory or session state, access control being the next class at 25% Secure storage attacks driven through the REE filesystem interface: key-blob handling that allows decryption, substitution or rollback of stored secrets from the normal world Key material leaking back across the boundary through the cryptographic operations of the GlobalPlatform Internal Core API Any of the above reached from an unprivileged starting point rather than from an assumed compromised kernel or a malicious signed TA, since the self-attack exclusion closes off the alternative 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 finding must cross the TEE boundary: the report has to demonstrate impact outside the originating Trusted Application or Normal World component, not just inside it A proof-of-concept showing the issue is exploitable and causes meaningful security impact is required, using existing supported platform code 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 jointly and control the timing of any advisory. Arm's terms forbid discussing or disclosing vulnerability information, including proof-of-concept videos on YouTube or Vimeo, without prior written consent, and downstream silicon vendors typically need lead time on a TEE fix, so publication is Arm's call rather than a fixed clock. 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