PHP2Shell und die Node.js-Lücken selbst beheben: eine Anleitung

Am 21. Oktober 2026 haben PHP und Node.js Sicherheitsupdates veröffentlicht. Die PHP-Lücken heißen inzwischen PHP2Shell und werden laut den Sicherheitsforschern von watchTowr bereits aktiv ausgenutzt. Läuft deine Website mit WordPress, Joomla, TYPO3, Shopware oder einem anderen PHP-System, solltest du heute nachsehen. In den meisten Fällen ist das in einer Viertelstunde erledigt.

Stand dieses Beitrags: 23. Oktober 2026, abends ergänzt um den Abschnitt „Wirkt das Update wirklich?“.

Worum es geht

PHP2Shell sind zwei Fehler im PHP-Interpreter selbst (CVE-2026-109618 und CVE-2026-109619), beide mit 9,2 von 10 Punkten bewertet. Ein Angreifer kann damit über eine präparierte Anfrage eigenen Code auf dem Server ausführen, ohne sich anzumelden. Der Fehler steckt in PHP, deshalb schützen dich aktuelle Plugins und Themes hier nicht. Betroffen sind alle üblichen Betriebsarten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Abgesichert sind diese Versionen:

PHP 8.1, 8.0, 7.4 und älter bekommen keine neuen Versionen mehr. Wer darauf läuft, muss auf einen neueren Zweig wechseln. PHP 8.2 ist ab dem 31. Dezember 2026 ebenfalls ohne Updates, wer jetzt ohnehin umstellt, nimmt besser gleich 8.3 oder 8.4.

Schritt 1: Backup machen

Bevor du etwas änderst, sichere Dateien und Datenbank. Bei WordPress geht das mit einem Backup-Plugin, bei den meisten Hostern auch im Kundenbereich. Ein PHP-Update geht fast immer glatt, aber ein altes Plugin kann mit einer neuen PHP-Version zicken. Mit Backup ist das in fünf Minuten zurückgedreht.

Schritt 2: Herausfinden, was bei dir läuft

WordPress: Im Dashboard unter „Werkzeuge“ → „Website-Zustand“ → Reiter „Bericht“, Abschnitt „Server“. Dort steht die PHP-Version.

Hosting-Paket (Strato, IONOS, all-inkl, Hetzner, Infomaniak und andere): Im Kundenbereich gibt es eine Einstellung „PHP-Version“, meist bei der Domain oder dem Webspace.

Eigener Server oder vServer: Auf der Kommandozeile:

php -v

Achtung bei Debian, Ubuntu und Red Hat: Die Distributionen spielen Sicherheitskorrekturen in ihre eigenen Pakete ein, ohne die Versionsnummer zu ändern. Ein Debian-Server kann also sicher sein, obwohl php -v eine ältere Nummer zeigt. Dort entscheidet, ob das Paket-Update eingespielt ist (siehe Schritt 3).

Schritt 3: Das Update einspielen

Hosting-Paket: Bei großen Hostern spielt der Anbieter die Korrekturen innerhalb einer Hauptversion selbst ein. Steht bei dir 8.2 oder neuer, frag beim Support kurz nach, ob PHP2Shell gepatcht ist. Steht dort 8.1, 8.0 oder 7.x, stell im Kundenbereich auf 8.3 oder 8.4 um und ruf danach ein paar Seiten deiner Website auf, auch das Kontaktformular und den Login. Klemmt etwas, stell zurück und aktualisiere zuerst die Plugins.

Eigener Server mit Debian oder Ubuntu:

sudo apt update && sudo apt upgrade

Danach PHP neu starten, sonst laufen die alten Prozesse weiter. Wie der Dienst bei dir heißt, zeigt:

systemctl list-units --type=service | grep -E "php|apache"

Dann zum Beispiel:

sudo systemctl restart php8.3-fpm

Bei Apache mit mod_php ist es sudo systemctl restart apache2.

Ob die Korrektur drin ist, siehst du im Änderungsprotokoll des Pakets. Taucht dort eine der beiden CVE-Nummern auf, ist alles gut:

apt changelog php8.3-fpm | grep -E "CVE-2026-10961[89]"

Red Hat, Alma, Rocky: sudo dnf upgrade, danach ebenfalls PHP-FPM bzw. den Webserver neu starten.

PHP aus dem Remi-Repository: Dort gab es am 21. Oktober noch keine Updates. Steig in diesem Fall auf die Pakete der Distribution um.

Docker: Das offizielle Image neu ziehen (docker pull php:8.3-fpm oder dein Tag), das eigene Image neu bauen und den Container neu starten.

Wenn das Update gerade nicht geht

Das PHP-Projekt nennt Übergangslösungen und sagt selbst dazu, dass sie das Update nicht ersetzen. Die einfachsten:

