TONTOU: New CPU Attack Steals Passwords from Your Processor

How a tiny timing window in your CPU’s security defenses is letting attackers leak your most sensitive data

Imagine your CPU has a security guard. Every time sensitive code runs, this guard cleans up any potential “bugs” that might have been planted by malicious programs. It’s thorough. It’s systematic. And for years, security researchers thought it was enough.

Turns out, they were wrong.

Researchers from MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) have discovered that this security guard has a critical blind spot—a tiny window of time between when it finishes cleaning and when the protected code actually runs. They’ve named their exploit TONTOU, and it’s letting attackers extract password hashes directly from the Linux kernel.

Here’s what you need to know about this sophisticated attack, how it works, and what it means for your servers.

What is Spectre, and Why Should You Care?

To understand TONTOU, we need to start with its predecessor: Spectre.

Picture this scenario: You’re at a coffee shop, having a private conversation with your accountant about your finances. You’re being careful—you’ve checked that no one is eavesdropping, you’re speaking quietly, and you’ve positioned yourself away from other tables.

But here’s the problem: the barista has been making your drink for months. Every time you come in, they notice the rhythm of your conversation. They’ve learned that when you lean forward and whisper, you’re about to say something financial. Even though they can’t hear the words directly, they can read the patterns—your body language, the timing of your sips, the way you glance around.

That’s essentially what Spectre does to your CPU.

Your processor is constantly trying to optimize performance. When it encounters a branch in code (a decision point like “if this, then that”), it doesn’t wait to see which path is correct. Instead, it guesses—using something called a branch predictor—and starts executing code down that predicted path speculatively, before it knows for certain whether it made the right choice.

Most of the time, this is great for performance. If the CPU guessed right, it’s already done work that would otherwise have been wasted time. If it guessed wrong? No big deal—the CPU throws away the results and takes the correct path.

Except… the CPU doesn’t clean up perfectly. Just like our hypothetical barista could read body language patterns, researchers discovered that you could measure subtle side effects of speculative execution—the CPU’s version of body language. These “side-channel” signals can reveal what the CPU was speculatively working on, including sensitive data it should never have accessed.

Spectre v2, also known as Branch Target Injection (BTI), specifically targets the indirect branch predictor. This is the part of the CPU that predicts where code should jump when the destination isn’t known at compile time—like when the kernel needs to call a function through a pointer.

An attacker who can manipulate this predictor can trick the CPU into speculatively executing attacker-chosen code, which then leaves traces of sensitive data in the CPU’s cache—traces that can be measured and extracted.

The Defenses We Built (And Why They Matter)

When Spectre hit the headlines in 2018, the tech industry scrambled to respond. Intel and AMD, along with operating system developers, deployed a series of patches and microcode updates.

For Spectre v2 specifically, the defense strategy centered on neutralization. The idea was straightforward: before running sensitive kernel code, make sure the branch predictor is clean—free from any malicious influence that might have been planted by untrusted code.

Intel’s implementation is called Enhanced Indirect Branch Restricted Speculation (eIBRS). When enabled, it isolates the branch predictor state, preventing userspace programs from influencing kernel branch predictions. Think of it as a security checkpoint: every time the kernel takes control, it sanitizes the branch predictor to ensure no “bugs” have been planted.

AMD’s approach, called Safe RET, focuses specifically on protecting return instructions. It uses a combination of return thunks and training functions to ensure that speculative returns can’t be hijacked. Essentially, it makes every return instruction deliberately mispredict to a safe location, preventing attackers from steering execution toward malicious code.

These defenses have been considered robust for years. The assumption was that an attacker couldn’t exploit the time between neutralization and actual branch execution—it was simply too short, too unpredictable.

Enter TONTOU: Finding the Gap

Daniël Trujillo, a PhD student, and Professor Mengjia Yan from MIT CSAIL decided to examine this assumption more closely.

What they found was a window that everyone had overlooked—a gap between the Time-of-Neutralization and Time-of-Use. Hence the acronym: TONTOU.

Here’s the insight: neutralization isn’t instantaneous. There’s a brief period after the branch predictor is cleaned but before it’s actually used by the protected code. The researchers discovered that this window, while tiny, is exploitable.

The key to their attack is something called interrupt injection.

How Interrupt Injection Works

