Neue PHP-Sicherheitslücke zwei Tage nach PHP2Shell: Was WordPress-Agenturen wissen sollten

Zwei Tage nach der Behebung der PHP2Shell-Sicherheitslücke veröffentlichte das PHP-Team eine neue Warnung zu demselben Teil von PHP. Diesmal ist das Risiko deutlich geringer, und es gibt keinen Notfall-Patch. Hier erfahren Sie, worin der Unterschied besteht, was dies für WordPress-Seiten bedeutet und was zu tun ist.

TL;DR

Am 23. Oktober 2026 veröffentlichte PHP einen Informationshinweis zu einer neuen Sicherheitslücke ( CVE-2026-115560) in einer PHP-Funktion namens „session upload progress“.
Dadurch kann ein Angreifer Code auf einem Server ausführen, allerdings nur in einer ungewöhnlichen Konfiguration, die PHP in der Praxis als unwahrscheinlich einstuft. PHP wird das Problem in der nächsten regulären Version beheben, jedoch nicht durch ein Notfall-Update.
Die PHP-Updates vom 21. Oktober, mit denen PHP2Shell behoben wurde, beheben dieses neue Problem nicht.
PHP empfiehlt folgende Einstellung: session.upload_progress.enabled=0. Wenn Sie diese Einstellung bereits für PHP2Shell vorgenommen haben, müssen Sie nichts weiter tun.
Die höhere Priorität hat nach wie vor PHP2Shell: Es muss sichergestellt werden, dass jede Website tatsächlich eine bestimmte PHP-Version verwendet.

Was PHP angekündigt hat

Am 21. Oktober veröffentlichte PHP Notfall-Updates für PHP2Shell, zwei kritische Sicherheitslücken in PHP selbst. Falls Sie dies verpasst haben sollten: In unserem PHP2Shell-Leitfaden erfahren Sie, was passiert ist und was zu tun ist.

Am 23. Oktober veröffentlichte PHP eine neue Meldung zu CVE-2026-115560. Ähnlich wie bei einer der PHP2Shell-Sicherheitslücken (CVE-2026-109619) betrifft diese Schwachstelle den Fortschritt beim Hochladen von Dateien. Diese PHP-Funktion ermöglicht es einer Website, während des Hochladens einer Datei einen Fortschrittsbalken anzuzeigen.

Die neue Sicherheitslücke kann zudem zur Ausführung von Remote-Code führen, was bedeutet, dass ein Angreifer eigene Befehle auf dem Server ausführen kann. Der große Unterschied besteht darin, wie schwer es ist, diese Sicherheitslücke auszulösen.

Warum dieses Produkt ein geringeres Risiko birgt

PHP2Shell konnte auf einem normalen Server mit einer einzigen Anfrage ausgelöst werden, noch bevor überhaupt Website-Code ausgeführt wurde. Die neue Sicherheitslücke erfordert eine ganz bestimmte Kombination aus Einstellungen und Code. Laut PHP müssen alle folgenden Bedingungen gleichzeitig erfüllt sein:

In den PHP-Einstellungen des Servers ist „session.serialize_handler“ (die Art und Weise, wie PHP Sitzungsdaten speichert) auf „php_binary“ oder „php_serialize“ gesetzt.
Der Code der Website schaltet diese Einstellung während des Betriebs der Website mithilfe von `ini_set()` auf PHP um.
Dies geschieht, bevor die Sitzung mit `session_start()` gestartet wird.
Der Fortschritt beim Hochladen der Sitzung ist weiterhin aktiviert.

Wenn eine Website während ihres Betriebs die Art und Weise, wie Sitzungsdaten gespeichert werden, nie ändert, ist sie von diesem Problem nicht betroffen. Aus diesem Grund wird das Problem von PHP im Rahmen des regulären Release-Zyklus behoben und nicht durch ein Notfall-Update.

Zum Zeitpunkt der Erstellung dieses Artikels wurden noch keine Angriffe gemeldet, bei denen diese Schwachstelle ausgenutzt wurde. Die seit dem 21. Oktober beobachteten Angriffe richteten sich gegen die PHP2Shell-Schwachstellen.

Was das für WordPress bedeutet

