PHP2Shell: Was die PHP-Sicherheitslücke ist und wie Sie sie schließen

Die PHP-Sicherheitslücke PHP2Shell besteht aus zwei kritischen Fehlern in PHP selbst, geführt als CVE-2026-109618 und CVE-2026-109619. Über sie kann ein Angreifer ohne Login Code auf jedem Server ausführen, der PHP-Seiten ausliefert. Abhilfe schafft ein PHP-Update: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder das gepatchte Paket Ihrer Distribution, danach ein Neustart aller PHP-Worker.

Die Details sickerten am 20. Oktober durch, zwei Tage vor der geplanten Veröffentlichung. Das PHP-Projekt zog die Fixes daraufhin um einen Tag vor und lieferte sie am 21. Oktober aus. Wenn bei Ihnen irgendetwas auf PHP läuft (WordPress, WooCommerce, TYPO3, Shopware, Drupal, Magento, Laravel, ein Hosting-Panel), prüfen Sie Ihre Version noch heute.

Was ist die PHP-Sicherheitslücke PHP2Shell?

PHP2Shell ist der Name, den Forscher zwei Remote-Code-Execution-Lücken in der PHP-Laufzeitumgebung gegeben haben. Gemeldet wurden sie von Forschern bei Calif, Wiz, OpenAI und Quarkslab. PHP bewertet beide mit 9.2 nach CVSS v4.0.

Die Fehler sitzen dort, wo PHP eine eingehende Anfrage parst, also bevor Ihr Anwendungscode überhaupt startet. Ein Update von WordPress, einem Plugin oder Ihrem Framework ändert daran nichts. Das PHP-Binary selbst muss ausgetauscht werden.

Das Advisory von PHP nennt jedes Setup, das Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht es bei Apache mit mod_php. Dort gibt es einen nachgewiesenen Exploit, bei dem eine einzige Anfrage ohne Authentifizierung den Angriff auslöst, bevor irgendein Anwendungscode läuft. Außerdem beschreibt das Advisory RCE über die Funktion Session Upload Progress unter PHP-FPM, sofern die Anwendung die passenden Bedingungen bietet.

Welche PHP-Versionen sind betroffen?

Alles vor den vier gepatchten Releases. So steht es im Advisory von PHP und in den Sicherheits-Releases vom 21. Oktober:

Cloudflare und Imperva zufolge reichen die Fehler bis PHP 5.4 zurück. Das PHP-Advisory führt alle Versionen unterhalb der gepatchten Releases als betroffen, nennt aber keine erste betroffene Version.

Eine alt wirkende Versionsnummer kann trotzdem gepatcht sein. Linux-Distributionen portieren Fixes zurück und behalten die alte Upstream-Nummer. Ubuntu 24.04 liefert den Fix als 8.3.6-0ubuntu0.24.04.13 aus, das meldet weiterhin 8.3.6. Debian 12 hat 8.2.35-1~deb12u1 (DLA-4848-1), Debian 13 8.4.27-1~deb13u1 (DSA-6574-1). Vergleichen Sie die vollständige Paketversion mit dem Security-Tracker Ihrer Distribution, nicht nur die ersten drei Zahlen.

Wird PHP2Shell bereits ausgenutzt?

Die Berichte widersprechen sich, und die Lage ändert sich stündlich. Was die Quellen gemeldet haben, in zeitlicher Reihenfolge:

• 17. Oktober: Amazon registrierte auf seinen MadPot-Honeypots einen Exploit-Versuch gegen PHP2Shell, vier Tage vor den Patches. Die Anfrage kam von einer IP-Adresse, die zu einem kommerziellen Anonymisierungsdienst gehört.
• 20. Oktober: Die Details tauchten im Netz auf. watchTowr bestätigte, dass die Fehler echt sind. Huntress hatte nach eigenen Angaben keine Ausnutzung gesehen und kannte keinen öffentlichen Exploit-Code.
• 21. Oktober, 03:02 UTC: Cloudflare schaltete WAF-Regeln für PHP2Shell scharf. Später schrieb das Unternehmen, es habe Angriffstraffic gegen seine Kunden gesehen, und die Angreifer hätten den Payload abgewandelt, um die Regeln zu umgehen.
• 21. Oktober, 14:00 UTC: PHP veröffentlichte die Fixes. watchTowr meldete noch am selben Tag Ausnutzung beider Fehler in seinem Honeypot-Netz.
• 21. Oktober, nachmittags (US-Zeit): Der Executive Director der PHP Foundation sagte gegenüber CNBC, es gebe keine Belege für funktionierende Exploits, nur „unvollständige, fehlgeleitete und nicht funktionierende generierte". Imperva sah bei seiner eigenen Überwachung vor der Veröffentlichung keinen passenden Traffic.
• 23. Oktober: Keine der beiden CVEs steht bislang im Known Exploited Vulnerabilities Catalog der CISA (letzte Aktualisierung am 21. Oktober).

