The Secure Vault Inside Your Device Has a Math Bug That Could Let Attackers Forge Digital Signatures

Billions of smartphones, smart TVs, payment terminals, and connected devices carry a hidden secure chamber that's supposed to be unbreakable — and a newly disclosed flaw means an attacker could trick that chamber into accepting forged credentials as genuine.

Who's at Risk — and How Many Devices

The vulnerability, tracked as CVE-2026-33662 and rated HIGH with a CVSS score of 7.5, lives inside OP-TEE — an open-source software project used by device manufacturers around the world to implement a security technology called TrustZone on Arm processors. OP-TEE is not obscure. It underpins secure boot sequences, digital rights management, mobile payment systems (including components of Android's hardware-backed Keystore), and identity verification on devices from set-top boxes to industrial controllers.

Arm's TrustZone architecture powers an estimated over 3 billion devices shipped annually, and OP-TEE is one of the most widely deployed open-source software stacks running inside it. Any product built on OP-TEE versions 3.8.0 through 4.10 — a window spanning several years of releases — is potentially affected. That range covers a vast swath of the embedded and mobile device ecosystem, from consumer electronics to critical infrastructure terminals.

The Vault, the Forgery, and the Math Trick

To understand why this matters, picture your device as a bank with two floors. The ground floor is the normal operating system — Android, Linux, whatever you interact with daily. But there's a locked vault in the basement, a sealed room where your most sensitive operations happen: verifying that software is genuinely from who it claims to be from, processing payment credentials, storing biometric keys. Nothing from the ground floor can read what happens in the vault. This sealed room is TrustZone's "secure world," and OP-TEE is the software that runs inside it.

One of the vault's most critical jobs is checking digital signatures — the cryptographic stamps that prove a piece of software or data is authentic and hasn't been tampered with. Think of it like a wax seal on a royal decree: if the seal checks out, you trust the document. The flaw in CVE-2026-33662 means that under specific conditions, an attacker can craft a malformed signature that the vault accepts as legitimate — even though it isn't. In practical terms, this could mean malicious firmware getting waved through as "verified," a fraudulent payment token being treated as genuine, or a rogue software update bypassing the checks that are supposed to keep it out.

How does the trick work? The vulnerable code is responsible for packaging a signature in a very specific, standardized way — adding structured padding around the actual cryptographic data. To figure out how much padding to add, it does a subtraction. If an attacker can influence the size of a cryptographic key being used (specifically by feeding in an unusually small key), that subtraction goes negative — but because the code doesn't check for this, the negative result wraps around to a huge positive number. The function then happily writes a massive string of padding bytes, corrupting memory in a way that can make forged signatures look valid. It's a classic case of a program trusting its own math without verifying the answer makes sense.

The Technical Anchor: Integer Underflow in `emsa_pkcs1_v1_5_encode()`

For security researchers: the root cause is an integer underflow in the function emsa_pkcs1_v1_5_encode(), located in core/drivers/crypto/crypto_api/acipher/rsassa.c. The "PS size" (padding string length) is computed by subtracting the digest length and fixed EMSA-PKCS1-v1_5 overhead fields from the RSA modulus size. No lower-bound check is performed before this value is passed to a memory-fill operation. By selecting a modulus small enough to cause the result to underflow (wrapping around in unsigned integer arithmetic), an attacker controls the effective length of the 0xFF padding written by the subsequent memset-equivalent call. The vulnerability class is CWE-191 (Integer Underflow) leading to a cryptographic bypass — specifically, signature verification bypass in an EMSA-PKCS1-v1_5 RSA signing context within a Trusted Execution Environment. CVSS 7.5 (High), with the most significant impact vector being integrity: verified-code guarantees can be broken without confidentiality or availability needing to fall first.

Discovery, Exploitation Status, and Known Campaigns

As of publication, no active exploitation has been confirmed in the wild, and no specific threat actors or victim organizations have been publicly linked to this vulnerability. The flaw was identified through code review of the OP-TEE open-source repository, which is maintained under the Trusted Firmware project — the same governance body that oversees foundational firmware for a large portion of the Arm ecosystem.

The absence of confirmed exploitation is not a reason to relax. Vulnerabilities in TEE cryptographic stacks are highly attractive to sophisticated attackers — nation-state groups and advanced cybercriminal operations in particular — precisely because they operate below the radar of conventional endpoint security tools. An exploit running inside TrustZone's secure world is largely invisible to the operating system sitting above it. Antivirus software, EDR agents, and kernel-level monitors cannot see into the vault. This makes bugs like CVE-2026-33662 premium targets for patient, well-resourced attackers who are willing to wait for the right moment. Security teams should treat the absence of a known exploit as a limited grace period, not a safety guarantee.

The OP-TEE maintainers have acknowledged the issue and a patch has been prepared for the project's repository. Device manufacturers and platform vendors who integrate OP-TEE into their products now face the harder challenge: pushing that fix through their own build and certification pipelines and getting it onto devices in the field — a process that can take months in the embedded world, and that never reaches every device.

What You Should Do Right Now

Whether you're an individual developer, a product security engineer, or a CISO overseeing a fleet of embedded or mobile devices, here are three concrete steps:

Identify your OP-TEE version immediately. If your product, platform, or SDK integrates OP-TEE anywhere between version 3.8.0 and 4.10 (inclusive), you are in the vulnerable range. Check your build manifests, vendor BSPs (Board Support Packages), and SDK release notes. The OP-TEE version is typically reported in boot logs or accessible via the TEE supplicant interface on Linux-based systems. If you don't know your version, that is itself an urgent finding.
Apply the patch from the official OP-TEE repository and rebuild. The fix addresses the underflow in emsa_pkcs1_v1_5_encode() by adding a bounds check before the padding calculation is used. Pull from the OP-TEE upstream repository (github.com/OP-TEE/optee_os) targeting the commit that resolves CVE-2026-33662, integrate it into your build system, and push updated firmware to affected devices as quickly as your release process allows. If you use a third-party SoC vendor's OP-TEE fork (common with Qualcomm, MediaTek, NXP, and others), contact that vendor for their patched release.
Audit any RSA signature verification paths that accept external or user-supplied key material. In the near term — before patching is complete — review whether any code path in your system allows untrusted input to influence the RSA modulus size fed into OP-TEE signing or verification operations. Restricting key sizes to safe minimums (2048-bit or larger, enforced at input validation before reaching the TEE) reduces the practical exploitability of this flaw and serves as a useful defense-in-depth measure regardless of patch status.