Ein Unternehmen aktualisiert sein CMS, prüft die Plugins und schließt das Wartungsticket. Trotzdem kann der Webserver angreifbar bleiben: Die Schwachstelle liegt nicht in der Anwendung, sondern in ihrer PHP-Laufzeit. Genau dieses Problem adressieren die am 21. Oktober 2026 veröffentlichten Notfallupdates gegen PHP2Shell. Für Betriebsteams geht es deshalb nicht nur um ein installiertes Paket, sondern um den nachweislich reparierten Prozess, der produktive Anfragen bearbeitet. [1][4]
Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619 ermöglichen unter den jeweiligen Voraussetzungen Codeausführung ohne vorherige Anmeldung. Beide sind mit CVSS 4.0 von 9,2 bewertet. Canonical bestätigt, dass die ursprünglich für den 22. Oktober geplante Veröffentlichung nach einem öffentlichen Leak auf den 21. Oktober vorgezogen wurde. Das ist ein aktuelles Patchereignis, keine lediglich neu aufbereitete Altlast. [2][3][4]
Zwei Fehlerklassen an derselben Sicherheitsgrenze
Bei CVE-2026-109618 wird Speichermangel zum Kontrollflussproblem. PHP verwendet für bestimmte Out-of-Memory-Situationen einen abrupten Ausstieg mittels longjmp(). Erfolgt dieser, während interne Anfragedaten erst teilweise initialisiert sind, kann die anschließende Bereinigung ungültigen Zustand verarbeiten. Aus einem vermeintlich normalen Ressourcenfehler entsteht damit eine Möglichkeit zur Speicherkorruption und Codeausführung. Der Patch ersetzt diesen problematischen Abbruch durch kontrollierte Mechanismen für weichen beziehungsweise harten Speichermangel. [2]
Besonders wichtig ist die Trennung der Betriebsarten. Für Apache mit mod_php beschreibt das Advisory einen bestätigten Angriffspfad bereits während des Request-Starts, bevor Anwendungscode läuft. PHP-FPM beendet dagegen einen Worker bei fehlgeschlagenem Request-Start. Das verhindert diese konkrete Sequenz, ist aber keine generelle Entwarnung: Nach erfolgreichem Start können anwendungsspezifische Speicherfehler weiterhin relevante Zustände erreichen. Für diese erste CVE weist PHP ausdrücklich auf die unterschiedliche Beweislage hin. [2]
CVE-2026-109619 betrifft Zustand, der eine Anfrage unzulässig überlebt. Ein Worker behält globale Verweise auf Speicher, der bereits freigegeben wurde. Eine spätere Anfrage desselben Workers kann diese veralteten Verweise nutzen, bevor die normale Initialisierung sie zurücksetzt. Das ist ein Use-after-free über Request-Grenzen hinweg. [3]
Für diesen zweiten Komplex sind Codeausführungspfade sowohl unter mod_php als auch unter FPM bestätigt; der validierte FPM-Pfad benötigt eine geeignete Anwendungsoperation. Viele Worker oder häufiges Recycling verändern die Trefferwahrscheinlichkeit, beseitigen die Ursache jedoch nicht. Die Ausführung erfolgt mit den Rechten des Web-Workers, nicht automatisch mit Root-Rechten. [3]
Was jetzt als repariert gilt
PHP nennt vier korrigierte Upstream-Versionen: 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Betroffenheitsprüfungen müssen den jeweiligen Versionszweig berücksichtigen. Das Projekt fordert alle Betreiber von PHP-Webanwendungen zum unmittelbaren Update auf; die Warnung umfasst auch andere Integrationen wie CGI, FrankenPHP und LiteSpeed. [1]
Bei Distributionspaketen reicht der Vergleich mit diesen Upstream-Nummern nicht aus. Canonical veröffentlicht beispielsweise für Ubuntu 24.04 das korrigierte Paket 8.3.6-0ubuntu0.24.04.13. Die ältere Basisversion bedeutet hier nicht, dass der Sicherheitsfix fehlt. Maßgeblich sind die vollständige Paketversion und die Sicherheitsmeldung des verantwortlichen Distributors. [4]
Umgekehrt beendet ein erfolgreiches Paketupdate den Vorgang noch nicht. Canonical weist ausdrücklich darauf hin, dass betroffene Anwendungen neu gestartet werden müssen; bei mod_php betrifft das beispielsweise Apache. Auch automatische Updates ersetzen diesen Schritt nicht. Als betriebliche Konsequenz sollte jedes Team den Neustart beziehungsweise den Austausch seiner produktiven Instanzen dokumentieren und anschließend deren tatsächlich verwendete Laufzeit prüfen. Eine alleinige CLI-Prüfung ist dafür kein hinreichender Nachweis. [4]
Warum das Thema über klassisches Webhosting hinausgeht
Wiz beschreibt die Lücken als Fehler im PHP-Kern und demonstrierte Angriffe gegen WordPress, Drupal und Joomla. Diese Anwendungen waren Testziele, nicht die eigentliche Fehlerursache. Zusätzlich berichten die Forscher über das Auslesen von Prozessspeicher. Ein Team sollte die Untersuchung deshalb nicht auf veränderte Webdateien oder einen einzelnen CMS-Typ verengen. [5]
Der AI-Security-Bezug liegt in der Forschung: Nach Darstellung von Wiz halfen Frontier-Modelle dabei, komplexe Exploitketten zu entwickeln und an unterschiedliche Speicherlayouts anzupassen. Das ist eine Aussage des beteiligten Forschungsteams, kein unabhängiger Nachweis universeller Exploit-Automatisierung. Für Unternehmen bleibt dennoch eine sinnvolle Schlussfolgerung: Hoher technischer Aufwand auf Angreiferseite sollte nicht als dauerhafte Schutzmaßnahme eingeplant werden. [5]
Für die praktische Priorisierung empfehlen sich daher Erreichbarkeit, Betriebsart, vorhandene Fixes und Berechtigungen des Workers als Entscheidungskriterien. Eine öffentliche Marketingseite kann hohe Priorität verdienen, wenn ihr Prozess zugleich Zugangsdaten für weitere Systeme besitzt. Eine interne Anwendung ist nicht automatisch harmlos, benötigt aber eine andere Expositionsbewertung.
Konkreter Arbeitsauftrag für Unternehmen
Erstens: Laufzeiten statt nur Anwendungen inventarisieren. Für jeden Webdienst sollten Verantwortlicher, PHP-Betriebsart, Paketquelle, Container-Image und Netzwerkexposition erfasst werden. Managed-Hosting-Anbieter sollten die Behebung beider CVEs bestätigen. Eine pauschale Aussage über aktuelle CMS-Versionen beantwortet diese Frage nicht.
Zweitens: Patch und Aktivierung getrennt abnehmen. Erst korrigierte Pakete oder Images bereitstellen, danach Worker und Replikate kontrolliert ersetzen. Anschließend prüfen, ob alte Prozesse, Nebenpools oder zurückgebliebene Instanzen weiterhin Traffic erhalten. Die Freigabe sollte auf einem Laufzeitnachweis beruhen, nicht allein auf dem Deployment-Status.
Drittens: Den möglichen Schaden begrenzen. Web-Worker sollten nur die erforderlichen Dateien und Dienste erreichen. Getrennte Dienstidentitäten, eng begrenzte Datenbankrechte und restriktiver ausgehender Verkehr sind sinnvolle zusätzliche Kontrollen. Sie ersetzen keinen Patch, können aber eine erfolgreiche Codeausführung weniger folgenreich machen.
Viertens: Bei Verdachtsmomenten Incident Response einschalten. Wiz nennt ungewöhnliche Multipart-Anfragen, Speicherfehler, wiederholte HTTP-500-Antworten und auffällige Worker-Wechsel als mögliche Untersuchungsansätze. Solche Signale sind weder alleiniger Kompromittierungsbeweis noch vollständige Erkennung. Empfohlen ist ihre Korrelation mit Prozessstarts, Netzwerkverbindungen und Änderungen an Anwendung oder Zugangsdaten. [5]
Grenzen von Workarounds und Angriffsmeldungen
Das Abschalten von session.upload_progress.enabled deckt nach PHP-Angaben nur bestimmte bestätigte Pfade ab. Ebenso beseitigt das Verbergen von Warnungen die zugrunde liegenden Zustandsfehler nicht. Das offizielle Advisory warnt ausdrücklich vor einer universellen Konfigurationslösung. [3]
Auch memory_limit=-1 ist keine pauschale Reparatur. Es entfernt einen kontrollierbaren Auslöser der ersten Fehlerklasse, verhindert aber nicht jeden fehlgeschlagenen Speicherzugriff und verlangt zusätzliche Verfügbarkeitskontrollen. Solche Übergangsmaßnahmen gehören in eine dokumentierte Risikoentscheidung, nicht in ein blind kopiertes Standardrezept. [2]
Belastbare öffentliche Opferzahlen lassen sich aus den hier ausgewerteten Primärquellen nicht ableiten. Forschungsdemonstrationen dürfen nicht mit flächendeckend erfolgreichen Angriffen gleichgesetzt werden. Gleichzeitig ist die fehlende Bestätigung eines Einbruchs kein Grund, eine exponierte, verwundbare Laufzeit unverändert weiterzubetreiben.
Fazit
PHP2Shell macht die Laufzeit selbst zur Priorität. Unternehmen sollten beide CVEs anhand ihrer Paketquelle prüfen, den Fix in sämtlichen produktiven Workern aktivieren und die Ausführung mit möglichst kleinen Berechtigungen absichern. Die entscheidende Abschlussfrage lautet nicht: Ist das Update installiert? Sondern: Welcher nachweislich reparierte Prozess beantwortet jetzt die nächste Anfrage?
Quellen
- PHP: Sicherheitswarnung und Notfallversionen, 21. Oktober 2026
- PHP Security Advisory: CVE-2026-109618, RCE via OOM corruption
- PHP Security Advisory: CVE-2026-109619, RCE via stale global state
- Canonical: PHP2Shell-Fixes und Hinweise zum Neustart, 21. Oktober 2026
- Wiz Research: PHP2Shell – technische Untersuchung und AI-gestützte Forschung, 21. Oktober 2026