PHP2Shell, Tag sechs: Der Server ist gepatcht. Und der Rest?

Mittwochnachmittag, kurz nach zwei: Das BSI ruft Warnstufe Orange aus. Um vier kommen die Patches. Danach eine Nacht, in der Sie Server aktualisieren, Dienste vom Netz nehmen und zwischendurch der Geschäftsführung erklären, warum die Website gerade nicht erreichbar ist. Donnerstag früh dann die Frage, die niemand gern beantwortet: „Sind wir betroffen?“

Heute, Montag, eine Stunde vor diesem Beitrag, hat das PHP-Team neue Windows-Pakete veröffentlicht. Wieder ein Update, diesmal wegen einer Lücke in einer mitgelieferten Bibliothek. Wenn Sie in dieser Woche das Gefühl hatten, nur hinterherzulaufen: Das lag nicht an Ihnen. Vier Tage von der Ankündigung bis zu den ersten erfolgreichen Angriffen sind für niemanden ein bequemer Zeitplan.

• Dienstag, 20. Oktober. Das PHP-Sicherheitsteam kündigt ein Release für zwei kritische Lücken an, beide mit CVSS 4.0 von 9,2. Einzelheiten soll es erst mit dem Release geben.
• Mittwoch, 21. Oktober. Das BSI warnt mit Stufe 3 / Orange. Um 16 Uhr erscheinen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die PHP-Entwickler schreiben dazu: Es gibt keine vollständige Abhilfe, das Update ist die einzige sichere Wahl. Die Stadt Mainz schaltet vorsorglich mainz.de ab, weitere Behörden, Hochschulen und Kliniken nehmen Dienste vom Netz.
• Freitag, 23. Oktober. PHP rät zusätzlich, session.upload_progress.enabled=0 zu setzen, bis zum nächsten regulären Release. Censys zählt in Deutschland rund 4,2 Millionen Dienste, die eine verwundbare PHP-Version melden.
• Wochenende. Auf Honeypots, also absichtlich verwundbar betriebenen Testservern, werden die ersten erfolgreichen Angriffe dokumentiert, auf PHP 8.4.26.
• Montag, 26. Oktober. Neue Windows-Pakete mit dem Zusatz -1, etwa 8.5.12-1. Sie beheben eine Lücke im Brotli-Dekompressor (CVE-2026-111497). Erreichbar ist sie über die cURL-Erweiterung, wenn eine Anwendung die automatische Dekomprimierung einschaltet. Die PHP-Version selbst bleibt dieselbe.

Das Update einzuspielen war der leichte Teil. Schwierig ist, sicher zu sein, dass es überall angekommen ist. Fünf Stellen, an denen es in so einer Woche haken kann:

Die Versionsnummer ist kein Patchstand. Debian, Ubuntu und Red Hat bauen Korrekturen in ihre eigenen Pakete ein. Die PHP-Version bleibt dabei oft dieselbe, nur die Paketrevision ändert sich. Unter Windows trägt dieselbe PHP-Version seit heute den Zusatz -1. Ein Scanner, der Versionsnummern liest, meldet deshalb gepatchte Server als verwundbar. Umgekehrt beweist eine passende Nummer im Banner nicht, dass das Paket die letzte Korrektur enthält. Maßgeblich ist das Änderungsprotokoll des Pakets.

Ein Update wirkt erst im neuen Prozess. PHP-FPM-Pools, FastCGI-Worker, Container: Was vor dem Update gestartet wurde, läuft mit dem alten Code weiter, bis es neu startet. Das betrifft auch Prozesse, an die niemand mehr denkt, etwa einen Testserver, der seit Wochen auf einem Entwicklerrechner läuft.

PHP läuft auch dort, wo niemand „PHP“ sagt. In der Weboberfläche der Firewall, auf dem NAS, in Nextcloud, im Intranet-Wiki, in einem Container-Image mit eigenem PHP. Bei Appliances heißt das: warten, bis der Hersteller liefert, und die Oberfläche bis dahin aus dem Internet nehmen. Bei Containern genügt es nicht, den Host zu aktualisieren. Das Image muss neu gebaut werden.

Der Webspace gehört dem Hoster, das Risiko Ihnen. Bei gehosteten Seiten spielen Sie den Patch nicht selbst ein. Fragen Sie schriftlich nach, auf welcher Version Ihre Umgebung läuft und seit wann. Eine Antwort mit Datum ist mehr wert als „wir sind dran“ im Statusblog.

