Einen GPU-Server absichern: BMC, Firmware, NVIDIA-Treiber, Container Toolkit, Inferenz-APIs, Modelldateien und gemeinsam genutzte GPUs

Die Angriffsfläche, Ebene für Ebene

Ein GPU-Server fügt der üblichen Checkliste Ebenen hinzu, und zwei davon liegen unterhalb des Betriebssystems: Die CISA beschreibt Baseboard Management Controller als Komponenten, die „getrennt vom Betriebssystem (OS) und von der Firmware arbeiten, um Fernverwaltung und Fernsteuerung zu ermöglichen, selbst wenn das System heruntergefahren ist“. Versionen und Daten: Stand Oktober 2026.

Unsere Zusammenfassung der folgenden Abschnitte; Quellen: Dokumentation und CVE-Einträge von CISA, AMI, NVIDIA, vLLM, Ollama, PyTorch und Hugging Face, abgerufen im September und Oktober 2026.

BMC und Firmware

In einem technischen Blogbeitrag vom Juni 2025 warnt NVIDIA, dass kompromittierte BMCs „zu einer Plattform für Persistenz über alle Systeme hinweg werden, die sie kontrollieren“. Seine ersten Empfehlungen lauten: „Platzieren Sie BMC-Schnittstellen in isolierten Managementnetzen und machen Sie sie niemals aus dem Internet erreichbar“ und „Arbeiten Sie mit Ihren Herstellern zusammen, um sicherzustellen, dass die BMC-Firmware aktualisiert wird und CVEs verfolgt werden“. Außerdem rät NVIDIA, BMC-Ereignisse als Teil von Protokollierung und Erkennung zu behandeln.

Isolation ersetzt das Patchen nicht. CVE-2024-54085 in der BMC-Firmware MegaRAC SPx von AMI erlaubt es einem Angreifer, in den Worten des CVE-Eintrags, „die Authentifizierung aus der Ferne über das Redfish Host Interface zu umgehen“. AMI bewertet die Lücke nach CVSS-Version 4.0 mit 10,0, und AMIs Sicherheitshinweis vom 11. März 2025 nennt die SPx-Versionen, in denen sie behoben ist; die CISA hat sie am 25. Juni 2025 „auf Grundlage von Belegen für eine aktive Ausnutzung“ in ihren „Known Exploited Vulnerabilities Catalog“ aufgenommen. Fragen Sie Ihren Serverhersteller, welches BMC-Release die Korrektur enthält. IPMI bringt ein älteres Risiko mit: Die IPMI-Spezifikation in Version 2.0 selbst erlaubt es einem Angreifer aus der Ferne, vom BMC einen Passwort-Hash zu beschaffen, um das Passwort offline zu erraten (CVE-2013-4786). Wo Redfish, das über HTTPS läuft, Ihren Bedarf abdeckt, würden wir IPMI over LAN abschalten; jeder BMC braucht ein langes, individuelles Passwort.

Derselbe Sicherheitshinweis von AMI führt außerdem CVE-2024-54084 auf, eine BIOS-Lücke in AMIs Firmware Aptio V. AMIs Sicherheitshinweise vom 8. September und 13. Oktober 2026 nennen weitere Lücken in Aptio V, darunter CVE-2026-33197, von AMI mit 8,7 bewertet; fragen Sie den Serverhersteller also neben dem BMC-Release auch nach BIOS-Updates. Auch GPUs haben Firmware: Im Product Brief zur H200 NVL beschreibt NVIDIA, dass der CEC-Baustein der Karte „den Inhalt des GPU-Firmware-ROMs authentifiziert, bevor er der GPU erlaubt, von ihrem ROM zu booten“, mit Schutz vor Rollbacks und Widerruf von Schlüsseln, und die Produktseite der L40S sowie das Datenblatt der RTX PRO 6000 Server Edition führen Secure Boot auf. Notieren Sie für jede Karte den Eintrag VBIOS Version, den nvidia-smi -q ausgibt, und beziehen Sie GPU-Firmware nur vom Serverhersteller oder von NVIDIA.

Sicherheitsupdates für NVIDIA-Treiber je Zweig

