Am 21. Oktober 2026 um 14:00 UTC hat das PHP-Team Fixes für zwei kritische Sicherheitslücken veröffentlicht, CVE-2026-109618 und CVE-2026-109619, bekannt als PHP2Shell. Wir haben etwa eine Stunde später angefangen. Gegen 17:00 UTC waren alle Server, die wir betreuen, abgesichert: 88 Projekte in unserem Support. Hier beschreiben wir, wie wir vorgegangen sind und was uns aufgehalten hat. Dieselben Hindernisse gibt es auf vielen Servern, die noch niemand gepatcht hat.
Wenn Sie nur wissen wollen, ob Ihre Website betroffen ist und was Sie Ihren Hoster fragen sollten, lesen Sie unseren ersten Beitrag zu PHP2Shell.
Die erste Stunde: den Angriffsweg überall kappen
Ein korrigiertes PHP auf Dutzenden Servern zu installieren dauert. Den verwundbaren Mechanismus abzuschalten dauert Minuten. Das haben wir deshalb zuerst gemacht, auf jedem Server, bevor wir irgendetwas gebaut haben.
Das PHP-Advisory nennt session.upload_progress.enabled als einen der Wege für CVE-2026-109619. Wir haben die Option in der zentralen PHP-Konfiguration jeder PHP-Version auf jedem Server abgeschaltet und die PHP-Worker neu gestartet. Laut Advisory zählen .user.ini und ini_set() nicht, also haben wir die Dateien auf Serverebene geändert. Unter PHP 8.5 haben wir außerdem fatal_error_backtraces abgeschaltet, wie das Advisory empfiehlt.
Damit war nur der bestätigte Session-Weg von CVE-2026-109619 zu. Für CVE-2026-109618 brauchte es das Update selbst.
Drei Arten von Servern, drei Wege zum Patch
Unsere 88 Projekte laufen auf ganz unterschiedlichen Setups, und jedes brauchte seinen eigenen Weg.
Server mit PHP aus Distributionspaketen. Hier kommt der Fix von den Paket-Maintainern. Ubuntu hat am Tag des Releases korrigierte Pakete veröffentlicht. Ein Haken für alle, die so einen Server prüfen: Nach dem Update kann php -v weiter die alte Nummer zeigen, zum Beispiel 8.3.6, weil Ubuntu das Paket patcht und die Version beibehält. Prüfen Sie stattdessen die Paketversion.
Server, die über ein Hosting-Panel laufen. Mehrere Server nutzen aaPanel, das sein eigenes PHP baut. Am Tag des Releases hatte das Panel kein aktualisiertes PHP. Auf das Panel zu warten hätte bedeutet, diese Server für unbestimmte Zeit offen zu lassen. Also haben wir PHP selbst gebaut.
Docker-Container. Einige Projekte betreiben PHP in Containern aus bestehenden Images. Eine ganze Anwendung mitten in einem Vorfall neu zu bauen und auszurollen bringt zusätzliches Risiko. Wir haben stattdessen das PHP in den laufenden Containern gepatcht und saubere Image-Rebuilds für später eingeplant.
PHP selbst bauen, ohne das Panel kaputtzumachen
Der PHP-Build eines Panels unterscheidet sich von einem Standard-Build. Wer PHP mit Standardoptionen baut und einfach einsetzt, verliert Extensions, und das Panel erkennt sein eigenes PHP nicht mehr.
Wir haben ein Build-Skript geschrieben und es auf jedem Panel-Server pro PHP-Version laufen lassen:
- es liest die genauen configure-Optionen aus dem bereits installierten PHP, damit der neue Build dieselben Extensions und Pfade hat;
- es baut die korrigierte Version aus dem offiziellen Quellcode;
- es prüft, gegen welche OpenSSL- und curl-Bibliotheken das neue Binary gelinkt ist. Das Panel linkt manche PHP-Versionen gegen eigene, ältere Kopien dieser Bibliotheken, und das Skript sorgt dafür, dass der neue Build dieselben nutzt;
- es sichert die alten Binaries, installiert die neuen und startet PHP neu;
- wenn PHP nicht wieder hochkommt, stellt es die alten Binaries selbst wieder her.
Mit dem Skript konnten wir eine PHP-Version auf einem Server patchen, die Websites prüfen und das Ganze auf dem nächsten Server wiederholen, ohne jedes Mal Handarbeit.
PHP 7.4, 8.0 und 8.1: kein offizielles Release
Für diese Zweige veröffentlicht das PHP-Team keine Releases mehr. Für PHP2Shell gab es für 7.4, 8.0 und 8.1 nur die Änderungen im Quellcode. Einige unserer Projekte laufen noch auf diesen Versionen.
Dort haben wir die Quellcode-Fixes des PHP-Teams auf das letzte Release des jeweiligen Zweigs angewendet und mit demselben Skript gebaut. Die veröffentlichten Änderungen betreffen auch Versionsdateien und Changelogs, die sich nicht sauber auf ein Release anwenden lassen. Deshalb haben wir nur die Codeänderungen übernommen.
Ein Server lief mit PHP 7.4 aus den Paketen von Ubuntu 20.04. Für dieses Ubuntu-Release kommt der Fix nur über Ubuntus erweiterte Sicherheitswartung (ESM), und die nutzt dieser Server nicht. Wir haben PHP 7.4 mit denselben Build-Flags gebaut, die Ubuntu verwendet, und nur das PHP-FPM-Binary ersetzt. Das Original liegt daneben. Ein späteres Paket-Update würde unseren Build überschreiben, das haben wir in der Projektdokumentation vermerkt.
Container: jetzt gepatcht, später neu gebaut
Für jeden Container haben wir das korrigierte PHP in einer sauberen Kopie des offiziellen Images für dasselbe Betriebssystem gebaut. Danach haben wir nur die PHP-Binaries und die benötigten Extensions in den laufenden Container kopiert, mit einem Backup der Originale im Container.
Ein Image auf Alpine-Basis brauchte dieselben zusätzlichen Quellcode-Patches, die das offizielle PHP-Docker-Image einspielt. Sonst scheiterte der Build mit einem neueren Compiler.
Der Haken an diesem Vorgehen: Der Fix hält nur, bis jemand den Container aus dem alten Image neu erstellt. Wenn Ihr Team Container auf diese Weise gepatcht hat, setzen Sie einen Image-Rebuild auf den Plan. Sonst kommt die Lücke mit dem nächsten Deploy zurück.
Nach dem Patch: Logs
Als jeder Server ein korrigiertes PHP hatte, haben wir auf allen Servern die Logs von Webserver und PHP nach Anfragen durchsucht, die zu einer Ausnutzung der Lücken passen. Anzeichen für eine Ausnutzung haben wir nicht gefunden.
Was wir Website-Betreibern nach diesem Abend sagen würden
- Das Tempo Ihres Hosters ist Ihr Tempo. Wenn Ihr PHP von einem Panel kommt oder von einem Anbieter, der auf das Panel wartet, bleibt Ihre Website offen, bis er handelt. Fragen Sie ihn heute, welche Version bei Ihnen läuft.
- Altes PHP kostet weiter. PHP 8.1 und älter haben diesmal nur Fixes im Quellcode bekommen. Beim nächsten Mal gibt es vielleicht gar keine. Der Support für PHP 8.2 endet am 31. Dezember 2026.
- Container und eigene Builds brauchen jemanden, der sich zuständig fühlt. Niemand aktualisiert sie automatisch. Jemand muss wissen, dass es sie gibt und wie man sie neu baut.
Unser automatisches Monitoring läuft rund um die Uhr, und unsere Ingenieure reagieren, wenn es einen Vorfall meldet.
Wenn Sie dasselbe für Ihre Server brauchen
Wir prüfen Ihre PHP-Version und aktualisieren sie innerhalb eines Arbeitstags. Schreiben Sie uns.
Für die laufende Betreuung gibt es Server-Support, Website-Support und DevOps. Wenn Ihre mobile App mit einem PHP-Backend spricht, braucht dieses Backend dasselbe Update. Das übernehmen wir im Rahmen des Supports für mobile Apps. Ob sonst noch etwas offen ist, zeigt ein Penetrationstest.
Quellen
- Ankündigung und Gegenmaßnahmen des PHP-Teams: https://www.php.net/archive/2026.php
- Security Advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w und https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available