Alte Zweige bekommen kein Release. Für PHP 8.1 und älter gibt es keine offizielle Version. Das PHP-Team hat für 7.4, 8.0 und 8.1 minimale Korrekturen im Quellcode bereitgestellt. Das hilft allen, die selbst kompilieren. Alle anderen sind auf ihren Distributor, einen Anbieter mit Langzeitunterstützung oder ein Upgrade angewiesen, das vermutlich schon länger auf der Liste steht. Der nächste Termin ist bereits bekannt: PHP 8.2 bekommt nach dem 31. Dezember 2026 keine Sicherheitskorrekturen mehr.

Wer Code mit den Rechten des Webservers ausführen kann, liest auch, was der Webserver lesen darf: die Datenbankzugänge in der Konfigurationsdatei, API-Schlüssel, SMTP-Passwörter. Sehen Sie deshalb nach, bevor Sie das Kapitel schließen. Abgestürzte Worker im Ereignisprotokoll, PHP-Dateien, wo keine hingehören, Session-Dateien mit fremdem Inhalt: Findet sich eines davon, tauschen Sie diese Zugänge aus.

Halten Sie außerdem fest, wann Sie welches System aktualisiert haben. Wenn Kunden, Prüfer oder Versicherer danach fragen, ist eine laufend geführte Liste mit Zeitstempeln schnell geschickt. Im Nachhinein muss sie aus Protokollen, Tickets und Erinnerung zusammengesetzt werden.

Für alle, die am Donnerstag einen Termin buchen wollten, sah es so aus. Und es stimmt: Ein abgeschalteter Dienst ist ein Ausfall, den man Kunden und Bürgern erklären muss. Ein abgeschalteter Shop verliert Umsatz, und Dank gibt es dafür nicht, wenn am Ende nichts passiert ist.

Die Gegenrechnung ist trotzdem eindeutig. Ein paar Stunden Stillstand kosten weniger als ein übernommener Server, mit dem jemand anderes weiterarbeitet. In den Kommentaren eines Admin-Blogs stand es kürzer: „Aber lieber mal paar Stunden offline als gänzlich ruiniert.“

Wer abgeschaltet hat, hat sich Zeit gekauft. Teuer wird es dort, wo diese Zeit nicht reicht, weil niemand weiß, wo überall PHP läuft.

Patchen geht schnell, wenn klar ist, wo. Die Zeit geht ins Suchen. Fünf Fragen, die Sie jetzt beantworten können, solange die Woche noch frisch ist:

• Wo läuft bei uns PHP: auf Servern, in Appliances, in Containern, beim Hoster?
• Wer ist für jede dieser Stellen zuständig, mit Namen und Vertretung?
• Woran erkennen wir den tatsächlichen Patchstand: Paket, Build, Neustart?
• Wie schnell liefern Hersteller und Hoster, und haben wir das schriftlich?
• Welcher Zweig läuft als nächster aus, und wann planen wir den Umstieg?

Wer diese Fragen beantworten kann, für den ist die nächste Warnstufe Orange ein langer Arbeitstag, aber keine Nacht ohne Ende.

Am hartnäckigsten sind Anwendungen, die auf einem alten Zweig festhängen, weil ein Upgrade sie brechen würde. Das ist kein PHP-Problem, sondern ein Legacy-Problem, und es betrifft Access, Delphi oder .NET genauso. Wie groß es bei Ihnen ist, zeigt ein erster Blick mit unserem Legacy-Check: zehn Fragen, drei Minuten, ohne dass Ihre Antworten gespeichert werden. Wie wir geschäftskritische Altanwendungen weiterentwickeln, statt sie neu zu schreiben, steht unter Legacy-Modernisierung.

Sprechen Sie uns an, wenn eine Anwendung bei Ihnen nicht mehr mitkommt und Sie wissen wollen, welche Wege es gibt.

Quellen (Stand 26. 10. 2026, 15 Uhr): PHP-Sicherheitsteam, Ankündigung vom 20. 10., Sicherheitshinweis und Releases vom 21. 10., Hinweis zu Session Upload Progress vom 23. 10., aktualisierte Windows-Pakete vom 26. 10. (php.net); BSI, Cybersicherheitswarnung „PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Version 1.1; ZDFheute, 21. 10. 2026; Censys, php2shell.censys.com, Stand 23. 10. 2026. Das Zitat stammt aus den Kommentaren zu „php2shell: PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619“ in Borns IT- und Windows-Blog, 21. 10. 2026.