NVIDIA veröffentlicht seine Sicherheitsbulletins in seinem Repository product-security auf GitHub, als Markdown, als maschinenlesbares CSAF und als CVE-Einträge: Laut dem Repository wird NVIDIA PSIRT ab dem 1. Oktober 2026 „Sicherheitsbulletins nur noch auf GitHub in den Formaten Markdown, CSAF und CVE veröffentlichen“. Abonnieren Sie das Repository, um über neue oder überarbeitete Bulletins benachrichtigt zu werden, und die E-Mail-Benachrichtigungen auf NVIDIAs Seite „Product Security“.

NVIDIAs Lebenszyklustabelle sieht für einen Production Branch „vierteljährliche (oder bedarfsweise) Bugfix- und Sicherheits-Releases für 1 Jahr“ vor und für einen Long Term Support Branch dasselbe für 3 Jahre. Ein Beispiel ist CVE-2026-47489 aus NVIDIAs Sicherheitsbulletin vom 30. September 2026. Diese Lücke in der Kernel-Modus-Schicht des Display-Treibers für Linux, von NVIDIA mit 7,8 bewertet, ist in 595.91.07 auf R595 und 580.178.04 auf R580 behoben, auf dem New Feature Branch R615 in 615.71.09; für R535, einen Zweig, dessen Supportende NVIDIAs Tabelle mit Juni 2026 angibt, nennt der CVE-Eintrag keinen Treiber. Die neueren Releases vom 19. bis 22. Oktober 2026, 615.71.10, 580.196.07 und 595.112.07, nennen in ihren Release Notes keine CVE. Ein Server erhält das Sicherheits-Release seines eigenen unterstützten Zweigs; unser Treiberleitfaden zeigt, wie man einen Zweig pinnt. Der CVE-Eintrag nennt außerdem vGPU-Gasttreiber und den vGPU Manager bis vGPU 20.1 und vGPU 19.5, also brauchen sowohl der vGPU Manager auf dem Host als auch der Treiber in jedem Gast das korrigierte Release, vGPU 20.2 oder 19.6. Der Angriffsvektor ist lokal, und nach unserer Lesart kann das auch Code in einem Container einschließen, dem eine GPU zugewiesen ist, denn GPU-Container nutzen den Treiber des Hosts. Wir bauen KI-Server auf Bestellung und installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime; schreiben Sie uns, welchen Treiberzweig Sie festschreiben wollen, und unser Team hilft Ihnen weiter.

Das Container Toolkit und der GPU Operator

Das NVIDIA Container Toolkit läuft auf dem Host und richtet jeden GPU-Container beim Start ein; unter Kubernetes stellt der GPU Operator es standardmäßig bereit. Fünf Lücken, zwei davon von NVIDIA mit 9,0 bewertet, zeigen, warum es auf seine Version ankommt.

Von NVIDIA veröffentlichte CVE-Einträge (cve.org und NVD), NVIDIAs GitHub-Advisory zu CVE-2024-0132 sowie die Release Notes von Container Toolkit 1.20.1 und GPU Operator 26.7.2, gelesen am 23. Oktober 2026; die Release Notes des Toolkits zu 1.19 und 1.20 nennen keine CVE. 1.17.8 ist das erste Toolkit-Release außerhalb des Versionsbereichs, den die Einträge als betroffen führen, und GPU Operator 25.3.1 liefert es mit; die Release Notes des Operators nennen CVE-2025-23266 und CVE-2025-23267 erstmals in 25.3.2. CVE-2026-24260 wurde am 1. Juli 2026 veröffentlicht; Toolkit 1.19.1 und GPU Operator 26.3.2, der es mitliefert, sind die ersten Releases außerhalb des betroffenen Bereichs, und keine der beiden Release Notes nennt die CVE.

CDI (das Container Device Interface) schützte vor CVE-2024-0132 und CVE-2025-23359, nicht aber vor den Lücken in den Hooks, und drei der fünf Beschreibungen nennen ein präpariertes Image als Angriffsweg. Beziehen Sie Images nur aus einer Registry, die Sie kontrollieren, pinnen Sie sie per Digest und beschränken Sie, wer GPU-Container starten darf; unter Kubernetes ist das jeder, der Pods auf GPU-Nodes anlegen darf. Das README des Device-Plugins, das die NVIDIA-Runtime als Standard-Runtime des Nodes voraussetzt, warnt, dass ein Pod, der keine GPU anfordert, „alle GPUs der Maschine“ bekommt; prüfen Sie also auch diese Voreinstellung. Seit v25.10.0 bindet der Operator GPUs standardmäßig über CDI ein und macht die Runtime-Klasse nvidia nicht mehr zum Standard-Handler, und die Releases seiner Version 26.7 enthalten Toolkit 1.20. Ein Upgrade über OLM (Operator Lifecycle Manager) unter OpenShift lässt cdi.enabled unverändert, und laut NVIDIAs Release Notes müssen GPU-Management-Container, die GPUs über NVIDIA_VISIBLE_DEVICES statt über das Device-Plugin erhalten, runtimeClassName: nvidia setzen; lassen Sie diese Klasse nur für vertrauenswürdige Pods zu.

