CVE-2025-46733: OP-TEE optee_os · Improper Handling of Exceptional Conditions
Affects OP-TEE optee_osSource CVE Database V5
Not known to be exploited · CVSS 7.9 High.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:LExploitation evidence
Disclosed: evidence found.
CVE published 4 Jul 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
GitHubop-tee/optee_ospkg:github/op-tee/optee_osOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
European organizations should take the following specific mitigation steps: 1) Immediately upgrade OP-TEE to a patched version that includes the fix (commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f) to sanitize return codes and prevent panic triggers. 2) Restrict permissions on the tee-supplicant binary and related processes to prevent unauthorized stopping or replacement, ensuring only trusted users can interact with these components. 3) Implement strict endpoint security controls to limit local user privileges and prevent attackers from gaining the ability to replace tee-supplicant. 4) Monitor for abnormal tee-supplicant behavior or TA panics as indicators of exploitation attempts. 5) For critical systems using fTPM or other TAs with persistent memory, consider additional runtime integrity checks and attestation mechanisms to detect PCR resets or unexpected TA reloads. 6) Conduct security audits of TAs leveraging the Secure Storage API to assess susceptibility to similar panic-triggering attacks. 7) Employ hardware-based protections and secure boot chains to reduce risk of local privilege escalation that could enable this attack. 8) Coordinate with device and platform vendors to ensure timely deployment of patches and security updates.
Description
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE’s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.