Eine Woche nach PHP2Shell: Angriffe laufen, und jetzt kommt eine Linux-Kernel-Lücke dazu

Am 21. Oktober veröffentlichte das PHP-Team Notfall-Updates für zwei kritische Lücken, CVE-2026-109618 und CVE-2026-109619 („PHP2Shell“). Damals ging es darum, wie schnell Sie patchen. Eine Woche später lautet die Frage anders: Wurden Sie in der Zwischenzeit angegriffen, und was kann ein Angreifer tun, sobald PHP geknackt ist?

Was seit dem 21. Oktober passiert ist

• Die Angriffe begannen vor den Patches. Berichten zufolge (unter anderem Amazon Threat Intelligence) lief die Ausnutzung etwa vier Tage vor Erscheinen der korrigierten Versionen an. Honeypot-Daten bestätigten später erfolgreiche Versuche, etwa gegen Apache mit mod_php unter PHP 8.4.26.
• Die CISA bestätigte es am 26. Oktober. Beide PHP-Lücken stehen im Katalog der Known Exploited Vulnerabilities, mit Frist 29. Oktober für US-Bundesbehörden. Wie viele produktive Systeme tatsächlich betroffen waren, sagt der Eintrag nicht.
• Das Ausmaß ist groß. Das Threat-Intelligence-Labor der TU Delft hat Berichten zufolge mehr als 50.000 Angriffsanfragen von über 600 IP-Adressen in 70 Ländern erfasst. Ein Forscher fand Hinweise auf Ausnutzung von CVE-2026-109618, aber keine für CVE-2026-109619, die beiden sind in der Praxis also nicht gleich gefährlich. Patchen Sie trotzdem beide.
• Frühe Meldungen über „erfolgreiche Einbrüche“ waren teils voreilig. Vorsicht bei Zahlen zu kompromittierten Servern: Eine belastbare Zählung gibt es noch nicht.

Das Neue: von PHP zu Root

Am 28. Oktober nahm die CISA CVE-2026-46300 auf, eine Linux-Kernel-Lücke mit dem Spitznamen „Fragnesia“. Es ist eine lokale Rechteausweitung im ESP-in-TCP-Code des Kernels, mit der ein unprivilegierter Nutzer den Page-Cache von Dateien verändern kann, die er nur lesen darf. Öffentlicher Exploit-Code zielt Berichten zufolge auf die zwischengespeicherte Kopie von /usr/bin/su, sodass der nächste Aufruf des Programms Angreifer-Code als Root ausführt.

Laut CISA-Eintrag lässt sich diese Lücke mit den beiden PHP-Lücken verketten, um PHP-Web-Shells einzuschleusen und Befehle als Root auszuführen. Darauf kommt es für Administratoren an: PHP2Shell allein gibt dem Angreifer die Rechte des Webserver-Benutzers. Mit der Kernel-Lücke dahinter ist ein verwundbarer Server nicht nur eine veränderte Website, sondern eine komplett übernommene Maschine, mit allen anderen Websites und allen Geheimnissen darauf.

Wie verbreitet die Kette ist, sagt die CISA nicht, und Erpressungs-Kampagnen sind als „unbekannt“ eingetragen. Die Kernel-Lücke wurde im Mai bekannt und betrifft Kernel, die vor dem 13. Mai 2026 gebaut wurden. Viele regelmäßig gepatchte Server haben die Korrektur also schon. Server, die nie neu starten, nicht.

Ist das ein Einzelfall?

Nein. Die CISA nimmt im Schnitt 8 Einträge pro Woche auf, seit August zwischen 3 und 14. Ungewöhnlich ist diese Woche, dass vier der acht Einträge Software sind, die Sie auf dem eigenen Server betreiben: PHP zweimal, der Linux-Kernel und GitLab. Der Katalog ist eine gute, kostenlose Frühwarnliste. Ich veröffentliche jeden neuen Eintrag auf einer eigenen Seite, mit dem, was zu prüfen ist: aktiv ausgenutzte Sicherheitslücken.

Prüfen in 15 Minuten

