Nvidia DCGM Exporter: unauthenticated DoS (CVE-2026-47483)

A high-severity vulnerability in Nvidia DCGM Exporter, the service that publishes GPU metrics for monitoring systems such as Prometheus, lets anyone who can reach the service, without authentication, exhaust its memory and crash it. The flaw is tracked as CVE-2026-47483, scored CVSS 8.2, and fixed in version 4.8.2. It was discovered and reported to Nvidia by researchers at Lava, a data center security startup; The Register (8 October 2026), Help Net Security and CSO Online (9 October 2026) covered it.

Beyond the flaw itself, Lava’s research shows how exposed the monitoring services of AI infrastructure are on the internet.

What happened

According to Lava researcher Michael Katchinskiy, quoted by all three outlets, four internet scans run between March and May 2026 found about 2,100 GPU servers exposing DCGM Exporter metrics, covering more than 12,000 unique GPUs and an estimated $100 million in hardware. None required authentication and all answered over plaintext HTTP. The exposed cards included Blackwell Ultra B300, H200 and H100 GPUs, used for large AI workloads, as well as consumer RTX 5090 and 4090 cards.

The hosts belonged to about 300 organisations. The US hosted 5,274 of the exposed GPUs (44%); according to Help Net Security, it was followed by Romania with 2,054 and China with 1,967. Some exposed services ran on customer infrastructure at GPU cloud providers: the outlets name Voltage Park, Lambda, Northern Data and DigitalOcean, and The Register also mentions Nebius. According to Help Net Security, Voltage Park confirmed that all the exposed DCGM Exporter instances had been deployed by customers and contacted the customers involved.

The sources disagree on when the fix was released: The Register says Nvidia shipped it in September, Help Net Security points to an Nvidia security bulletin dated 28 July 2026, and CSO Online says May. None of the three reports active exploitation.

Technical details

DCGM Exporter reads temperature, utilisation, memory, power and errors from the host’s GPUs and publishes them over HTTP, typically on port 9400 (according to Help Net Security), at /metrics. The metrics include the exact model and the UUID of each GPU.

The problem lies in Go’s profiling endpoints /debug/pprof/, exposed alongside /metrics by about a quarter of the hosts found. Some of these endpoints keep a request open for a duration chosen by the caller: with many concurrent unauthenticated requests, memory consumption grows until the exporter crashes. According to CSO Online, Nvidia’s bulletin classifies the flaw as uncontrolled resource consumption (CWE-400).

According to Help Net Security, Lava first assumed operator misconfiguration, but then reproduced the behaviour with the official DCGM Exporter container, unmodified: a deployment that exposes the exporter on a routable interface may therefore expose /debug/pprof/ as well.

The consequences described:

• loss of visibility into GPU health and activity, because monitoring stops;
• CPU and RAM pressure on the host, which can slow down training or inference processes on the same machine, especially without strict resource limits;
• reconnaissance: even without the flaw, the metrics reveal what hardware an organisation runs, how heavily it uses it and whether it has errors.

Lava also examined Prometheus Node Exporter: 12,096 public hosts exposed data on Nvidia/Mellanox InfiniBand and RoCE adapters (models, firmware, link state) and in some cases hostnames, operating system and kernel versions, and BIOS details. Where the two exporters overlapped, Katchinskiy says GPU activity could be tied to the server, its software and the surrounding network.

In MITRE ATT&CK terms, exhausting the exporter’s memory maps to T1499 (Endpoint Denial of Service), while collecting the exposed metrics falls under T1592 (Gather Victim Host Information). The sources report no indicators of compromise.

Impact for European and Italian organisations

Romania being second for exposed GPUs shows that the problem is not limited to the US. Anyone running GPUs on premises or in the cloud for AI, scientific computing or image processing, including universities, research centres and healthcare organisations, should check what their monitoring stack exposes. For NIS2 entities, vulnerability management and the protection of monitoring systems are part of the required security measures. As Katchinskiy points out, in the cloud it also matters to know what the provider is responsible for and what the customer is: in the cases cited, the exporters had been deployed by customers.

What to do now

1. Upgrade DCGM Exporter to version 4.8.2 or later, as stated in Nvidia’s bulletin.
2. Make sure the --enable-pprof option is off unless you need profiling. According to Help Net Security it is opt-in in current versions; according to CSO Online it may be enabled by default in unpatched versions.
3. Take DCGM Exporter, Node Exporter and Prometheus off the public internet: bind exporters to the loopback interface or a private network and restrict access to your monitoring systems with firewall rules or security groups. Protect Prometheus query APIs and target pages in the same way.
4. Check from the outside whether port 9400 and the /metrics and /debug/pprof/ paths of your hosts answer from the internet.
5. Set CPU and memory limits on the exporter container, so that a malfunction cannot take resources away from workloads.
6. Monitor the monitoring: an exporter that stops responding should be treated as an event to investigate, not just a fault.

How ARXDOME helps

ARX Expose shows what an attacker sees from the outside: open ports, recognised products and known vulnerabilities on public services, which helps find exporters exposed by mistake. ARX Shield shows open vulnerabilities by machine and by package, and ARX Sentry collects logs and the inventory of software, processes and ports from servers, so you know where DCGM Exporter runs and in which version.

Last updated: 9 October 2026