{"slug": "rent-a-slice-get-the-host-what-nvroot-and-forgeptr-say-about-ai-runtime-trust", "title": "Rent a Slice, Get the Host: What NvRoot and ForgePtr Say About AI Runtime Trust", "summary": "Security researchers at Stealthium published findings on two NVIDIA GPU driver privilege-escalation flaws, NvRoot (CVE-2026-47591) and ForgePtr (CVE-2026-47501), both found by Senior Security Researcher Branislav Brzak with working exploits, and NVIDIA has released fixes. NVIDIA rates each bug 7.8 (High) as a local vulnerability, but the researchers argue they should be treated as Critical on multi-tenant GPU nodes, where an unprivileged tenant can gain root and rewrite files shared with the host and neighboring tenants. Both flaws have existed in the driver since its first open-source release in May 2022, and the team says it has reported 25+ further vulnerabilities across the AI runtime stack that have not yet cleared disclosure.", "body_md": "Every GPU cloud makes some version of the same promise. You rent a slice of a GPU, and the slice is yours. Your model weights, your prompts and your customers’ data stay inside your new rented kingdom.\n\nNeoclouds and hyperscalers actively promote their services as multi-tenant-capable, with users protected by isolation technologies like containers, NVIDIA Multi-Instance GPU (MIG), or virtualization. This gives users a sense of security. Vulnerabilities like NvRoot and ForgePtr say otherwise: the trust stack is weaker and more vulnerable than you think, not as mature as you may assume, and definitely not something you can trust blindly.\n\nThis week our research team publishes about NvRoot (CVE-2026-47591) and ForgePtr (CVE-2026-47501). Two separate privilege escalation bugs in the NVIDIA GPU driver. Our Senior Security Researcher Branislav Brzak found them, and built working exploits for each. We shipped detections for our customers and reported them to NVIDIA, who has since released fixes.\n\n## Rent Shouldn't Equal Root\n\nNvRoot lets an unprivileged user ask the driver for GPU write access to memory they can only read. It leads to root shell. On a shared node, every tenant can rewrite any file it can reach, including the ones it shares with the host and its neighbors.\n\nForgePtr starts with a missing error check and ends with an unprivileged write into kernel memory. From there we switched off ASLR, kernel lockdown and module signing, and loaded an unsigned kernel module on a machine running Secure Boot.\n\nNeither bug needs a special group or capability. They both look like ordinary GPU work to monitoring services or traditional security tooling watching the server. Both have been in the driver since its first open-source release in May 2022, more than four years ago.\n\nNVIDIA scores each one 7.8, High, as a local vulnerability. That is a fair score for a single-user workstation. On a GPU node rented out to strangers, \"local\" means every customer on the box. In that setting, neighbors become landlords. We recommend they be treated as Critical.\n\n## Isolation is sold at the top of the stack. Trust lives at the bottom.\n\nThe isolation story is told in layers customers can see: containers, Kubernetes namespaces, GPU partitions. Underneath every one of them sits a single kernel and a single GPU driver per host, shared by every tenant on it. MIG partitions the GPU. It does not partition the driver. Corruption via the driver breaks every slice above it.\n\nThe partition itself is not airtight either. Our [Behind Bars research](https://stealthium.io/blog/behind-bars-mig-side-channel-model-fingerprinting) showed that a tenant on one MIG slice can recover what a neighbor on another slice is running, across the boundary that is supposed to separate them.\n\nThat is the AI runtime threat surface. The most privileged code on an AI server is also the least watched. Security tooling was built to follow processes, files and network traffic on the CPU. An exploit that runs as a driver call and a GPU write gives that tooling almost nothing to see.\n\nBuilding AI inference or training on infrastructure you can't really trust is a significant challenge, because it undermines the fundamental premise of AI trust. If a neighbor can rewrite the libraries your model loads, you cannot vouch for its outputs. If they can read your weights, your IP is only as safe as the least careful tenant on the node.\n\n(Model poisoning can be incredibly difficult to spot. In our [ROME research we reproduced a known class of attack, Rank-One Model Editing](https://stealthium.io/blog/hands-off-detecting-model-weight-tampering), in which a poisoned Python library edits a model's weights directly in GPU memory. The model file never changes, and nothing watching the CPU sees it happen.)\n\n## Two bugs we can talk about, 25+ we can't yet\n\nNvRoot and ForgePtr are the first of our findings to clear disclosure. We have reported 25+ further vulnerabilities across the AI runtime stack, all going through coordinated disclosure with the technology owners & vendors involved. Stealthium customers are already covered for every one of them.\n\nLet’s pause here. Two vulnerabilities that essentially kill neocloud multi-tenancy, sitting in widely deployed, open-source driver code for four years. AI runtime has had very few people looking at it, and the industry has been treating that silence as safety. In the face of AI’s ongoing vulnpocalypse, we expect uncomfortable light to shine on this surface in the weeks ahead.\n\n## What to do this week\n\nIf you run GPU infrastructure, update to a fixed driver: 610.57.04, 595.91.07 or 580.178.04 for NvRoot, and 615.71.09 for ForgePtr, or later on your branch. Until you have, do not hand GPU devices to tenants or containers you don't fully trust. There is no sysctl or seccomp profile that closes either bug.\n\nFor those renting GPU capacity, today ask your provider at least one question: which driver version are my workloads running on, and when was it last patched? We recommend follow-up questions about whether they can currently detect multi-tenancy abuse in production.\n\nPatching these two bugs is necessary. Though know, there’s further version releases across the runtime stack that will be needed ahead. This attack surface is growing, and is being actively exploited in the wild. We're building Stealthium because you can't blindly trust an environment you can't see or control.", "url": "https://wpnews.pro/news/rent-a-slice-get-the-host-what-nvroot-and-forgeptr-say-about-ai-runtime-trust", "canonical_source": "https://stealthium.io/blog/rent-a-slice-get-the-host", "published_at": "2026-11-12 00:00:00+00:00", "updated_at": "2026-11-12 14:19:24.963683+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "ai-chips"], "entities": ["NVIDIA", "Stealthium", "NvRoot", "ForgePtr", "Branislav Brzak", "CVE-2026-47591", "CVE-2026-47501", "Multi-Instance GPU (MIG)"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/rent-a-slice-get-the-host-what-nvroot-and-forgeptr-say-about-ai-runtime-trust", "markdown": "https://wpnews.pro/news/rent-a-slice-get-the-host-what-nvroot-and-forgeptr-say-about-ai-runtime-trust.md", "text": "https://wpnews.pro/news/rent-a-slice-get-the-host-what-nvroot-and-forgeptr-say-about-ai-runtime-trust.txt", "jsonld": "https://wpnews.pro/news/rent-a-slice-get-the-host-what-nvroot-and-forgeptr-say-about-ai-runtime-trust.jsonld"}}