• In der php.ini oder der FPM-Pool-Konfiguration session.upload_progress.enabled = 0 setzen und alle PHP-Prozesse neu starten. Über .user.ini oder ini_set() wirkt das nicht.
• post_max_size klein halten: 8M ohne Datei-Uploads, 32M mit. upload_max_filesize bleibt darunter.
• Wer Cloudflare vor der Seite hat: Cloudflare hat Filterregeln gegen die bekannten Angriffswege ausgerollt, auch im kostenlosen Tarif.

Ein System, das sich gar nicht aktualisieren lässt, nimmst du besser vom Netz, bis es umgezogen ist. So rät es auch das britische National Cyber Security Centre.

Wirkt das Update wirklich?

Am 22. Oktober kursierte in sozialen Netzwerken die Behauptung, der Patch sei unvollständig und lasse sich umgehen. Das BSI schreibt in seiner Warnung (Version 1.2 vom 22. Oktober), diese Berichte seien widerlegt. Das Update schützt vor beiden PHP2Shell-Lücken.

Parallel wurde ein anderer Fehler in der PHP-Funktion unserialize() gemeldet (php-src #24481), der auch die neuen Versionen betrifft. Er ist nur ausnutzbar, wenn eine Anwendung fremde Daten mit unserialize() verarbeitet oder schon fremder Code auf dem Server läuft. Eine CVE-Nummer gibt es dafür noch nicht.

Wenn ein Update bei dir scheinbar nicht wirkt, liegt es meist an etwas Einfacherem: PHP-FPM oder Apache wurden danach nicht neu gestartet, und die alten Prozesse laufen weiter. Der Neustart aus Schritt 3 gehört deshalb immer dazu.

Node.js: zehn Lücken am selben Tag

Node.js betrifft weniger klassische Firmen- oder Vereinsseiten, dafür Web-Apps, Online-Tools und alles, was mit Next.js, Nuxt oder Express gebaut ist. Die schwerste der zehn Lücken (CVE-2026-111497) steckt im Brotli-Entpacker und erlaubt laut Node.js das Ausführen von fremdem Code. Angriffe sind bisher nicht bekannt. Dazu kommen drei Fehler bei der Prüfung von TLS-Zertifikaten und DNS-Namen.

Abgesichert sind 26.12.1, 24.22.1 und 22.23.4. Node.js 20 und älter bekommen keine Korrekturen mehr.

Version prüfen:

node -v

Aktualisieren: Mit nvm reicht nvm install 22 (bzw. 24 oder 26), danach die Anwendung neu starten. Mit Docker das Basis-Image (node:22) neu ziehen und neu bauen. Auf Plattformen wie Vercel oder Netlify legt der Anbieter die Node-Version fest. Prüf dort in den Projekteinstellungen, welche Version eingestellt ist, und stoß ein neues Deployment an.

Ein Sonderfall: Wer seine Anwendung als Startup-Snapshot oder als einzelne ausführbare Datei (SEA) ausliefert, muss sie mit der neuen Node-Version neu bauen. Sonst liefert crypto.randomUUID() in jedem Prozess dieselben Werte (CVE-2026-106074).

Den Überblick behalten

PHP2Shell wird nicht die letzte Lücke bleiben. Welche Lücken in PHP, Node.js, WordPress und anderen Web-Werkzeugen gerade aktuell sind, zeigt der Sicherheitsradar. Dort kannst du auch deine eigenen Versionen eintragen und sehen, ob sie noch Updates bekommen. Gescannt wird dabei nichts, die Eingaben bleiben in deinem Browser.

Wenn es dir zu technisch wird

Nicht jeder hat Lust, sich durch php.ini und Paketprotokolle zu arbeiten, und oft ist die Person, die die Seite eingerichtet hat, nicht mehr greifbar. Wenn du hängst oder unsicher bist, ob alles geklappt hat, schreib mir. Ich schaue mir das gerne an.

Zum Kontaktformular

Warum ich meine CMS selbst in .NET baue

Solche Wochen sind ein Grund, warum ich die Redaktionssysteme für meine Kunden selbst in ASP.NET Core baue. Auch .NET bekommt Sicherheitsupdates, das gehört zu jeder Software dazu. Aber es gibt nur einen Update-Weg. Bei einer WordPress-Seite sind es PHP, der WordPress-Kern, das Theme und oft zwanzig Plugins von verschiedenen Leuten, die alle zueinander passen müssen. Mehr dazu steht im Beitrag WordPress oder eigene Lösung.

Diese Website ist übrigens nicht betroffen: Sie läuft ohne PHP, und Node.js nutze ich nur beim Bauen der Stylesheets.

Quellen

• PHP-Projekt: Ankündigung der Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35
• BSI: IT-Sicherheitshinweis „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Version 1.2
• watchTowr: PHP2Shell FAQ
• Help Net Security: PHP2Shell: Critical PHP vulnerabilities patched
• Node.js: October 2026 Security Releases