LAS VEGAS, 9 AUG 2026 — MIT researchers have shown that Spectre v2 mitigations can be stepped around on current Intel and AMD processors, and read the root password hash out of kernel memory to prove it. AMD is writing patches. Intel has declined to, and paid the researchers a few hundred dollars. Arm says the class of attack is not one it protects against.
One disclosure, three vendors, three incompatible answers about whether anything needs fixing. For anyone running mixed hardware, that is the actual problem.
What TONTOU does
The attack's name comes from the window it exploits — Time-of-Neutralization to Time-of-Use. Spectre v2 defences work by neutralising the processor's indirect branch predictor before the kernel uses it, so an attacker's poisoned entries cannot steer execution. TONTOU re-poisons it in the gap between the cleaning and the use.
The attack works by injecting interrupts. An unprivileged program schedules high-frequency timer interrupts, waiting for one to land inside that window. When it does, the interrupt handler runs after the sanitisation and before the victim branch executes, and it re-contaminates predictor structures such as the return stack buffer and the branch history buffer.
Nothing here requires privilege. Local code execution as an ordinary user is the entire prerequisite, with all modern Spectre v2 mitigations enabled.
What it extracted
Daniël Trujillo and Mengjia Yan of MIT CSAIL demonstrated the full exploit on AMD Zen 2, and presented it at Black Hat USA on 6 August.
The more consequential part of the attack is that it breaks kernel address space layout randomisation on every run. KASLR is the assumption a great many other exploits have to defeat first, and an attack that removes it reliably makes unrelated bugs easier to weaponise.
The password hashes make for a good headline, but at 5.47 bytes per second, the extraction is slow. Eighteen minutes of uninterrupted local execution is not nothing to arrange. It is also entirely available to anyone who already has a shell, which on a shared or multi-tenant machine is a considerable population.
Tested silicon spans Intel Cascade Lake Refresh and Arrow Lake and AMD Zen 2 and Zen 4. On Intel, exploitation required specific software conditions the researchers did not fully chain.
Three vendors, three verdicts
| Vendor | Position | Patch? |
|---|---|---|
| AMD | Acknowledged the issue | Yes — committed to kernel patches |
| Intel | Declined further mitigation — real-world exploits depend on too many factors, including whether a usable disclosure gadget exists | No — bug bounty paid in the hundreds of dollars |
| Arm | Classes interrupt injection as passive leakage, which it does not actively protect against | No |
Vendor positions as reported. The disagreement is not about whether the attack works — all three acknowledged the behaviour — but about whether the preconditions make it worth mitigating.
Read the three together and the disagreement is not technical. Nobody disputes that the attack works. They disagree about whether a local attacker with time is a threat model worth spending silicon and performance on.
Intel's argument has some merit. Speculative-execution attacks need a disclosure gadget in the victim code to turn mispredicted execution into an observable signal, and whether a useful gadget exists in a given kernel build is not a property Intel controls. Arm's position is narrower still and honestly stated: this is a category it never claimed to defend.
AMD's is the position that costs money. Committing to kernel patches means an engineering programme and, historically with this class of mitigation, a performance cost borne by every customer including the overwhelming majority who will never be attacked this way.
What a few hundred dollars says
The bug-bounty figure is a footnote and an informative one.
After defeating a mitigation that cost the industry years and measurable performance, demonstrating it end to end, and extracting a password hash from kernel memory for a Black Hat presentation, the researchers received a few hundred dollars from one of the two vendors. Bounty programmes price by exploitability, and by that measure the award is internally consistent with Intel's position that the attack is impractical.
That one number shows the entire incentive structure at work. Microarchitectural research of this kind takes months, needs hardware and expertise most independent researchers do not have, and produces findings that vendors are free to decline to act on. Academic labs can absorb that; the bug-bounty economy cannot. If the finding had been a remotely exploitable flaw in a web application, the same effort would have paid orders of magnitude more.
That matters beyond fairness, because the pipeline that surfaces this class of attack is small and largely academic, and a vendor's right to decline is exercised against a discipline with very few people in it.
The problem this creates for defenders
A security team does not get to pick one of those three answers. It runs a fleet.
Under the ordinary process, a vulnerability arrives with a severity score, a patch, and a deadline, and the work is scheduling. For two of the three vendors, there is no CVE to track, no patch to apply, and no shared assessment of the risk. The decision has been handed back to the operator with three vendors' reasoning and no arbiter.
This pushes the question past "is TONTOU severe" to something more useful: "who can run unprivileged code on this machine, and for how long uninterrupted". On a locked-down single-tenant server the answer makes this uninteresting. On a shared build runner, a multi-tenant host, a CI system that executes untrusted pull requests, or a workstation where users install their own tooling, eighteen minutes of local execution is the normal state of affairs.
What to do
Apply the AMD kernel patches when they land. That part is ordinary.
For Intel and Arm silicon, treat this as a change to your tenancy assumptions rather than a patching task, because no patch is coming. The only available mitigation is to reduce who gets local execution and on what. This means separating untrusted build workloads from secrets and being deliberate about which hosts run code from outside your organisation.
And record the decision. A vulnerability the vendor has declined to fix does not disappear from your estate; it becomes an accepted risk, and accepted risks are only defensible when somebody wrote down what was accepted and why. If your process can only represent "patched" and "unpatched", this class of finding will keep falling out of it.
What to watch
Keep an eye on the USENIX Security presentation in late October; a full paper with more chains demonstrated could change a vendor's position. A working Intel chain would also put direct pressure on their "too many factors" argument. Finally, watch for the performance cost of AMD's patches — that number will decide how many operators actually deploy them.
View author profile → · Editorial policy
