php2shell: Wie wir einen der kritischsten PHP-Sicherheitstage seit Jahren erlebt haben

Am Nachmittag des 21. Oktober 2026 erschienen die Fix-Versionen für php2shell. Rund zehn Minuten später lief auf den ersten Produktivsystemen, die wir betreiben, die gepatchte PHP-Version. Das ist keine Heldengeschichte, sondern das Ergebnis eines Tages, den unser gesamtes Team von morgens bis spät abends im Incident-Modus verbracht hat.

Zwei kritische Lücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, schnell „php2shell“ getauft. Pre-Auth Remote Code Execution, CVSS 4.0: 9.2. Übersetzt: Ein Angreifer braucht keinen Login und kein Passwort, um eigenen Code auf dem Server auszuführen.

Wenn Sie eine Website, einen Shop oder ein Portal auf PHP-Basis betreiben, betrifft Sie das. Dieser Text ist ein Erfahrungsbericht: was wir gesehen haben, was wir getan haben, was wir festgestellt haben und was Sie jetzt konkret prüfen sollten.

Was php2shell ist

Zwei Schwachstellen, zwei Mechanismen, ein gemeinsames Ergebnis.

CVE-2026-109618 ist eine Speicherkorruption bei der Verarbeitung von Multipart-Uploads, also genau bei dem Vorgang, der abläuft, wenn jemand eine Datei über ein Formular an Ihre Anwendung schickt.

CVE-2026-109619 beruht auf einem „stale global state“, einem globalen Zustand, der nicht korrekt zurückgesetzt wird. Darüber existiert ein bestätigter Weg zur Codeausführung, konkret über die PHP-Funktion Session-Upload-Progress. Sie schreibt den Fortschritt laufender Datei-Uploads in die Session, wird selten bewusst genutzt und ist bei vielen Installationen trotzdem aktiv.

Der wichtige Punkt für Entscheider: Diese Lücken sitzen nicht in WordPress, Shopware, Symfony, Laravel oder Ihrer Individualentwicklung. Sie sitzen in PHP selbst, in der Schicht darunter. Betroffen sind damit praktisch alle PHP-Webanwendungen, auch auf den EOL-Versionen 7.x, 8.0 und 8.1, die keinen Patch mehr bekommen.

Warum diese Lücke anders war

Der Sicherheitsforscher Kevin Beaumont bezeichnete die Lage gegenüber Help Net Security als eine der größten Schwachstellen seit Jahren. Help Net Security wies zudem darauf hin, dass der Angriff greift, bevor überhaupt Anwendungscode ausgeführt wird; Setups mit mod_php gelten als besonders exponiert.

Die Konsequenz: Gepflegte Anwendungssicherheit hilft hier nur begrenzt. Starke Passwörter, Zwei-Faktor-Authentifizierung oder ein aktuelles CMS-Release greifen erst, wenn PHP die Anfrage bereits verarbeitet hat. Wirksam schützt am Ende nur das PHP-Update selbst.

Der Tag lief nicht nach Lehrbuch

Details zur Lücke waren vor dem offiziellen Release durchgesickert, das Release wurde wegen des Leaks um einen Tag vorgezogen. Für Verteidiger heißt das: Angreifer hatten Informationen, bevor es einen Fix gab.

Am Nachmittag erschienen die Fix-Versionen: 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Noch am selben Tag bestätigten Sicherheitsfirmen, darunter watchTowr und Cloudflare, die Ausnutzung „in the wild“. Am Abend tauchte öffentlicher Exploit-Code auf. Auch Medien wie die FAZ berichteten.

Paketquellen unter Last

Dazu kam ein Engpass, der an solchen Tagen oft unterschätzt wird: Die Paketquellen, über die viele Betreiber PHP aktualisieren, waren den ganzen Tag überlastet, etwa das verbreitete Ubuntu-PPA. Für viele kamen die Updates erst spät. Auch Distributionen wie AlmaLinux meldeten, dass gepatchte Pakete noch gebaut werden.

Man kann nicht patchen, was noch nicht verfügbar ist. Wer ausschließlich auf Distributionspakete gesetzt hat, saß in einem Zeitfenster, in dem die Lücke aktiv ausgenutzt wurde und das Update noch nicht ankam.

Unser 21. Oktober

Keine Kundennamen, keine internen Details. Aber der Ablauf.

Lagebild statt Bauchgefühl

Wir haben die Lage den ganzen Tag automatisiert live verfolgt, über mehr als 20 Quellen parallel: php.net, das PHP-Source-Repository und die Security Advisories, NVD, CISA-KEV, die Paketquellen der Distributionen, Hacker News, Reddit, Mastodon, die Fachblogs der Sicherheitsfirmen und Google News.

Parallel dazu die eigenen Daten: Server- und Zugriffsprotokolle aller betreuten Systeme und eine automatische Prüfung aller laufenden Anwendungsinstanzen auf verdächtige Prozesse, Dateien und Verbindungen, im 5-Minuten-Takt, den ganzen Tag.

Das Ziel: zwei Fragen jederzeit beantworten zu können. Hat sich die Bedrohungslage geändert? Und hat sich auf unseren Systemen etwas verändert?

Inventur: Wer ist betroffen?

Bevor man handelt, muss man wissen, worüber man redet. Wir haben alle PHP-Anwendungen unserer Kunden identifiziert und nach Risiko priorisiert: Ist das System öffentlich erreichbar? Verarbeitet es Datei-Uploads, also den Angriffsweg? Läuft es bei uns oder bei einem Drittanbieter?

