PHP2Shell: Betroffene PHP-Versionen und Sicherheitsupdates

PHP2Shell bezeichnet zwei kritische Schwachstellen in der PHP-Laufzeit, die unter bestimmten Bedingungen fremde Codeausführung ohne Anmeldung ermöglichen. Wer eine PHP-Website betreibt, sollte den Patchstand der tatsächlich laufenden PHP-Version prüfen. CISA führt beide ursprünglichen CVEs seit dem 26. Oktober 2026 im Katalog bekannter ausgenutzter Schwachstellen; daraus ergibt sich keine weltweite Opferzahl. Quelle: offizieller CISA-Datenspiegel.

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Updates für zwei kritische Schwachstellen. Unter passenden Bedingungen ermöglichen sie die Ausführung fremden Codes auf einem Server ohne vorherige Anmeldung. Das erklärt die Dringlichkeit der Warnungen. Es bedeutet aber nicht, dass jede PHP-Website erfolgreich angegriffen wurde. Quelle: CERT-EU.

Dieser Artikel wurde am 30. Oktober 2026 geprüft. Das Video arbeitet mit dem Stand vom 24. Oktober. Spätere Nachträge werden hier ausdrücklich von den ursprünglichen Lücken unterschieden. Die Erklärung dient der Einordnung und Absicherung, nicht dem Nachbauen eines Angriffs.

Warum ein PHP-Fehler viele Anwendungen betrifft

PHP arbeitet häufig auf dem Server, bevor eine fertige Seite im Browser ankommt. Es kann beispielsweise eine Anfrage bearbeiten, Daten abrufen und die Antwort zusammensetzen. Eine Anwendung wie WordPress baut auf dieser Laufzeit auf.

Liegt eine Schwachstelle in der Laufzeit selbst, muss die darüberliegende Anwendung nicht denselben Fehler im eigenen Code enthalten. Das ist der Unterschied zwischen einem defekten Bauteil im Fundament und einem Fehler in einem einzelnen Zimmer.

Wie weit PHP verbreitet ist, misst unter anderem W3Techs. Am 30. Oktober nennt der Dienst 69,2 Prozent der Websites, deren serverseitige Programmiersprache er kennt. Dieser Nenner gehört zur Zahl. Sie beschreibt weder sämtliche Websites noch den Anteil verwundbarer oder tatsächlich übernommener Server. Quelle: W3Techs.

Die Verbreitung erklärt die große mögliche Reichweite einer Laufzeitlücke. Ob eine konkrete Installation betroffen ist, muss trotzdem anhand ihres Patchstands und ihrer Betriebsbedingungen geprüft werden.

Zwei Schwachstellen, zwei Arten von ungültigem Speicherzustand

PHP verarbeitet Anfragen in Prozessen, häufig sogenannten Workern. Für eine Anfrage werden Daten aufgebaut und später wieder freigegeben. Dabei muss auch der Fehlerfall sauber funktionieren.

CVE-2026-109618: Wenn der Abbruch zu früh kommt

Die erste Schwachstelle betrifft den Umgang mit Speichermangel. Ein Abbruch kann erfolgen, während interne Daten erst teilweise initialisiert sind. Beim späteren Aufräumen kann dieser unvollständige Zustand fälschlich als gültig behandelt werden.

Stell dir eine Umzugsliste vor, auf der einige Kartonnummern noch fehlen. Bricht die Vorbereitung ab, darf ein anschließender Aufräumprozess nicht so handeln, als sei jeder Eintrag vollständig. In Software sind solche falschen Annahmen über Speicher besonders gefährlich.

Das PHP-Advisory zu CVE-2026-109618 bestätigt unauthentifizierte Codeausführung mit den Rechten des Web-Workers. Wie zuverlässig ein bestimmter Angriff funktioniert, hängt unter anderem vom Build, von den Erweiterungen und vom Speicherlayout ab.

CVE-2026-109619: Ein Verweis bleibt zu lange erhalten

Bei der zweiten Schwachstelle kann langlebiger Prozesszustand auf Speicher zeigen, der zu einer bereits beendeten Anfrage gehörte. Der Speicher wurde freigegeben, der Verweis aber nicht rechtzeitig zurückgesetzt. Eine spätere Verarbeitung greift dann darauf zu.

Das nennt sich Use-after-free: Die bisherige Verwendung des Speichers ist beendet, trotzdem wird er über einen alten Bezug weiter benutzt. Vereinfacht entspricht das einem alten Abholschein für ein Fach, das inzwischen ganz anderen Inhalt hat.

