Safe-RET-Lücke CVE-2026-68480: Spectre-v2-Schutz auf AMD-Zen-Servern ausgehebelt

Wer virtuelle Maschinen oder Container mit fremdem Code auf AMD-Prozessoren betreibt, hat seit dem 6. August 2026 eine Aufgabe im nächsten Wartungsfenster: Die Spectre-v2-Abwehr Safe-RET lässt sich auf Zen 1 bis Zen 4 aushebeln. Ein unprivilegierter lokaler Prozess kann damit Kernel-Speicher auslesen. Patches liegen für alle gepflegten Kernel-Zweige bereit.

Nicht betroffen sind Intel-Systeme, dort greifen die bestehenden Maßnahmen laut aktuellem Stand weiter. Ebenfalls entspannt bleiben können Betreiber von Einzweck-Servern, auf denen ausschließlich eigener, vertrauenswürdiger Code läuft, denn der Angriff setzt lokale Codeausführung voraus. Kritisch wird es dort, wo fremde Workloads mitlaufen: Hosting, Multi-Tenant-Virtualisierung, CI-Runner, Container-Plattformen und Terminalserver mit interaktiven Nutzern.

Was ist passiert?

AMD-Prozessoren wehren Spectre v2 mit einer Technik namens Safe RET ab. Sie bereinigt den Branch Predictor direkt vor jeder Kernel-Rückkehr. Das Verfahren geht davon aus, dass zwischen dieser Bereinigung und der anschließenden Nutzung nichts Feindliches ausgeführt wird, insbesondere kein Interrupt.

Genau diese Annahme haben Daniel Trujillo und Mengjia Yan vom MIT CSAIL gebrochen. Ihre Technik heißt Interrupt Injection: Ein Angreifer platziert einen Hardware-Interrupt mit Nanosekunden-Genauigkeit in dem Fenster zwischen Bereinigung und Nutzung. Auf Zen 2 ist dieses Fenster nur zwei Instruktionen beziehungsweise sechs Byte breit. Der Interrupt-Handler dient dann als Trainingsgadget für den Branch Predictor, in Kombination mit der älteren Inception-Lücke CVE-2023-20569 wird der Return Stack Buffer mit angreiferkontrollierten Zielen gefüllt.

Die Schwachstelle ist als CVE-2026-68480 geführt, AMD referenziert sie als AMD-SN-7061. Der Kernel-Commit lag bereits am 2. Juni 2026 in den Stable-Trees, öffentlich gemacht wurde die Lücke erst zwei Monate später zur Black Hat USA 2026.

Wer ist betroffen?

1. AMD-Prozessoren der Generationen Zen 1 bis Zen 4. Demonstriert wurde der Angriff laut AMD auf Zen 1 und Zen 2, für Zen 3 und Zen 4 halten die Forscher ihn für möglich, ein Nachweis steht aus.
2. Linux-Systeme, die die SRSO-Abwehr im Modus Safe RET nutzen. Das ist die Standardeinstellung auf betroffener Hardware.
3. Fixe stehen in Linux 7.1.7, 6.18.43, 6.6.149, 6.1.181 sowie in den LTS-Zweigen 5.15.214 und 5.10.263. Distributionen ziehen nach, Fedora 44 hat den Kernel 7.1.7 bereits ausgeliefert.
4. Nicht betroffen: Intel-Plattformen sowie AMD-Systeme, auf denen kein nicht vertrauenswürdiger Code ausgeführt werden kann.

Wie kritisch ist das?

Technisch handelt es sich um Informationsabfluss durch eine geschwächte Schutzmaßnahme, nicht um Remote Code Execution und nicht um direkte Rechteausweitung. Voraussetzung ist lokale Codeausführung auf dem betroffenen Host. Die von den Forschern erreichte Leserate liegt bei rund 5,47 Byte pro Sekunde, ein gezieltes Auslesen von Schlüsselmaterial ist damit langsam, aber nicht ausgeschlossen.

Meldungen über Ausnutzung in freier Wildbahn liegen bis zum 9. August 2026 nicht vor. Ein Eintrag im CISA-KEV-Katalog existiert nicht. Das rechtfertigt kein Notfallfenster, wohl aber ein zeitnah geplantes Kernel-Update. Wer Hosting oder Multi-Tenant-Virtualisierung betreibt, sollte es höher priorisieren als ein normales Routine-Update, weil dort per Definition fremder Code auf der Maschine läuft.

Was sollten Admins jetzt tun?

1. Inventar prüfen: Welche Hosts laufen auf AMD Zen 1 bis Zen 4? Schnell erkennbar über die CPU-Modellbezeichnung in /proc/cpuinfo.
2. Aktuellen Schutzstatus auslesen über /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow. Steht dort ein Safe-RET-Modus, ist das System vor dem Patch angreifbar.
3. Kernel aktualisieren auf mindestens 7.1.7, 6.18.43, 6.6.149, 6.1.181, 5.15.214 oder 5.10.263 beziehungsweise auf das entsprechende Distributionspaket. Reboot einplanen, ohne Neustart greift der Fix nicht.
4. Priorisieren nach Mandantenfähigkeit: Hypervisor, Container-Hosts, CI-Runner und Terminalserver zuerst, danach Einzweck-Systeme.
5. Nach dem Neustart erneut die Vulnerabilities-Datei prüfen und die Kernel-Version dokumentieren.
6. Keine Mitigation deaktivieren, um Leistung zu gewinnen. Der Angriff nutzt genau die Lücke in dieser Schutzfunktion.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen mit klassischen Einzelserver-Aufbauten ist die Lage entspannt: Ohne fremden Code auf der Maschine fehlt der Ansatzpunkt. Wer aber Virtualisierung mit mehreren Kunden betreibt, Container aus fremden Registries fährt oder Nutzern eine Shell gibt, sollte den Kernel-Wechsel in das nächste reguläre Wartungsfenster nehmen und nicht auf den übernächsten Zyklus schieben.

Der Fall zeigt zudem, wie wertvoll saubere Kernel-Update-Prozesse sind. Wer seine Server ohnehin regelmäßig und automatisiert mit Sicherheitsupdates versorgt, hat den Patch in der Regel schon erhalten, ohne einzeln reagieren zu müssen.

Passende Anleitungen auf S-EDV

1. Unattended Upgrades einrichten Sicherheitsupdates auf Debian und Ubuntu automatisiert einspielen, damit Kernel-Fixes nicht liegen bleiben.
2. Proxmox VE installieren und grundkonfigurieren Basis für Virtualisierungshosts, auf denen dieses Update besonders zählt.
3. Fragnesia: Root-Lücke im Linux-Kernel ein weiterer Kernel-Fall aus 2026 zum Vergleich der Vorgehensweise.

Quellen

1. NVD: CVE-2026-68480
2. Red Hat Security: CVE-2026-68480
3. Phoronix: Linux Patched For Safe RET Interrupt Vulnerability
4. Linux Compatible: Stable-Kernel 6.18.43, 6.6.149, 6.1.181
5. The Hacker News: New Interrupt Injection Attack