Inferenz-APIs und Notebooks

vLLM lauscht auf allen Schnittstellen, sofern --host nicht gesetzt ist, und sein --api-key schützt nur Pfade unter /v1, /v2, /inference und /cohere. Seine Sicherheitsseite, gelesen am 23. Oktober 2026, führt die Routen auf, die der Schlüssel nicht abdeckt: Inferenz-Routen wie /invocations, /pooling, /classify, /score und /rerank sowie Steuer-Routen wie /pause, /resume und /update_weights, die „das Modellverhalten ändern können“. Die Seite rät, sich nicht allein auf den Schlüssel zu verlassen. Die Antwort der Dokumentation ist ein Reverse Proxy, der per Allowlist „nur die Endpunkte, die Sie Endnutzern zugänglich machen wollen“, freigibt, und eine Firewall, die nur den API-Port durchlässt; die Ports für torch.distributed und die Übertragung des KV-Caches sind vertrauenswürdigen Hosts vorbehalten, und der Verkehr zwischen Knoten ist „standardmäßig unsicher“. Setzen Sie VLLM_SERVER_DEV_MODE=1 niemals im Produktivbetrieb: Es fügt /collective_rpc hinzu, das die Dokumentation „extrem gefährlich“ nennt.

Ollama „bindet standardmäßig an 127.0.0.1, Port 11434“, sodass nur lokale Prozesse es erreichen, und OLLAMA_HOST ändert das. Sein offizielles Container-Image setzt jedoch OLLAMA_HOST=0.0.0.0:11434, und Docker gibt einen Port, der wie in Ollamas Docker-Anleitung als -p 11434:11434 angegeben ist, standardmäßig auf allen Adressen des Hosts frei. Seine lokale API „erfordert keine Authentifizierung“, ein solcher Container antwortet also jedem, der den Port erreichen kann. Dasselbe gilt für einen Server, der mit dieser Einstellung geöffnet wurde, wie es eines von NVIDIAs DGX-Spark-Playbooks für den Fernzugriff tut. Über die Lücke CVE-2026-103663, veröffentlicht am 8. Oktober 2026, konnte eine nicht authentifizierte Anfrage an /api/pull eine Datei außerhalb der Modellablage schreiben; kann der Ollama-Dienst nach /usr/lib/ollama schreiben, läuft die Datei nach einem Neustart als root, und diesen Fall stuft der CVE-Eintrag als kritisch ein (CVSS 9.4), sonst mit 6.9; Ollama 0.35.0 behebt sie, setzen Sie daher 0.35.0 oder neuer ein. Jupyter Server schaltet die Token-Authentifizierung standardmäßig ein, und seine Dokumentation erklärt, warum: „Zugriff auf den Jupyter Server bedeutet Zugriff auf das Ausführen beliebigen Codes“. Unser Vergleich der Serving-Engines zeigt, auf welchen Adressen drei weitere Engines standardmäßig lauschen.

Binden Sie jede Engine und jeden Notebook-Server an localhost oder eine interne Adresse und stellen Sie ein TLS-Gateway davor, das jedem Team oder jeder Anwendung einen eigenen Schlüssel gibt, Routen per Allowlist freigibt, Anfrageraten begrenzt und protokolliert, wer was gefragt hat. Prompts und Antworten können personenbezogene Daten enthalten, deshalb braucht dieses Protokoll eine eigene Zugriffskontrolle und eine eigene Aufbewahrungsfrist.

Wenn Sie das Gateway und das Protokoll nicht selbst aufbauen wollen, umfasst unsere Leistung Private AI/ML die Zugriffskontrolle und die Protokollierung von Anfragen und Antworten. Nennen Sie uns, welche Teams und Anwendungen Ihre Modelle aufrufen, und wir antworten innerhalb eines Werktages.

Modelldateien und Remote-Code

