OP-TEE OS CVE-2026-44362

Exploitation requires local authenticated access (PR:L per CVSS vector) with the ability to present a TA binary to the REE filesystem TA loader (ree_fs_ta_open()). The vulnerable deployment must be configured to use subkey-based signing chains for TA authentication - the rollback bypass only affects this code path; configurations authenticating TAs directly via a root key without subkey delegation are not impacted. The attacker must additionally possess or be able to produce a TA signed with a previously revoked or downgraded subkey, meaning they require access to an older signing key that has been formally revoked. Limiting factors: the attack vector is strictly local (AV:L), not exploitable remotely; subkey signing infrastructure must be in active use; and the attacker needs a validly-signed-but-revoked TA artifact. No user interaction is required once access is established.

The CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N accurately reflects real-world risk: exploitation requires local authenticated access with no network-facing attack surface and no confidentiality or availability impact, yielding a base score of 5.5. The practical severity is, however, context-dependent: for deployments using OP-TEE to enforce DRM, mobile payment attestation, secure boot integrity, or hardware-backed key revocation, bypassing the rollback control is architecturally catastrophic, as the entire trust model assumes revoked keys cannot re-authenticate. For deployments not using subkey-based signing chains, this vulnerability has no impact at all. EPSS data was not provided in the available intelligence sources. No KEV listing exists, and no public exploit code has been identified, so opportunistic or automated exploitation is not anticipated. The primary risk scenario is targeted abuse by a privileged local actor - an insider, a compromised OS process with sufficient access to the TA loader, or a device owner on a consumer device attempting to load unauthorized trusted code.

A locally authenticated attacker on an OP-TEE-enabled device running versions 3.20.0-4.10.x obtains or crafts a TA binary signed with a previously revoked or older-version subkey - for instance, a key deliberately revoked after a prior TA compromise. The attacker submits this TA through the normal ree_fs_ta_open() loading path; because shdr_load_pub_key() silently drops subkey_version and key->version stays zero, check_update_version() passes the rollback check unconditionally, and the TEE loads the unauthorized TA into the TrustZone secure world. No public exploit code has been identified at time of analysis.