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

GPUThor Rowhammer: ECC schützt NVIDIA-GPUs nicht mehr

GPUThor Rowhammer knackt erstmals den ECC-Schutz von NVIDIA-GPUs – bis zur Root-Shell. Was betroffen ist und was du jetzt prüfen solltest.

GPUThor Rowhammer: ECC schützt NVIDIA-GPUs nicht mehr

Ein Forschungsteam der University of Toronto hat mit GPUThor Rowhammer erstmals den ECC-Schutz von NVIDIA-Grafikkarten ausgehebelt. Bislang galt aktiviertes ECC als ausreichende Antwort auf Rowhammer-Angriffe gegen GPUs. Diese Annahme ist seit dem 25. August 2026 widerlegt: Chris S. Lin, Joyce Qu, Aditya Rajeev und Gururaj Saileshwar kommen bis zur Root-Shell auf dem Host-System – und zwar mit eingeschaltetem ECC. Die Arbeit erscheint im November auf der ACM CCS 2026.

Was GPUThor Rowhammer technisch anders macht

Rowhammer ist ein physikalischer Effekt in DRAM-Speicher. Wer eine Speicherzeile oft genug ansteuert, lässt Ladung aus den Nachbarzeilen abfließen und kippt dort einzelne Bits. Bisherige GPU-Angriffe wie GPUHammer (2025) oder GPUBreach (2026) hämmerten dabei gleichmäßig. Sie umgingen die eingebaute Schutzfunktion der Speicherchips – Target Row Refresh, kurz TRR – zwar bereits, erzeugten aber nur wenige Dutzend bis einige Hundert Bitflips pro Gigabyte. Wenig genug, dass aktiviertes ECC sie allesamt wegkorrigierte.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

GPUThor arbeitet stattdessen mit einem ungleichmäßigen Muster. Dafür haben die Forscher zwei undokumentierte Eigenschaften der GPU-Speicheranbindung rückwärts analysiert: wie wiederholte Speicherzugriffe zusammengefasst werden und wie oft TRR tatsächlich eingreift. Das Ergebnis ist eine 6,6-fach höhere Intensität auf der entscheidenden Speicherzeile – und zwischen 4.548- und 23.597-mal mehr Bitflips als bei GPUHammer.

Vier Karten getestet, ECC hält nicht mehr

Nachgewiesen wurde der Angriff auf vier Ampere-Workstation-Karten mit GDDR6-Speicher, gemessen mit deaktiviertem ECC:

  • RTX A5000 (24 GB): rund 377.000 Bitflips pro Gigabyte
  • RTX A6000 (48 GB): rund 114.000
  • RTX A4500 (20 GB): rund 75.000
  • RTX A4000 (16 GB): rund 72.000

Das SECDED-Verfahren dieser Karten korrigiert einen gekippten Bit je 16-Byte-Einheit und erkennt einen zweiten. In den Messläufen fanden die Forscher 387 Doppelbitfehler, die ECC zwar erkennt, aber nicht reparieren kann – und zwei Dreifachbitfehler, die es still auf einen falschen Wert „korrigierte“. Der größte Teil davon entfiel auf die A5000.

Im Live-Test mit aktiviertem ECC – möglich nur auf der A6000, weil die übrigen Karten in einer Cloud ohne ECC-Schalter liefen – reichte das für zwei Angriffe. Erstens Denial of Service: rund alle zwei Stunden ein GPU-Reset, der alle laufenden Jobs beendet; nach etwa 18 Stunden meldete sich die Karte selbst als austauschbedürftig. Zweitens Rechteausweitung: Durch gezielte Bitflips in den GPU-Page-Tables kommt ein unprivilegiertes CUDA-Programm an beliebigen Speicher und öffnet eine Root-Shell auf dem Host. Der komplette Angriff bis zur Root-Shell dauert dabei rund 1,1 Minuten – mit GPUHammer-Mustern waren es 21,9 Stunden.

Was das für dich bedeutet

Bevor jetzt jemand die Grafikkarte ausbaut: Für den normalen Arbeitsplatz-PC ist das keine akute Gefahr. Der Angreifer muss Code auf der GPU ausführen können. Wer allein am eigenen Rechner arbeitet und keine fremden CUDA-Kernels startet, hat ein völlig anderes Bedrohungsmodell als ein Cloud-Anbieter.