1. PHP: Welche Version läuft, in welcher Form? Korrigiert sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Webserver und Kommandozeile können verschiedene PHP-Versionen nutzen.

php -v
php-fpm -v 2>/dev/null || ls /usr/sbin/php-fpm*
apachectl -M 2>/dev/null | grep -i php      # mod_php

Die Einzelheiten für Plesk, Synology, Shared Hosting und Docker stehen in der Patch-Anleitung. Wenn Sie heute nicht patchen können, senkt die Notlösung in der php.ini das Risiko.

2. Kernel: Ist die Korrektur installiert und aktiv? Installieren reicht nicht, der neue Kernel zählt erst nach einem Neustart.

uname -r
# Debian / Ubuntu
apt list --upgradable 2>/dev/null | grep -i linux-image
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required
# RHEL / Alma / Rocky
dnf updateinfo list security | grep -i kernel
needs-restarting -r

Das Sicherheitsbulletin Ihrer Distribution zu CVE-2026-46300 nennt die korrigierte Paketversion. Kernel-Versionsnummern führe ich hier nicht auf, weil sie je nach Distribution abweichen.

3. Neustart noch nicht möglich? Gemeldete Zwischenlösung. Berichten zufolge hilft es, die Module esp4, esp6 und rxrpc zu sperren. Das stört IPsec und AFS. Prüfen Sie zuerst, ob Sie sie nutzen:

lsmod | grep -E 'esp4|esp6|rxrpc'
ip xfrm state | head
# nur wenn Sie IPsec/AFS NICHT nutzen:
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/block-esp.conf
sudo modprobe -r esp4 esp6 rxrpc

4. Nach Web-Shells suchen. Kürzlich geänderte PHP-Dateien in den Webverzeichnissen und die typischen Einzeiler:

find /var/www -name '*.php' -mtime -10 -ls 2>/dev/null
grep -rlE '(eval|assert|system|passthru|shell_exec)[[:space:]]*\([[:space:]]*\$_(POST|GET|REQUEST|COOKIE)' /var/www 2>/dev/null

In der ersten Liste erscheinen auch legitime Updates, lesen Sie sie also, statt nur zu zählen. Für die Kernel-Lücke prüfen Sie, ob die System-Binärdateien unverändert sind (dpkg -V util-linux unter Debian und Ubuntu, rpm -V util-linux unter RHEL). Die Ausgabe sollte leer sein. Ein Neustart oder ein Kernel-Update räumt einen verfälschten Page-Cache auf; Berichten zufolge hilft nach der Absicherung auch das Leeren des Caches (echo 3 | sudo tee /proc/sys/vm/drop_caches).

Wenn Sie etwas finden

Behandeln Sie es als Kompromittierung, nicht als Datei zum Löschen. Eine Web-Shell mit einem Kernel-Exploit dahinter kann Root bedeutet haben. Server isolieren, Logs und Datenträgerabbild für die Analyse sichern, aus einem sauberen Backup wiederherstellen, alle Geheimnisse auf der Maschine ändern (Datenbank-Passwörter, API-Schlüssel, SSH-Schlüssel, .env-Dateien) und patchen, bevor die Maschine wieder ans Netz geht.

Was ich heute tun würde

• PHP überall patchen, auch das PHP der Kommandozeile, von Cronjobs und Containern.
• Kernel-Update einspielen und den Neustart einplanen. Ein Kernel-Patch, der auf das „nächste Wartungsfenster“ wartet, ist auf einem Server, der schon über PHP angegriffen wird, eine offene Tür.
• Logs bis zum 17. Oktober prüfen, nicht nur bis zum Tag des eigenen Patches.
• PHP weniger erlauben: disable_functions für exec, system, passthru, shell_exec, wo die Anwendung sie nicht braucht, und getrennte Pools pro Website. Das ersetzt den Patch nicht, erschwert aber die Kette.

Quellen: Recorded Future, BleepingComputer, SOC Prime und der Known Exploited Vulnerabilities Catalog der CISA. Stand 30. Oktober 2026; die Zahlen stammen aus den genannten Berichten und dem CISA-Feed und können sich ändern.