Lava ontdekt duizenden blootgestelde GPU-servers en een hoog‑ernstig NVIDIA-monitoringslek

De infrastructuur achter een AI‑model kan een verrassende hoeveelheid onthullen voordat iemand er inbreekt. Een openbaar monitoring‑endpoint kan de GPU’s in een server, hun benutting en de software eromheen onthullen. Een fout in diezelfde monitoringservice kan zichtbaarheid omzetten in een beschikbaarheidsrisico.

Nieuw onderzoek van Lava, uitgebracht op 8 oktober, beschrijft beide problemen. Het beveiligingsbedrijf identificeerde ongeveer 2.100 publiek toegankelijke NVIDIA DCGM Exporter‑hosts die meer dan 12.000 unieke GPU’s rapporteerden zonder authenticatie. Tijdens haar onderzoek ontdekte Lava ook een hoog‑ernstige kwetsbaarheid die een niet‑geauthenticeerde aanvaller in staat kan stellen om bronnen uit te putten en GPU‑monitoring te laten crashen.

NVIDIA heeft het probleem toegewezen aan CVE-2026-47483, beoordeelt het als 8.2, Hoog en heeft een update uitgebracht. De bevindingen zetten een minder glamoureus onderdeel van AI‑infrastructuur in de schijnwerpers: de services die worden gebruikt om dure rekencapaciteit te observeren, hebben zelf bescherming nodig.

Wat de onderzoekers vonden — en wat de cijfers betekenen

Lava’s origineel onderzoek door Michael Katchinskiy beschrijft vier scans uitgevoerd tussen maart en mei 2026. De totalen vertegenwoordigen daarom observaties gedurende die onderzoeksperiode, in plaats van een actuele telling van systemen die vandaag nog blootgesteld zijn.

De hosts leverden GPU‑telemetrie terug zonder authenticatie. Lava observeerde datacenterversnellers, waaronder H100‑s, H200‑s en Blackwell Ultra B300‑s, evenals RTX‑4090‑ en 5090‑systemen. Het bedrijf schatte dat de geobserveerde GPU’s meer dan $100 miljoen aan hardware vertegenwoordigen, gebaseerd op geschatte marktwaarden. Dat cijfer beschrijft de hardwarewaarde, niet de verliezen door een aanval.

Ongeveer een kwart van de blootgestelde DCGM‑hosts maakte ook interne Go‑profilering‑endpoints toegankelijk. Deze subset is belangrijk: een blootgesteld metrics‑endpoint en een bereikbare kwetsbare profilering‑interface zijn gerelateerde maar afzonderlijke bevindingen. Het zou misleidend zijn om alle 12.000‑plus GPU’s te beschrijven als bevestigde slachtoffers van deze kwetsbaarheid.

Lava zegt dat het uitputting van bronnen heeft gereproduceerd in een gecontroleerde omgeving, in plaats van de openbare implementaties aan te vallen. Het onderzoek toont een potentieel aanvalspad aan; het bewijst niet dat de geobserveerde organisaties zijn geëxploiteerd of dat hun modelgegevens zijn gestolen.

Waarom GPU‑monitoring meer onthult dan een statuslampje

DCGM staat voor Data Center GPU Manager. NVIDIA’s DCGM Exporter-documentatie legt uit dat de exporter geselecteerde GPU‑telemetrie‑velden verzamelt en ze aanbiedt in een formaat dat Prometheus kan verwerken. Het metrics‑endpoint wordt doorgaans gebruikt door monitoringsystemen om de toestand en activiteit van GPU‑knooppunten bij te houden.

Temperatuur, benutting, geheugengebruik, stroomverbruik en foutgebeurtenissen zijn nuttig voor operators omdat ze beschrijven hoe de rekencapaciteit zich gedraagt. Wanneer dezelfde informatie toegankelijk is voor vreemdelingen, wordt het een inventaris‑ en verkenningsbron.

De blootgestelde antwoorden kunnen hardware‑modellen en operationele details onthullen. Herhaalde metingen kunnen aanwijzingen geven over drukke periodes en terugkerende activiteit. Die aanwijzingen bewijzen niet dat een specifiek model wordt getraind of bediend, maar ze kunnen een buitenstaander helpen om te bepalen wat een omgeving bevat en wanneer deze actief is.

Die onderscheiding is het waard om te behouden. Het lezen van GPU‑telemetrie is niet hetzelfde als het lezen van de gewichten, trainingsdata of prompts van een model. Toch kan infrastructuurinformatie waardevol zijn: een aanvaller die leert welke componenten en versies aanwezig zijn, heeft een specifieker startpunt dan iemand die met een ondoorzichtige server te maken heeft.

De kwetsbaarheid richt zich op de monitoringservice

NVIDIA’s beveiligingsbulletin lokaliseert de fout in DCGM Exporter’s /debug/pprof endpoints. Gelijktijdige niet‑geauthenticeerde profilering‑verzoeken kunnen ongereguleerde resource‑consumptie veroorzaken, met potentieel denial‑of‑service en informatie‑onthulling. Het advies erkent Lava’s Michael Katchinskiy voor het melden ervan.

Profilering is een legitieme diagnostische mogelijkheid. Het helpt ontwikkelaars om CPU‑ en geheugen­gedrag binnen een applicatie te onderzoeken. Het beveiligingsprobleem ontstaat wanneer een potentieel dure interne functie bereikbaar wordt voor een niet‑vertrouwde aanroeper zonder passende controles.

