CVE-2026-46333 (ptrace exit-race): Mitigation in Minuten aktiv

Die heute öffentlich gewordene Linux-Kernel-Schwachstelle CVE-2026-46333 im ptrace-Pfad (in einigen Quellen als „ssh-keysign-pwn” geführt) wurde innerhalb weniger Minuten nach Bekanntwerden auf allen rack::SPEED cPanel- und Plesk-Servern per Mitigation entschärft. Die kurze Reaktionszeit lag daran, dass unser Security-Response-Team seit der Fragnesia-Welle vom Vortag ohnehin in erhöhter Alarmbereitschaft war.

Was die Lücke macht

CVE-2026-46333 ist ein Logik-Fehler in der Kernel-Funktion __ptrace_may_access(). Ein privilegierter Prozess, der gerade seine Credentials abgibt, bleibt für eine sehr kurze Zeitspanne über die ptrace-Familie erreichbar, obwohl das dumpable-Flag diesen Pfad eigentlich bereits geschlossen haben sollte. In Kombination mit dem pidfd_getfd()-Syscall kann ein unprivilegierter lokaler Nutzer in diesem Fenster offene Datei-Deskriptoren des privilegierten Prozesses abgreifen. Typische Beute sind SSH-Host-Private-Keys und die /etc/shadow-Passwortdatenbank. Damit ist auch ohne klassisches Root-Privilege-Escalation der Weg zum Root-Zugriff offen.

Der Bug schlummerte seit November 2016 (Mainline-Kernel 4.10-rc1) im Code. Voraussetzung für den Angriff bleibt lokaler Shell-Zugriff. Aus dem Internet ist die Lücke nicht direkt ausnutzbar. Funktionierende Exploits sind in Umlauf.

Hintergründe und technische Details:

• Qualys Threat Research: Local root and credential disclosure in the Linux Kernel ptrace path
• CloudLinux: ptrace exit-race mitigation and kernel update

Was wir konkret getan haben

Innerhalb von wenigen Minuten nach der Disclosure haben wir die offizielle CloudLinux-Mitigation auf allen Maschinen mit cPanel und Plesk ausgerollt: eine Härtung des ptrace-Pfads über das Yama-LSM, die das Angriffsfenster für unprivilegierte Prozesse vollständig kappt. Der verwundbare Code-Pfad ist im laufenden Kernel damit nicht mehr erreichbar, der Exploit läuft ins Leere, bevor er das pidfd_getfd()-Fenster überhaupt nutzen kann.

Die schnelle Reaktion war kein Zufall: nach der Dirty-Frag-Welle Anfang Mai und Fragnesia gestern stand das Security-Response-Team ohnehin auf erhöhter Bereitschaft. Patch-Pipeline, Roll-out-Skripte und Maschinen-Inventar waren aus den vorherigen Wellen heiß, entsprechend kurz war der Weg von der Disclosure bis zum flächendeckenden Schutz.

Nächster Schritt: Kernel-Patch

Sobald CloudLinux und die anderen Distributionen die zugehörigen Build-Pakete fertig haben, rollen wir sie aus und starten die Maschinen neu. Die Mitigation bleibt bis dahin aktiv. Den Wartungs-Termin pro Maschine kommunizieren wir wie üblich vorab über Ticket- bzw. Status-Benachrichtigung. Den Live-Stand findest du auf der rack::SPEED Status-Page.

Was du selbst tun solltest

Aktiv tun musst du nichts. Auf einem rack::SPEED Managed-Server bist du durch die Mitigation und die Account-Isolation der Plattform gegen den lokalen Angriff abgesichert. Wer einen eigenen Managed Server mit Shell-Accounts betreibt, bekommt die Mitigation flächendeckend ausgerollt, genauso wie auf den Hosting-Maschinen.

Bei Rückfragen oder Sonderfällen erreichst du uns über das Kontaktformular oder telefonisch unter +49 (0)2102 305 84 30.

Drei Kernel-Lücken in vierzehn Tagen: Copy-Fail, Dirty Frag samt Fragnesia, jetzt ptrace exit-race. Die Bereitschaft, die wir aus der letzten Welle nicht wieder zurückgefahren haben, hat heute Minuten gekostet statt Stunden.