-
Am 21. Oktober 2026 veröffentlicht das PHP-Projekt ein außerplanmäßiges Sicherheitsupdate gegen zwei kritische Lücken, die unter dem Namen „PHP2Shell“ die Runde machen. Betroffen ist nicht WordPress, nicht ein Plugin, sondern PHP selbst, die Sprache, in der rund drei Viertel aller Websites laufen. Ein Angreifer kann darüber ohne Anmeldung eigenen Code auf dem Webserver ausführen. Dieser Beitrag erklärt, was dahintersteckt, wer betroffen ist und was Sie als Betreiber einer Website jetzt tun sollten.
Was ist passiert?
Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und sind mit 9,2 von 10 Punkten (CVSS v4.0) als kritisch eingestuft. Sie stecken in der Session-Verwaltung von PHP, genauer in der Funktion, mit der PHP den Fortschritt von Datei-Uploads in der Sitzung mitschreibt. Ein speziell präparierter Upload bringt den PHP-Prozess dazu, bereits freigegebenen Speicher weiterzuverwenden, ein sogenannter Use-after-free. Daraus lässt sich die Ausführung beliebigen Codes bauen, und zwar ohne Benutzerkonto, ohne Passwort, von außen.
Ungewöhnlich ist der Ablauf: Das PHP-Sicherheitsteam hatte den Fix unter Verschluss vorbereitet und am 20. Oktober nur angekündigt, dass am 21. Oktober um 14:00 UTC (16:00 Uhr deutscher Zeit) ein Update erscheint. Noch vor der Veröffentlichung sind Details durchgesickert, und ein Proof-of-Concept-Werkzeug namens „PHP2Shell“ kursiert bereits. Ein Sicherheitsforscher hat beide Fehler nach eigenen Angaben nachgestellt. Bestätigte Angriffe in freier Wildbahn gab es bis zum 20. Oktober nicht, aber es ist damit zu rechnen, dass Massenscans unmittelbar nach dem Erscheinen des Patches beginnen. Denn ab dann lässt sich aus dem Unterschied zwischen alter und neuer Version die genaue Angriffsstelle ablesen.
Wer ist betroffen?
Praktisch jede Website, die mit PHP läuft, also WordPress, Joomla, TYPO3, Shopware, Nextcloud, Laravel-Anwendungen und unzählige Eigenentwicklungen. Die Lücke liegt unterhalb der Anwendung, deshalb schützt ein aktuelles WordPress oder ein gepflegtes Plugin nicht davor. Nach aktuellem Stand sind alle unterstützten PHP-Zweige betroffen, also 8.2, 8.3, 8.4 und 8.5; die offizielle Liste der betroffenen und der korrigierten Versionen veröffentlicht das PHP-Projekt mit dem Update.
Entscheidend ist dabei weniger, welche Anwendung Sie betreiben, als wo: Die Lücke wird auf dem Server geschlossen, nicht in Ihrer Website. Auf gemeinsam genutzten Hostingservern kommt hinzu, dass eine kompromittierte Nachbarseite je nach Konfiguration auch andere Kunden auf demselben Server gefährden kann. Die Frage, die Sie sich stellen sollten, lautet also: Wer betreibt meinen Server, und kümmert der sich darum?
Was Sie als Website-Betreiber jetzt tun sollten
Die eigentliche Lösung ist das PHP-Update. Alles andere ist Überbrückung. In dieser Reihenfolge:
- PHP-Version prüfen. In WordPress unter Werkzeuge → Website-Zustand → Bericht → Server, bei anderen Systemen im Hosting-Panel. Steht dort eine 7.x oder 8.0/8.1, ist das schon vor dieser Lücke ein Problem, dazu unten mehr.
- Beim Hoster nachfragen, wann das Sicherheitsupdate eingespielt wird und ob bis dahin die Notlösung aus dem nächsten Abschnitt aktiv ist. Ein Hoster, der auf diese Frage keine Antwort hat, ist ein Risiko.
- Nach dem Update kontrollieren, dass tatsächlich die korrigierte Version läuft. Die fixen Versionsnummern nennt das PHP-Projekt mit dem Release. Bei eigenem Server: Pakete aktualisieren und PHP-FPM bzw. den Webserver neu starten, sonst laufen die alten Prozesse weiter.
- Backup und Anwendungsupdates wie immer: aktuelle Sicherung, WordPress-Core, Plugins und Themes auf Stand. Das schließt diese Lücke nicht, verkleinert aber die Angriffsfläche insgesamt.
Was nicht hilft: ein Sicherheits-Plugin in WordPress, eine Firewall-Regel, die PHP-Sessions oder Formular-Uploads pauschal sperrt (damit funktionieren weder Logins noch Kontaktformulare), oder das Abwarten, ob „schon nichts passieren wird“. Mit einem öffentlich verfügbaren Exploit-Werkzeug ist die Frage nicht ob, sondern wann automatisierte Scanner Ihre Seite erreichen.
Die Notlösung bis zum Patch
Die verdächtige Funktion, die Upload-Fortschrittsanzeige in der Session, nutzt kaum eine Anwendung, WordPress nicht, die gängigen Shop- und CMS-Systeme ebenfalls nicht. Sie lässt sich deshalb gefahrlos abschalten. Die Einstellung lautet:
session.upload_progress.enabled = 0Sie gehört in die php.ini des Servers oder in die Konfiguration des PHP-FPM-Pools; danach muss PHP-FPM bzw. der Webserver neu gestartet werden, damit die laufenden Prozesse den Wert übernehmen. Auf Shared Hosting kann das nur der Hoster tun. Ob die Einstellung greift, zeigt eine phpinfo()-Seite im Webverzeichnis (danach wieder löschen); die Ausgabe von
php -iauf der Kommandozeile ist dafür nicht aussagekräftig, weil sie die Konfiguration des Kommandozeilen-PHP zeigt, nicht die des Webservers.Zwei Einschränkungen sind wichtig. Die oft empfohlene Zeile
php_flag session.upload_progress.enabled offin der .htaccess funktioniert nur, wenn PHP als Apache-Modul läuft; bei den heute üblichen FastCGI- und FPM-Setups erzeugt sie einen Serverfehler 500. Und: Der Schalter deckt nach Angaben des Forschers, der die Fehler nachgestellt hat, nur eine der beiden Lücken ab. Die zweite sitzt in der Verarbeitung von Multipart-Uploads und lässt sich so nicht entschärfen. Die Notlösung senkt das Risiko, sie beseitigt es nicht.Warum alte PHP-Versionen jetzt zum echten Risiko werden
Das Update erscheint nur für die Zweige, die das PHP-Projekt noch pflegt. PHP 7.4 ist seit Ende 2022 ohne Sicherheitsupdates, 8.0 seit Ende 2023, 8.1 seit Ende 2025. Websites auf diesen Versionen bleiben dauerhaft angreifbar, nicht nur gegen PHP2Shell, sondern gegen jede Lücke, die seither gefunden wurde. Bisher war das ein abstraktes Risiko, das viele Betreiber ausgesessen haben, weil die Seite ja läuft. Mit einem frei verfügbaren Exploit für eine Lücke, die ohne Anmeldung Code ausführt, ist es ein konkretes.
Der häufigste Grund für alte PHP-Versionen sind alte Themes und Plugins, die mit PHP 8 nicht mehr laufen. Das ist ärgerlich, aber lösbar: Theme wechseln, Plugin ersetzen oder die Seite neu aufsetzen. Was nicht lösbar ist, ist ein kompromittierter Server, von dem aus Spam verschickt, Kundendaten abgezogen oder Besucher auf Betrugsseiten umgeleitet werden. Wer heute noch auf PHP 7 oder 8.0/8.1 ist, hat mit diesem Vorfall den Anlass, das Thema nicht weiter zu verschieben.
Fazit
PHP2Shell ist kein WordPress-Problem und keines, das Sie mit einem Plugin lösen. Es ist ein Server-Thema: PHP abschalten, was nicht gebraucht wird, Update einspielen, sobald es da ist, und danach prüfen, dass es wirklich läuft. Wer seinen Hoster fragt und eine klare Antwort bekommt, ist auf der sicheren Seite. Wer keine bekommt, sollte das als Antwort verstehen.
Quellen
