PHP2Shell: nicht nur
ein Website-Problem

Am 21. Oktober 2026 hat das PHP-Projekt vier korrigierte Versionen für zwei kritische Schwachstellen im Interpreter veröffentlicht, CVE-2026-109618 und CVE-2026-109619, genannt PHP2Shell. Beide erreichen 9,2 von 10 auf der Skala CVSS (Common Vulnerability Scoring System) Version 4.0 und erlauben einem Angreifer aus der Ferne, ohne Zugangsdaten, Code auf dem Server auszuführen oder den Speicher des Prozesses auszulesen. Die Berichterstattung dieser Tage spricht fast nur von Websites, WordPress voran. Der fehlende Punkt ist ein anderer: Der Fehler liegt in der Laufzeitumgebung, und PHP läuft auch in der GUI von Firewalls, im Captive Portal, in NAS-Geräten (Network Attached Storage), in Telefonanlagen und in Ticketsystemen. Wer die Websites inventarisiert hat, hat die halbe Arbeit getan.

Was zwischen dem 17. und 21. Oktober geschah

Beide Lücken entstehen an derselben Schwachstelle: der Art, wie PHP fatale Fehler, insbesondere Speichererschöpfung, während der Verarbeitung einer Anfrage behandelt. CVE-2026-109618 unterbricht PHP, während die internen Strukturen der Anfrage nur teilweise initialisiert sind, und die anschließende Bereinigung behandelt ungültige Daten als gültig. CVE-2026-109619 hinterlässt im globalen Zustand des Workers Verweise auf bereits freigegebenen Speicher, die eine spätere, vom selben Worker bediente Anfrage wiederverwendet, bevor die Initialisierung sie zurücksetzt. Der verwundbare Code ist laut Wiz Research, die die Fehler am 19. August entdeckt und am 24. gemeldet hat, seit PHP 5.4 vorhanden, also seit 2012.

Die koordinierte Offenlegung hat nicht gehalten. Am 17. Oktober registrieren die Honeypots von Amazon einen ersten Ausnutzungsversuch, aus einem kommerziellen Anonymisierungsnetz. Am 20. Oktober sickern die technischen Details an die Öffentlichkeit durch, und das PHP-Projekt kündigt eine außerplanmäßige Veröffentlichung für den Folgetag an. Am 21. Oktober um 14:00 UTC erscheinen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35; Cloudflare hatte die Schutzregeln seiner WAF (Web Application Firewall) bereits um 03:02 UTC aktiviert und erklärt, Angriffsverkehr gegen eigene Kunden beobachtet zu haben. Am selben Nachmittag veröffentlicht die italienische ACN (Nationale Agentur für Cybersicherheit) den Alert AL07/261021/CSIRT-ITA mit systemischer Auswirkung „Hoch (65,64)“, das CERT-EU das Advisory 2026-018, und das SANS Internet Storm Center hebt seine Alarmstufe auf Gelb. Am 22. Oktober sind keine Kompromittierungen realer Systeme bestätigt, die Versuche sind jedoch dokumentiert und Proof-of-Concept-Code ist öffentlich.

Für PHP 8.1 und älter veröffentlicht das Projekt keine Korrekturen: Die ACN schreibt es ausdrücklich. Das PHP-Sicherheitsteam hat jedoch minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereitgestellt, und die vorab informierten Linux-Distributionen und LTS-Anbieter veröffentlichen eigene Pakete. Ein Termin für den Kalender: PHP 8.2 fällt am 31. Dezember 2026 aus dem Support.

Warum ein WordPress-Update nicht reicht

Die bösartige Anfrage wird von PHP verarbeitet, bevor der Anwendungscode läuft. Deshalb ändert ein Update von WordPress, Theme oder Plugins nichts: Der Interpreter, der die Website ausführt, muss aktualisiert werden, und bei Shared Hosting ist der Hoster zu fragen. Wiz hat die Codeausführung ohne Anmeldung auf den neuesten offiziellen Images von WordPress, Drupal und Joomla gezeigt, betont aber, dass auch eine „Hello World“-Seite auf einem verwundbaren PHP angreifbar ist. Das höchste Risiko besteht laut php.net auf Apache mit mod_php, wo der Angriff mit Standardeinstellungen gelingt; PHP-FPM, php-cgi, FrankenPHP und LiteSpeed sind ebenfalls betroffen.

Es gibt einen zweiten, seltener genannten Effekt: CVE-2026-109618 erlaubt auch das Auslesen des Speichers des PHP-Prozesses, ohne bis zur Codeausführung zu gehen. Durch diesen Speicher laufen Passwörter, Sitzungs-Token, API-Schlüssel und, laut Sansec, auch private TLS-Schlüssel. Wer feststellt, exponiert gewesen zu sein, schließt den Vorfall nicht mit dem Patch: Er muss die Geheimnisse rotieren.

