TL;DR - On 6 August, researchers disclosed a new CPU side-channel attack they call TONTOU. It sidesteps the Spectre v2 mitigations most Linux fleets have been carrying since 2018, and a working proof of concept on Linux was able to read password hashes out of process memory. The good news is that mitigations are already in mainline and stable Linux kernels, and the microcode updates are rolling from the chip vendors. What you need to do: confirm your fleet is on a patched kernel, confirm the CPU microcode is current, and treat any unpatched box as exposed until you have evidence otherwise.
I was halfway through a kernel audit on a client fleet last Wednesday when the TONTOU write-up landed in my RSS reader. I was already in the right headspace, which is the only reason I did not just bookmark it and move on. I had two servers on the screen, both supposedly patched for the class of bug TONTOU is in, and the disclosure was telling me the patch we already ran might not be enough.
That is the part worth pausing on. Spectre v2 is not a new story. We have been carrying its mitigations in our kernels and our microcode for the better part of a decade, and most sysadmins I work with treat the Spectre family as done. After last Wednesday I am treating it as a treadmill that just had another step bolted on the back.
By The Numbers
| Number | What it means |
|---|---|
| 2018 | The year the original Spectre v2 mitigations landed in Linux and in x86 microcode |
| 6 Aug 2026 | Date the TONTOU research was disclosed |
| 2 | Patches you need: a CPU microcode update AND a kernel update. One is not enough |
| 0 | Publicly confirmed in-the-wild exploitation as of the disclosure |
| /etc/shadow | The Linux file the proof-of-concept targeted, by reading the hashed credentials out of an unprivileged process |
| Seconds, not minutes | The order of magnitude the proof of concept needed to extract a usable hash from a vulnerable system (precise timing not in the public disclosure) |
What TONTOU actually is
Every CPU vulnerability story since Spectre has been a game of cat and mouse between researchers and the mitigations chip vendors and kernel developers bolted on top of the original fixes. The mouse finds a new corner of the speculative-execution machinery that the original mitigations did not cover, the cat adds a new barrier, and the treadmill turns.
TONTOU is a fresh corner. The research team showed a way for an unprivileged process to coax a vulnerable CPU into leaking the contents of memory it should not be able to see, even on a system that has every Spectre v2 mitigation enabled. The technique works against the IBRS, IBPB, and retpoline stack we have been running since 2018. That stack is not enough on its own.
The proof of concept runs as an ordinary user, in a vanilla Linux process, against a kernel that has the original Spectre v2 mitigations compiled in. From there it walks the side channel and reads credential material out of other processes. For a Linux box that is doing anything with authentication, that is exactly the memory you do not want a side channel reaching.
This is not a vulnerability in the Linux kernel. It is a vulnerability in the CPU, exposed through a side channel the kernel and microcode together are supposed to close. The fix has to land in both places, which is the part that catches IT teams out.
Why the patch treadmill is not over
I have been having the same conversation with clients for about eight years now. We patched for Spectre in 2018, then for Meltdown, then for the Spectre NG variants, then for L1TF, MDS, TAA, SRBDS, Downfall, Reptar. Each time the same shape: a new research paper, a new kernel, a new microcode, a small batch of servers to reboot.
A Linux sysadmin running a small fleet in 2026 is carrying a long list of microcode updates and a long list of kernel security advisories, and the discipline of running both has quietly become its own job. The easy mistake is to patch the kernel and assume the microcode came along for the ride. With this class of bug, the microcode is most of the fix. The kernel piece is the plumbing that turns the new microcode on.
That is the mistake TONTOU is built to expose.
What the patch actually looks like
The mitigations are in the upstream Linux kernel and in the stable trees the major distributions backport from. The microcode updates are in flight, with the chip vendors publishing new packages and the distro vendors repackaging them. The shape of the fix is the same shape we have been running since 2018, with a fresh set of version numbers.
On Debian or Ubuntu the move is to install the current distro kernel, reboot, and confirm the microcode package is current. On RHEL, AlmaLinux, Rocky, or Oracle Linux the move is the same through the vendor's update channel. The patch path is ordinary. The verification is the part that tends to slip.
Three checks, in order:
- Kernel version. Confirm the running kernel is from a build that includes the TONTOU mitigations. A
uname -rand a comparison against your distro's advisory feed is the minimum. - Microcode version. Confirm the CPU microcode is the post-TONTOU build. On Intel, the
intel-microcodepackage is the easy path. The kernel exposes the loaded microcode revision through/sys/devices/system/cpu/cpu0/microcode/version, and the value there should match the post-TONTOU revision for your CPU model. - Mitigations on. Confirm the kernel turned the new mitigations on. The
spectre_v2line in/sys/devices/system/cpu/vulnerabilities/is the canonical readout. After a patched reboot the file should show a status other thanVulnerablefor Spectre v2, and any new TONTOU-specific entry should showMitigationorNot affecteddepending on the kernel.
The third check is the one teams skip. They patch the kernel, they install the microcode, and they never look at the vulnerabilities file to confirm the kernel noticed. It is a five-second check that turns a guess into evidence.
Hash leak: what an attacker actually walks away with
The reason this matters beyond the usual CPU-vuln hand-wringing is the password-hash piece. The proof of concept read credential material out of process memory. On a Linux server the most useful thing an attacker can usually find in memory is a hash from /etc/shadow, a Kerberos ticket, or a session token for a privileged service. None of those are cleartext passwords, but a stolen hash is a stolen password for any account whose hash the attacker can copy.
For an ANZ SMB running a Linux fleet the attack chain is short. A vulnerable box doing any kind of authentication is the target. A user account on that box, or any process that is allowed to run code on it, is the entry point. From there the side channel leaks a usable hash, and the attacker tries to crack it offline. If the password is short or reused, the hash cracks in minutes, and the attacker has a credential that works on the box they started on and on every other box where the same account has the same password.
The TONTOU leak is one box. The credential reuse is the part that turns one box into a fleet-wide problem. The standard hardening discipline applies, and it has applied since 2017: long unique passwords per service, no shared admin accounts, no service accounts whose password hash lives in /etc/shadow and not in a secrets manager.
Where to look in your environment
If you run a small Linux fleet the audit is short. For each box, three things, in order:
- The running kernel version and whether it is from a build that includes the TONTOU mitigations.
- The loaded CPU microcode revision and whether it is the post-TONTOU revision for your CPU model.
- The contents of
/sys/devices/system/cpu/vulnerabilities/spectre_v2and the new TONTOU-specific status entry if your kernel has one.
If you run a managed Kubernetes cluster or a hosted database, the platform team handles this for you, but verify rather than assume. Most Linux distributions backport security fixes into their stable kernels without bumping the major version, which is good for stability and bad for the audit. A box on a 5.x LTS kernel from a year ago may or may not have the patch, depending on the distro's backport policy. The way to find out is the checks above, not the kernel version alone.
If you are running a kernel you built yourself, or a kernel from a vendor whose update cadence you are not sure of, this is the week to find out. The patches are in mainline and the stable trees. The gap is usually in the rebuild and the rollout, not in the patch itself.
The honest reassurance
Nothing about TONTOU is unusual in shape. The disclosure was coordinated, the patches were ready, and the mitigation is the same kind of kernel-and-microcode update we have been running for years. There is no public proof of exploitation in the wild, no ransomware crew has claimed TONTOU as a vector, and the proof of concept runs in a research setting, not an opportunistic attack.
The reason I am writing it up anyway is the patching gap. Most of the Linux servers I have audited over the last year have the Spectre family of mitigations in place, and a meaningful minority of them have stale microcode, or kernels that did not pick up the backport, or vulnerabilities files that say Vulnerable for one of the older variants. The shape of the gap is predictable. The fix is to close the gap on the predictable schedule, not to wait for the next paper.
FAQ
Is this a Linux-specific bug?
No. TONTOU is a CPU side-channel attack. The proof of concept was demonstrated on Linux because that is where the researchers built the demonstration, and because the Linux kernel exposes the right primitives for the kind of memory reads the attack needs. Any operating system running on a vulnerable CPU can be targeted the same way. The patch shape is the same everywhere: microcode plus kernel mitigations.
Do I need to worry if my servers are virtualised?
Yes, if the hypervisor is not on a patched microcode and a patched kernel. The side channel does not stop at the guest boundary. A vulnerable hypervisor can leak the contents of one guest into another. Confirm with your hosting provider that the host kernel and the host microcode are current, and confirm your guest kernels are too.
Will the kernel update break anything?
It is unlikely, but the standard kernel-update discipline applies. Test on a non-production box first, especially if you have any out-of-tree kernel modules (some storage drivers, some specialised network drivers, GPU drivers on bare metal). The microcode update itself is non-disruptive in most cases and takes effect at the next reboot, but the kernel mitigations only turn on once the box is rebooted into the new kernel.
What if I cannot reboot this week?
You can install the microcode and the kernel package without rebooting, and the mitigations will be queued for the next maintenance window. The risk in the gap is that an attacker who already has a foothold on the box can use the side channel during the gap. If the box is internet-facing and the service it runs is exposed, treat the gap as live risk and prioritise the reboot.
Is there a workaround without the patch?
The kernel ships with a knob to force the new mitigations on, and some distros will let you enable it ahead of the full microcode update. It is not a substitute for the real patch. The CPU is still vulnerable, and the knob only changes the kernel's behaviour. Use it as a stopgap on the way to a proper patch, not as a plan.
My take
I have been a Linux sysadmin long enough to know that the boring answer is usually the right one. Boring answer here: patch the kernel, update the microcode, reboot, check the vulnerabilities file, write the result in your runbook. That is the same answer we have been giving since 2018, and it still works.
The less boring answer is that the treadmill is not slowing down. The research community is still finding new ways to use the speculative-execution machinery every modern CPU ships with, and the kernel and microcode communities are still closing them one at a time. The discipline of running both, on every box, on a predictable schedule, is the difference between a fleet that absorbs the next paper and a fleet that finds out about it from a breach notification.
I spent Wednesday afternoon running the three checks on the two boxes I already had open. One was clean. One had a stale microcode, which I had assumed the host provider was handling. The host provider was not. I have fixed it and added a microcode check to my quarterly Linux audit, because the predictable gap is the one I am trying to close.
Forward this to whoever owns your Linux fleet, especially if that person is also the person who set the boxes up three years ago and has not looked at them since. The patch is the easy half. The verification is the half that decides what happens next.
Mathew Clark
Founder, SecureInSeconds
Currently: comparing microcode revisions on a small Linux fleet and finding more stale microcode than I would like to admit.
Further Reading
- New TONTOU CPU attack bypasses Spectre v2 fixes, leaks Linux password hashes (BleepingComputer) - the original disclosure coverage
- Linux kernel vulnerabilities file documentation (kernel.org) - the canonical read for
/sys/devices/system/cpu/vulnerabilities/ - Intel microcode update guidance (Intel) - the vendor's own update path
- Spectre variant 2 mitigations on Linux (kernel.org) - the long-form documentation of the mitigations we have been carrying since 2018
- SecureInSeconds: the August 2026 patch Tuesday breakdown - the related Microsoft patching story
- SecureInSeconds: verify before you patch, the CISA KEV triage workflow - the triage discipline that applies to CPU disclosures too
- SecureInSeconds: the MFA fatigue playbook for session revocation - because the credential the side channel leaks is the same credential the attacker will try to use
