Lava findet Tausende offengelegte GPU-Server und einen hochgradigen NVIDIA-Überwachungsfehler

Die Infrastruktur hinter einem KI‑Modell kann eine überraschend große Menge an Informationen preisgeben, bevor jemand in sie einbricht. Ein öffentliches Überwachungs‑Endpunkt kann die GPUs in einem Server, deren Auslastung und die umgebende Software offenlegen. Ein Fehler in diesem selben Überwachungsdienst kann die Sichtbarkeit in ein Verfügbarkeitsrisiko verwandeln.

Neue Forschung von Lava, veröffentlicht am 8. Oktober, beschreibt beide Probleme. Das Sicherheitsunternehmen identifizierte etwa 2.100 öffentlich zugängliche NVIDIA‑DCGM‑Exporter‑Hosts, die mehr als 12.000 eindeutige GPUs ohne Authentifizierung meldeten. Während seiner Untersuchung entdeckte Lava außerdem eine hochgradige Schwachstelle, die einem nicht authentifizierten Angreifer ermöglichen könnte, Ressourcen zu erschöpfen und die GPU‑Überwachung zum Absturz zu bringen.

NVIDIA hat das Problem CVE-2026-47483 zugewiesen, es mit 8,2, Hoch bewertet und ein Update veröffentlicht. Die Ergebnisse rücken einen weniger glamourösen Teil der KI‑Infrastruktur in den Fokus: Die Dienste, die zur Beobachtung teurer Rechenleistung verwendet werden, benötigen eigenen Schutz.

Was die Forschenden fanden – und was die Zahlen bedeuten

Lavas ursprüngliche Forschung von Michael Katchinskiy beschreibt vier Scans, die zwischen März und Mai 2026 durchgeführt wurden. Die Gesamtsummen stellen daher Beobachtungen aus diesem Forschungszeitraum dar und nicht eine aktuelle Zählung von Systemen, die heute noch offengelegt sind.

Die Hosts gaben GPU‑Telemetrie ohne Authentifizierung zurück. Lava beobachtete Rechenzentrums‑Beschleuniger, darunter H100‑, H200‑ und Blackwell‑Ultra‑B300‑Modelle sowie RTX‑4090‑ und 5090‑Systeme. Das Unternehmen schätzte, dass die beobachteten GPUs einen Hardwarewert von mehr als 100 Millionen US‑Dollar darstellen, basierend auf ungefähren Marktwerten. Diese Zahl beschreibt den Hardwarewert, nicht Verluste durch einen Angriff.

Etwa ein Viertel der offengelegten DCGM‑Hosts stellte zudem interne Go‑Profiling‑Endpunkte bereit. Diese Teilmenge ist wichtig: Ein offengelegter Metrik‑Endpunkt und ein erreichbares, verwundbares Profiling‑Interface sind verwandte, aber unterschiedliche Befunde. Es wäre irreführend, alle über 12.000 GPUs als bestätigte Opfer dieser Schwachstelle zu bezeichnen.

Lava gibt an, dass es die Ressourcenerschöpfung in einer kontrollierten Umgebung reproduziert hat, anstatt die öffentlichen Bereitstellungen anzugreifen. Die Forschung zeigt einen potenziellen Angriffsweg; sie beweist nicht, dass die beobachteten Organisationen ausgenutzt wurden oder dass deren Modelldaten gestohlen wurden.

Warum GPU‑Überwachung mehr offenbart als ein Statuslicht

DCGM steht für Data Center GPU Manager. NVIDIAs DCGM Exporter Dokumentation erklärt, dass der Exporter ausgewählte GPU‑Telemetrie‑Felder sammelt und sie in einem Format bereitstellt, das Prometheus verarbeiten kann. Sein Metrik‑Endpunkt wird typischerweise von Überwachungssystemen genutzt, um den Zustand und die Aktivität von GPU‑Knoten zu verfolgen.

Temperatur, Auslastung, Speichernutzung, Stromverbrauch und Fehlereignisse sind für Betreiber nützlich, weil sie das Verhalten der Rechenleistung beschreiben. Wenn dieselben Informationen Fremden zugänglich sind, werden sie zu einer Inventar‑ und Aufklärungsquelle.

