CVE-2026-43494 „PinTheft": Mitigation vorsorglich aktiv
Linux-Kernel-Lücke „PinTheft" (CVE-2026-43494) im RDS-Zerocopy-Pfad. CloudLinux ist nach eigener Aussage nicht betroffen, wir haben die Mitigation auf allen rack::SPEED-Servern trotzdem ausgerollt.
Die heute öffentlich gewordene Linux-Kernel-Schwachstelle „PinTheft” (CVE-2026-43494) betrifft den RDS-Zerocopy-Pfad des Kernels. CloudLinux hat erklärt, dass die eigenen Kernel von der Lücke nicht betroffen sind. Wir haben die zugehörige Mitigation trotzdem direkt nach Bekanntwerden auf allen rack::SPEED cPanel- und Plesk-Servern ausgerollt, sicherheitshalber und ohne auf eine Detail-Prüfung pro Maschine zu warten.
Was die Lücke macht
PinTheft ist eine lokale Privilege-Escalation. Sie verkettet einen Double-Free-Fehler im RDS-Zerocopy-Sendepfad (Reliable Datagram Sockets, Funktion rds_message_zcopy_from_user()) mit den Fixed Buffers von io_uring. Bei jedem fehlschlagenden Zerocopy-Send wird genau eine FOLL_PIN-Referenz der ersten gepinnten Speicherseite gestohlen. Wiederholt ausgeführt, hält io_uring am Ende einen Zeiger auf eine fremde Speicherseite, daher der Name. Über diesen Weg verschafft sich ein unprivilegierter lokaler Nutzer Root-Rechte.
Der Bug steckt seit Kernel 4.17 (2018) im Code, die Exploit-Kette nutzt allerdings io_uring-Funktionen, die es damals noch nicht gab. Voraussetzung für den Angriff bleibt lokaler Shell-Zugriff. Aus dem Internet ist PinTheft nicht direkt ausnutzbar. Ein funktionierender Proof-of-Concept ist veröffentlicht.
Hintergründe und technische Details:
- BleepingComputer: Exploit released for PinTheft Arch Linux root escalation flaw
- TuxCare: PinTheft grants local root where RDS and io_uring are exposed
- Security Affairs: PinTheft, another Linux privilege escalation
Was wir konkret getan haben
CloudLinux gibt an, dass die eigenen Kernel nicht verwundbar sind. Wir haben die Mitigation trotzdem flächendeckend eingespielt: eine modprobe-Blacklist, die das Laden des RDS-Moduls unterbindet. RDS ist auf Hosting- und Webservern ohnehin nicht im Einsatz, der Schritt kostet also keine Funktion und schließt den Angriffsvektor unabhängig davon, wie die Kernel-Prüfung im Detail ausgeht.
Die Logik dahinter ist die gleiche wie bei den Kernel-Lücken der vergangenen Wochen: Wenn eine Mitigation nichts kostet und ein Restrisiko ausschließt, rollen wir sie aus, statt auf das letzte Wort der Vendor-Analyse zu warten. Lieber eine Maßnahme zu viel als eine zu spät. Wie die Hardware-Firewall mit IPS/IDS auf unseren Servern gehört auch das schnelle Schließen von Kernel-Vektoren zum Standard-Betrieb.
Nächster Schritt: Kernel-Patch
Ein Kernel-Patch für PinTheft ist bereits verfügbar. Sobald CloudLinux und die anderen Distributionen die regulären Build-Pakete freigegeben haben, rollen wir sie auf allen Servern 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-Hosting-Tarif bist du durch die Mitigation und die Account-Isolation der Plattform abgesichert. Wer einen eigenen Managed Server oder Managed Cluster mit Shell-Accounts betreibt, hat die RDS-Blacklist flächendeckend ausgerollt bekommen.
Bei Rückfragen oder Sonderfällen erreichst du uns über das Kontaktformular oder telefonisch unter +49 (0)2102 305 84 30.
Nicht betroffen zu sein ist ein guter Ausgangspunkt. Den Vektor trotzdem zu schließen, kostet uns nichts und dir nichts.