2,100 AI Servers Are Leaking GPU Telemetry, and the CVE Is the Boring Part

Between March and May, researchers at datacenter security startup Lava scanned the public internet and found roughly 2,100 GPU servers answering unauthenticated HTTP requests on port 9400. About 12,000 GPU UUIDs across some 300 organizations, describing hardware model, utilization, memory pressure, power draw, and error counts to anyone who asked.

The vulnerability that came out of that research, CVE-2026-47483, is real. Patch it. But it is not the interesting part of the story.

How a monitoring agent ends up public

DCGM Exporter is a small Go daemon that serves NVIDIA GPU metrics in Prometheus format over plaintext HTTP. It ships with no authentication, which is normal for the Prometheus ecosystem: the endpoint is assumed to sit on a trusted network, with access control handled around it.

That assumption dies in deployment. The standard install is a Kubernetes DaemonSet from a Helm chart, running with elevated privileges so it can read GPU state. Then a NodePort service, a cloud load balancer rule, a permissive security group, or host networking puts 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 pipeline. Monitoring is plumbing, and plumbing does not get threat-modeled.

The exposed hardware ranged from Blackwell B300 and H200 nodes down to consumer RTX 4090 boxes, at infrastructure belonging to Nebius, Lambda, Voltage Park, DigitalOcean, and others. Some of that is tenant workloads on provider kit. That makes it worse: this is a common team-level habit, not one vendor's bad default.

The CVE, and why EPSS is scoring the wrong thing

Affected builds expose Go's /debug/pprof handlers with no auth and no concurrency limits. Fire a few dozen parallel requests at /debug/pprof/profile?seconds=60 and the exporter chokes. Textbook CWE-770, CVSS 8.2, network-reachable with no privileges. NVIDIA fixed it in DCGM Exporter 4.8.2.

Killing a metrics daemon sounds minor until you remember it runs privileged so the rest of your stack can see GPU health. Take it down and your monitoring and orchestrators go blind to utilization and error events right when an attacker wants you blind. Roughly 25 percent of the exposed hosts also served pprof data, which leaks call stacks and allocation patterns as free reconnaissance.

Here is my disagreement with how this got triaged. EPSS sits at 0.00551, it is not in CISA's KEV, no known exploitation. A numbers-driven process deprioritizes that, and I get it. But the SSVC record marks the bug automatable, because the exploit is a loop around curl. And EPSS scores the probability of CVE exploitation. It says nothing about the value of the exposed surface itself. A fully patched exporter on the open internet still hands out your GPU inventory and workload rhythm on a schedule. Twelve thousand UUIDs is a targeting list. Patching fixes the crash. It does nothing about the leak.

Lock it down this week

The durable fix is making 9400 unreachable from everything except your scrapers. In Kubernetes:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dcgm-exporter-scrape-only
spec:
  podSelector:
    matchLabels:
      app: dcgm-exporter
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: prometheus
      ports:
        - protocol: TCP
          port: 9400

If a proxy or ingress fronts the exporter, return 404 on /debug/ and rate-limit the /metrics route.

What you can do today:

• Query Shodan or Censys against your own ASNs, domains, and cloud ranges for port 9400. If you lack an external view of your footprint, that gap is the real finding.
• Upgrade to DCGM Exporter 4.8.2 and verify the running image tag, not the chart version. Pinned tags are how clusters run year-old exporters without anyone deciding to.
• Audit security groups on GPU nodes. If 9400 is open to 0.0.0.0/0, so is everything described above.
• Alert on /debug/pprof requests from non-loopback sources and on Prometheus scrape failures.

Who actually owns the metrics agent on your GPU clusters, platform or security? Based on 2,100 open endpoints, my guess is nobody.

Longer writeup with the full recon-to-DoS path and detection rules: https://axeploit.com/blog/the-cve-is-the-boring-part-2100-ai-servers-are-leaking-gpu-telemetry-to