php2shell: Zwei kritische PHP-Lücken – was Website-Betreiber jetzt tun müssen

Stand: 22. Oktober 2026

Am 21. Oktober hat das PHP-Projekt Updates für zwei kritische Sicherheitslücken veröffentlicht. Unter dem Namen php2shell ermöglichen sie, aus der Ferne Code auf einem Webserver auszuführen, ganz ohne Anmeldung. Betroffen sind laut PHP-Team alle Versionen seit PHP 5. Das trifft damit fast jede WordPress-, Laravel- oder Shop-Installation.

Was ist passiert?

Entdeckt hat die Lücken das Forschungsteam Calif gemeinsam mit dem PHP Ecosystem Security Team. Das Code-Audit wurde von OpenAI im Rahmen von „Patch the Planet" gefördert. Eigentlich sollte die Veröffentlichung später erfolgen, wegen eines Leaks wurde sie um einen Tag vorgezogen.

Bei CVE-2026-109618 genügen ein präpariertes Upload-Formular oder stark verschachtelte Arrays. Die Aufräumarbeiten nach dem Speicherfehler geraten durcheinander, Angreifer können Speicher auslesen und freigeben und am Ende Code im Kontext des Webservers ausführen. Bei CVE-2026-109619 erzeugt die erste Anfrage einen instabilen Zustand, die zweite nutzt ihn aus. Nicht jeder fatale Fehler lässt sich so missbrauchen.

Wie gefährlich ist das wirklich?

• Keine Anmeldung nötig. Jede erreichbare PHP-Seite ist ein Ziel.
• Aufwendig, aber automatisierbar. Ein Angriff braucht einige tausend bis zehntausend Anfragen. Für Bots ist das kein Hindernis. Die Entdecker haben die Ausführung von Systembefehlen auf einem Laravel-Server gezeigt.
• Betroffen sind mod_php, PHP-FPM und LSAPI. Bei FrankenPHP ist die Lage laut heise unklar.
• Ausnutzung bisher nicht bekannt, wird aber bald erwartet. Heise rechnet mit funktionierenden Exploits binnen Stunden bis spätestens einem Tag. Ein kursierender Proof of Concept zielt nur auf LiteSpeed (lsphp8) und ließ sich in einer Laborumgebung nicht nachstellen. Darauf sollte sich niemand verlassen.

Auch Geräte mit PHP-Oberfläche sind ein Thema: NAS, Router und Appliances. Genannt werden unter anderem pfSense, OPNsense, QNAP, Synology, DrayTek, Netgear, TP-Link, Citrix, Palo Alto, Ivanti und F5. Ihre Weboberflächen gehören nicht ins Internet und sollten auf Herstellerupdates geprüft werden.

Welche Versionen sind gepatcht?

Wer noch auf einer älteren Version läuft, sollte nicht auf einen Backport warten, sondern mindestens auf PHP 8.3 wechseln.

Was Sie jetzt tun sollten

1. PHP aktualisieren. Das ist der einzige vollständige Schutz. Bei Linux-Servern über die Distribution, sobald das Paket da ist.
2. Docker-Container neu bauen oder neu ziehen. Ein docker pull allein hilft nicht, wenn das Image noch nicht neu gebaut wurde. Prüfen Sie mit php -v im laufenden Container, welche Version tatsächlich läuft. Bei Kubernetes zusätzlich den Rollout neu starten und imagePullPolicy beachten, sonst bleibt der alte Stand im Cache.
3. Übergangsweise absichern, falls noch kein Patch verfügbar ist:Das PHP-Team bezeichnet das ausdrücklich nur als Notlösung.
   • Speicherlimit, maximale POST-Größe und Verschachtelungstiefe (max_input_nesting_level) restriktiv setzen
   • Upload-Fortschritt abschalten (laut heise allein keine Lösung)
   • Anfragelimit pro FPM-Worker setzen, Fehler-Backtraces und Versionsangaben ausblenden
   • SELinux oder AppArmor aktiv lassen
   • WAF-Regeln nutzen, Cloudflare hat welche bereitgestellt
4. Seiten im Zweifel vom Netz nehmen, wenn kein Update verfügbar ist und die Seite nicht gebraucht wird. Einzelne Hoster haben PHP-Dienste vorübergehend abgeschaltet, Uberspace zum Beispiel.
5. Logs prüfen. Auffällig sind sehr viele Anfragen auf Upload-Endpunkte oder Formulare, wiederholte PHP-Fatal-Errors wegen des Speicherlimits und Neustarts der PHP-Prozesse.
6. Nach dem Update neue Dateien und Benutzer kontrollieren, wenn die Seite zwischen Veröffentlichung und Patch erreichbar war.

Unser Vorgehen bei FEHMER TECH

Wir betreiben unsere Kundenseiten auf einem eigenen Kubernetes-Cluster. Dort haben wir am Tag der Veröffentlichung geprüft, welche PHP-Version in jedem Container läuft, und die Images auf den jeweils neuesten verfügbaren Stand gebracht. Weil die offiziellen WordPress-Images oft einige Stunden bis Tage hinter dem PHP-Release herhinken, beobachten wir den Image-Digest automatisch und spielen das gepatchte Image ein, sobald es erscheint. Und wir prüfen danach nicht nur, ob die Seite lädt, sondern auch, welche PHP-Version wirklich ausgeliefert wird.

Wenn Sie nicht sicher sind, welche PHP-Version Ihre Website nutzt oder wer für das Update zuständig ist: Schreiben Sie uns, wir schauen es uns an.

Fazit

php2shell ist ein Update-Fall, kein Konfigurationsfall. Wer PHP selbst betreibt, patcht heute. Wer die Seite bei einem Hoster hat, fragt dort nach dem Stand. Und wer ein NAS oder einen Router mit Web-Oberfläche hat, schaut nach Herstellerupdates und macht die Oberfläche nicht öffentlich erreichbar.

Quellen: heise online, „php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP" und „Wichtige PHP-Updates am 21. Oktober beheben Codeeinschleusung-Schwachstellen".