Das PHP-State-Advisory beschreibt mehrere mögliche Wege. Manche hängen von Einstellungen oder dem Verhalten der Anwendung ab. Deshalb ist die Aussage „jede Anfrage übernimmt jeden PHP-Server“ unzutreffend.

Was 9,2 von 10 Punkten bedeutet

Beide ursprünglichen Lücken werden mit CVSS v4 9,2 bewertet. Die Advisories nennen zugleich hohe Angriffskomplexität und zusätzliche Angriffsvoraussetzungen. Das widerspricht sich nicht: Eine Schwachstelle kann schwer auszunutzen sein und im Erfolgsfall große Schäden ermöglichen. Quellen: OOM-Advisory, State-Advisory.

CVSS beschreibt Eigenschaften und Schweregrad einer Schwachstelle. Der Wert ist keine Wahrscheinlichkeit, mit der ein Server übernommen wird, und keine Zählung erfolgreicher Angriffe. Für eine konkrete Risikobewertung kommen die eigene Umgebung und die aktuelle Bedrohungslage hinzu. Quelle: FIRST-Spezifikation.

Auch Remote Code Execution, kurz RCE, braucht eine genaue Übersetzung: Fremder Code läuft im betroffenen Prozess. Seine Möglichkeiten hängen zunächst von dessen Rechten ab. Vollständiger Administrator- oder Root-Zugriff folgt daraus nicht automatisch.

Bei Apache mit mod_php wurden besonders direkte Angriffswege nachgewiesen. Andere Betriebsarten sind deshalb nicht grundsätzlich sicher. Das State-Advisory bestätigt beispielsweise einen FPM-Weg über den Session-Lebenszyklus, der passendes Anwendungsverhalten voraussetzt. Eine technische Voraussetzung einer Variante darf nicht stillschweigend für alle Varianten gelten.

Was über Angriffe belegt ist

In Berichten über Sicherheitslücken werden oft mehrere Stufen vermischt:

Beobachtung	Was sie belegt	Was daraus noch nicht folgt
Ein Programm stürzt durch einen Test ab	Ein Fehler lässt sich auslösen	Verlässliche fremde Codeausführung
RCE gelingt in einer Versuchsumgebung	Ein konkreter Angriffsweg funktioniert	Derselbe Erfolg auf allen Installationen
Ein Sensor erfasst verdächtige Anfragen	Es gibt Angriffsversuche	Eine produktive Website wurde übernommen
Ein Incident wird untersucht und bestätigt	Ein konkreter Einbruch ist nachgewiesen	Eine weltweite Opferzahl

AWS berichtet von einem PHP2Shell-Versuch, den das MadPot-Beobachtungsnetz bereits am 17. Oktober registrierte. Der Bericht sagt ausdrücklich, dass unklar sei, ob diese Versuche auf realen Systemen erfolgreich gewesen wären. Quelle: AWS.

CrowdStrike meldete am 23. Oktober, innerhalb der eigenen Sichtbarkeit keine erfolgreiche Ausnutzung beobachtet zu haben. Das Unternehmen erläutert außerdem die Hürden zwischen einem Absturznachweis und einem zuverlässig nutzbaren RCE-Angriff. Diese begrenzte Beobachtung ist keine weltweite Entwarnung. Quelle: CrowdStrike.

Auch das niederländische NCSC präzisierte am 23. Oktober seine Einschätzung: Ausnutzung sei komplex, eine großflächige Welle weniger wahrscheinlich als zunächst angenommen. Ein möglicher Auslandsfall blieb unbestätigt. Die Empfehlung zum schnellen Patchen blieb bestehen. Quelle: NCSC-NL.

Diese Seiten wurden für den Artikel erneut gelesen. Ihr Abruf am 30. Oktober macht die darin datierten Beobachtungen nicht zu einer neuen weltweiten Bestandsaufnahme. Eine belastbare globale Zahl erfolgreich übernommener Websites lässt sich daraus nicht ableiten.

Weshalb ein Dienstausfall keinen Hack beweist

Passbolt Cloud wurde am 21. Oktober vorsorglich von 14:30 bis 17:25 Uhr CEST offline genommen, während der Anbieter die Korrektur ausrollte. In seinem Incident-Bericht nennt Passbolt keine gefundenen Spuren einer Ausnutzung. Quelle: Passbolt.

Wer nur die nicht erreichbare Website sah, konnte daraus nicht erkennen, ob ein Angriff stattgefunden hatte. Die Unterbrechung war hier eine Schutzmaßnahme. Dieses Beispiel zeigt, warum Statusmeldungen des betroffenen Anbieters wichtiger sind als Spekulationen über einen Ausfall.

Welche PHP-Versionen die ursprünglichen Lücken schließen

