CVE-2026-109618 und CVE-2026-109619 im Fokus
Stand 21. Oktober 2026
Zwei kritische Sicherheitslücken in PHP setzen Betreiber von Webdiensten unter erheblichen Zeitdruck. CVE-2026-109618 und CVE-2026-109619 können die Ausführung fremden Codes ohne vorherige Anmeldung ermöglichen. Beide sind mit CVSS v4.0 9,2 bewertet. Die Sicherheitsupdates wurden am 21. Oktober 2026 um 13:30 Uhr UTC veröffentlicht, also um 15:30 Uhr mitteleuropäischer Sommerzeit.
Welche betrieblichen Folgen bereits die Gefährdung haben kann, zeigen die Niederlande. Die Regierung meldete am 21. Oktober vorsorgliche Abschaltungen, darunter Overheid.nl, MijnOverheid.nl und DigiD. Ihre Mitteilung dokumentiert eine Schutzentscheidung; sie ist kein Nachweis erfolgreicher Angriffe auf diese Dienste.
Für Unternehmen stellt sich damit eine konkrete Aufgabe: Sie müssen ihre betroffenen Laufzeiten finden, verfügbare Korrekturen in den tatsächlichen Betrieb bringen und über den Umgang mit Diensten entscheiden, die bis dahin verwundbar bleiben. Der Sammelname PHP2Shell steht für zwei verwandte Fehlerklassen mit unterschiedlichen Angriffswegen. Diese Unterschiede sind für die Bewertung der eigenen Umgebung wesentlich.
Die Schwachstellen liegen unterhalb der Anwendung
Die Fehler betreffen die PHP-Laufzeit, also die Software, die PHP-Anwendungscode auf dem Server ausführt. Ein aktualisiertes Content-Management-System oder ein korrigiertes Plugin beseitigt diese Laufzeitfehler allein nicht. Cloudflare weist ausdrücklich darauf hin, dass die darunterliegende PHP-Software aktualisiert werden muss. Bei verwaltetem Hosting liegt diese Aufgabe häufig beim Dienstleister.
Das PHP-Projekt stuft sämtliche Installationen, die Webanfragen verarbeiten, als gefährdet ein. Genannt werden PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Daraus folgt eine breite Prüfaufgabe für Betreiber. Daraus folgt jedoch nicht, dass dieselbe Anfrage jede dieser Konfigurationen auf identische Weise kompromittieren kann.
Hinzu kommt indirekte Nutzung: Das niederländische NCSC verweist auf PHP in Appliances, Netzwerkgeräten und Managementoberflächen. Dort lässt sich die Laufzeit oft nur über ein Produktupdate des Herstellers ersetzen. Eine Bestandsaufnahme allein anhand öffentlich sichtbarer Websites erfasst solche Abhängigkeiten nicht vollständig.
CVE-2026-109618 und der Abbruch bei Speichermangel
Die erste Lücke entsteht beim Umgang mit Speichermangel, technisch Out-of-Memory oder OOM. PHP kann die Verarbeitung einer Anfrage dabei abrupt mit longjmp() verlassen. Geschieht das während einer unvollständigen Initialisierung, bleiben interne Daten in einem ungültigen Zustand zurück. Die anschließende Aufräumroutine kann diese Daten dennoch wie gültige Strukturen behandeln. Aus einem Speicherfehler kann so die Ausführung fremden Codes werden.
Besonders kritisch ist Apache mit mod_php. Diese Betriebsart führt das Aufräumen auch nach einem fehlgeschlagenen Start der Anfrage aus. Ein nachgewiesener Angriff setzt bereits bei der Verarbeitung der Eingabedaten an, bevor der Anwendungscode läuft. Eine Anmeldung innerhalb der Anwendung liegt dann zu spät im Ablauf, um diesen Weg zu verhindern.
PHP-FPM beendet bei einem fehlgeschlagenen Start den betroffenen Worker. Damit entfällt genau dieser frühe Angriffsweg. Fehler nach erfolgreichem Start bleiben jedoch relevant. FPM darf deshalb nicht als pauschal geschützte Alternative behandelt werden. Eine vorgeschaltete Zugangskontrolle, die Anfragen bereits vor PHP abweist, ist technisch von einer Anmeldung innerhalb der PHP-Anwendung zu unterscheiden.
CVE-2026-109619 und der Zustand aus früheren Anfragen
Die zweite Lücke betrifft die Grenze zwischen aufeinanderfolgenden Anfragen. Ein Worker, also ein weiterlaufender Bearbeitungsprozess, kann Zustandsinformationen behalten, die noch auf Speicher einer abgeschlossenen Anfrage zeigen. Dieser Speicher ist bereits freigegeben. Verwendet eine spätere Anfrage desselben Workers solche Verweise vor der regulären Neuinitialisierung, entsteht ein Use-after-free: ein Zugriff auf nicht mehr gültigen Speicher.
Für eine Ausnutzung braucht es eine Operation, die den problematischen Zustand hinterlässt, und eine spätere Operation, die ihn verwendet. Fatale Fehler und bestimmte Diagnose- oder Session-Abläufe können daran beteiligt sein. PHP bestätigt einen Angriffsweg über die Verarbeitung des Upload-Fortschritts sowohl für mod_php als auch für FPM. Bei FPM hängt dieser Weg von einer geeigneten Operation während der Anwendungsausführung ab.
Die bestätigten Auswirkungen reichen bis zur Preisgabe von Speicherinhalten und zur Codeausführung mit den Rechten des Web-Workers. Das bedeutet nicht automatisch Administratorrechte auf dem gesamten Rechner. Für den Schutzbedarf ist dennoch erheblich, auf welche Dateien, Datenbanken und Zugangsdaten dieser Prozess zugreifen darf.
KI verändert die praktische Ausnutzbarkeit
Die Bedeutung von KI lässt sich hier an konkreter Forschungsarbeit beschreiben. Wiz berichtet, dass Modelle bei der Analyse, beim wiederholten Testen und bei der Anpassung funktionierender Exploits an unterschiedliche Anwendungen und Speicheranordnungen halfen. Nach Darstellung des Teams wurde damit eine Anpassung innerhalb von Stunden möglich. Wiz demonstrierte Angriffe auf Installationen von WordPress, Drupal und Joomla sowie das Auslesen sensibler Prozessdaten. Die Anwendungen dienten als Demonstrationsziele; der Fehler liegt in PHP selbst.
Die Arbeiten begannen deutlich vor dem Veröffentlichungstag. Calif beschreibt einen ersten Fund Anfang August und eine Meldung an PHP am 11. August. Wiz untersuchte die Fehler unabhängig und meldete seine Ergebnisse am 24. August. OpenAI schildert die anschließende Zusammenarbeit mit Forschern, PHP-Verantwortlichen und Infrastrukturbetreibern zur Vorbereitung von Korrekturen und Schutzmaßnahmen.
Für die Risikobewertung ergibt sich daraus eine fachliche Konsequenz: Hohe technische Komplexität bietet weniger verlässlichen zeitlichen Schutz, wenn Analyse und Anpassung beschleunigt werden. Das erlaubt keine belastbare Prognose, wie schnell ein bestimmter Angreifer eine bestimmte Installation übernehmen kann. Es spricht aber dagegen, verfügbare Updates allein deshalb aufzuschieben, weil die veröffentlichten Fehler schwierig erscheinen.
Die korrigierten Versionen sind verfügbar
Für die unterstützten PHP-Zweige stehen seit dem 21. Oktober die folgenden Korrekturen bereit. Die genannten Versionen beheben beide Lücken.
PHP-Zweig
Erste korrigierte Version
8.2
8.2.35
8.3
8.3.36
8.4
8.4.27
8.5
8.5.12
Bei Distributions- und LTS-Paketen ist die Sicherheitsmeldung des jeweiligen Lieferanten maßgeblich. Ein zurückportierter Fix kann enthalten sein, obwohl die sichtbare Versionsnummer unter einer der genannten Upstream-Versionen liegt. Für PHP 7.4, 8.0 und 8.1 hat das PHP-Team angesichts der Schwere außerdem minimale Quellcode-Backports bereitgestellt. Das bedeutet keine Wiederaufnahme des regulären Supports dieser alten Zweige.
Betreiber älterer Anwendungen sollten deshalb zwei Entscheidungen getrennt treffen: die kurzfristige Absicherung mit einem nachweislich korrigierten Paket und den Umstieg auf eine regulär unterstützte Plattform. Eine langfristige Migration darf den unmittelbar verfügbaren Sicherheitsfix nicht aufhalten; ein Notfallfix ersetzt wiederum keine tragfähige Wartungsperspektive.
Der Patch muss den laufenden Dienst erreichen
Das NCSC empfiehlt, Laufzeitversionen, Drittanbieter-Images und eingebettete PHP-Komponenten gesondert zu prüfen. Seine Produktübersicht ist eine Hilfestellung und keine abschließende Liste. Ein dort nicht genanntes Produkt ist daher nicht automatisch unbetroffen. Für ausgelagerte Dienste sollte der Lieferant den Status des konkret eingesetzten Produkts und seiner PHP-Komponente bestätigen.
Wie viele Schritte zwischen Veröffentlichung und Schutz liegen können, zeigt die Mitteilung des Container-Image-Anbieters serversideup. Sie beschreibt die Abhängigkeit von PHP-Releases, den offiziellen Docker-Images und den darauf aufbauenden eigenen Builds. Erst anschließend können Kunden aktualisierte Images einsetzen. Für festgeschriebene ältere Release-Tags oder konkrete alte PHP-Versionen ist eine bewusste Umstellung erforderlich.
Daraus lässt sich ein sinnvoller betrieblicher Nachweis ableiten. Für jeden betroffenen Dienst sollte feststehen, welcher Host, Container oder verwaltete Dienst die Anfragen tatsächlich verarbeitet, welches korrigierte Paket beziehungsweise Image dort eingesetzt wird und wann die Umstellung erfolgt ist. Anschließend muss geprüft werden, dass sämtliche aktiven Instanzen die neue Laufzeit verwenden. Eine Versionsanzeige in einer beliebigen Administrations-Shell reicht dafür nicht aus, wenn der Webdienst eine andere Installation nutzt.
Zur Umstellung gehören die vorgesehenen Neustarts oder ein vollständiges erneutes Deployment. Bei mehreren Instanzen verdient die letzte noch aktive alte Instanz dieselbe Aufmerksamkeit wie die erste aktualisierte. Auch Vorlagen für automatisch hinzukommende Instanzen müssen korrigiert sein. Sonst kann die nächste Skalierung den verwundbaren Stand erneut in den Betrieb bringen.
Die fachliche Funktionsprüfung sollte die Wege abdecken, auf die der jeweilige Dienst angewiesen ist: Anmeldung, Dateiübertragung, Importe, Formularverarbeitung und angebundene Geschäftsabläufe. Für einen Dienst ohne Uploads ist eine andere Auswahl sinnvoll als für ein Kundenportal mit Dokumenteneingang. Ziel ist ein überprüfter, nutzbarer Dienst mit korrigierter Laufzeit.
WAF und Konfigurationsänderungen schaffen begrenzten Schutz
Cloudflare berichtet über ausgerollte WAF-Schutzmaßnahmen und empfiehlt dennoch ausdrücklich das PHP-Update. Der Anbieter beschreibt außerdem die Auswertung zusammengehöriger Anfragen und Antworten, weil die Anfrage allein nicht immer ausreichend zwischen Angriff und legitimer Nutzung unterscheiden lasse. Daraus lässt sich keine allgemeine Schutzgarantie für eine beliebige Web Application Firewall ableiten.
CERT-EU betont ebenfalls, dass Konfigurationsänderungen nur einzelne Angriffswege begrenzen. Dazu zählen die Deaktivierung der Upload-Fortschrittsfunktion und, unter PHP 8.5, bestimmter Fehler-Backtraces. Solche Einstellungen müssen an der richtigen Stelle greifen; die betroffenen Worker sind neu zu starten. Eingriffe in das PHP-Speicherlimit bleiben ebenfalls unvollständig und verlangen eine passende Begrenzung der Ressourcen außerhalb von PHP.
Für den Betrieb bedeutet das: Jede Zwischenmaßnahme braucht einen benannten Geltungsbereich, eine Prüfung ihrer Wirksamkeit und einen Termin für den vollständigen Fix. Eine Maßnahme, die einen bekannten Weg erschwert, sollte nicht als Beleg gelten, dass sämtliche Varianten ausgeschlossen sind. Bei einer WAF muss zudem der relevante Verkehr tatsächlich durch die Schutzschicht laufen; ein direkt erreichbarer Ursprungserver gehört in dieselbe Prüfung.
Angriffsversuche und erfolgreiche Kompromittierung unterscheiden
Die Lage ist bereits dynamisch. Cloudflare meldet am 21. Oktober beobachteten Angriffsverkehr und Änderungen an Angriffsdaten, mit denen Schutzregeln umgangen werden sollten. Das belegt Angriffsversuche. Es liefert keine belastbare Zahl erfolgreich kompromittierter Systeme und keinen Nachweis einer flächendeckenden Übernahme betroffener Webdienste.
Wiz nennt für die Untersuchung unter anderem ungewöhnliche Multipart-Anfragen zusammen mit Speicherfehlern, wiederholte Serverfehler, auffällige Session-Cookies und unerklärliche Worker-Neustarts. Diese Hinweise sind Anhaltspunkte für eine Untersuchung. Einzelne Fehler können auch andere Ursachen haben; umgekehrt sind unauffällige Anwendungsprotokolle kein umfassender Sicherheitsnachweis.
Patchen und die Prüfung einer möglichen Kompromittierung beantworten unterschiedliche Fragen. Das Update behebt die dokumentierten Laufzeitfehler. Ob zuvor bereits Daten abgeflossen oder Veränderungen vorgenommen worden sind, muss gesondert untersucht werden. Bei konkreten Verdachtsmomenten sollten Protokolle und weitere Spuren gesichert, mögliche Zugriffe auf Geheimnisse bewertet und die zuständigen Incident-Response-Verantwortlichen eingebunden werden. Ein notwendiger Austausch von Zugangsdaten richtet sich nach dieser Bewertung.
Über den Weiterbetrieb muss rechtzeitig entschieden werden
CERT-EU empfiehlt, die Isolation öffentlich erreichbarer Anwendungen zu erwägen, wenn ein sofortiges Update nicht möglich ist. Das niederländische NCSC formuliert strenger und rät dazu, noch nicht aktualisierte Systeme vorsorglich offline zu halten. Diese Empfehlungen zeigen, dass eine zeitweilige Einschränkung Teil einer geordneten Sicherheitsreaktion sein kann.
Für Unternehmen braucht diese Entscheidung eine betriebliche Grundlage. Wie kritisch ist der Dienst für die nächsten Stunden? Welche Daten und Berechtigungen wären bei einer Übernahme erreichbar? Gibt es einen belastbaren Updatezeitpunkt? Lassen sich Funktionen eingeschränkt anbieten, während die betroffene Verarbeitung abgeschaltet bleibt? Die Antworten verbinden die technische Gefährdung mit den Folgen für Kunden, Beschäftigte und Geschäftspartner.
Die Entscheidung kann je nach Dienst unterschiedlich ausfallen. Bei einer Informationsseite lässt sich möglicherweise eine statische Ersatzseite bereitstellen. Ein Transaktionsportal benötigt gegebenenfalls einen anderen Annahmeweg, eine geregelte Bearbeitung auflaufender Vorgänge und eine Information an die Nutzer. Solche Ersatzverfahren müssen zur tatsächlichen Aufgabe passen. Ein vorgeschlagenes Ausweichverfahren hilft wenig, wenn es dieselbe gefährdete PHP-Komponente voraussetzt.
Auch die Wiederfreigabe sollte vorab einen verantwortlichen Entscheider und klare Nachweise haben: Korrektur auf allen aktiven Instanzen, erfolgreiche Prüfung der wesentlichen Funktionen, Bewertung vorhandener Verdachtsmomente und eine kontrollierte Rückkehr aus vorläufigen Schutzmaßnahmen. Ein Rückfall auf ein altes Image muss berücksichtigt werden, damit eine technische Störung nach dem Update nicht unbemerkt wieder zur ursprünglichen Verwundbarkeit führt.
Ein hilfreicher Lagebericht nennt deshalb je kritischem Dienst den belegten Schutzstatus, offene technische Schritte, die verbleibende Einschränkung und den nächsten Entscheidungstermin. Damit kann eine Geschäftsverantwortliche beurteilen, welche Leistung verfügbar ist und wo sie eine bewusste Risikoentscheidung treffen muss. Eine reine Anzahl abgeschlossener Update-Tickets sagt darüber wenig aus.
Die Lehre reicht bis zur Wartung der gemeinsamen Grundlage
Die PHP Foundation beschreibt eine bemerkenswerte Vorgeschichte. Erste Hinweise auf das OOM-Problem lagen bereits 2024 vor. Die Behebung stockte unter anderem wegen schwieriger Abwägungen zwischen Kompatibilität, möglichen neuen Verfügbarkeitsproblemen und Auswirkungen auf Erweiterungen. Hinzu kamen knappe personelle Ressourcen und ein Entscheidungsprozess, der keine zügige Lösung hervorbrachte. Mit konkreten RCE-Nachweisen im August 2026 wurde die Behebung zur höchsten Priorität.
Auch die Veröffentlichung geriet unter Druck. Nach Angaben der Foundation zirkulierten die CVE-Kennungen vorzeitig; daraufhin wurde der Release vom 22. auf den 21. Oktober vorgezogen. Diese Darstellung macht deutlich, dass zu einer Sicherheitskorrektur auch Abstimmung, Paketbau und die Vorbereitung der Betreiber gehören. Eine fertige Änderung am Quellcode allein schützt die installierte Basis noch nicht.
Für Organisationen, deren Geschäftsprozesse von PHP abhängen, folgt daraus eine dauerhafte Aufgabe. Sie brauchen gepflegte Bestände, verlässliche Lieferantenkontakte, vorbereitete Updatewege und Personen, die technische Restrisiken mit betrieblichen Folgen zusammenführen können. Auch die Wartungsfähigkeit zentraler Open-Source-Komponenten gehört in die Bewertung solcher Abhängigkeiten.
PHP2Shell zeigt, wie eng Speicherverwaltung und Geschäftsbetrieb verbunden sein können. Sobald eine grundlegende Laufzeit betroffen ist, entscheidet die gesamte Umsetzungskette über die Dauer der Gefährdung. Ein belastbarer Abschluss ist erreicht, wenn die korrigierte Software nachweislich auf allen relevanten Instanzen läuft, der Dienst fachlich funktioniert und mögliche Folgen einer vorherigen Ausnutzung bewertet sind.
Quellen
[1] CERT-EU · Critical Vulnerabilities in PHP · Security Advisory 2026-018, aktualisiert am 21. Oktober 2026; Releasezeit, Bewertung und Gegenmaßnahmen.
[2] PHP · Security advisory und Sicherheitsreleases · 21. Oktober 2026; betroffene Betriebsarten, korrigierte Versionen und Backports.
[3] Rijksoverheid · Vorsorgliche Abschaltung von Websites · 21. Oktober 2026, 15:13 Uhr, mit Updatehinweis; unter anderem Overheid.nl, MijnOverheid.nl und DigiD.
[4] Cloudflare · Protections against php2shell · 21. Oktober 2026; beobachtete Angriffsversuche und ergänzende WAF-Schutzmaßnahmen.
[5] NCSC-NL · PHP2Shell Operational Information · Stand 21. Oktober 2026; Bestandsaufnahme und eingebettete PHP-Komponenten.
[6] PHP · CVE-2026-109618 RCE via OOM corruption · Hersteller-Advisory GHSA-w8hw-w9fx-j79w, 21. Oktober 2026.
[7] PHP · CVE-2026-109619 RCE via stale global state · Hersteller-Advisory GHSA-6wmf-4rv5-p3rp, 21. Oktober 2026.
[8] Wiz Research · PHP2Shell · 21. Oktober 2026; Forschungsergebnisse, KI-Unterstützung und Untersuchungshinweise. Aussagen zur Forschung sind Eigenangaben des Teams.
[9] Calif Research · PHP2Shell · Forschungsbericht mit Entdeckungs- und Meldungszeitachse; abgerufen am 21. Oktober 2026.
[10] OpenAI · Patch the Planet · 21. Oktober 2026; Eigenbericht zur koordinierten Reaktion mit PHP und Forschungspartnern.
[11] serversideup · Critical PHP security release · Maintainer-Mitteilung vom 21. Oktober 2026; Lieferkette von Container-Images und Umgang mit Versions-Tags. Dynamischer Veröffentlichungsstatus.
[12] NCSC · Patches beschikbaar update nu · 21. Oktober 2026; aktuelle Handlungsempfehlung einschließlich vorsorglicher Abschaltung.
[13] PHP Foundation · Today’s PHP Security Release · 21. Oktober 2026; Vorgeschichte, Ressourcen- und Entscheidungsprobleme sowie koordinierte Veröffentlichung.