Eine Modelldatei kann Code enthalten, der beim Laden ausgeführt wird. Hugging Face warnt: „Es gibt gefährliche Angriffe mit Ausführung beliebigen Codes, die verübt werden können, wenn Sie eine pickle-Datei laden.“ Pickle ist das Format von Checkpoints wie pytorch_model.bin, und die Prüfung der pickle-Importe, die Hugging Face auf dem Hub vornimmt, „ist nicht zu 100 Prozent narrensicher“. Gegen dieses Risiko wurde safetensors entwickelt: Sein README fragt „Kann ich eine zufällig heruntergeladene Datei verwenden und erwarten, dass kein beliebiger Code ausgeführt wird?“, stuft safetensors als sicher ein und pickle als „unsicher, führt beliebigen Code aus“ und definiert die Datei als eine Header-Länge, einen JSON-Header und einen Byte-Puffer.

Für pickle-Checkpoints setzen Sie PyTorch 2.6 oder neuer ein. Seit Version 2.6 verwendet torch.load die Einstellung weights_only=True, sofern kein pickle-Modul übergeben wird; das beschränkt den Unpickler auf das, was State Dicts aus einfachen Tensoren und einigen primitiven Typen brauchen, und 2.6.0 hat CVE-2025-32434 behoben, eine Lücke zur Codeausführung aus der Ferne in torch.load mit weights_only=True in 2.5.1 und früher.

In Transformers führt trust_remote_code=True Modellcode aus, der aus dem Modell-Repository stammt und nicht aus der Bibliothek; die Dokumentation rät, von einer bestimmten Revision zu laden, einem Commit-Hash, „um zu vermeiden, Modellcode zu laden, der sich geändert haben könnte“. vLLM lässt --trust-remote-code standardmäßig ausgeschaltet und nimmt für dasselbe Pinning --revision und --code-revision entgegen. Laut seinem Advisory GHSA-h3rc-6mm3-gc2m vom 6. Oktober 2026 konnte bei eingeschaltetem --trust-remote-code eine multimodale Anfrage die Revision des Prozessor-Codes über mm_processor_kwargs.code_revision selbst wählen und so Code aus einer Revision laden, die ein Angreifer kontrolliert, etwa aus einem Pull Request im Hugging-Face-Repository des Modells; betroffen sind die Releases ab 0.7.3 vor 0.31.0, das die Lücke behebt. vLLM hat im September und Oktober 2026 rund dreißig Sicherheitshinweise veröffentlicht, mehrere davon zu Denial of Service ohne Authentifizierung; setzen Sie daher 0.31.0 oder neuer ein, besser das aktuelle Release, Stand November 2026 0.33.0 vom 2. November 2026, dessen CUDA-13.0-Builds einen Treiber ab R580 brauchen; seit 0.32.0 schaltet vLLM den Cross-Origin-Zugriff aus dem Browser ab, sofern --allowed-origins nicht gesetzt ist. Außerdem setzt vLLM voraus, dass seine Cache-Verzeichnisse „privat und vertrauenswürdig“ sind; wer in sie schreiben kann, kann vLLM also dazu bringen, Code auszuführen: Nur das Dienstkonto sollte in VLLM_CACHE_ROOT und in die Modellablage schreiben.

Mehrere Mandanten auf einer GPU: MIG, Time-Slicing und virtuelle Maschinen

MIG gibt jeder Instanz „separate und isolierte Pfade durch das gesamte Speichersystem“, und für den Mehrmandantenbetrieb stellt NVIDIA fest: „MIG stellt sicher, dass ein Client die Arbeit oder das Scheduling anderer Clients nicht beeinträchtigen kann“. Time-Slicing bietet nichts davon, denn „es gibt keine Speicher- oder Fehlerisolierung zwischen Replikaten“: Behandeln Sie Pods mit Time-Slicing als eine einzige Vertrauensdomäne. Unser Kubernetes-Leitfaden vergleicht die Methoden und die MIG-fähigen Karten.

MIG partitioniert die GPU, nicht den Treiber: Jeder Container nutzt weiterhin den Treiber des Hosts, in dem eine lokale Lücke wie CVE-2026-47489 steckt. Mandanten, die einander nicht vertrauen dürfen, gehören in getrennte virtuelle Maschinen mit einer GPU per Passthrough oder einer vGPU, hinter einen Gastkernel und einen Hypervisor. Mit dem standardmäßig aktiven Prefix Caching von vLLM können Unterschiede in der Zeit bis zum ersten Token verraten, ob der zwischengespeicherte Prompt eines anderen Nutzers genauso begann. Seine Dokumentation empfiehlt, bei jeder Anfrage cache_salt zu setzen, „mit einem Geheimnis, das auf die Mandantengrenze zugeschnitten ist, die Sie durchsetzen wollen“.