Die offengelegten Antworten können Hardware‑Modelle und betriebliche Details offenbaren. Wiederholte Messungen können Hinweise auf Stoßzeiten und wiederkehrende Aktivitäten geben. Diese Hinweise beweisen nicht, dass ein bestimmtes Modell trainiert oder bereitgestellt wird, können jedoch einem Außenstehenden helfen, einzugrenzen, was eine Umgebung enthält und wann sie aktiv ist.

Diese Unterscheidung ist es wert, beibehalten zu werden. Das Auslesen von GPU‑Telemetrie ist nicht dasselbe wie das Auslesen von Modellgewichten, Trainingsdaten oder Eingabeaufforderungen. Dennoch kann Infrastrukturinformation wertvoll sein: Ein Angreifer, der erfährt, welche Komponenten und Versionen vorhanden sind, hat einen konkreteren Ausgangspunkt als jemand, der einem undurchsichtigen Server gegenübersteht.

Die Schwachstelle zielt auf den Überwachungsdienst ab

NVIDIA-Sicherheitsbulletin lokalisiert den Fehler im DCGM Exporter’s /debug/pprof Endpunkte. Gleichzeitige nicht authentifizierte Profiling‑Anfragen können unkontrollierten Ressourcenverbrauch verursachen, mit möglichem Denial‑of‑Service und Informationsfreigabe. Der Hinweis dankt Lava’s Michael Katchinskiy für die Meldung.

Profiling ist eine legitime Diagnosefunktion. Es hilft Entwicklern, das CPU‑ und Speicherverhalten innerhalb einer Anwendung zu untersuchen. Das Sicherheitsproblem entsteht, wenn eine potenziell ressourcenintensive interne Funktion für einen nicht vertrauenswürdigen Aufrufer ohne geeignete Kontrollen erreichbar wird.

Laut Lava vermuteten die Forschenden zunächst einen Konfigurationsfehler des Betreibers, reproduzierten dann das Verhalten mit NVIDIAs offiziellem Container. Sie zeigten, dass Ressourcenerschöpfung den Exporter zum Absturz bringen kann, wodurch die Sichtbarkeit des GPU‑Zustands verloren geht. CPU‑ und Speicherbelastung könnte zudem Trainings‑ oder Inferenz‑Workloads, die den Server teilen, beeinträchtigen.

Das Abstürzen eines Exporters stoppt nicht zwangsläufig die GPU‑Workload selbst. Die unmittelbare Auswirkung ist der Verlust der Überwachung; Störungen benachbarter Workloads hängen von der Ressourcenisolierung und der Bereitstellung ab. Dies ist eine Software‑Dienst‑Schwachstelle im Zusammenhang mit GPU‑Infrastruktur und kein Hinweis auf einen Fehler im GPU‑Silizium.

Der Unterschied ist betriebspraktisch von Bedeutung. Wenn die Überwachung während einer Verlangsamung der Arbeitslast verschwindet, müssen die Verantwortlichen untersuchen, ob das Beobachtungssystem selbst ausfällt. Jeden fehlenden Messwert als bloßes Instrumentierungsproblem zu behandeln, könnte die Erkennung eines Ressourcenverbrauchs‑Vorfalls verzögern.

Die Exposition reicht über die GPU‑Ebene hinaus

Lavas Ankündigung beschreibt außerdem 12.096 öffentlich zugängliche Node‑Exporter‑Hosts. Node Exporter meldet Server‑ und Betriebssysteminformationen, anstatt dieselbe Rolle wie DCGM Exporter zu übernehmen. Die offengelegten Daten enthielten Hardware‑ und Softwaredetails, die Außenstehenden helfen könnten, die Systeme rund um GPU‑Arbeitslasten zu verstehen.

Diese Zahlen sollten getrennt bleiben. Die Node‑Exporter‑Beobachtungen stellen ein breiteres Infrastruktur‑Expositions‑Problem dar und nicht eine weitere Zählung von Hosts, die für CVE‑2026‑47483 als verwundbar bestätigt wurden. Das Zusammenführen der Zahlen würde verschleiern, welcher Dienst und welches Risiko jede Zahl repräsentiert.

Die weiterreichende Implikation ist, dass die KI‑Sicherheit die Überwachungs‑ und Verwaltungsschicht einbeziehen muss. Zugriffs‑Kontrollen für Modelle schützen nicht automatisch einen Metrik‑Dienst, der neben dem Modell bereitgestellt wird. Eine Organisation kann ihre Inferenz‑API sichern, während ein anderer Dienst auf derselben Infrastruktur offen im Internet steht.

