Kritische PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619: Was Sie wissen müssen

Am 21. Oktober 2026 hat das PHP-Sicherheitsteam PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, um CVE-2026-109618 und CVE-2026-109619 zu beheben. Beide Schwachstellen sind nach CVSS v4.0 mit 9,2 bewertet und können auf jeder PHP-Installation, die Web-Requests verarbeitet, zu einer Remote-Code-Ausführung ohne Authentifizierung führen. Das PHP-Team stuft mod_php als die Bereitstellungsvariante mit dem höchsten Risiko ein: Hier existiert ein nachgewiesener Exploit, der greift, bevor überhaupt Anwendungscode ausgeführt wird. Nur ein Update behebt das Problem vollständig. Red Sift hat den Hardenize-Kundenstamm nach Hosts mit PHP durchsucht und betroffene Kunden direkt benachrichtigt.

• Jede PHP-Version ab PHP 5 kann betroffen sein – unter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed.
• Für PHP 8.1 und älter gibt es kein offizielles Release. Nutzen Sie einen Backport Ihres Anbieters, die reinen Quellcode-Patches des PHP-Teams für 7.4, 8.0 und 8.1 oder führen Sie ein Upgrade durch.
• Konfigurationsänderungen verringern die Angriffsfläche für bekannte Angriffswege, machen eine Installation aber nicht sicher.
• PHP ist häufig in Appliances und Drittanbieterprodukten enthalten. Eine Versionsprüfung auf Ihren eigenen Servern liefert daher kein vollständiges Bild.

PHP betreibt einen großen Teil des serverseitigen Webs – von Content-Management-Systemen bis hin zu Admin-Oberflächen auf Netzwerk-Appliances. Ein Fehler, der es einer anonymen Anfrage erlaubt, Code in der PHP-Laufzeitumgebung selbst auszuführen, unabhängig von der darauf laufenden Anwendung, hat eine nahezu maximale Reichweite für eine Web-Schwachstelle.

Das PHP-Team hat am 20. Oktober eine Vorankündigung veröffentlicht und die Fixes am folgenden Tag ausgeliefert. Die nationalen CERTs reagierten schnell. CERT-EU forderte Organisationen auf, sich auf sofortiges Patchen vorzubereiten und zu erwägen, aus dem Internet erreichbare PHP-Anwendungen zu isolieren, bis Fixes verfügbar sind. Das britische NCSC rief Organisationen zu sofortigem Handeln auf – beginnend damit, jedes System zu identifizieren, auf dem PHP läuft.

Beide Fehler liegen in der Art und Weise, wie PHP den Request-bezogenen Zustand innerhalb eines Workers verwaltet, und nicht im Anwendungscode.

• CVE-2026-109618, RCE durch Speicherbeschädigung bei Speichermangel (OOM) (GHSA-w8hw-w9fx-j79w). Ein Out-of-Memory-Zustand kann PHP unterbrechen, während interne Request-Daten erst teilweise initialisiert sind. Die anschließende Request-Bereinigung behandelt diese halbfertigen Daten als gültig und beschädigt dadurch den Speicher. Unter bestimmten Bedingungen kann ein Angreifer, der eine Anfrage in den OOM-Pfad lenken kann, diese Speicherbeschädigung ausnutzen, um Code auszuführen.
• CVE-2026-109619, RCE durch veralteten globalen Zustand (GHSA-6wmf-4rv5-p3rp). Interner Zustand, der zu einem Request gehört, kann den Speicher überdauern, auf dem er basiert. Eine spätere Anfrage, die vom selben Worker verarbeitet wird, kann diesen veralteten Zustand verwenden, bevor die normale Initialisierung ihn zurücksetzt – das Ergebnis ist ein Use-after-free über Request-Grenzen hinweg.

Der zweite Fehler ist vor allem für langlebige Worker relevant – und genau so arbeiten PHP-FPM, mod_php und FrankenPHP. Das PHP-Team stuft mod_php als die riskanteste Konfiguration ein, weil der nachgewiesene Exploit bereits beim Parsen der Anfrage ausgelöst wird, noch bevor Ihre Anwendung die Anfrage sieht. Eine WAF-Regel, die an Anwendungsrouten gebunden ist, erkennt ihn daher nicht.

