CVE-2026-31431 „Copy-Fail": Updates und Server-Neustart eingeplant
Lokale Root-Eskalation im Linux-Kernel-Crypto-Subsystem (algif_aead), distributionsübergreifend. Wir spielen die Updates auf allen rack::SPEED-Servern direkt nach Veröffentlichung ein.
Die heute bekannt gewordene Sicherheitslücke „Copy-Fail” (CVE-2026-31431) betrifft den Linux-Kernel — konkret das Crypto-Subsystem über die AF_ALG-Socket-Schnittstelle. Wir haben die Lage seit Veröffentlichung im Blick, spielen die Distributions-Updates direkt nach Erscheinen auf allen unseren Servern ein und führen die nötigen Kernel-Neustarts so zeitnah wie möglich durch.
Was die Lücke macht
CVE-2026-31431 erlaubt es einem lokal angemeldeten Nutzer, mit einem 732 Byte kurzen Python-Skript Root-Rechte zu erlangen. Die Schwachstelle sitzt im Kernel-Modul algif_aead (Authenticated Encryption with Associated Data über AF_ALG) und wird über fehlerhafte Buffer-Behandlung beim Kopieren von Crypto-Operationen ausgelöst — daher der Marketing-Name „Copy-Fail”. Die Lücke ist gravierend, weil sie distributionsübergreifend wirkt: RHEL, AlmaLinux, Ubuntu, Debian und ihre Derivate sind gleichermaßen betroffen, sobald sie einen verwundbaren Kernel ausliefern.
Hintergründe und technische Details:
- Heise Security: Copy-Fail — Linux-root in allen großen Distributionen mit 732 Byte Python
- Projekt-Seite: copy.fail
- AlmaLinux-Advisory: CVE-2026-31431 Copy-Fail
Was wir konkret tun
Sobald der jeweilige Distributions-Hersteller die gepatchten Kernel-Pakete veröffentlicht hat, rollen wir sie auf allen rack::SPEED-Servern aus. Weil die Lücke im Kernel sitzt, greift der Fix erst nach einem Reboot — der laufende Kernel bleibt sonst verwundbar. Wir führen die Neustarts so zeitnah wie möglich durch; die Sicherheitslage rechtfertigt den außerordentlichen Wartungsaufwand. Im laufenden Betrieb ist mit einer kurzen Unterbrechung beim Reboot zu rechnen, weitere Einschränkungen sind nicht zu erwarten.
Aktuell laufende Jobs werden vom Reboot natürlich nicht abgeschnitten — wir koordinieren die Neustarts intern, damit kein Kunde mitten in einer Operation stecken bleibt. Den aktuellen Roll-out-Stand siehst du jederzeit auf unserer Status-Seite.
Restrisiko
Bis die Patches durch sind, bleibt ein theoretisches Restrisiko: ein Angreifer braucht für die Ausnutzung lokalen Shell-Zugang. Auf unseren Hosting-Tarifen ist dieser Zugang ohnehin auf den jeweiligen Account beschränkt (Account-Isolation via CloudLinux OS), auf Managed Servern und Clustern haben nur du und unser Team Shell-Zugriff. Die Kombination aus eingeschränktem Zugriffsmodell und kurzer Patch-Latenz macht das Risiko in der Praxis überschaubar — null ist es aber nicht, deshalb der zeitnahe Reboot.
Was du tun musst
Nichts. Wir kümmern uns um Kernel-Update und Reboot. Deine Anwendung läuft nach dem Neustart mit dem gepatchten Kernel weiter, ohne Eingriff von dir.
Falls du eigene Linux-Maschinen jenseits unserer Plattform betreust, gilt die übliche Empfehlung: Distributions-Kernel-Update einspielen, danach neustarten. Eine Übersicht der jeweiligen Patch-Versionen findest du auf den Hersteller-Advisories oben.
Bei Fragen zum Patch-Stand auf deinem Server erreichst du unseren Support direkt im Kundencenter oder über das Kontaktformular. Mehr zur Plattform-Architektur, auf der wir die Updates ausrollen: Unsere Server.
Wir patchen, sobald die Updates da sind.