Zum Inhalt springen
Tech & Tacheles„Klartext zu KI, Security und Crypto"
← Alle Beiträge
Cybersecurity Oktober 2, 2026

Nvidia GPU-Treiber: 114 Lücken – und keine einzige kritische

Nvidia schließt 114 Schwachstellen in GPU- und vGPU-Treibern. Die kolportierte kritische Lücke mit CVSS 9.9 steht nicht in den Primärdaten. Was wirklich zu tun ist.

Nvidia GPU-Treiber: 114 Lücken – und keine einzige kritische

Nvidia hat am 30. September 2026 ein Sammel-Advisory veröffentlicht, das 114 Schwachstellen in GPU-Treibern und vGPU-Software schließt. Durch die Fachpresse läuft dazu die Angabe, eine dieser Lücken sei „kritisch“ mit CVSS 9.9. Diese Zahl steht nicht in Nvidias maschinenlesbaren Bulletin-Daten – und auch nicht im CVE-Eintrag, den Nvidias eigenes PSIRT eingereicht hat. Wer die Nvidia GPU-Treiber jetzt patcht, sollte wissen, wovor er sich tatsächlich schützt – und wovor nicht.

Was im Advisory 5861 wirklich steht

Ich habe die offizielle Maschinendatei zum Bulletin 5861 aus Nvidias Product-Security-Repository ausgewertet, nicht die Berichte darüber. Das Ergebnis am 2. Oktober 2026:

  • 114 Schwachstellen insgesamt – das passt zu den Medienberichten
  • Einstufung: 78 mal „High“, 36 mal „Medium“
  • Keine einzige Lücke ist als „Critical“ eingestuft
  • Höchster CVSS-v3.1-Basiswert im gesamten Bulletin: 7.8

Den Höchstwert 7.8 erreichen 70 der 114 Einträge. Vier davon laufen auch durch die Berichte: CVE-2026-47505 (Windows-Displaytreiber, Use-after-free im Kernel), CVE-2026-47500 (Windows und Linux, fehlerhafte Referenzzählung), CVE-2026-47489 (Linux-Displaytreiber, überschreibbare Read-only-Speicherrechte) und CVE-2026-47574 (Linux vGPU Virtual GPU Manager).

Woher die 9,9 kommt – und warum sie nicht trägt

Die kolportierte 9.9 taucht in Zusammenhang mit CVE-2026-47574 auf. Die NVD listet für genau diese CVE den Vektor CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H und damit Basiswert 7.8 („High“), veröffentlicht am 30. September 2026 durch Nvidias PSIRT selbst. Auch Nvidias eigene Maschinendatei zum Bulletin (Revision 1.0.0 vom 30. September) nennt 7.8 und stuft keinen einzigen Eintrag als „Critical“ ein. Mehrere Berichte verorten die 9.9 allerdings in der HTML-Fassung desselben Bulletins auf Nvidias Support-Seiten. Diese Seite konnte ich nicht selbst abrufen – sie ist clientseitig gerendert. Deshalb halte ich nur fest, was belegbar ist: In den Maschinendaten und im CVE-Eintrag steht 7.8. Wenn die 9.9 tatsächlich auf der Webseite steht, ist das kein Pressefehler, sondern ein Widerspruch innerhalb von Nvidias eigenen Veröffentlichungen.

Der entscheidende Punkt steckt im Vektor. Ich habe die CVSS-Vektoren aller 114 Einträge ausgewertet: 112 mal AV:L (lokal), zweimal AV:P (physischer Zugriff) – kein einziges Mal AV:N oder AV:A. Keine dieser 114 Lücken lässt sich also aus dem Netz heraus auslösen. Ein Angreifer muss schon Code auf dem System ausführen können – als normaler Benutzer, über eine SSH-Sitzung oder in einer VM. Bei den nötigen Rechten ist das Bild gemischt: 91 Einträge verlangen niedrige Rechte (PR:L), 21 sogar hohe (PR:H), und zwei kommen ohne Rechte aus – darunter CVE-2026-47576 mit 7.7.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

Was das für dich bedeutet

Das ist kein Grund zur Entwarnung, aber ein Grund für eine andere Priorisierung. Eine Rechteausweitung mit CVSS 7.8 ist in der Praxis die zweite Stufe eines Angriffs, nicht der Einstieg. Für einen Einzelplatz-PC heißt das: beim nächsten Treiberupdate mitnehmen, kein Notfall. Wer dagegen Maschinen betreibt, auf denen fremder oder halbvertrauter Code läuft, hat ein echtes Thema.

Besonders betroffen sind aus meiner Sicht drei Szenarien. Erstens Multi-User-Systeme, etwa Rechen- oder Trainingsknoten, auf denen mehrere Personen Jobs starten. Zweitens VDI- und vGPU-Umgebungen: Der Virtual GPU Manager sitzt genau auf der Mandantengrenze, und CVE-2026-47574 ist als „incorrect resource transfer between spheres“ (CWE-669) beschrieben. Nvidia bewertet den Eintrag allerdings mit S:U, also ohne Scope-Wechsel – ein belegter Gast-zu-Host-Ausbruch steht in den Primärdaten nicht. Ernst nehmen, aber nicht zum Hypervisor-Escape hochschreiben. Drittens Workstations, auf denen Modelle oder Container aus dem Internet ausgeführt werden – wie leicht da fremder Code hereinkommt, war schon beim Thema GPU-Angriffe per Rowhammer zu sehen.

Konkret zu prüfen

Erst die eigene Version feststellen, dann entscheiden. In PowerShell oder im Terminal:

nvidia-smi --query-gpu=name,driver_version --format=csv,noheader

Die von Nvidia genannten korrigierten Versionen sind je Zweig unterschiedlich. Für GeForce unter Windows: 616.56 (R615), 610.88 (R610) oder 582.78 (R580, für Maxwell, Pascal und Volta). Für GeForce unter Linux: 615.71.09, 610.57.04, 595.91.07 beziehungsweise 580.178.04. Achtung bei R610 unter Windows: In den Bulletin-Daten verweisen 66 Einträge auf 610.60, 68 auf 610.88. Wer alles abdecken will, nimmt 610.88.

Bei vGPU gilt 19.6 für die 19er-Reihe und 20.2 für die 20er-Reihe. Wichtig: Host und Gast müssen beide aktualisiert werden. Nur den Virtual GPU Manager zu patchen und die Guest-Treiber stehen zu lassen, schließt die Mandantengrenze nicht. Genau diesen halben Schritt sehe ich in VDI-Projekten regelmäßig.

Mein Praxis-Tipp für den Betrieb: Nimm das Bulletin als Anlass, einmal zu zählen, auf wie vielen deiner GPU-Systeme unprivilegierte Nutzer oder fremde Container Code ausführen dürfen. Diese Zahl bestimmt die Dringlichkeit, nicht der CVSS-Wert. Und wer die eigene GPU-Hardware für lokale KI-Modelle nutzt, findet im Ratgeber zu Hardware für lokale KI und LLMs die Auswahlkriterien, die über den Treiberstand hinausgehen.

Quellen

Newsletter

Mehr Klartext, direkt ins Postfach

Neue Analysen zu Security, KI und Crypto per Mail – zum Einstieg die AD-Checkliste mit 12 Sofortmaßnahmen als PDF.

Zur Anmeldung