Die Forscher haben funktionierende Exploits gebaut, und andere Teams geben an, die Fehler nachgestellt zu haben. Gehen Sie davon aus, dass Angreifer das ebenfalls können. Jeder ungepatchte PHP-Server, der aus dem Internet erreichbar ist, gilt damit als angreifbar.

So prüfen Sie Ihre PHP-Version

Entscheidend ist das PHP, das Webanfragen bedient. Auf vielen Servern ist das PHP auf der Kommandozeile ein anderer Build als das hinter der Website.

Auf dem Server:

php -v                     # command line PHP
php-fpm8.3 -v              # the FPM build (the name varies: php-fpm, php-fpm8.4)
apachectl -M | grep php    # a php_module line means Apache runs PHP as mod_php
dpkg -l | grep php         # Debian/Ubuntu: the full package versions
rpm -qa | grep php         # RHEL, Rocky, Alma, Fedora

Im Browser: Legen Sie eine Datei info.php mit dem Inhalt <?php phpinfo(); in Ihr Web-Root, rufen Sie sie auf und lesen Sie oben die Version und die Zeile Server API ab (sie zeigt FPM, Apache 2.0 Handler oder CGI). Löschen Sie die Datei gleich danach, denn sie legt Ihre komplette Konfiguration offen.

In WordPress: Gehen Sie zu Werkzeuge > Website-Zustand > Bericht und öffnen Sie Server. Die Zeile PHP-Version zeigt die Version, mit der Ihre Website läuft.

Im Hosting-Panel: cPanel zeigt sie unter MultiPHP Manager oder Select PHP Version, Plesk in den PHP-Einstellungen der Domain. Bei IONOS, Strato oder ALL-INKL finden Sie die PHP-Version im Kundenbereich des Hosters, bei den meisten Managed-Hostern auf der Übersichtsseite der Website.

In Docker: docker exec <container> php -v meldet das PHP im laufenden Container, und nur das zählt.

Für einen Test von außen hat Searchlight Cyber laut Help Net Security einen Open-Source-Checker veröffentlicht, php2shell-scanner. Setzen Sie ihn nur gegen Hosts ein, die Ihnen gehören.

So schließen Sie die PHP-Sicherheitslücke

Für jeden Stack gilt dieselbe Reihenfolge: zuerst die Server, die aus dem Internet erreichbar sind, danach jeden PHP-Prozess neu starten. Ein gepatchtes Binary auf der Platte bringt nichts, solange alte Worker weiter Anfragen bedienen.

Debian und Ubuntu

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # match your version
sudo systemctl restart apache2      # if you use mod_php

Prüfen Sie danach mit dpkg -l | grep php die Paketversionen gegen den Security-Tracker von Debian oder Ubuntu. Unter Ubuntu 20.04 und älter kommen die gepatchten 7.x-Pakete über Ubuntu Pro. Drittanbieter-Repositories aktualisieren nach eigenem Zeitplan: Laut Help Net Security hatte rpms.remirepo.net am Tag des Releases noch kein Update. Prüfen Sie also, ob Ihr Repository nachgezogen hat, bevor Sie sich darauf verlassen.

RHEL, Rocky, AlmaLinux und Fedora

Führen Sie sudo dnf upgrade 'php*' aus und starten Sie danach php-fpm und httpd neu. Die gepatchte Paketversion steht im Advisory Ihres Anbieters, denn sie weicht von der Upstream-Nummer ab.

Docker-Images

Die offiziellen php-Images auf Docker Hub haben am 21. Oktober die Tags 8.5.12, 8.4.27, 8.3.36 und 8.2.35 bekommen. Pinnen Sie einen davon, bauen Sie neu und deployen Sie:

FROM php:8.4.27-fpm

docker compose build --pull && docker compose up -d

Ein laufender Container behält sein altes PHP, bis Sie ihn ersetzen. Images, die auf php aufbauen (auch wordpress), brauchen ebenfalls einen frischen Pull und ein neues Deployment.

Shared Hosting, cPanel und Plesk

Hier können Sie PHP nicht selbst patchen. Der Hoster aktualisiert die PHP-Builds, die das Panel anbietet (auf den meisten cPanel-Servern ea-php aus EasyApache oder alt-php von CloudLinux). Das gilt genauso für Server mit Plesk, das in Deutschland neben cPanel weit verbreitet ist, und für Hoster wie IONOS, Strato oder ALL-INKL, bei denen Sie die PHP-Version im Kundenbereich auswählen. Sehen Sie auf der Statusseite des Hosters nach oder fragen Sie beim Support, ob seine PHP-Builds die Fixes für CVE-2026-109618 und CVE-2026-109619 enthalten. Läuft Ihre Website noch auf 7.4 oder 8.1, stellen Sie sie im MultiPHP Manager, unter Select PHP Version oder im Kundenbereich auf 8.3 oder neuer um, am besten nach einem Test auf einer Staging-Kopie.

Managed WordPress Hosting

Ihr Hoster patcht PHP für Sie. Laut WordPress.org ist für diese Fehler kein WordPress-Update nötig oder geplant. Lassen Sie sich bestätigen, dass der Hoster den Fix ausgerollt hat, und prüfen Sie dann Website-Zustand > Bericht > Server. Läuft die Website auf PHP 8.1 oder älter, ziehen Sie sie hoch, denn diese Zweige bekommen nur noch Backports von Anbietern.

Windows und selbst kompilierte Builds

Gepatchte Quellen und Windows-Binaries liegen auf der Download-Seite von php.net. Für 7.4, 8.0 und 8.1 hat PHP minimale Quellcode-Backports für alle veröffentlicht, die PHP selbst bauen.

Wenn Sie heute nicht patchen können

PHP ist da unmissverständlich: Nur ein Update behebt die PHP-Lücke vollständig. Das Advisory nennt Einstellungen, die bestimmte Angriffswege versperren, einen Server aber nicht sicher machen:

• Setzen Sie session.upload_progress.enabled=0 in der php.ini, im FPM-Pool oder in der Serverkonfiguration (nicht per ini_set() oder .user.ini) und starten Sie danach jeden Worker neu. Das schließt die bestätigten Wege über Sessions.
• Unter PHP 8.5 setzen Sie fatal_error_backtraces=0 und starten jeden Worker neu.
• Setzen Sie memory_limit=-1 so, dass Anwendungen es nicht überschreiben können, etwa per php_admin_value. Kombinieren Sie das mit einem niedrigen post_max_size (8M ohne Uploads, 32M mit) und einem Speicherlimit für Container oder cgroup. Verwenden Sie nicht RLIMIT_AS oder RLIMIT_DATA, die den Fehler auslösen können.
• Begrenzen Sie am Webserver oder Proxy die Größe der Anfragen, die Zahl der Felder und Multipart-Teile sowie die Verschachtelungstiefe. Nimmt die Website nie Uploads an, weisen Sie Multipart-Anfragen ganz ab.

Testen Sie jede Änderung, bevor Sie sie ausrollen, denn manche legen Uploads lahm. Lässt sich ein Server nicht rechtzeitig patchen oder absichern, raten das britische NCSC und WordPress.org, ihn vom Netz zu nehmen oder hinter ein VPN oder eine Allowlist zu stellen, damit ihn nur bekannte Adressen erreichen.

Weniger Angriffsfläche, solange Sie patchen

Nichts davon hält einen Scanner davon ab, Anfragen zu schicken. Die Massenausnutzung einer frischen Lücke läuft automatisiert: Skripte durchkämmen das Internet nach PHP-Servern und feuern den Exploit auf jeden einzelnen ab. Diese Scanner laufen meist auf gemieteten Servern in Hosting- und Rechenzentrumsnetzen oder leiten ihren Traffic über VPNs, Proxys und Tor. Amazons erste Sichtung kam von einem Anonymisierungsdienst. Echte Besucher surfen selten aus einem Rechenzentrum.

Daraus ergibt sich eine zweite Schutzschicht für die Tage, die das Patchen aller Systeme dauert: Anfragen aus diesen Netzen abweisen, bevor sie PHP erreichen. IPScanner erkennt PHP2Shell nicht und repariert PHP nicht. Es prüft, wer sich verbindet, ordnet jeden Besucher einer Klasse zu (Mensch, verifizierter Crawler, bösartige Automatisierung, Hosting, Tor, VPN, Proxy und einige mehr) und blockiert die Klassen, die Sie auswählen.

Die Prüfung muss vor PHP laufen. PHP2Shell schlägt zu, während PHP die Anfrage parst. Alles, was innerhalb von PHP läuft, setzt zu spät ein.

Das WordPress-Plugin und die Prüfungen für WooCommerce stoppen Fake-Registrierungen, Spam und Card Testing an Ihren Formularen. Für PHP2Shell sind sie die falsche Ebene. Eine WordPress-Website auf einem einzelnen Apache-Server ohne vorgeschaltete Komponente kommt am schnellsten zu einem Gate, wenn Cloudflare mit dem Worker davor sitzt.

Erst Monitor-Modus, dann blockieren. Der Monitor-Modus protokolliert jedes Urteil und blockiert nichts. So sehen Sie, wer Ihre PHP-Endpunkte aufruft, bevor Sie etwas ändern. Stellen Sie nach ein paar Stunden Hosting, Tor und bösartige Automatisierung auf Blockieren. VPN und Proxy sind Abwägungssache: auf einem Admin-Panel blockieren, bei einem öffentlichen Shop lieber zweimal überlegen. Verifizierte Suchmaschinen und KI-Crawler aus dem Crawler-Verzeichnis kommen immer durch.

Blockieren setzt den Starter-Plan voraus. Im Free-Plan läuft eine Website ausschließlich im Monitor-Modus. Neue Konten erhalten sieben Tage lang die Starter-Funktionen ohne Kreditkarte, das deckt ein Patch-Fenster ab. Details unter Preise.

Die Grenzen, klar benannt:

• Ein Angreifer an einem privaten Internetanschluss oder hinter einem Residential Proxy, den die Prüfungen übersehen, erreicht PHP trotzdem.
• Die Gates sind fail-open. Ist die IPScanner-API langsam oder nicht erreichbar, gehen Anfragen durch, die Website bleibt also online.
• Ein Gate hilft nur, wenn der Traffic auch hindurchläuft. Antwortet Ihr Ursprungsserver auf seiner öffentlichen IP, umgeht ein Scanner Cloudflare komplett. Lassen Sie den Ursprungsserver deshalb nur Verbindungen aus den IP-Bereichen von Cloudflare annehmen.

Liegt Ihre Website hinter Cloudflare, lassen Sie zusätzlich die verwalteten WAF-Regeln eingeschaltet. Laut Cloudflare laufen die PHP2Shell-Regeln seit dem 21. Oktober standardmäßig in jedem Tarif. Diese Regeln untersuchen die Anfrage selbst, IPScanner prüft, wer sie geschickt hat. Keins von beidem ersetzt den Patch.

Prüfen, ob jemand eingedrungen ist

Stand ein Server seit Mitte Oktober mit offener PHP-Lücke im Netz, sehen Sie genau hin, bevor Sie zum nächsten Punkt übergehen. Advisories und Incident Responder nennen dieselben Anzeichen:

• große oder tief verschachtelte Multipart-POST-Anfragen an .php-Pfade, oft mit PHP_SESSION_UPLOAD_PROGRESS im Body
• Fehlermeldungen „Allowed memory size exhausted" und gehäuft abgestürzte oder neu gestartete PHP-Worker in den Error-Logs
• neue oder geänderte Dateien im Web-Root, neue Cronjobs oder Benutzerkonten
• PHP- oder Webserver-Prozesse, die Shells starten oder ausgehende Verbindungen aufbauen, die Sie nicht zuordnen können

Bei Verdacht auf eine Kompromittierung isolieren Sie den Server und sichern die Logs, bevor Sie irgendetwas neu starten. Tauschen Sie danach jedes Geheimnis aus, das PHP lesen konnte: Datenbankpasswörter, API-Schlüssel, Session-Schlüssel.

PHP2Shell-Checkliste

1. Jede PHP-Installation erfassen, die aus dem Internet erreichbaren zuerst, inklusive Hosting-Panels, Appliances und Container.
2. Die Version ermitteln, die Webanfragen bedient (phpinfo, Website-Zustand, php-fpm -v), nicht nur php -v.
3. 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder das gepatchte Paket der Distribution installieren.
4. Jeden PHP-FPM-Pool, Apache und LiteSpeed-Worker neu starten; Container neu bauen und neu deployen.
5. Auf 8.1 oder älter einen Backport eines Anbieters besorgen oder upgraden. Geht beides nicht, die Website vom Netz nehmen oder per Allowlist abschotten.
6. Noch kein Patch möglich? Die Übergangseinstellungen von PHP setzen und den Zugriff einschränken.
7. Ein Gate vor PHP setzen (Cloudflare, Traefik, Caddy, nginx), erst im Monitor-Modus, dann Hosting, Tor und bösartige Automatisierung blockieren.
8. Den Ursprungsserver auf den vorgeschalteten Proxy beschränken.
9. Die Logs ab dem 17. Oktober nach den oben genannten Anzeichen durchsuchen.
10. Auf jedem Server, der ungepatcht erreichbar war, die Geheimnisse austauschen.

Quellen: PHP Security Advisory, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, WordPress.org, Cloudflare, watchTowr FAQ, watchTowr, Help Net Security, SecurityWeek, The Hacker News, CNBC, Imperva, Qualys, Armis, Ubuntu, Debian.