Die ersten korrigierten Releases vom 21. Oktober sind:

PHP-Zweig	Erstes korrigiertes Release für die beiden ursprünglichen CVEs
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

Die Versionsangaben stammen aus den PHP-Advisories. Sie sind Mindeststände für diese Fehler, keine Empfehlung, zukünftige Sicherheitsupdates auszulassen.

Wichtig ist die tatsächlich verwendete PHP-Laufzeit. Ein WordPress-, Theme- oder Plugin-Update ersetzt ihre Korrektur nicht. Wer PHP nicht selbst verwaltet, sollte sich den Patchstand vom Hosting-Anbieter bestätigen lassen. Quelle: Automattic.

Ein installiertes Paket reicht nicht immer

Ein aktualisiertes Paket auf der Festplatte hilft erst, wenn auch die laufenden Prozesse die korrigierte Version verwenden. Bei Containern müssen aktualisierte Images tatsächlich ausgerollt werden. Ein neu veröffentlichtes Installationsimage ändert bereits laufende Instanzen nicht von allein. Solche Unterschiede erläutert beispielsweise die Passbolt-Betriebsanleitung zum Vorfall.

Bei älteren Paketen können Anbieter Sicherheitskorrekturen zurückportieren. Die sichtbare Hauptversionsnummer allein ist daher kein vollständiger Patchnachweis. PHP nennt außerdem ausnahmsweise minimale Quellcode-Backports für 7.4, 8.0 und 8.1. Das hebt deren reguläres Supportende nicht auf. Quelle: PHP-Archiv.

Wie Distributionen Softwarepakete bündeln und pflegen, erklärt der Überblick zu Linux-Distributionen und ihren Update-Modellen. Für einen konkreten Sicherheitsfix bleibt die Meldung des jeweiligen Paketanbieters maßgeblich.

Zwei Nachträge, die nicht verwechselt werden dürfen

Der Session-Upload-Nachtrag vom 23. Oktober

Unter CVE-2026-115560 wurde ein weiterer, ungewöhnliche Konfiguration und Anwendungsverhalten voraussetzender Weg angekündigt. Er betrifft Session-Upload-Fortschritt und einen Wechsel des Serialisierungsverfahrens während der Ausführung. Die ursprünglichen Updates schließen diesen zusätzlichen Fall nicht. Quelle: CERT-EU.

PHP empfiehlt dafür vorübergehend session.upload_progress.enabled=0 und kündigt eine Korrektur im nächsten regulären Fehlerbehebungsrelease an. Dieser Hinweis steht beim Abruf am 30. Oktober weiterhin im PHP-Archiv. Ein inzwischen erschienener Fix wird hier deshalb nicht behauptet.

Neue Windows-Pakete vom 26. Oktober

PHP veröffentlichte außerdem Windows-Builds mit dem Suffix -1: 8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1. Sie enthalten Brotli 1.2.1 gegen die separate CVE-2026-111497. Die PHP-Runtime-Version bleibt unverändert. Das ist kein Beleg für eine Korrektur der zusätzlichen Session-CVE. Quelle: PHP-Meldung vom 26. Oktober.

Welche Rolle KI bei der Entdeckung spielte

Die PHP Foundation beschreibt frühe Hinweise im Umfeld der Sicherheitsprüfung von 2024. Unterschiedliche Reparaturansätze brachten Kompatibilitäts- und Betriebsrisiken mit sich; die Foundation benennt außerdem Ressourcen- und Entscheidungsprobleme. Quelle: Foundation-Rückblick.

Wiz nennt Atlas, Gemini 4 Argon und GPT-5.6 Sol als Unterstützung bei Forschung, Angriffsnachweisen und Validierung. Das ist ein Bericht eines Beteiligten, kein unabhängiger Modellvergleich. Forschende und PHP-Maintainer bleiben zentrale Akteure der Untersuchung und Reparatur. Quelle: Wiz.

Die technischen Fähigkeiten eines Modells und die Zuverlässigkeit eines vollständigen Arbeitsablaufs sind auch im Artikel zu Gemini 4 Argon getrennte Fragen. Ein entdeckter Fehler muss eingeordnet, korrigiert und als wirksames Update bei den Betreibern ankommen.

Für eine eigene Website ergibt sich daraus ein klarer Prüfpfad: Zuständigkeit klären, den konkreten Laufzeit-Patchstand bestätigen, laufende Instanzen berücksichtigen und die gesonderten Nachträge prüfen. Bei Verdachtszeichen gehört außerdem eine Untersuchung der bisherigen Aktivitäten dazu. Ein Update schließt einen Fehler; es beantwortet nicht rückwirkend, was zuvor auf dem Server passiert ist.