Ernst wird es überall dort, wo eine physische GPU von mehreren Parteien genutzt wird – also in geteilten KI-Instanzen, bei Rechenzeit-Anbietern und in Uni- oder Firmenclustern. Genau dort liegt aus CISO-Sicht der eigentliche Punkt: Die Mandantentrennung auf GPU-Ebene ist deutlich dünner als die auf CPU-Ebene, an die wir uns über Jahre gewöhnt haben. Wer aus der Servervirtualisierung kommt, unterstellt reflexhaft eine Isolationsgrenze, die es beim geteilten Grafikspeicher in dieser Qualität schlicht nicht gibt.

Der zweite, unterschätzte Weg führt über die Lieferkette: Ein manipuliertes Modell oder ein kompromittiertes Python-Paket bringt fremden Code auf deine GPU, ohne dass jemand „einbrechen“ muss. Das ist derselbe Mechanismus, den wir zuletzt bei unsicheren MCP-Servern gesehen haben – nur eine Ebene tiefer im Stack.

Was du jetzt konkret tun solltest

  • ECC anlassen, aber nicht darauf vertrauen. ECC hebt weiterhin die Hürde und fängt Einzelbitfehler ab. Als alleinige Antwort auf Rowhammer taugt es nicht mehr.
  • Fehlerzähler ins Monitoring nehmen. nvidia-smi -q -d ECC zeigt korrigierte und unkorrigierbare Fehler, jeweils volatil und aggregiert. Ein plötzlicher Anstieg der korrigierten Fehler ist der beste Frühindikator, den du hast – aber ein löchriger: Dreifach-Bitflips erzeugen laut den Forschern stille Datenkorruption, die in keinem Zähler auftaucht.
  • IOMMU/DMA-Isolation aktivieren. Laut Berichterstattung über NVIDIAs Security Notice empfiehlt der Hersteller neben System-ECC und Telemetrie-Überwachung ausdrücklich die DMA-Isolation. Sie setzt als einzige Maßnahme direkt am Pfad „Page-Table-Manipulation zu Root“ an.
  • Geteilte GPUs vermeiden – und das vertraglich festhalten. Bei eingekaufter Rechenzeit für sensible Workloads gehört „dedizierte physische Karte, kein Time-Sharing der GPU“ in die Leistungsbeschreibung, nicht in ein Nebengespräch.
  • Fremden GPU-Code wie fremden Systemcode behandeln. Modelle und Abhängigkeiten aus unbekannten Quellen gehören nicht ungeprüft auf eine Karte, die im selben Host wie deine Produktivdaten steckt.

Für alle, die lokale KI selbst betreiben, hat das eine angenehme Kehrseite: Wer die eigene Karte im eigenen Rechner betreibt, statt Rechenzeit zu teilen, umgeht das Kernproblem dieser Angriffsklasse. Wie du dafür sinnvoll ausstattest, steht in meinem Ratgeber zu Hardware für lokale KI (LLMs). Wie gut kompakte Modelle inzwischen auf einer einzigen Karte laufen, zeigt das Beispiel Nvidia Nemotron 3.5 Lightning.

Einordnung: Wie dringend ist das?

Zur Ehrlichkeit gehört: Für GPUThor gibt es keine CVE-Nummer und keinen Patch, den du einspielen könntest. Es ist eine Hardware-Schwäche, kein Softwarefehler. Ein echter Fix braucht stärkere Fehlerkorrektur oder Gegenmaßnahmen im Speicher-Controller künftiger Generationen.

Und „nur vier Karten“ ist keine Entwarnung. Auf HBM-, GDDR6X- und GDDR7-Speicher erzeugten die aktuellen Muster im Test zwar keine Bitflips, doch die Forscher schließen ausdrücklich nicht aus, dass andere Muster dort funktionieren. Im Paper steht zudem, dass die Rechteausweitung auf Server-GPUs wie der A100 grundsätzlich möglich bleibt, weil auch dort nur SECDED-ECC greift – und dass die RAS-Repair-Funktion aktueller Blackwell-Karten den Angriff verlangsamt, aber nicht verhindert.

Ein Detail am Rande, das die Quellen unterschiedlich darstellen: BleepingComputer nennt den 21. August als Datum des NVIDIA-Hinweises, die Projektseite der Forscher nennt den 25. August als Embargo-Ende und Veröffentlichungstag des Security Notice. Am Sachverhalt ändert das nichts, an der Sorgfalt beim Zitieren schon.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden