- Stealthium says CVE-2026-47591 in NVIDIA's driver lets an unprivileged user become root, including from inside a container with GPU access.
- The researchers argue that on shared GPU hosts this is a host-level compromise. NVIDIA rates it CVSS 7.8 High.
- Leaders should check driver versions on shared GPU hosts, compare them with NVIDIA's bulletin, and ask whether monitoring would see this attack.
On shared GPU hosts, containers share a kernel and a driver
When a company rents a slice of a GPU, it can be buying something like an apartment. The walls are supposed to keep neighbours apart. Yet where tenants run as containers on one host, they share the plumbing underneath, and that plumbing is the driver software that lets the GPU talk to the machine.
Security firm Stealthium has published research on a flaw in that plumbing. It calls the bug NvRoot and tracks it as CVE-2026-47591. The firm says an unprivileged user on an affected NVIDIA driver can become root, the all-powerful administrator account. Its summary of the risk for rented GPUs is blunt: rent equals root. The firm frames that for multi-tenant environments, meaning hosts where several customers run workloads side by side.
This is the researchers' assessment, and they published no proof-of-concept code. NVIDIA has released a security update for its GPU display driver and vGPU software. The bulletin lists CVE-2026-47591 and credits a reporter named junghyunpark2001. Stealthium says its own team found the bug and reported it to NVIDIA. The sources do not reconcile the two accounts, so Stealthium's claim of discovery stands as its own.
How the attack works
GPU drivers do something that would worry a security engineer elsewhere. They take memory that belongs to an ordinary program and let the GPU read and write it directly. Stealthium says that arrangement only works if the driver checks carefully who may do what to which memory.
A program asks the driver to pin a piece of memory so the GPU can reach it. The request names two permissions: what the processor may do with that memory, and what the GPU may do. The design intends the two to be separate, with the driver honouring each.
The researchers say vulnerable drivers trust the wrong one. They describe a single pin request whose two permission settings disagree, which ends with the GPU able to write to a file the caller is only allowed to read. The target is a program that runs with elevated rights, such as /usr/bin/su.
The attacker then overwrites the in-memory copy of that program with a payload and runs it. The kernel reads the real elevated-rights setting from disk and grants root. Then it runs the rewritten copy. Stealthium says it completed the full chain in its own testing and got a root shell.
Why your usual alarms may stay quiet
Stealthium makes two points that matter for defenders. First, the file on disk never changes, so file-integrity checks see nothing move. Second, the attack looks like normal GPU work. The researchers say the attacker makes a pin call and a GPU write, as every CUDA program does. There is no corrupted kernel memory and no race to win.
The researchers add that the bug is deterministic and does not depend on the kernel version. In their account, the result is the same inside an unprivileged container and on a bare host. They also say they built detection for exploitation before the patch landed.
What it means on shared hardware
On a single-user workstation, a local root bug needs someone already logged in. On a shared GPU host, that someone can be a customer. Stealthium says the poisoned memory is shared with the host. A container with GPU access, which a neocloud customer can buy, could therefore compromise the host. Because the tampered program is the one the host runs, Stealthium says other tenants who run it would execute the attacker's code as well.
NVIDIA scores the flaw CVSS 7.8, rated High. Stealthium recommends treating it as Critical in multi-tenant environments. NVIDIA's bulletin also warns that its ratings reflect average risk across many systems and may not match a specific installation.
Stealthium says it confirmed root on driver 610.43.02. It says the fix in 610.57.04 rejects the write when the memory is pinned. The researchers also say they hold more than 25 further High or Critical findings across the AI runtime stack, under responsible disclosure. Those are unpublished claims, and readers cannot assess them yet.
Questions to put to your team
The lesson here is that GPU capacity is now a shared trust boundary, not just a purchase. Ask your infrastructure team and any GPU provider these questions.
Which of our hosts run NVIDIA drivers that NVIDIA's bulletin lists as affected, and which tables cover our branch? Do any of them let more than one customer or team run code? Has the provider applied the update, and can it say when? Would our monitoring notice an attack that changes only memory and leaves files on disk untouched?
For hosts that cannot be updated at once, the same questions decide which workloads to separate first. The bulletin says earlier branches not listed may also be affected, so check your version before assuming you are clear.
On hosts where tenants share a kernel through containers, privacy depends on the driver as much as on the walls. Verify that the driver has been updated.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NVIDIA.