Es ist dieselbe Schlussfolgerung wie im Artikel über die WordPress-Schwachstellen: Das Problem ist nicht das einzelne Plugin, sondern ein Interpreter, der im Internet lauscht, um Seiten auszuliefern, die sich nicht ändern. Eine statische Website, beim Build erzeugt und über ein CDN verteilt, hat kein PHP, keine Worker, nichts, was diese Woche zu aktualisieren wäre. Unsere Website ist so gebaut, und so ist auch das Managed Hosting, das wir auf Azure Static Web Apps anbieten.

PHP läuft nicht nur in Websites: Firewalls, NAS, Telefonanlagen, ITSM

Viele Netzwerk-Appliances und viele Unternehmensanwendungen haben eine in PHP geschriebene Weboberfläche. Der Hersteller aktualisiert sie mit der Firmware, die PHP-Version wählt also nicht das Unternehmen, und oft weiß niemand, welche es ist. In den zwei Tagen nach dem Patch kamen die Advisories der Hersteller in Wellen, und sie beschreiben vier verschiedene Situationen.

Open-Source-Firewalls. pfSense und OPNsense haben GUI und Captive Portal in PHP. Beide haben am 21. Oktober korrigierte Pakete veröffentlicht: OPNsense mit einem Hotfix für die Community- und die Business-Edition, pfSense mit neuen PHP-Paketen für die unterstützten Versionen, die über die Shell und nicht über die GUI zu installieren sind. Das Captive Portal ist der schlimmste Fall: Es ist ein PHP-Dienst, der konstruktionsbedingt nicht vertrauenswürdigen Clients antwortet, in Hotels, Geschäften, Wartezimmern und Gastnetzen, und es muss nach dem Update neu gestartet werden. Die GUI dagegen antwortet standardmäßig nur im LAN: Wenn das so ist, bleibt es eine Frage der Hygiene, kein Notfall.

Kommerzielle Firewalls und Appliances. Einige große Hersteller haben die Web-Verwaltungsschnittstelle ihrer Appliances als verwundbar erklärt und haben am 22. Oktober noch keinen Termin für die Korrektur; andere führen eine lange Liste von Produkten „in Prüfung“ und keines als bestätigt. In beiden Fällen lautet die Empfehlung gleich: Verwaltung nur von vertrauenswürdigen internen Adressen erreichbar und, bis der Fix da ist, kein Verwaltungsport im Internet.

NAS. Die Betriebssysteme einiger NAS-Geräte nutzen PHP in ihren Webkomponenten und Anwendungen; am 22. Oktober führt ein sehr verbreiteter Hersteller alle Versionen als „in Korrektur“ und bittet, das NAS vom Internet zu trennen, VPN zu nutzen und nicht benötigte Dienste zu stoppen. Andere NAS-Plattformen nutzen im System kein PHP, wohl aber die installierten Apps, etwa eine Datei-Cloud oder ein CMS: Dort wird die App aktualisiert, nicht die Firmware.

Telefonanlagen, ITSM und der Rest. Open-Source-Telefonanlagen haben ihre Verwaltungs-GUI in PHP: Aktuelle Versionen auf einer unterstützten Distribution erhalten das korrigierte PHP aus den Repositories der Distribution, alte laufen auf PHP-Zweigen ohne Support und bleiben ungeschützt. Dasselbe gilt für Ticketsysteme, Wikis, Monitoring-Frontends, Webmail und Hosting-Panels: Nicht die Anwendung muss aktualisiert werden, sondern das PHP darunter, mit dem Paket der Distribution oder des Herstellers; bei vom Hersteller verwalteten Cloud-Versionen kümmert sich dieser darum.

Für jede Appliance ohne Advisory gibt es eine einzige Frage an den Lieferanten: Führt die GUI PHP aus, in welcher Version, und von wo aus ist sie erreichbar?

Was im Unternehmen zu tun ist, in dieser Reihenfolge