Modern CPUs are constantly being interrupted. Network packets arrive, timers expire, hardware signals need attention. These interrupts are how the CPU juggles all its responsibilities, temporarily pausing what it’s doing to handle something urgent before returning to its previous task.

Trujillo and Yan discovered that unprivileged user programs can schedule timer interrupts to occur at specific moments—and these interrupts create the perfect hook for re-poisoning the branch predictor.

Think of it like this: imagine a bank vault. Every time the bank manager enters the vault, security protocols ensure no one else is inside. The vault is thoroughly checked and sealed. But what if, in the split second between when the vault is checked and when the manager actually steps inside, someone could slip in through a side entrance?

That’s what interrupt injection accomplishes. By precisely timing when hardware interrupts fire, the researchers can redirect the kernel to an interrupt handler during that vulnerable post-neutralization window. This handler then “poisons” the branch predictor state—but now it’s happening after the security checkpoint has already run.

The Four Stages of a TONTOU Attack

The researchers broke down their exploit into four distinct phases:

Stage 1: Neutralization

The kernel runs its standard protection, cleaning the branch predictor state. From the CPU’s perspective, everything is secure.

Stage 2: Redirection

The attacker’s pre-scheduled timer interrupt fires at precisely the right moment, forcing the kernel to redirect to an interrupt handler. This happens during the vulnerable window, before the protected branch executes.

Stage 3: Poisoning

The interrupt handler itself contains code that manipulates the branch predictor—specifically targeting the Return Stack Buffer (RSB), which tracks where functions should return. By polluting this buffer, the attacker sets up the conditions for speculative misprediction.

Stage 4: Exploitation

When the kernel resumes execution and encounters a return instruction, the poisoned RSB causes it to speculatively execute attacker-chosen code. This speculative execution accesses sensitive data (like password hashes), leaving detectable traces in the CPU’s cache.

Why Linux Password Hashes Are at Risk

The researchers tested their attack against a real-world target: the /etc/shadow file on Linux systems.

For those unfamiliar, /etc/shadow is where Linux stores password hashes. Unlike /etc/passwd, which is readable by all users, /etc/shadow can only be read by the root user. It’s one of the most protected files on any Linux system.

The attack doesn’t read the file directly—remember, this is a side-channel attack, not a direct exploit. Instead, the CPU is tricked into speculatively accessing areas of kernel memory that happen to contain the file’s contents, and those accesses leave measurable traces in the cache.

On an AMD Zen 2 system running Linux 6.14 with all current Spectre mitigations enabled, the researchers were able to:

• Leak kernel memory at 5.47 bytes per second with 91.97% accuracy
• Break Kernel Address Space Layout Randomization (KASLR) in 10 out of 10 attempts
• Successfully extract /etc/shadow contents in 5 out of 10 attempts, with each successful extraction taking about 18 minutes

Now, 5.47 bytes per second might sound slow. But for password hashes, it’s enough. A typical Linux password hash entry is only a few hundred bytes. With patience—and attackers have plenty of patience—this is a practical exploit.

Who Is Affected?

The attack has been demonstrated on both AMD and Intel processors:

AMD Processors:
– Zen 2 (fully demonstrated with working exploit)
– Zen 4 (confirmed vulnerable)
– Safe RET mitigation does not protect against TONTOU

Intel Processors:
– Cascade Lake Refresh (confirmed vulnerable)
– Arrow Lake (confirmed vulnerable)
– eIBRS mitigation does not protect against TONTOU

The researchers noted that Intel attacks require additional complexities, but the vulnerability exists.

Importantly, the attack works against stock Linux kernels with all default mitigations enabled. No special configuration is needed—in fact, that’s part of what makes this discovery significant. The researchers didn’t have to disable protections or load custom kernel modules. They simply found a gap in the protections themselves.

How This Differs From Previous Attacks

TONTOU isn’t the first Spectre variant, but it represents an important evolution.

Previous attacks like Inception (which Trujillo also contributed to) focused on poisoning branch predictors and hoping the poisoned state would be used later. This was effective but somewhat imprecise.

TONTOU introduces something new: active control over when the poisoning happens. By using interrupt injection, attackers can time their attack to occur precisely when it will be most effective—right after neutralization but before the protected code runs.

This transforms what was once a passive waiting game into an active, predictable exploit.

What Makes Linux Particularly Vulnerable?

Linux isn’t the only operating system vulnerable to TONTOU—the underlying CPU vulnerability exists regardless of OS. However, the researchers demonstrated their attack specifically against Linux, and there are reasons why Linux systems may face higher risk:

1. Open Architecture: Linux’s kernel is open source, making it easier for researchers (and attackers) to understand the exact timing of neutralization routines.

2. Wide Deployment: Linux powers the majority of the world’s servers, including cloud infrastructure where attackers might gain a foothold.

3. Attack Surface: The Linux kernel’s interrupt handling architecture creates exploitable timing windows.

4. Timer Accessibility: Linux allows unprivileged programs to schedule precise timer events—a feature the attack leverages heavily.

What Are the Mitigations?

When the researchers disclosed their findings to Intel, AMD, and ARM, responses varied:

AMD has committed to addressing the issue through kernel patches. They’ve published security advisory AMD-SB-7061, noting that the interrupt injection issue appears to be associated with how Linux implements the Safe RET mitigation.

Intel has acknowledged the research but has not yet committed to specific patches.

ARM has classified TONTOU’s interrupt injections as “passive leakage,” stating they do not “actively protect against” this category of attack.

For organizations running Linux servers, the immediate recommendations include:

1. Apply kernel patches as they become available: Watch for updates from your distribution’s security team.

2. Monitor for suspicious timer activity: While not foolproof, detecting unusual patterns in hardware interrupt requests might indicate an attack in progress.

3. Reduce attack surface: Consider restricting unprivileged code execution on systems storing highly sensitive data.

4. Layer your defenses: No single mitigation is perfect. Defense-in-depth strategies remain essential.

Timeline: How We Got Here

Let’s put TONTOU in historical context:

• January 2018: Spectre and Meltdown vulnerabilities disclosed to the public, triggering a wave of CPU security research.

• 2018-2022: Intel and AMD deploy various mitigations, including eIBRS and Safe RET, specifically designed to neutralize branch predictor attacks.

• July 2023: The Inception attack demonstrates new techniques against AMD processors.

• August 2026: TONTOU presented at Black Hat USA and USENIX Security, showing that neutralization-based defenses have exploitable gaps.

This timeline shows an ongoing cat-and-mouse game. Each mitigation addresses known attacks, but the complexity of modern CPUs means new vulnerabilities continue to emerge.

The Bigger Picture: CPU Security Isn’t Solved

TONTOU illustrates a fundamental truth about hardware security: mitigations are only as good as the assumptions they’re built on.

The neutralization approach made a reasonable assumption—that the time between cleaning and using the branch predictor was too short to exploit. Reasonable, but wrong.

As processors grow more complex, the attack surface expands. Features designed for performance—branch prediction, speculative execution, out-of-order execution—create opportunities for side-channel attacks. And as TONTOU shows, even our best defenses can have blind spots.

This doesn’t mean mitigation efforts are futile. Far from it. eIBRS, Safe RET, and similar protections have raised the bar significantly, making attacks harder and more sophisticated. TONTOU required world-class researchers years of work to develop.

But it does mean that hardware security must remain an active, evolving discipline. Yesterday’s assumptions need constant re-examination.

What This Means for IT Professionals

For those managing Linux infrastructure, TONTOU represents both a specific threat and a broader lesson.

Immediate concerns:

• Assess your exposure. Systems running AMD Zen processors with untrusted userspace code are at highest risk.
• Monitor kernel security advisories from your distribution.
• Plan for kernel updates when patches become available.

Broader implications:

• Side-channel attacks are not theoretical—it’s possible to extract real data in practical timeframes.
• Hardware vulnerabilities require ongoing vigilance, not one-time patches.
• Defense-in-depth matters. If one layer fails, others must be ready.

The Bottom Line

TONTOU isn’t a panic-inducing vulnerability. It requires sophisticated timing, local code execution, and patience. Most organizations won’t face an immediate threat.

But it’s a wake-up call.

When researchers can extract password hashes from a fully patched Linux kernel with all mitigations enabled, it tells us something important: our assumptions about CPU security need constant testing.

The good news? Disclosure works. Trujillo and Yan responsibly reported their findings, giving vendors time to develop fixes before going public. The security community is paying attention, and patches will follow.

The lesson? Stay vigilant, stay updated, and never assume yesterday’s defenses will stop tomorrow’s attacks.

TONTOU was presented at Black Hat USA on August 6, 2026, and will be presented at USENIX Security 2026 (October 27-29). The full research paper is available at MIT CSAIL.