ForgePtr (CVE-2026-47501) is an NVIDIA driver local privilege escalation vulnerability found by the Stealthium team. We built a working exploit to demonstrate the bug and confirm root, and reported it to NVIDIA. We also built detection for the bug’s exploitation, live before the patch landed. We’re publishing today enough to understand and defend against it: no proof-of-concept, and some specifics held back. Under responsible disclosure, we have 25+ further High or Critical vulnerabilities across the AI runtime stack.
Let’s have a look at how an NVIDIA driver bug enables a would-be attacker to root shell, escape from an unprivileged container onto the host, and neuter runtime configs including Secure Boot. It’s time to dive into ForgePtr (CVE-2026-47501), ready?
Let’s consider the layers of hardened GPU hosts:
- Secure Boot vouching for the boot and the kernel.
- Kernel lockdown sealing the interfaces that could tamper with a running kernel.
- Module signing making sure only code you trust loads.
- ASLR,
mmap_min_addr, ptrace scoping and the rest raise the price of the next bug. - Containers keeping untrusted workloads in their lane.
- And IOMMU keeping GPU from wandering through host memory.
All the above? ForgePtr takes them off the board, from an unprivileged account, using one bug in the NVIDIA driver underneath.
A single unprivileged write into kernel memory is enough to go from a normal user inside a container to root on the host, then switch off ASLR, kernel lockdown, module signing and Secure Boot's runtime enforcement, and load an unsigned kernel module on a fully locked-down machine. We verified every step on affected hardware.
For organizations who are renting or have rented multi-tenanted GPUs, this exploit is beyond critical. It’s far from a sophisticated bug to exploit. No capability, no group membership, no `CAP_SYS_ADMIN`, just a local account on a machine with an affected NVIDIA driver.
## A(nother) Big Bug
Essentially ForgePtr as a bug is the unprivileged ability to write chosen bytes to a chosen address in kernel memory. Below is how that translates to root and other attacker outcomes.
Becoming Root
We’re gonna start with core_pattern. It’s a template string, held in kernel memory, that says what to run when a process crashes. If it starts with a |, the kernel pipes the crashing process to that program and runs it as root. Writing to it shouldn’t be a thing. It is here. Oops.
ForgePtr can write its own path into core_pattern and stage a tiny script that hands back a root shell. An unprivileged user execs straight into uid=0.
An unprivileged user rewrites core_pattern three bytes at a time, crashes a child, and drops into a root shell.
From Container to Host
This is where a local-root bug becomes such a problem for GPU neoclouds offering multi-tenancy, and those renting that. core_pattern is global kernel state. It is not namespaced, so a process inside a container writes to the exact template the host uses.
Point it at |/proc/%P/root/<payload> and two well-known Linux details line up. %P is the crashing process's PID in the host's namespace, and /proc/<pid>/root/ is a magic symlink to that process's filesystem. The crash handler ends up executing a program that lives inside the container, and runs it as real host root, in the host's namespaces, with no shared folder required.
From an unprivileged container with nothing but GPU access, that is total host takeover: a root-owned backdoor on the host, every other tenant's data readable and writable, persistence on the node, and a clean pivot off it. We are going to state this clearly: ForgePtr, for multi-tenant GPU clouds, allows neighbors to become landlords.
Ciao Hardening Layers
End of day, most Linux system defenses are variables in kernel memory. Given ForgePtr can write kernel memory, it can rewrite configs to their most permissive values, host-wide.
sys_prot_disable resolving each protection to its live kernel address and driving it to zero, including the adjacency guard that skips a hazardous target.
| What ForgePtr can modify | What that gets an attacker |
|---|---|
kptr_restrict |
Kernel pointers stop being masked, handing out live addresses |
dmesg_restrict |
Unprivileged reads of the kernel log, leaking more addresses and state |
randomize_va_space |
ASLR off, predictable memory layouts |
unprivileged_bpf_disabled |
Unprivileged bpf() back on, a whole attack surface reopened |
protected_symlinks /protected_hardlinks |
Classic symlink and hardlink races in /tmp live again |
ptrace_scope |
Any process can attach to any other of the same user |
mmap_min_addr |
Low-address mappings allowed, making kernel NULL-deref bugs exploitable |
kernel_locked_down |
Lockdown dropped to none, unsealing interfaces it was built to block |
sig_enforce |
Module signature enforcement off, so unsigned kernel modules load |
Let’s hold on Secure Boot. Secure Boot's runtime teeth are kernel lockdown and module signature enforcement, and both live in memory ForgePtr reaches. Flip sig_enforce from Y to N, drop lockdown to none, and the kernel will load an unsigned module with the signed bootchain still perfectly intact and completely unaware.
We verified this: unsigned modules on a Secure Boot machine after the teardown runs.
How The Bug Works #
Honestly, the underlying bug is almost boring… It’s a missing error check.
In the driver's event-buffer setup path a caller-supplied handle is converted into a kernel pointer, and nothing checks if that conversion succeeds or fails. Hand it a handle that does not resolve and the driver keeps your raw, attacker-chosen value as if it were a valid kernel pointer, then reports success.
Later, when that object is freed, the kernel decrements a counter at the address you supplied. That’s it: an arbitrary decrement of a chosen location. It becomes "write any byte you like" because decrementing a byte over and over wraps it through every possible value, so for any byte whose current value you can read back, you can land it on whatever you want.
The only other ingredient is knowing where to write, since modern kernels randomize their layout (KASLR). ForgePtr pairs its known target offsets with an additional, unprivileged KASLR leak primitive to resolve each one to its live address.
"But IOMMU" #
Fair elsewhere. Doesn’t help here.
IOMMU polices DMA, the memory a device reaches into. ForgePtr never asks the GPU to touch the target memory. The kernel itself performs the write, acting on a pointer it was handed through an ordinary driver call. The GPU is only the doorway to the bug; it is not what does the writing. So IOMMU mappings, device isolation, and confidential-compute features aimed at GPU memory aren’t applicable security controls in the face of ForgePtr.
The Bug’s Not New #
We traced this flaw through NVIDIA's open GPU kernel modules. It’s present in the very first public release, 515.43.04 from May 2022, and has remained through every build before the version release shipped in September.
That’s multi-tenant GPU security configs as optional for attackers for the last four years.
(Because it’s in the first open release, it likely predates open-sourcing in the closed driver too.)
What to Do #
NVIDIA reports this fixed in driver 615.71.09, which adds the missing error check. If you run NVIDIA's GPU driver, update to 615.71.09 or later.
We want to be clear, there’s no meaningful workaround short of patching. The flaw is in the driver's own logic, reachable by anything that can open the GPU device, so no sysctl or seccomp profile closes it. If you’re a neocloud that hands GPUs to containers or tenants you do not fully trust, we suggest you treat the update as urgent.
NVIDIA Timeline #
- September 9, 2026: NVIDIA releases updated versions, with the fix in driver 615.71.09
- September 30, 2026: NVIDIA publishes its security bulletin, assigns CVE-2026-47501, notifies of covered branches of versions.
Catching ForgePtr #
We found ForgePtr while doing a deep-dive on NVIDIA driver security. Through the weeks between our responsible disclosure and the public fix, the detection below was already protecting Stealthium customers. That’s security coverage ahead of any patch advisory / availability, when the bug was live, unknown, and unfixed.
ForgePtr exploitation looks normal. It opens an expected GPU device, makes ordinary driver calls, and the only outwardly fishy moment is a process crashing, something that happens on healthy machines all day. No socket, no credential, no file dropped where a scanner is looking. We don’t think it’s overstating to say your current security stack will not flag it.
Stealthium instruments the NVIDIA driver and CUDA runtime from the kernel. For this class of attack, there’s a few things to hunt for:
- Malformed setup calls: An event-buffer object constructed around a notification handle that failed to resolve is the trigger itself, visible at the driver boundary the moment it happens.
- Writes that shouldn’t exist: An unprivileged context landing a write on
core_pattern,kernel_locked_down,sig_enforceor the sysctl-backed globals is, by itself, an alert. These are not addresses a normal workload writes. - Boundary crossings: The target is host-global state reached from inside a container. Stealthium treats node's tenancy layout as first-class telemetry, so "a container just rewrote a host-wide kernel global" arrives as a single finding (not something to be pieced together afterwards.)
The same telemetry that allows Stealthium to catch ForgePtr allows us to catch other AI infrastructure attacks. We’re focused on securing production AI, and that starts with visibility across the AI runtime stack.
If you’d like to read our other research, you can head to our other local privilege escalation vulnerability we’re releasing information about today, or head here to read about a model poisoning attack that traditional tools miss completely.
Methods & Attribution #
Vulnerability found by Stealthium Senior Security Researcher: Branislav Brzak
Affected range: present in source in every open-source driver release from 515.43.04 (2022-05-09) through 610.57.04 (2026-08-03); runtime-confirmed to root on 610.43.02 and 610.57.04. Fixed in 615.71.09 (2026-09-09).
Requirements: an NVIDIA GPU driver in the affected range, an unprivileged local account (no special group, no CAP_SYS_ADMIN), and an additional unprivileged KASLR leak primitive to resolve live kernel addresses. The write primitive itself is architecture-agnostic.
References: NVIDIA Security Bulletin, September 2026 · CVE-2026-47501 (NVD)