Confidential Computing schützt Gewichte und Daten während der Verarbeitung vor dem Host selbst. NVIDIA führt es für die H200 NVL (Produktseite) und die RTX PRO 6000 Server Edition (Datenblatt, Dezember 2025) als unterstützt. Die GPU arbeitet dann mit einer vertraulichen virtuellen Maschine auf einer CPU mit AMD SEV-SNP oder Intel TDX zusammen, und in NVIDIAs Referenzarchitektur vom Juni 2026 werden Modellschlüssel nur gegen gültige Attestierungsnachweise freigegeben. Dieses Dokument lässt „anfälligen Inferenzcode innerhalb der CVM“, Seitenkanäle und physische Angriffe außerhalb seines Bedrohungsmodells und verweist für unterstützte Kombinationen auf NVIDIAs Kompatibilitätsmatrix, die sich nach GPU, VBIOS und Treiber durchsuchen lässt.

Netzsegmente und ausgehender Verkehr

Vier Segmente decken die meisten GPU-Server ab: Management für BMCs und Hypervisoren, Storage für Modelle, Datensätze und Backups, ein Cluster-Segment für den Verkehr zwischen Knoten und ein Service-Segment, in dem die Nutzer das Gateway erreichen und sonst nichts. Nur ein gehärteter Jump-Host sollte die BMCs erreichen. Auch Exporter für GPU-Metriken gehören in ein internes Segment. NVIDIA bewertet CVE-2026-47483, veröffentlicht am 28. Juli 2026, mit 8,2: Nicht authentifizierte Anfragen an die Endpunkte /debug/pprof von DCGM Exporter bis Version 4.8.2 können zu Denial of Service und zur Offenlegung von Informationen führen, und der Eintrag nennt auch DCGM selbst bis 4.5.2. Setzen Sie bei beiden neuere Releases ein und lassen Sie nur Prometheus auf Port 9400 zugreifen; unser Leitfaden zum GPU-Server-Monitoring behandelt den Exporter.

Liegen die Gewichte lokal, braucht ein Inferenzserver keinen Internetzugang. Laden Sie Modelle über einen einzigen kontrollierten Weg in die Modellablage, stellen Sie sie aus einem lokalen Pfad bereit, den die Modelleinstellung von vLLM akzeptiert, und setzen Sie HF_HUB_OFFLINE=1, womit die von vLLM genutzte Client-Bibliothek von Hugging Face keine HTTP-Aufrufe an den Hub absetzt und nur zwischengespeicherte Dateien liest. Für multimodale Modelle begrenzt --allowed-media-domains in vLLM die Hosts, von denen es Medien abruft, als Schutz vor Server-Side Request Forgery, und seine Dokumentation ergänzt VLLM_MEDIA_URL_ALLOW_REDIRECTS=0, damit Weiterleitungen diese Liste nicht umgehen können. Zu Backups der Modellablage siehe Backup eines KI-Servers.

Sollen dieselben Maßnahmen im gesamten Netzwerk gelten, nicht nur auf den GPU-Servern, richtet unser Engineering-Partner Vixen.UNO im Rahmen der Leistung Cyber-Resilienz Netzwerk­segmentierung, Zero-Trust-Zugriff mit Multi-Faktor-Authentifizierung und Privileged Access Management, EDR/XDR auf Servern und die Ereigniszentralisierung im SIEM ein.

Was wir liefern

Wir bauen KI-Server nach Auftrag mit Out-of-Band-Management über IPMI und den BMC, installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime und liefern sie mit Herstellergarantie auf jede Komponente, unter einem EU-Vertrag und auf einer Rechnung. Unser GPU-Sortiment umfasst die H200 NVL und die RTX PRO 6000 Server Edition, für die NVIDIA Confidential Computing angibt, sowie die L40S, die L4 und die RTX-PRO-Workstation-Karten. Unter demselben Vertrag liefert unser Engineering-Partner Vixen.UNO Cyber-Resilienz: ein segmentiertes Netzwerk mit Zero-Trust-Zugriff, Backups, die durch planmäßige Test­wiederherstellungen geprüft werden, und einen Incident-Response-Plan mit Rollen, Maßnahmen und Fristen.

FAQ