Jede PHP-Installation, die Web-Requests verarbeitet, ist betroffen. Das umfasst PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. CERT-EU weist darauf hin, dass jede Version ab PHP 5 betroffen sein kann. Eine alte Versionsnummer ist also kein Grund, einen Host niedriger zu priorisieren – im Gegenteil: Sie ist ein Grund, ihn weiter nach oben zu setzen, denn für PHP 8.1 und älter wird es kein offizielles Paket geben.

Schwieriger ist der Umgang mit PHP, das Sie nicht selbst installiert haben. Appliances, gehostete Dienste und Drittanbieteranwendungen liefern PHP häufig als interne Komponente mit. Diese Produkte werden erst abgesichert, wenn der jeweilige Anbieter ein Update veröffentlicht. NCSC-NL pflegt eine Übersicht über Software mit PHP-Abhängigkeit, die betroffen sein könnte – ein guter Ausgangspunkt für diesen Teil der Suche.

Noch vor dem PHP-Release haben wir die von uns überwachten Hosts im gesamten Hardenize-Kundenstamm gescannt, um festzustellen, auf welchen PHP läuft. Anschließend haben wir diese Hosts den jeweiligen Kunden zugeordnet und alle direkt Betroffenen kontaktiert – mit einer Liste potenziell exponierter Hostnamen, dem Release-Zeitpunkt und Links zu den offiziellen Advisories. So hatten Teams bereits vor der Veröffentlichung der gepatchten Versionen einen Überblick über ihre Gefährdung und konnten Wartungsfenster einplanen, statt erst nach dem Release mit der Bestandsaufnahme zu beginnen.

Wenn Sie Hardenize-Kunde sind und keine Benachrichtigung erhalten haben, haben wir auf den Hosts, die wir für Sie überwachen, kein PHP gefunden. Wir empfehlen Ihnen dennoch, auf Ihrer Seite eine kurze Prüfung durchzuführen. Externes Scanning erkennt nur, was ein Host preisgibt, und deckt nur die Assets in Ihrem Konto ab. Interne Systeme, Hosts außerhalb Ihres überwachten Bereichs und Produkte, die ihre PHP-Laufzeitumgebung verbergen, müssen Sie weiterhin selbst prüfen.

Wenn Sie betroffen sind, patchen Sie so schnell wie möglich alles, was sich patchen lässt. Alle Punkte auf dieser Liste betreffen Hosts, die Sie heute noch nicht patchen können.

• Identifizieren Sie jede PHP-Installation, beginnend mit aus dem Internet erreichbaren Hosts. Filtern Sie nicht nach Version, da alle Versionen betroffen sein können. Berücksichtigen Sie auch Container, Base-Images und alles, was aus dem Quellcode gebaut wurde.
• Aktualisieren Sie auf eine gepatchte Version. Wechseln Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder installieren Sie das gepatchte Paket Ihrer Distribution. Linux-Distributionen und LTS-Anbieter haben die Patches vorab erhalten. Wenn Sie rpms.remirepo.net nutzen, empfiehlt das PHP-Team, auf Distributionspakete umzusteigen oder aus dem Quellcode zu bauen, da dieses Repository keine Updates am selben Tag bereitgestellt hat.
• Behandeln Sie End-of-Life-Branches. Nutzen Sie für 8.1 und älter einen Backport Ihres Anbieters, bauen Sie aus den Quellcode-Backports des PHP-Teams für 7.4, 8.0 oder 8.1 oder führen Sie ein Upgrade durch.
• Starten Sie jeden Worker neu. Ein gepatchtes Binary nützt nichts, solange FPM-Pools oder Apache-Kindprozesse noch den alten Code ausführen.
• Spüren Sie mitgeliefertes PHP auf. Prüfen Sie die Advisories der Anbieter von Appliances und Produkten, die PHP enthalten, und spielen Sie deren Updates ein, sobald sie verfügbar sind.
• Schützen oder isolieren Sie, was Sie nicht patchen können. Setzen Sie die unten beschriebenen Übergangsmaßnahmen um. Wenn das nicht möglich ist, raten CERT-EU und NCSC übereinstimmend dazu, die aus dem Internet erreichbare Anwendung bis zur Behebung vom Netz zu nehmen.
• Suchen Sie auf Hosts, die exponiert blieben, nach Anzeichen einer Kompromittierung. Das NCSC empfiehlt, auf allen Systemen, die Sie nicht zeitnah aktualisieren konnten, vor oder parallel zur Behebung nach Backdoors zu suchen.