Patchen und Zugriffsbeschränkung lösen unterschiedliche Probleme

Das Sicherheitsupdate ist bereits verfügbar. NVIDIAs Bulletin identifiziert DCGM Exporter 4.8.2 als aktualisierte Version und listet außerdem DCGM 4.5.3 auf. Betreiber sollten die aktuelle Beratung und die unterstützte Release‑Kopplung für ihre Bereitstellung konsultieren, anstatt diese beiden Komponenten‑Versionsnummern als austauschbar zu betrachten.

Ein Upgrade behebt die veröffentlichte Schwachstelle. Es stellt jedoch nicht von selbst sicher, dass der Metrik‑Endpunkt angemessen beschränkt ist. Ein gepatchter Exporter kann weiterhin Telemetriedaten preisgeben, wenn er öffentlich erreichbar bleibt ohne Zugriffskontrollen.

Das Prometheus‑Sicherheitsmodell warnt ausdrücklich davor, Komponenten‑HTTP‑Endpunkte ohne geeignete Maßnahmen in öffentlichen Netzen zu exponieren. Seine Richtlinien decken Metriken, APIs und Go‑Profiling‑Schnittstellen ab und erkennen die Möglichkeit einer Überlastung dieser Dienste.

Für Teams, die ihre KI‑Infrastruktur überprüfen, deutet das auf eine praktische Reihenfolge hin:

• Inventarisieren Sie bereitgestellte Überwachungsdienste. Ermitteln Sie, welche Exporter, Prometheus‑Server und Diagnose‑Schnittstellen laufen, wer sie besitzt und wie sie erreichbar sind.
• Wenden Sie die Sicherheitsupdates des Anbieters an. Prüfen Sie die tatsächlich bereitgestellte Software‑ oder Container‑Version, nicht nur eine Konfigurationsdatei, die noch nicht ausgerollt wurde.
• Begrenzen Sie den Überwachungszugriff. Nutzen Sie private Netzwerke sowie geeignete Firewall‑, Sicherheitsgruppen‑ und Zugriffskontrollen, sodass Telemetrie nur der Überwachungsinfrastruktur zur Verfügung steht, die sie benötigt.
• Überprüfen Sie die Profilierungsanforderungen. Lava empfiehlt, --enable-pprof deaktiviert zu lassen, sofern Profilierung nicht ausdrücklich benötigt wird; in aktuellen Versionen ist sie optional.
• Verifizieren Sie die Sichtbarkeit nach der Behebung. Bestätigen Sie, dass autorisierte Erfassung weiterhin funktioniert und dass unerwartete Exporter‑Fehler bemerkt werden.

Diese Schritte adressieren separate Fragen: ob die Software die Schwachstelle enthält, ob ein unzuverlässiger Dritter darauf zugreifen kann und ob ein Überwachungsfehler erkannt wird. Das Lösen einer Frage klärt die anderen nicht.

KI‑Infrastruktur benötigt einen expliziten Sicherheitsverantwortlichen

Die GPU‑Kapazität erstreckt sich häufig über provider‑betriebene Infrastruktur und kundenseitig bereitgestellte Dienste. Eine sinnvolle Sicherheitsüberprüfung identifiziert, wer jede Komponente wartet, wer die Netzwerkaussetzung kontrolliert und wer reagiert, wenn ein öffentlicher Endpunkt gemeldet wird. Ohne diese Zuordnungen kann ein Überwachungsdienst zwischen zwei Teams sitzen, die jeweils erwarten, dass das andere ihn sichert.

Die zentrale Lehre aus Lavas Forschung ist praktisch: Der Schutz von KI‑Rechenleistung beinhaltet den Schutz der Systeme, die sie messen und verwalten. Die neuen Erkenntnisse dokumentieren eine signifikante historische Exposition, während NVIDIAs Hinweis einen Remediations‑Pfad für die veröffentlichte Schwachstelle bietet. Für Betreiber besteht die Priorität darin, ihre aktuelle Bereitstellung zu überprüfen, den Fix anzuwenden und interne Beobachtungsdienste innerhalb ihrer vorgesehenen Vertrauensgrenze zu halten.