What two Google EdgeTPU vulnerabilities reveal about the systems beneath the model
When I began reverse engineering Google’s EdgeTPU, I was not trying to persuade a model to ignore its instructions. I was asking a more basic question: could the processor executing the model itself be trusted?
Most conversations about AI security begin much higher in the stack. We test whether a model can be manipulated through prompt injection, whether hidden instructions can be extracted, or whether safety training can be bypassed. That work is necessary. But it assumes the model is running as intended—that it received the input we think it received, executed the weights we inspected, and returned an output that reached the application unchanged.
A model does none of that alone. Between a prompt and a result sits a chain of frameworks, compilers, runtimes, drivers, memory, firmware and processors. Each layer helps determine what computation actually takes place.
If one of those layers is compromised, an attacker may not need to jailbreak the model. They can go underneath it.
What the EdgeTPU vulnerabilities exposed
The EdgeTPU is an AI accelerator in Google’s Tensor system-on-chip. Android communicates with it through host-side drivers and firmware interfaces, passing commands and data across a boundary between two distinct computing environments.
While analyzing that boundary, I found two memory-corruption vulnerabilities: CVE-2026-0150 and CVE-2026-0153. Google classified them as High- and Critical-severity elevation-of-privilege vulnerabilities in its June 2026 Pixel Update Bulletin.
CVE-2026-0150 was an integer overflow in the EdgeTPU firmware’s ExecuteGraph command handler. The resulting size calculation could lead to an out-of-bounds write. CVE-2026-0153 was another out-of-bounds write, this time caused by an incorrect bounds check while the firmware wrote to a host-message buffer.
Exploiting these conditions allowed me to obtain code execution at the TPU’s EL2 privilege level.
That result matters because an accelerator is not simply a mathematical function implemented in silicon. It is another computer inside the system. It runs firmware, parses commands, manages memory and exchanges messages with other processors. It has its own privilege levels and its own security boundaries.
Root access on the Android host and EL2 execution on the TPU are not the same capability. Modern systems-on-chip are heterogeneous: different processors run different firmware and may have access to different memory, data and peripherals. Crossing from one processor into another can expose attack surface that is supposed to remain isolated even when part of the host is compromised.
The data passing through an AI accelerator may also be sensitive. On-device inference can involve images, voice, documents or biometric-related information that users and developers expect to remain local. Keeping data off a cloud server reduces one class of exposure, but it does not make the local inference path automatically trustworthy.
The EdgeTPU bugs were conventional memory-safety flaws in an unconventional place. That is precisely the point. The chip’s role in AI did not make integer overflow, bounds checking or privilege separation any less relevant.
The model is not the computation
This follows a familiar pattern in systems security. A well-designed application cannot defend itself against a compromised kernel, because the kernel controls the memory and execution environment on which the application depends. An operating system cannot preserve all of its guarantees if a hypervisor, trusted execution environment or firmware layer beneath it has been taken over.
AI systems inherit the same dependency. We often treat “the model” as both the artifact being evaluated and the computation eventually performed. They are not necessarily the same thing.
There are really two security questions. The first is whether the model behaves safely when it receives an adversarial input. The second is whether the intended model was actually executed on the intended input and whether its result arrived intact. Prompt-injection testing addresses the first question. The integrity of the execution stack determines the second.
Recent research shows that this distinction is not limited to the case where an attacker has already compromised firmware.
In June 2026, researchers introduced FloatDoor, a platform-triggered backdoor for language models. They measured the same Qwen model across 23 deployment platforms, including NVIDIA GPUs, Google TPUs, server CPUs and Apple silicon. Because low-precision floating-point arithmetic is not associative, and because hardware and inference backends perform operations in different orders, each platform left small but measurable differences in the model’s internal state.
The researchers trained lightweight adapters to amplify those differences into a platform signal. The resulting checkpoint could behave normally on one platform but produce attacker-chosen behavior on another. In one experiment, it was roughly three times more likely to generate vulnerable code on the targeted platform, while its general benchmark performance remained largely unchanged.
Another study, Your Compiler Is Backdooring Your Model, examined a different part of the same problem. Deep-learning compilers optimize models through transformations such as operator fusion, parallelization and hardware-specific code generation. Those transformations can reorder floating-point operations. The researchers showed that a specially constructed model could appear benign before compilation and activate a backdoor after being processed by an official, unmodified compiler.
FloatDoor, the compiler work and my EdgeTPU research attack different layers of the stack. Together they make a broader point that model-centric security reviews tend to miss: the behavior of a deployed AI system is not solely a property of its weights.
The framework that loads the model, the compiler that transforms it, the numerical backend that evaluates it, and the processor that executes it all participate in producing the answer.
Agents make the integrity of that answer more important
For a conventional classifier, a corrupted inference result might mean a wrong label. For a chatbot, it might mean a false or unsafe response. Those outcomes can already be serious, but an AI agent adds another step: it can turn the response into an action.
Agents increasingly call APIs, write code, query databases and interact with payment, identity and administrative systems. In that setting, the output of inference is not merely displayed to a user. It may be parsed as a tool call and executed automatically.
Suppose a model correctly refuses an unsafe administrative request. If the execution environment replaces its result with a valid-looking command after inference, the orchestration layer may act on something the model never produced. The alignment policy worked. The system still failed.
The same is true if a malicious checkpoint behaves safely during an audit but activates only on the hardware used in production. The auditor and the user may believe they evaluated the same model, yet the deployed system follows a different path.
The effect is bounded by the authority given to the agent. High-impact actions therefore need controls outside the model: narrow credentials, deterministic authorization checks, transaction limits and human approval where appropriate. A prompt is an instruction to a model. It is not an authorization boundary.
Looking below the model
AI security needs to follow the complete path from input to action. That includes the model, but also the code and hardware that give the model operational meaning.
Model-loading code and file formats should be treated as parsers of untrusted input. Compilers and optimized runtimes need testing for semantic as well as functional consistency. Driver and firmware interfaces deserve the same fuzzing, reverse engineering and privilege-boundary analysis applied to operating systems and network protocols. Firmware updates need a trustworthy signing and rollback-protection chain. Where attestation is used, its root of trust must sit outside the component being measured; a compromised processor cannot meaningfully vouch for itself.
Model-level testing remains necessary, but it cannot answer what happens below the model. Prompt injection, data poisoning and alignment cover only the layers at which the model can defend itself.
Security research often becomes more powerful when it moves one layer down. Instead of attacking an application’s checks, an attacker targets the kernel enforcing them. Instead of attacking an operating system’s policy, they target the firmware beneath it. In an AI system, the same principle applies: if the environment performing inference cannot be trusted, the model cannot restore that trust from above.
The EdgeTPU vulnerabilities are one example of what becomes visible when we stop treating AI hardware as a black box. The broader lesson is simple: a model’s output is only as trustworthy as the system that computed and acted on it.