• Setzen Sie memory_limit=-1 so, dass Anwendungen den Wert nicht überschreiben können, etwa per php_admin_value in der FPM-Pool- oder Apache-Konfiguration. Stellen Sie sicher, dass keine Pool-, Verzeichnis- oder Anwendungseinstellung wieder ein festes Limit setzt. Ein zugrunde liegender Allokationsfehler kann den verwundbaren Pfad dennoch erreichen.
• Senken Sie post_max_size auf 8M, wo keine Uploads benötigt werden, bzw. auf 32M, wo sie benötigt werden, und halten Sie upload_max_filesize darunter. Setzen Sie Limits für Request-Größe, Anzahl der Felder, Anzahl der Multipart-Teile, Anzahl der Header und Verschachtelungstiefe auf Webserver- oder Proxy-Ebene durch – auch für Anfragen ohne verwertbaren Content-Length-Header.
• Verwenden Sie ein Container- oder cgroup-Speicherlimit, das nur den betroffenen Worker beendet. Verwenden Sie nicht RLIMIT_AS oder RLIMIT_DATA, da diese den verwundbaren Allokationsfehler auslösen können.

• Setzen Sie session.upload_progress.enabled=0 in der php.ini, im FPM-Pool oder in der Serverkonfiguration und starten Sie anschließend jeden Worker neu. ini_set() und .user.ini greifen zu spät, um zu helfen.
• Setzen Sie unter PHP 8.5 fatal_error_backtraces=0 und starten Sie jeden Worker neu.
• Entfernen Sie ungültige oder veraltete Request-bezogene Einstellungen, die vor der Initialisierung Diagnosemeldungen ausgeben. Das Unterdrücken der Ausgabe mit error_reporting, display_errors oder @ hilft nicht.
• Beheben Sie Fatal Errors und Ausführungs-Timeouts, die ein Angreifer auslösen kann – auch in Callbacks, bei der Upload- oder Importverarbeitung und bei der Bereinigung.

Diese Maßnahmen blockieren die bestätigten Angriffswege, aber nicht jede Variante davon. Betrachten Sie sie als Überbrückung bis zum Patch.

Die erste Anweisung in den Advisories von CERT-EU und NCSC ist identisch: Finden Sie heraus, wo PHP läuft. Für die meisten Teams ist das der langwierigste Schritt, denn die Antwort verteilt sich über Cloud-Konten, übernommene Domains, Marketing-Websites und Hersteller-Appliances, die niemand auf einer Liste hat.

Red Sift Hardenize erkennt und überwacht kontinuierlich Ihre nach außen gerichteten und Cloud-Assets. Wird eine Schwachstelle auf Ebene der Laufzeitumgebung wie diese entdeckt, liegt die Liste der exponierten Hosts also bereits vor. Genau das ermöglicht es uns, Kunden mit konkreten Hostnamen zu benachrichtigen, noch bevor die gepatchten Versionen ausgeliefert werden.

• PHP-Sicherheitshinweis und Release-Ankündigungen, 20. und 21. Oktober 2026
• GHSA-w8hw-w9fx-j79w, CVE-2026-109618
• GHSA-6wmf-4rv5-p3rp, CVE-2026-109619
• CERT-EU Security Advisory 2026-018
• NCSC, kritische Sicherheitslücke in PHP
• NCSC-NL php2shell: Übersicht betroffener Software