A new class of attack on shared GPUs is about to become public knowledge. The issue for operators is less the flaw itself than what it says about who is responsible for security in a multi-tenant AI data centre.
By Steven Foley | Datacenter Focus | 13 November 2026
Most AI infrastructure security conversations focus on the model, the prompt or the network – this weekend an uncomfortable one moves to the hardware.
Researchers at the University of Toronto have shown that the memory inside certain GPUs can be manipulated so that data is quietly corrupted – the technique is called GPUThor. The attack code is scheduled for public release on 15 November, alongside the paper’s conference presentation. The unsettling part is that a safeguard the industry relied on, built to catch memory errors, can be fooled into correcting an error wrongly and reporting no fault at all. The system looks healthy while the data is wrong.
What it means in plain terms
Think of a shared office where every tenant has a locked door, but the walls between offices are thinner than anyone assumed. Nobody has to break in – they only have to make enough noise next door to disturb what’s happening inside.
Earlier research in this family showed the potential consequences for AI. A 2025 demonstration degraded a model’s accuracy from around 80 percent to below 1 percent. The model keeps running and the dashboards stay green, but the answers are quietly worse.
Why operators should care even if they aren’t affected
Let’s be fair about the scope; On current testing, the immediate exposure is concentrated in Ampere-generation workstation cards rather than the newest data-centre accelerators – if your estate is all the latest hardware, this particular flaw may not be your problem, but that is the least interesting part of the story – three things matter more.
The business model is the exposure: Shared GPU rental, where several customers’ workloads sit on the same fleet, is exactly where this kind of attack becomes dangerous. Researchers have also warned that bare-metal AI clouds add a further risk: hardware that is reclaimed and handed to the next customer – if something persists in the hardware between tenants, the operator carries that risk, not the customer.
Fixes will lag. Hardware flaws can’t be patched with a Tuesday update. Mitigations are often settings, replacements or reduced performance, and each one costs money or capacity. Industry frameworks already list delays in vulnerability patching as a risk in their own right.
Customers will start asking. This week Lava Security’s Top 10 list of neocloud and AI data centre risks became an official OWASP project, covering firmware, GPU infrastructure, tenant isolation and shared management systems. A published checklist gives your customers’ procurement and security teams a ready-made set of questions – Operators who can’t answer them will lose deals to those who can.
The real issue is ownership
The unspoken arrangement has been that the chip vendor secures the chip, the customer secures the workload and the operator secures the building. GPUThor shows that the gaps sit between those three -when a shared GPU is compromised, the customer’s first call will be to the operator.
We have already covered how the industry is buying AI security one product at a time while attackers see one connected environment – this is the hardware version of that problem.
Three questions for your next leadership meeting
- Which of our customers share physical GPUs with someone else, and do they know it?
- When hardware is reassigned from one tenant to the next, what proves it is clean?
- If a hardware flaw surfaced tomorrow that we couldn’t patch, who pays for the replacement, and what does our contract say?
If answers to these questions aren’t clear, then this weekend’s headlines will be a useful prompt to find out.
