Bei den letzten beiden Kernel-Lücken – Copy Fail und Dirty Frag – ging es darum, sich zu root hochzustufen. ssh-keysign-pwn ist subtiler und in mancher Hinsicht unangenehmer: Hier hebelt ein unprivilegierter Nutzer keine Rechte aus, sondern liest direkt aus, was eigentlich nur root sehen darf – die privaten SSH-Host-Keys deines Servers und den Inhalt von /etc/shadow mit allen Passwort-Hashes. Auf meinem Mehrnutzer-Webserver wäre das der Worst Case: Einmal abgeflossene Host-Keys lassen sich nicht zurückrufen, und Shadow-Hashes knackt ein Angreifer offline in aller Ruhe.
Die Lücke betrifft praktisch jeden Linux-Server, egal ob Root-Server beim Hoster, Cloud-VM, Webserver oder die Kiste im Heimnetz. Ich bin auf meinem netcup-vServer als Erstes über den ptrace_scope-Wert gestolpert – stand auf 0, also komplett offen. Der Check dauert keine zwei Minuten, der Patch ist ein apt full-upgrade, und für den Fall, dass dein Wartungsfenster erst nächste Woche ist, gibt es eine Einzeiler-Mitigation ganz ohne Reboot.
Was ist CVE-2026-46333 („ssh-keysign-pwn”)?
CVE-2026-46333 ist eine Information-Disclosure-Lücke im Linux-Kernel, die in der Praxis auf eine Rechteausweitung hinausläuft. Sie steckt in der Funktion __ptrace_may_access() und ist eine klassische Race-Condition: Wenn ein privilegierter Prozess (eine setuid-Binary) beim Beenden seine Rechte abgibt, existiert ein winziges Zeitfenster, in dem die Sicherheitsprüfung des Kernels eine Lücke hat – der „dumpable”-Check wird übersprungen, weil der Speicher-Deskriptor des Prozesses schon auf NULL steht.
Genau in diesem Moment greift der Angriff: Über den Syscall pidfd_getfd() (seit Kernel 5.6) kann ein unprivilegierter Prozess offene Datei-Deskriptoren aus dem sterbenden privilegierten Prozess klauen. Die Ziele sind setuid-root-Binaries, die im normalen Ablauf root-eigene Dateien öffnen:
ssh-keysign– liest die privaten SSH-Host-Keys (/etc/ssh/*_key)chage– liest die Passwort-Datenbank/etc/shadowpkexecundaccounts-daemon– über sie lassen sich sogar root-Befehle ausführen
Eingestuft ist die Lücke mit CVSS 5.5 (CISA) – Canonical bewertet sie wegen der Tragweite trotzdem als High Priority. Der verwundbare Code liegt seit Kernel 4.10 (November 2016) im Mainline, scharf wird er praktisch ab Kernel 5.6 (da kam pidfd_getfd). Entdeckt hat die Lücke das Qualys Threat Research Unit; das volle Advisory erschien am 20. Mai 2026, ein öffentlicher Proof-of-Concept kursiert seit dem 15. Mai. Details stehen in der Qualys-Analyse und im Ubuntu-Advisory.
Wichtig: Wie bei Dirty Frag und Copy Fail braucht der Angreifer lokalen Zugriff – einen Shell-Account, einen kompromittierten Dienst oder einen Container. Aus der Ferne allein ist die Lücke nicht ausnutzbar. Auf Single-User-Systemen ohne erreichbare Dienste ist das Risiko also gering; auf Mehrnutzer-Servern und überall, wo öffentlich erreichbare Software läuft, dagegen ernst.
Bist du betroffen?
Wenn du einen halbwegs aktuellen Linux-Kernel fährst (5.6 oder neuer) und ihn in den letzten Wochen nicht aktualisiert hast, lautet die Antwort vermutlich ja. Prüfe zuerst die laufende Version:
uname -rWelches Kernel-Paket installiert ist (Debian/Ubuntu/Proxmox):
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'Ein schneller Praxis-Test, ob die Voraussetzung für den Exploit (der pidfd_getfd-Pfad) überhaupt greifbar ist: Schau, ob ptrace_scope schon restriktiv steht. Steht der Wert auf 0 oder 1, ist der öffentliche Exploit-Pfad offen:
sysctl kernel.yama.ptrace_scopeGepatchte Kernel-Versionen
Die Fixes wurden in die Stable-Branches zurückportiert. Liegt deine Version darunter, musst du updaten. Die für Server relevanten Stände:
| Distribution | Linie | Gepatcht ab (mindestens) |
|---|---|---|
| Upstream Stable | 5.10 / 5.15 | 5.10.256 / 5.15.207 |
| Upstream Stable | 6.1 / 6.6 | 6.1.173 / 6.6.139 |
| Upstream Stable | 6.12 / 6.18 / 7.0 | 6.12.89 / 6.18.31 / 7.0.8 |
| Ubuntu 22.04 LTS | linux | 5.15.0-181.191 |
| Ubuntu 24.04 LTS | linux | 6.8.0-124.124 |
| Ubuntu 25.10 | linux | 6.17.0-35.35 |
| Ubuntu 26.04 LTS | linux | 7.0.0-22.22 |
Die vollständigen Listen inklusive aller Cloud-Kernel (AWS, Azure, GCP) und HWE-Varianten stehen im Ubuntu-Advisory. Für RHEL-Derivate gilt: Auf RHEL/AlmaLinux 9 ist pidfd_getfd vorhanden und der Exploit zuverlässig, auf RHEL 8 steckt der Logikfehler zwar auch drin, der öffentliche PoC läuft dort aber unzuverlässiger – patchen solltest du trotzdem.
Fix: Kernel patchen
Der saubere Weg ist auch hier das Kernel-Update plus Reboot. Der laufende Kernel im Speicher bleibt sonst verwundbar.
Debian / Ubuntu / Proxmox:
sudo apt update && sudo apt full-upgrade
sudo rebootRHEL / AlmaLinux / Rocky:
sudo dnf update 'kernel*'
sudo rebootNach dem Neustart prüfst du mit uname -r, ob der gepatchte Kernel läuft. Bei einem gemieteten Root-Server oder einer Cloud-VM lohnt vorher der Blick, ob dein Hoster den Reboot über ein eigenes Panel erwartet oder ob ein simples reboot über die SSH-Sitzung reicht – bei manchen Anbietern bootet sonst ein alter Rescue- oder Hoster-Kernel.
Mein Admin-Tipp: Wenn du nach diesem Vorfall auf Nummer sicher gehen willst, tausche die SSH-Host-Keys aus, falls dein Server über längere Zeit verwundbar und für andere Nutzer zugänglich war. Einmal abgeflossene Host-Keys bleiben kompromittiert, auch nachdem der Kernel gepatcht ist. Neue Keys erzeugst du mit sudo ssh-keygen -A (nach Löschen der alten unter /etc/ssh/) und startest den SSH-Daemon neu. Deine Nutzer sehen dann beim nächsten Login die bekannte „Host key changed”-Warnung – das ist hier gewollt.
Sofort-Mitigation ohne Reboot
Reboot heißt bei einem Produktiv-Server immer: Wartungsfenster, Ankündigung, Daumendrücken beim Hochfahren. Für genau diesen Fall gibt es hier eine Mitigation, die sofort greift und keinen Reboot braucht. Du hebst ptrace_scope auf den restriktivsten Wert 2. Dann darf nur noch root mit CAP_SYS_PTRACE überhaupt ptrace() nutzen. Genau das schneidet dem öffentlichen Exploit den Weg ab, weil dessen pidfd_getfd-Pfad über __ptrace_may_access() läuft.
echo 'kernel.yama.ptrace_scope=2' | sudo tee /etc/sysctl.d/99-cve-2026-46333.conf
sudo sysctl --systemDas wirkt persistent über Reboots hinweg. Prüfen:
sysctl kernel.yama.ptrace_scopeptrace_scope=2 ist kein Freifahrtschein. Normale Nutzer können dann gdb, strace oder perf nicht mehr gegen fremde Prozesse einsetzen, manche Container-Debugging-Workflows, kdump und CRIU können brechen, und Crash-Reporter mancher Browser-Sandboxen mucken auf. Auf einem reinen Produktions-Server ist das meist egal; auf einer Entwickler-Maschine kann es stören. Und Achtung: Einmal erhöht, lässt sich ptrace_scope zur Laufzeit nicht mehr senken – das geht erst nach einem Reboot wieder. Plane die Mitigation also bewusst, nicht aus Versehen.
Nach dem Kernel-Patch kannst du die Einschränkung wieder lockern, falls du sie nicht ohnehin als Härtung behalten willst (ptrace_scope=1 ist auf vielen Systemen ein guter Dauerwert):
sudo rm /etc/sysctl.d/99-cve-2026-46333.conf
sudo sysctl kernel.yama.ptrace_scope=1Fazit
ssh-keysign-pwn ist die unauffälligste der drei Frühjahrs-2026-Kernel-Lücken, aber für Server mit mehreren Nutzern die heikelste: Es geht nicht „nur” um root, sondern um abgeflossene SSH-Host-Keys und Passwort-Hashes, die auch nach dem Patch noch Schaden anrichten können. Mein Rat: Kernel patchen und rebooten, und wenn der Server eine Weile verwundbar und für Dritte zugänglich war, die Host-Keys vorsorglich neu erzeugen.
Mein konkreter Rat: heute schon ptrace_scope=2 setzen – das kostet nichts und bricht auf einem reinen Server nichts –, den Kernel-Patch dann ins nächste Wartungsfenster legen. Die Host-Key-Frage stellt sich nur, wenn fremde Accounts auf der Kiste waren. Wer Copy Fail und Dirty Frag noch offen hat, erledigt alle drei im selben Durchgang.
Häufige Fragen
Muss ich die Lücke patchen, wenn nur ich Zugriff auf den Server habe? ▾
Auf einem echten Single-User-System ohne erreichbare Dienste ist das Risiko gering – der Angriff braucht einen lokalen Account oder einen kompromittierten Prozess. Sobald aber öffentlich erreichbare Software läuft (Webserver, Mailserver, eine App mit Shell-Zugriff) oder mehrere Personen einen Account haben, solltest du zeitnah patchen. Bei gemieteten vServern weißt du außerdem nie sicher, was sonst noch auf der Maschine passiert.
Wie merke ich, ob die Lücke auf meinem Server schon ausgenutzt wurde? ▾
Eine forensisch saubere Antwort ist schwer, weil der Angriff kaum Spuren hinterlässt – er liest nur, er schreibt nichts. Anhaltspunkte: Schau im journalctl/auth.log nach unerwarteten Aufrufen von ssh-keysign, chage oder pkexec durch normale Nutzer, und prüfe mit Audit-Regeln (auditctl) auf pidfd_getfd-Syscalls, falls du Auditing aktiv hast. Im Zweifel gilt die Defensiv-Annahme: War der Server lange offen und für Dritte zugänglich, behandle Host-Keys und Passwort-Hashes als potenziell kompromittiert.
Kann ich ptrace_scope=2 dauerhaft anlassen, oder bricht mir das später etwas? ▾
Auf einem reinen Produktions-Server kannst du es dauerhaft als Härtung behalten – dort debuggt selten jemand fremde Prozesse. Stört es doch, ist ptrace_scope=1 (Standard auf vielen Distros) ein guter Mittelweg: Ein Prozess darf nur seine eigenen Kinder inspizieren. Auf Entwickler- oder CI-Maschinen, wo gdb/strace/Container-Debugging dazugehören, ist 2 dagegen oft zu eng. Wichtig: Hochsetzen geht jederzeit, runter nur nach einem Reboot.
Reicht es, ssh-keysign oder chage zu entfernen? ▾
Nein, das greift zu kurz. Diese Binaries sind nur die bekanntesten Ziele, die root-eigene Dateien öffnen – die eigentliche Lücke sitzt im Kernel, und es gibt weitere setuid-Programme (pkexec, accounts-daemon), über die der Angriff läuft. Einzelne Tools zu entfernen würde nützliche Funktionen kaputt machen, ohne das Grundproblem zu lösen. Der richtige Weg ist Kernel-Patch oder ptrace_scope=2.
Ist diese Lücke mit Copy Fail oder Dirty Frag verwandt? ▾
Nur insofern, als alle drei aus dem Frühjahr 2026 stammen und lokalen Zugriff voraussetzen. Technisch sind sie verschieden: Copy Fail sitzt in der Krypto-API, Dirty Frag in IPsec/ESP und RxRPC, ssh-keysign-pwn im ptrace-Pfad. Jede hat eine eigene Mitigation. Ein aktuelles Kernel-Update deckt oft mehrere ab – aber verlass dich nicht darauf, prüfe pro CVE gegen das Advisory deiner Distribution.