Volgens Lava vermoetten onderzoekers aanvankelijk een configuratiefout van de operator, en reproduceerden vervolgens het gedrag met NVIDIA’s officiële container. Ze toonden aan dat uitputting van bronnen de exporter kan laten crashen, waardoor de zichtbaarheid in GPU‑gezondheid verdwijnt. CPU‑ en geheugen‑druk kan ook de trainings‑ of inferentietaken die de server delen beïnvloeden.

Het laten crashen van een exporter stopt niet per se de GPU‑werkbelasting zelf. Het directe effect is verlies van monitoring; interferentie met naburige workloads hangt af van resource‑isolatie en de implementatie. Dit is een software‑service‑kwetsbaarheid rond GPU‑infrastructuur, en geen bewijs van een fout in de GPU‑silicon.

Het onderscheid is operationeel van belang. Als monitoring verdwijnt tijdens een vertraging van de werklast, moeten de responders onderzoeken of het observatiesysteem zelf faalt. Het behandelen van elke ontbrekende metriek als een instrumentatie‑inconvenient kan de herkenning van een incident met resource‑consumptie vertragen.

De blootstelling reikt verder dan de GPU‑laag

De aankondiging van Lava beschrijft ook 12.096 publiekelijk toegankelijke Node Exporter‑hosts. Node Exporter rapporteert server‑ en besturingssysteem‑informatie in plaats van dezelfde rol te vervullen als DCGM Exporter. De blootgestelde gegevens bevatten hardware‑ en software‑details die buitenstaanders kunnen helpen de systemen rondom GPU‑werklasten te begrijpen.

Die aantallen moeten gescheiden blijven. De Node Exporter‑observaties vormen een bredere infrastructuur‑blootstellingsbevinding, niet een extra telling van hosts die bevestigd kwetsbaar zijn voor CVE‑2026‑47483. Het combineren van de cijfers zou verduisteren welke service en welk risico elk getal vertegenwoordigt.

De bredere implicatie is dat AI‑beveiliging de monitoring‑ en beheerslaag moet omvatten. Toegangscontroles voor modellen beschermen niet automatisch een metriekservice die naast het model wordt ingezet. Een organisatie kan haar inference‑API beveiligen terwijl een andere service op dezelfde infrastructuur open blijft staan voor het internet.

Patchen en toegang beperken pakken verschillende problemen aan

De beveiligingsupdate is al beschikbaar. De bulletin van NVIDIA identificeert DCGM Exporter 4.8.2 als een bijgewerkte versie en vermeldt ook DCGM 4.5.3. Operators dienen het actuele advies en de ondersteunde release‑koppeling voor hun implementatie te raadplegen in plaats van die twee component‑versienummers als uitwisselbaar te beschouwen.

Upgraden verhelpt de gemelde kwetsbaarheid. Het zorgt echter niet op zichzelf voor een juiste beperking van het metriek‑endpoint. Een gepatchte exporter kan nog steeds telemetrie lekken als deze publiekelijk bereikbaar blijft zonder toegangscontroles.

Het Prometheus security model waarschuwt expliciet tegen het blootstellen van component‑HTTP‑endpoints aan openbare netwerken zonder passende maatregelen. De richtlijnen omvatten metrics, API’s en Go‑profilering‑interfaces, en erkennen de mogelijkheid dat deze services overbelast kunnen raken.

Voor teams die hun AI‑infrastructuur beoordelen, suggereert dat een praktische volgorde:

• Inventariseer geïmplementeerde monitoring‑services. Breng in kaart welke exporters, Prometheus‑servers en diagnostische interfaces draaien, wie ze bezit en hoe ze bereikbaar zijn.
• Pas de beveiligingsupdates van de leverancier toe. Controleer de daadwerkelijk geïmplementeerde software‑ of container‑versie, niet alleen een configuratie‑bestand dat nog niet is uitgerold.
• Beperk de toegang tot monitoring. Gebruik private netwerken en passende firewall‑, security‑group‑ en toegangscontroles zodat telemetrie alleen beschikbaar is voor de monitoring‑infrastructuur die het nodig heeft.
• Herzie profileringseisen. Lava raadt aan om --enable-pprof profiler uitgeschakeld te laten tenzij profilering expliciet nodig is; in de huidige versies is dit opt‑in.
• Verifieer zichtbaarheid na remediering. Bevestig dat geautoriseerde verzameling nog steeds werkt en dat onverwachte exporter‑fouten worden opgemerkt.

Deze stappen behandelen afzonderlijke vragen: of de software de kwetsbaarheid bevat, of een onbetrouwbare partij er toegang toe kan krijgen, en of een monitoring‑fout wordt gedetecteerd. Het oplossen van één aspect lost de andere niet op.

AI‑infrastructuur heeft een expliciete beveiligingseigenaar nodig

GPU‑capaciteit bestrijkt vaak zowel door de provider beheerde infrastructuur als door de klant uitgerolde services. Een nuttige beveiligingsreview identificeert wie elk component onderhoudt, wie de netwerkblootstelling beheert en wie reageert wanneer een openbaar eindpunt wordt gemeld. Zonder die toewijzingen kan een monitoring‑service tussen twee teams in zitten die elk van de ander verwachten dat die de service beveiligt.

De centrale les van Lava’s onderzoek is praktisch: het beschermen van AI‑computatie omvat het beschermen van de systemen die het meten en beheren. De nieuwe bevindingen documenteren een aanzienlijke historische blootstelling, terwijl NVIDIA’s advies een remediepad biedt voor de gemelde kwetsbaarheid. Voor operators is de prioriteit om hun huidige implementatie te verifiëren, de patch toe te passen en interne observatieservices binnen hun beoogde vertrouwensgrens te houden.