This article covers CVE-2026-47483, an unauthenticated profiling endpoint in NVIDIA DCGM Exporter that lets anyone crash the exporter and read its internals. NVIDIA patched it in July. Recent research published the technical detail on October 8. By the end of that working day we reproduced it, traced it to one block of source, and shipped a detection. Here’s how.

---

At 08:40AM Pacific on October 8, a writeup of CVE-2026-47483 published earlier that day crossed our feed. By 17:00PM the same day, a Stealthium detection for it was merged, covering customers running affected exporters.

NVIDIA's fix, bulletin and patched release shipped earlier, in July. Though while a bulletin tells you a fix exists, it does not upgrade your fleet. And once a public writeup explains the method, the effort needed to use the bug drops to a few lines of script. That gap, between a public method and an upgraded fleet, is where runtime detection earns its place.

The vulnerable component is standard across GPU fleets. DCGM Exporter turns GPU health into Prometheus metrics, and it listens on a routable port so a scraper can reach it. Affected releases also mount Go’s built-in /debug/pprof/ profiler on that same port, unauthenticated, with no way to turn it off. This enables two outcomes for attackers: flood or query. Flooding it causes the exporter to run out of memory and die, taking GPU host monitoring offline. Querying it and the exporter describes its own internals and how it was launched, a free map of the process for whoever asks.

Within a working day we reproduced the flaw, traced it to a single unguarded block in internal/pkg/server/server.go, narrowed the affected range in source to two releases, and shipped a kernel-level detector that raises a high alert the moment the endpoint is touched and escalates to critical once the requests become a flood.

Traditional tooling won’t read this as an attack. The exporter is trusted, its port is meant to be open, and the requests will be well-formed HTTP. A network monitor sees traffic to a metrics port and the crash that follows will read as one more out-of-memory event. When this attack lands, for many organizations, their only view into GPU observability has also just gone dark.

---

From Writeup to Detection

All times Pacific (PDT), October 8, 2026.

Time	Step
08:40	The CVE-2026-47483 writeup crosses our feed
09:10	Triaged against the dcgm-exporter source: the profiler is wired onto the metrics port in shipped code, (not a configuration option)
10:05	Minimal reproduction running: 61 MB to 265 MB under an eight-second flood, flat on the gated build
11:20	Traced through the release history: introduced in 4.8.0, gated in 4.8.2
13:30	Detector written and specced in the engine: high on first contact, critical on a flood
15:45	Verified end to end on a live GPU host
17:00	Detection merged. Customers on affected exporters covered

We unpack the timeline below.

---

Reproducing It

The original research had already shown the crash on NVIDIA's unmodified official container. We wanted a different answer: which line of code, and which releases.

So we built the smallest faithful copy of the exporter's HTTP server: the exact net/http/pprof handler set, mounted on the metrics router the way the shipped server.go mounts it, with roughly 20,000 live goroutines so the profiling dumps come out realistically large. Then we pointed 80 concurrent unauthenticated clients at each shape for eight seconds.

Build	Resident memory under an 8s flood	Data pulled
4.8.1 (vulnerable)	61 MB to 265 MB, still climbing	144 MB
4.8.2 (gated off)	flat, ~90 MB	0.9 MB

Memory was still rising when the flood stopped. Where that leads is the exporter exhausting its memory and crashing.

The heap, goroutine and cmdline endpoints add a smaller information leak on top. They return where the exporter is allocating memory, the call stack of every live goroutine, and the exact flags it was started with. This is a map of the process and its deployment, useful reconnaissance for an attacker choosing a next step. NVIDIA scores the CVE 8.2 (High), with availability impact rated high and confidentiality impact low. We agree with this scoring: the crash is the main impact, and the leak plays a supporting role.

---

Where the Bug Lives

One block in internal/pkg/server/server.go, inside NewMetricsServer. The vulnerable builds register the full profiler on the same router that serves /metrics, on every start, with no authentication and no condition.

// 4.8.1 (vulnerable): on the public metrics port, every start, no gate
router.HandleFunc("/debug/pprof/", pprof.Index)
router.HandleFunc("/debug/pprof/profile", pprof.Profile)
router.HandleFunc("/debug/pprof/trace", pprof.Trace)
router.Handle("/debug/pprof/heap", pprof.Handler("heap"))

We want to be clear that the patch doesn’t remove the feature. It adds a defaulted off gate:

// 4.8.2 (fixed): opt-in behind --enable-pprof, default false
if c.EnablePprof {
    router.HandleFunc("/debug/pprof/", pprof.Index)
    // ...
}

The release tags can actually provide a narrower range than NVIDIA's bulletin:

Version	pprof state
4.7.1 and earlier	endpoint did not exist yet, not affected in source
4.8.0, 4.8.1	registered unconditionally, vulnerable
4.8.2 and later	gated behind --enable-pprof, off by default, fixed

This was a code default, not a misconfiguration. An operator only had to do what the exporter exists for: listen where a scraper can reach it. The original researchers reached the same conclusion from the other direction, by reproducing on the unmodified container.

A note on the range: the 4.8.0 and 4.8.1 window is our reading of the source. NVIDIA's bulletin treats every DCGM Exporter release before 4.8.2 as affected, and that is the range to patch against.

---

How Stealthium Detects It

Before the crash, the only thing that gives this away is the request itself, seen on the host before it reaches the exporter. Stealthium instruments the kernel below the workload, so the pipeline for this class is short:

1. Capture at the socket: the agent reads each inbound HTTP request off the kernel's TCP path, so it sees the request line (GET /debug/pprof/...) for every process on the host, without the exporter's cooperation and without a network sensor in front of it.
2. Attribution: the request is tied to the process that received it. A /debug/pprof/ request landing on a dcgm-exporter process is the signature. The same path to anything else is left alone.
3. Rate and escalation: the first unauthenticated hit raises a high alert, because the vulnerable endpoint is exposed and being reached. The detector counts requests in a sliding window and, once the rate crosses the flood threshold, escalates once to critical for the active denial of service, rather than firing an alert per request.
4. Context: each alert names the process and the request, explains the CVE and the fix, maps to MITRE ATT&CK (T1190 for reaching the public-facing endpoint, T1499 for the denial of service, T1082 for the information leak), and carries a timeline of what was seen.

None of those stages were built for this CVE. Socket capture, process attribution and rate escalation already existed for other detections, which is why adding this one took one of our detection engineer’s afternoon!

What We Caught, Live

We verified it on a live GPU host: a real agent captured the HTTP requests to a running dcgm-exporter process, and the detector raised both severities. Both alerts below are from that run.

Stealthium high alert: unauthenticated profiling endpoint abuse on DCGM Exporter

Stealthium critical alert: profiling endpoint flood against DCGM Exporter

---

Patch Dates Are Not Protection Dates

This CVE is narrow: one endpoint, in one component, fixed by one flag. What it represents are wider risks.

GPU monitoring is privileged, trusted and network-reachable by design. That makes it attack surface, and an awkward kind: when it fails, it takes your view of the host down with it. A denial of service against the exporter is also a way to blind whoever is watching the GPUs on that host.

And the clock that matters is not disclosure to patch, it’s public disclosure (which provides method) to upgraded fleet. NVIDIA closed this in July; the detail that makes it easy to use arrived in October. Every GPU CVE has a version of that window, and coverage has to land inside it, on the host, without anyone re-architecting their monitoring.

This one went from public writeup to merged detection in a working day. That is the turnaround we aim for on every GPU CVE.

For this bug the fix is simple:

• Update DCGM Exporter to 4.8.2 or later.
• Keep --enable-pprof off unless you are actively profiling.
• Bind the exporter to loopback or a private interface, and restrict the metrics port so only your monitoring infrastructure can reach it.

The broader point is having something on the host that tells you the moment that endpoint is touched.

See Stealthium in action. Book a demo.

---

Methods and Attribution

Reproduction: a minimal server mirroring the pprof block in server.go, exercised with 80 concurrent unauthenticated clients for eight seconds against roughly 20,000 live goroutines. Vulnerable shape: 61 MB to 265 MB and climbing, 144 MB pulled. Gated shape: flat near 90 MB, 0.9 MB pulled. Figures are from our local reproduction. The out-of-memory crash on the official container is Lava's result.

Affected range: in source, the pprof block is present in DCGM Exporter 4.8.0 and 4.8.1, introduced in 4.8.0 and gated behind --enable-pprof (default off) in 4.8.2. Releases 4.7.1 and earlier never shipped the endpoint. NVIDIA's bulletin lists all releases before 4.8.2 as affected; patch to that range.

Detection: keyed on an inbound /debug/pprof/ request to a dcgm-exporter process, high on first contact and one critical escalation at the flood threshold, mapped to T1190, T1499 and T1082. Verified end to end on a live GPU host; the screenshots are the alerts from that run.

Vulnerability record: CVE-2026-47483, CVSS 3.1 base score 8.2 High (NVIDIA CNA, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H), CWE-770 Allocation of Resources Without Limits or Throttling. Published July 28, 2026.

Attributing original research: CVE-2026-47483 was found by the Lava Security research team (writeup by Michael Katchinskiy). Our contribution is the source-level root cause, the affected-range analysis and the detection. References: NVIDIA security bulletin, CVE-2026-47483 (NVD), NVIDIA dcgm-exporter.