• Inventar: Wo läuft PHP? Websites und Portale, auch die „vergessenen“; GUIs von Firewalls und Routern; Captive Portals; NAS und Videoüberwachung; Telefonanlage; ITSM, Wiki, Monitoring, Webmail; Container und auf dem NAS installierte Apps. Für jedes System: die PHP-Version, die die Anfragen bedient (nicht die der Kommandozeile, die abweichen kann), und aus welchen Netzen es erreichbar ist.
• Exponiertes schließen. Keine Verwaltungsschnittstelle und kein Captive Portal direkt im Internet. Der Fernzugriff läuft über VPN oder einen Zero-Trust-Zugang, und die GUI antwortet nur vertrauenswürdigen Netzen und Adressen. Kann ein verwundbarer Dienst weder aktualisiert noch geschützt werden, empfiehlt die ACN, ihn bis zum Update offline zu nehmen.
• Aktualisieren und die Worker neu starten. PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, oder das Paket der Distribution oder des Herstellers, das die Korrekturen zurückportiert. Das neue Binary wirkt erst nach dem Neustart von PHP-FPM oder des Webservers, und des Captive Portals, wo es eines gibt. Danach die Version von der Webseite aus prüfen, nicht nur in der Shell.
• Vorübergehende Abhilfen, nur wenn es keinen Patch gibt. Die von php.net genannten Einstellungen verringern die Angriffsfläche auf bestimmten Pfaden und machen eine Installation nicht sicher: memory_limit ohne vom Administrator erzwungene Grenze, niedriges post_max_size, session.upload_progress.enabled deaktiviert mit Worker-Neustart, fatal_error_backtraces deaktiviert auf PHP 8.5. RLIMIT_AS oder RLIMIT_DATA nicht verwenden, sie lösen genau den verwundbaren Pfad aus.
• Geheimnisse rotieren, falls Exposition bestand. Wo ein verwundbarer Dienst zwischen dem 17. und 21. Oktober erreichbar blieb, sind Anwendungspasswörter, Sitzungs-Token, API-Schlüssel und im Speicher gehaltene Zertifikate als potenziell ausgelesen zu behandeln und zu rotieren.
• Den Ausstieg aus alten Zweigen planen. PHP 7.4, 8.0 und 8.1 erhalten keine offiziellen Versionen; PHP 8.2 fällt am 31. Dezember 2026 aus dem Support. Eine auf einem alten Zweig festhängende Anwendung ist ein Problem für die nächsten zwei Monate, nicht für den nächsten Notfall.

Wonach in den Logs zu suchen ist, auch nach dem Update

Der ACN-Alert verlangt eine rückblickende Analyse der Logs „unabhängig von der Anwendung der Updates“, und der Grund ist die Chronologie: vier Tage mit Versuchen vor dem Patch, auf die niemand geachtet hat. Das abzudeckende Zeitfenster beginnt spätestens am 17. Oktober. Die Signale decken sich zwischen ACN, Wiz, Amazon und den PHP-Advisories:

• Anomale Multipart-POST-Anfragen: sehr lange Dateinamen, viele Header pro Teil, Größen nahe am Limit, vorhandenes Feld PHP_SESSION_UPLOAD_PROGRESS.
• Wiederkehrende Speichererschöpfungsfehler, wiederholte HTTP-500-Antworten, „Maximum execution time exceeded“, unerwartete Neustarts oder Fluktuation der PHP-Worker.
• Anomale PHPSESSID-Antwort-Cookies, zu groß oder fehlerhaft: Das ist die Spur des Speicherauslesens.
• Auf dem System: vom Web-Worker gestartete unerwartete Prozesse, veränderte Anwendungsdateien, neue Cronjobs oder Konten, unerklärte ausgehende Verbindungen.

Ein Hinweis aus den PHP-Advisories, der mehr wert ist als die ganze Liste: Das Fehlen von Fehlern in den Logs ist kein Beweis für Sicherheit. Historische Logs können ohne Deprecations gesammelt worden sein, und der Fehler kann auftreten, bevor PHP die Meldung schreibt. Wer einen Bericht unterschreiben muss, sollte das vorher wissen. Wenn etwas nicht zusammenpasst, ist es Zeit für die Incident Response, nicht für ein weiteres grep.

Der strukturelle Punkt: weniger exponierte Laufzeiten, weniger Notfälle

PHP2Shell ist nicht der erste Fall und wird nicht der letzte sein: Heartbleed 2014 und Log4Shell 2021 hatten dieselbe Form, eine von allen geteilte Komponente mit einem Fehler, den niemand sah. Was ein Unternehmen entscheiden kann, ist nicht, ob der nächste kommt, sondern wie viel Angriffsfläche es ihm bietet. Drei Entscheidungen, die die Fläche dauerhaft verkleinern: eine statische Website statt eines CMS mit Interpreter, die PHP aus dem Perimeter nimmt; eine cloud-verwaltete Firewall mit nie exponierter GUI, bei der die Verwaltung über einen Controller läuft und nicht über einen am WAN offenen Port; ein Zero-Trust-Zugang statt veröffentlichter Verwaltungsports. Nachgelagert zeigt ein regelmäßiges Vulnerability Assessment von außen, welche Schnittstellen im Internet wirklich antworten, was oft etwas anderes ist als das, was man glaubte.