Sometime between March and May, researchers at datacenter security startup Lava pointed a scanner at the public internet and found roughly 2,100 GPU servers willing to describe themselves to anyone who asked. Hardware model, utilization, memory pressure, power draw, error counts. No credentials, no exploit, just an HTTP GET to port 9400.
The vulnerability that came out of that research, CVE-2026-47483, is real and worth patching. It is not the interesting part of the story.
What Lava's scan actually found
The numbers deserve a slow read. About 2,100 exposed servers. Roughly 12,000 individual GPU UUIDs observed across some 300 organizations. The exposed hardware ranged from NVIDIA Blackwell Ultra B300, H200, and H100 datacenter cards down to consumer RTX 5090 and 4090 systems, which tells you the pattern spans serious training clusters, inference startups, and someone's well-funded side project alike.
The exposed boxes sat at infrastructure belonging to, among others, Nebius, Voltage Park, Lambda, Northern Data, and DigitalOcean. Some of that will be tenant workloads rather than provider-managed kit, and that makes it worse, not better. It means the misconfiguration is a common team-level habit, not one vendor's bad default.
Around 25 percent of the exposed hosts went further and also served Go's built-in /debug/pprof profiling data to the open internet. Keep that number in mind.
How a monitoring agent ends up public
DCGM Exporter is a small Go daemon. It reads telemetry out of NVIDIA GPUs and serves it in Prometheus format over plaintext HTTP on port 9400. It ships with no authentication. That is normal in the Prometheus ecosystem: the metrics endpoint is assumed to sit on a trusted network, with access control handled by the network layer around it.
The assumption breaks in deployment. The standard install is a Kubernetes DaemonSet, usually from a Helm chart, running with the elevated privileges it needs to query GPU state. From there, any one of a NodePort service, a cloud load balancer rule, a permissive security group, or host networking puts port 9400 on a routable address. Nobody notices, because nobody owns the metrics agent. The ML platform team installs it to get dashboards. Security reviews the inference API and the training data pipeline. Monitoring agents are plumbing, and plumbing does not get threat-modeled.
If this sounds familiar, it should. We covered the same pattern, an AI infrastructure component bound to a socket with no auth because "it's just local tooling," in our audit and lockdown playbook for the NemoClaw Ollama flaw. Different project, identical failure mode.
CVE-2026-47483 in plain terms
Go binaries commonly register net/http/pprof, which mounts profiling handlers under /debug/pprof. In affected DCGM Exporter builds, those handlers are reachable without authentication and without any concurrency limits.
The abuse is simple. A request to /debug/pprof/profile?seconds=60 makes the process run a CPU profile for the full duration. The heap, goroutine, and allocation handlers walk runtime structures and allocate buffers proportional to process state. Fire off a few dozen of those in parallel with a long seconds value and the costs multiply until the exporter chokes. That is textbook CWE-770, allocation of resources without limits or throttling, and it carries a CVSS 3.1 score of 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H). Network-reachable, no privileges, no user interaction.
Killing a metrics daemon sounds minor until you remember the exporter runs with elevated privileges precisely so the rest of your stack can see GPU health. Take it down and your monitoring pipelines and orchestrators go blind to utilization, memory, and error events, right when an attacker wants you blind. The profiling responses also leak function names, call stacks, and allocation patterns, which is free reconnaissance for a follow-on attack.
NVIDIA fixed it in DCGM Exporter 4.8.2. The NVIDIA product security advisory and the NVD entry are the primary sources. One practical note: NVIDIA's own bulletin page for this issue currently returns a 401 to anonymous readers, so the GitHub advisory is the one you can actually read. OpenCVE's enrichment lists DCGM Exporter 0.0 through 4.8.2 and DCGM itself 0.0 through 4.5.2 as affected, so check both components, not just the exporter container.
"EPSS is under 1%, so why care"
Here is the pushback I would give, so let me answer it. EPSS for this CVE sits at 0.00551. It is not in CISA's KEV catalog, and CISA's SSVC enrichment notes no known exploitation. A triage process driven purely by those numbers will deprioritize it, and I understand why.
Three problems with that call. First, the same SSVC record marks the vulnerability automatable. There is no exploit to develop; it is a loop around curl against a debug endpoint. When the "exploit" is a shell one-liner, the window between public disclosure and mass scanning is measured in hours, and AI-assisted exploit generation keeps compressing it further, as we saw when an AI built a working Avada exploit in two hours.
Second, EPSS scores the probability of CVE exploitation. It says nothing about the value of the exposed surface itself. Third, and this is the part the CVE-database coverage misses entirely, even a fully patched exporter on the open internet still hands out your GPU inventory and workload rhythm to anyone who scrapes it. Patching fixes the crash. It does nothing about the leak.
If the public coverage of this story has felt thin, that is because most of it is advisory regurgitation. The most detailed technical writeup circulating carries a disclaimer that its content was AI-generated. The exposure data, the part that matters for defenders, barely made it out of the original research.
The metrics alone are worth stealing
Strip the CVE away and look at what an open 9400 gives a stranger. GPU model and count via UUIDs: instant cluster sizing. Utilization, memory, and power over time: when training runs start and finish, which nodes are hot, what inference traffic looks like across the day. Error events: which cards are flaky.
Twelve thousand GPU UUIDs is an inventory. A competitor gets capacity intelligence. An attacker gets a targeting list and a schedule. And on the quarter of hosts also exposing pprof, they get runtime internals on top. None of this requires a single packet beyond an HTTP request, and none of it is fixed by 4.8.2.
Recon to denial of service: the full path
Put it together and the play looks like this:
- Discover. Search Shodan or Censys for port 9400 and the DCGM metrics fingerprint. Filter by target ASN or org. This is commodity internet-scan data, not bespoke recon.
- Map. Scrape
/metricson a schedule. Build the GPU inventory, learn the workload rhythm, pick a window that hurts, mid-checkpoint on a long training run or an inference traffic peak. - Profile. Probe
/debug/pprof/heapand/debug/pprof/goroutineon the roughly one in four hosts that answer. Harvest call stacks and allocation patterns for targeting. - Exhaust. Loop parallel requests to
/debug/pprof/profilewith a highsecondsvalue. Exporter CPU and RSS climb until Prometheus scrapes start failing and the cluster's GPU visibility drops out from under its operators.
No step here requires authentication, and the only step that touches the CVE is the last one.
What to do this week
Find your own endpoints before someone else does
Query Shodan and Censys against your own ASNs, domains, and cloud ranges for port 9400. Broaden it: Lava's recommendation covers any DCGM Exporter, Prometheus Node Exporter, or Go /debug/pprof endpoint exposed to the public internet. If you do not have an external view of your own footprint, that is the real gap, and forgotten internet-facing assets have a way of becoming someone else's finding, as the forgotten DNS record that leaked military base call logs made painfully clear.
Patch, and check the chart pins
Upgrade to DCGM Exporter 4.8.2 or later. Do not assume your Helm chart or DaemonSet manifest pulls latest; charts pin image tags, and pinned tags are how clusters run year-old exporters without anyone deciding to. Verify the running image, not the chart version.
Cut network reachability
The durable fix is making 9400 unreachable from anything except your scrapers. In Kubernetes, a NetworkPolicy does it:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: dcgm-exporter-scrape-only
namespace: gpu-monitoring
spec:
podSelector:
matchLabels:
app: dcgm-exporter
policyTypes: [Ingress]
ingress:
- from:
- podSelector:
matchLabels:
app: prometheus
ports:
- protocol: TCP
port: 9400If you front the exporter with a proxy or ingress, deny the debug paths outright and rate-limit the metrics route:
location /debug/ {
return 404;
}
location = /metrics {
limit_req zone=dcgm_metrics burst=10 nodelay;
proxy_pass http://dcgm-exporter:9400;
}Then audit the cloud security groups on any GPU node. If 9400 is open to 0.0.0.0/0, so is everything above.
Add detection around pprof and scrape failures
Three signals worth wiring up. First, HTTP access logs for /debug/pprof requests from non-loopback sources:
grep '/debug/pprof' /var/log/nginx/access.log | grep -vE '^(127\.|::1)'Second, correlate exporter CPU and RSS against concurrent inbound connections; a profiling flood has a distinctive shape. Third, alert when Prometheus scrape failures coincide with elevated host load, because that combination is the DoS landing, not a flake.
Monitoring endpoints leaking to the public internet is the same class of problem as leaked keys and forgotten cloud assets: an attack-surface problem. Axeploit is the scanner we use for that class of finding, and it will tell you what your GPU nodes are broadcasting before someone else's scan does.
If you want this checked automatically
If you want the auth and object-level checks in this article run against a live app, start with Axeploit's API security checker.
Key takeaways
- Roughly 2,100 GPU servers, about 12,000 GPU UUIDs across 300 organizations, were found exposing DCGM Exporter metrics to the internet, including hardware at Nebius, Voltage Park, Lambda, Northern Data, and DigitalOcean.
- DCGM Exporter ships with no authentication and serves plaintext HTTP on port 9400; default DaemonSet deployments plus one permissive firewall rule put it on the open internet.
- CVE-2026-47483 (CVSS 8.2) lets anyone crash the exporter through unauthenticated
/debug/pprofprofiling requests. Upgrade to 4.8.2 or later, but treat that as step one. - The exposure itself is the bigger finding: the telemetry hands out GPU inventory and workload timing, and patching does not close it. Network reachability does.
- Scan your own ranges for 9400 and pprof today, then enforce NetworkPolicies, block
/debug/at the proxy, and alert on scrape failures paired with elevated host load.