Bei Systemen in unserem Betrieb konnten wir direkt handeln. Bei Systemen auf Fremdhosting haben wir informiert, nachgefragt und Übergangsmaßnahmen abgestimmt.

Vor dem Patch: den Angriffsweg verengen

Zwischen „es gibt eine Lücke“ und „es gibt einen Fix“ liegt die eigentliche Arbeit.

• Staging- und Testsysteme hinter die Firewall. Sie sind oft öffentlich erreichbar und werden selten so aufmerksam gepflegt wie die Produktion.
• Datei-Uploads gezielt gesperrt oder zusätzlich abgesichert, abhängig davon, wie kritisch die Funktion für den jeweiligen Betrieb ist.
• PHP-Konfiguration gehärtet, unter anderem mit session.upload_progress.enabled = 0. Das schaltet genau das Feature ab, über das der bestätigte Angriffsweg läuft.
• Notfall-Builds von PHP aus dem Quellcode vorbereitet, um nicht von überlasteten Paketquellen abhängig zu sein.

Der Patch

Als die Fix-Versionen veröffentlicht wurden, waren die ersten Produktivsysteme rund zehn Minuten später aktualisiert, alle von uns betriebenen Systeme am selben Nachmittag und Abend.

Danach folgte der Teil, der in Incident-Berichten gern fehlt: der kontrollierte Rückbau. Gesperrte Uploads wieder freigegeben, temporäre Sperren zurückgenommen, Änderungen dokumentiert. Ein Incident ist erst vorbei, wenn die Infrastruktur wieder in einem definierten Zustand ist, nicht schon, wenn der Patch läuft.

Analyse: nachsehen, nicht hoffen

Anschließend haben wir Logs, Dateisysteme, Prozesse und Netzwerkverbindungen geprüft und nach typischen Spuren einer erfolgreichen Ausnutzung gesucht: veränderte oder neue Dateien in Web-Verzeichnissen, Prozesse, die dort nicht hingehören, ungewöhnliche ausgehende Verbindungen, auffällige Muster in den Zugriffsprotokollen.

Das Ergebnis, bewusst genau so formuliert:

Wir haben kein erfolgreiches Ausnutzen der Sicherheitslücken festgestellt.

Das ist eine Aussage auf Basis der Daten, die wir geprüft haben. Mehr kann man nach einer kritischen Pre-Auth-RCE-Lücke seriös nicht sagen.

Kommunikation

Betroffene Kunden haben wir morgens proaktiv informiert, über den Tag mit Zwischenständen auf dem Laufenden gehalten und abends Entwarnung gegeben. Kunden mit Hosting bei Drittanbietern haben wir unterstützt: Hoster informiert, Übergangsmaßnahmen abgestimmt, Logs geprüft, soweit Zugriff bestand.

Unsere Erfahrung: Geschäftsführer brauchen an so einem Tag keine CVE-Details, sondern drei Antworten. Sind wir betroffen? Ist etwas passiert? Wann ist es erledigt?

Der häufigste Irrtum: „Darum kümmert sich doch der Hoster“

Manchmal stimmt das. Oft ist es ungenauer, als es klingt. Ein Beispiel aus der Dokumentation von Laravel Forge: Die automatischen Sicherheitsupdates von Forge patchen PHP nicht, weil PHP dort aus einem eigenen Paket-Repository kommt und Ubuntus Unattended Upgrades nur Updates aus Ubuntus eigenem Security-Repository einspielen.

Die Frage ist also nicht, ob Sie „automatische Updates“ haben, sondern ob PHP selbst davon erfasst ist. Das lässt sich klären, aber nur, wenn jemand konkret nachfragt.

Dazu kommt der EOL-Fall: PHP 7.x, 8.0 und 8.1 bekommen keinen Patch mehr. Wer darauf läuft, hat kein Update-Thema, sondern ein Migrationsprojekt.

Was Sie jetzt tun sollten

1. PHP-Version prüfen und aktualisieren auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 (bzw. die gepatchten Pakete Ihrer Distribution).
2. Managed Hosting: Ihr Provider ist zuständig. Fragen Sie trotzdem aktiv nach und lassen Sie sich das Update bestätigen.
3. Eigene Server (vServer, Root-Server, Plesk): Handeln Sie selbst, und zwar dringend.
4. PHP 7.x, 8.0, 8.1: Es kommt kein Patch. Planen Sie Upgrade bzw. Migration.
5. Übergangsmaßnahmen nur als Brücke: session.upload_progress.enabled = 0, Absicherung von Uploads, Zugriffsbeschränkungen. Sie ersetzen das Update nicht.
6. Logs prüfen: Achten Sie auf Auffälligkeiten in Zugriffsprotokollen, neue Dateien in Web-Verzeichnissen und ungewöhnliche Prozesse.

Hinweis: Konfigurationsänderungen sollten Sie vorab in einer Testumgebung prüfen, da einzelne Anwendungen auf Upload-Funktionen angewiesen sind.

Fazit: Sicherheit ist Betrieb

Was am 21. Oktober geholfen hat, war nicht Improvisation, sondern Vorbereitung: zu wissen, was läuft, die Lage kontinuierlich zu beobachten, schnell und kontrolliert zu handeln und transparent zu kommunizieren. Sicherheit ist kein Zustand, den man einmal herstellt, sondern laufender Betrieb.

Unsicher, ob Ihre PHP-Systeme betroffen sind? Wir prüfen das kurzfristig. Jetzt Kontakt aufnehmen