From the NVIDIA edition of October 8, 2026
LAVA: CVE-2026-47483 in NVIDIA DCGM Exporter (CVSS 8.2) plus >2,000 unauthenticated internet-exposed GPU servers (~12,000 GPUs, ~$100M hardware)
LAVA (Lava Security) · Independent security research · Global (U.S. plurality of exposed GPUs)
- Publisher
- LAVA research blog
- Original publication
- 2026-10-08
- Source retrieved
- 2026-10-09
- Event date
- 2026-10-08
What happened
LAVA's Oct 8, 2026 post describes discovering that NVIDIA DCGM Exporter's /debug/pprof endpoints allow unauthenticated concurrent profiling requests to exhaust resources, causing denial of service and information disclosure—assigned CVE-2026-47483 (CVSS 8.2 High) with an NVIDIA bulletin. Separately, four internet scans found more than 2,000 GPU servers exposing DCGM Exporter without authentication and more than 12,000 unique GPUs (~$100 million hardware estimate), including Blackwell Ultra B300, H200, H100 and consumer RTX 5090/4090 systems. Metrics reveal model names, utilization and infrastructure detail. LAVA says it reproduced pprof exposure on NVIDIA's official exporter container without modification, tested resource exhaustion in a controlled environment (not against public hosts), and recommends upgrading and keeping exporters off the public internet.
Why it matters
Primary research behind the same-day Register coverage; gives SLED operators the technical mechanism (pprof resource exhaustion) and exposure evidence to justify emergency hygiene on university and agency GPU clusters.
Evidence and measured results
Opened and read the full LAVA research article dated October 8, 2026. Researcher-reported vulnerability and scan findings; NVIDIA acknowledgement via CVE/bulletin is cited. Controlled lab exploitation only.
Limitations and uncertainty
Exposure scans are historical (article describes research period); $100M hardware figure is the researcher's estimate. Official affected/fixed versions should be taken from NVIDIA's bulletin when patching.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-09; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Security leaders need primary research, not only headlines, to authorize emergency hardening of GPU monitoring.
- Stakeholders
- CISO
- Detection engineering
- Research computing
- Cloud security
- Discovery questions
- Do we run the official DCGM Exporter image?
- Are any Services typed LoadBalancer/NodePort to the internet?
- Who owns Helm chart defaults?
- Value hypothesis
- Using primary research to drive a time-boxed hygiene sprint can cut both disclosure and DoS risk (interpretation).
- Potential engagement
- A research-informed hardening engagement with briefing slides drawn from this CVE and exposure evidence.
- Unsupported claims
- That LAVA attacked the public hosts
- Current exact global exposure tally
- That metrics exposure alone is harmless
Pre-sales engineering
Role takeaway
- Fit
- Directly applicable to Kubernetes/GPU clusters using NVIDIA's exporter image.
- Architecture and integration
- NetworkPolicy/allowlists for scrape; disable pprof by default; pin patched exporter; separate management plane from workload plane.
- Prerequisites
- Cluster inventory of exporter Deployments/DaemonSets
- Ingress/SecurityGroup review
- CI version gate
- Constraints
- Chart defaults may re-enable pprof
- Multi-tenant student clusters drift
- Cloud marketplace images may lag
- Security
- Treat unauthenticated pprof as Critical-path availability for monitoring even when CVSS is High not Critical.
- Proof of value
- Confirm pprof not externally reachable
- Pin and verify fixed image digest
- Alert on new public listeners
Delivery
Role takeaway
- Work
- Execute cluster-by-cluster exporter hardening and verify with external scans.
- Dependencies
- Helm/chart owners
- Firewall changes
- Security scan windows
- Ownership
- Platform engineering implements; security validates; research computing communicates downtime.
- Skills and adoption
- Teach on-call to recognize exporter version and pprof flags.
- Governance checkpoints
- Chart default change review
- Rollout completion
- External scan clean
- Acceptance criteria
- All clusters on fixed digests (proposed)
- No public pprof/metrics listeners (proposed)
- Risks
- Partial rollout
- Namespaces recreating public Services
- Ignoring neocloud customer attachments
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Default-container behavior that exposes pprof when the exporter is reachable means network placement and flags matter as much as version pins in Kubernetes/Helm charts.
Governance
Who approves, reviews and stays accountable for outcomes?
Public GPU UUID and utilization leakage should trigger asset-inventory and possibly disclosure processes for institutions that find their ranges exposed.
Security and privacy
What data, permissions and controls need testing?
Combines reconnaissance (metrics) with availability impact (crash monitoring / host pressure); both matter for shared research clusters.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Hardening may briefly disrupt researcher dashboards; communicate alternate internal scrape endpoints.
Procurement
What should contracts, pricing and exit terms secure?
Require GPU cloud providers to attest that DCGM/Node Exporters are not internet-public by default in tenant templates.
Operating model
Which teams own the service once it runs?
Establishes continuous exposure scanning of GPU monitoring as a standing control, not a one-off incident.
Publication history
- 2026-10-08NVIDIA · Issue 339 resources
Stable resource ID: lava-cve-2026-47483-dcgm-exporter-internet-exposure-research-20261008