Der WordPress-Kern nutzt keine PHP-Sitzungen, daher ändert er niemals die Art und Weise, wie Sitzungsdaten gespeichert werden. Damit eine WordPress-Website gefährdet ist, müsste ein Plugin, ein Theme oder ein Stück benutzerdefinierter Code PHP-Sitzungen nutzen und die Sitzungseinstellungen während des Betriebs der Website ändern – genau wie oben beschrieben. Das kommt selten vor.

„Selten“ ist jedoch nicht gleichbedeutend mit „unmöglich“, insbesondere auf Websites mit älteren Plugins oder benutzerdefiniertem Code, den Sie nicht selbst geschrieben haben. Deshalb lohnt es sich nach wie vor, die empfohlene Einstellung für PHP anzuwenden.

Was WordPress-Agenturen tun sollten

1. Führe zunächst deine PHP2Shell-Prüfungen durch

PHP2Shell stellt das größere Risiko dar, und es wurden bereits Angriffe gemeldet. Stellen Sie sicher, dass auf jeder Website eine der gepatchten Versionen läuft: PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 – oder eine Version, die Ihr Hosting-Anbieter gepatcht hat.

2. Fortschritt beim Hochladen der Sitzung deaktivieren

PHP empfiehlt, „session.upload_progress.enabled=0“ bis zur nächsten regulären Version beizubehalten. Der WordPress-Kern nutzt diese Funktion nicht, daher führt das Deaktivieren selten zu Problemen. Falls Sie dies bereits wegen PHP2Shell getan haben, behalten Sie diese Einstellung bei.

Es kommt darauf an, wie Sie die Einstellung vornehmen. Laut der PHP-Sicherheitsempfehlung vom 21. Oktober sollte die Einstellung in der Datei „php.ini“, im PHP-FPM-Pool oder in der Serverkonfiguration vorgenommen werden, woraufhin jeder PHP-Worker neu gestartet werden muss. Sie sollte nicht über den Code der Website mit „ini_set()“ oder in einer „.user.ini“-Datei unter PHP-FPM festgelegt werden, da diese Änderungen zu spät wirksam werden.

Bei den meisten Hosting-Paketen müssen Sie Ihren Hosting-Anbieter darum bitten, dies zu erledigen.

3. Überprüfen Sie Ihren benutzerdefinierten Code

Falls Ihr Team benutzerdefinierte Plugins oder Themes entwickelt, suchen Sie darin nach Code, der die Einstellung „session.serialize_handler“ ändert, zum Beispiel „ini_set(‘session.serialize_handler’, …)“. Wenn Sie solchen Code finden, weist diese Website einen Teil der risikobehafteten Konfiguration auf; stellen Sie daher sicher, dass der Upload-Fortschrittsbalken für Sitzungen dort deaktiviert ist.

4. Planen Sie Ihre Upgrades auf PHP 8.2

PHP 8.2 hat den PHP2Shell-Patch erhalten, doch PHP hat bestätigt, dass die Lebensdauer dieser Version am 31. Dezember 2026 endet. Nach diesem Datum werden keine Sicherheitspatches mehr bereitgestellt, auch nicht für Probleme wie dieses. Falls einige Kundenwebsites noch mit PHP 8.2 laufen, ist jetzt ein guter Zeitpunkt, um die Umstellung auf PHP 8.3 oder höher zu planen. WordPress.org listet die empfohlenen PHP-Versionen auf.

5. Achten Sie weiterhin auf Anzeichen eines Angriffs

Angriffe auf PHP2Shell könnten noch eine Weile andauern, insbesondere auf Server, die noch nicht aktualisiert wurden. Achten Sie auf neue Admin-Benutzer, die Sie nicht angelegt haben, und auf PHP-Dateien, die Sie nicht kennen.

Abschließende Überlegungen

Nach einer Woche wie dieser neigt man leicht dazu, jede neue PHP-Warnmeldung als weiteren Notfall zu betrachten. Das ist hier jedoch nicht der Fall. PHP hat klar dargelegt, wer davon betroffen ist, eine einfache Einstellung zum Blockieren bereitgestellt und beschlossen, das Problem im Rahmen des normalen Zeitplans zu beheben.

Für die meisten WordPress-Agenturen dient diese Empfehlung in erster Linie als Erinnerung daran, das zu Ende zu bringen, was PHP2Shell angestoßen hat: zu überprüfen, ob jede Website eine feste PHP-Version verwendet, sicherzustellen, dass der Upload-Fortschritt in der Sitzung deaktiviert ist, und die Umstellung von PHP 8.2 noch vor Jahresende zu planen.