Sicherheitshinweis: Kritische PHP-RCE-Sicherheitslücken werden derzeit untersucht
Veröffentlicht am 21. Oktober 2026
Schweregrad: Kritisch
Klassifizierung: Mögliche Sicherheitslücke, die die Ausführung von Remote-Code ermöglicht / Sicherheitslücke in einer Webanwendungsplattform
Betroffene Plattform: PHP-Webanwendungen und Server, auf denen potenziell anfällige PHP-Versionen laufen
TLP: LÖSCHEN
Zusammenfassung
Ontinue Cyber Defense hat Kenntnis von zwei kritischen PHP-Sicherheitslücken, die öffentlich als CVE-2026-109618 und CVE-2026-109619. Das PHP-Projekt hat offiziell zwei kritische Sicherheitslücken bekannt gegeben, die mit CVSS v4.0 9,2, wobei die Veröffentlichung der Sicherheitsversion für 21. Oktober 2026 um 14:00 Uhr UTC / 15:00 Uhr BST. Zum Zeitpunkt der Veröffentlichung hat das PHP-Projekt die bekannt gegebenen Sicherheitslücken noch nicht öffentlich mit diesen CVE-Kennungen in Verbindung gebracht.
In Berichten von Drittanbietern werden die Sicherheitslücken als potenziell geeignet beschrieben, eine nicht authentifizierte Remote-Codeausführung zu ermöglichen. Offizielle technische Details, betroffene Versionen, behobene Versionen, Voraussetzungen für die Ausnutzung sowie Informationen zur Grundursache wurden jedoch noch nicht veröffentlicht.
Derzeit untersucht Ontinue die Sicherheitslücken aktiv, prüft die verfügbaren technischen Details und führt eine „Threat Hunting“-Analyse der relevanten Kundentelemetriedaten durch. Sollten in einer Kundenumgebung Anzeichen für eine Ausnutzung festgestellt werden, wird Ontinue unseren standardmäßigen Prozess zur Meldung und Eskalation von Vorfällen über das ION-Portal befolgen.
Kunden, die PHP-Anwendungen mit Internetanbindung betreiben, sollten dies als ein Risiko mit hoher Priorität betrachten und damit beginnen, zu überprüfen, wo PHP in ihrer Umgebung eingesetzt wird.
Was wir wissen
- Offiziell bestätigt: Das PHP-Projekt hat ein Sicherheitsupdate für 21. Oktober 2026 um 14:00 Uhr UTC / 15:00 Uhr BST um zwei kritische Sicherheitslücken zu beheben, die beide als CVSS v4.0 9,2.
- CVE-Kennungen: CVE-2026-109618 und CVE-2026-109619 wurden zwar öffentlich erwähnt, scheinen jedoch auf durchgesickerten oder vorveröffentlichten Informationen zu beruhen und sind von PHP noch nicht offiziell bestätigt worden.
- Details folgen: PHP hat bislang noch keine Angaben zu betroffenen Versionen, behobenen Versionen, Informationen zur Ursache oder offiziellen technischen Details veröffentlicht.
- Öffentliche Berichterstattung: Quellen von Drittanbietern beschreiben ein potenzielles Risiko der nicht authentifizierten Remote-Code-Ausführung, das möglicherweise mit Multipart-Anfragen und der Verarbeitung des Upload-Fortschritts in PHP-Sitzungen zusammenhängt.
- Beobachtete PoC-Aktivität: Der im Umlauf befindliche Code nutzt manipulierte mehrteilige POST-Anfragen, übergroße Dateinamenfelder, eine feste PHPSESSID und ein Muster mit zwei Anfragen.
- Die Belichtung kann variieren: Das Risiko hängt von der PHP-Version, der Laufzeitkonfiguration, der Exposition der Anwendung sowie davon ab, ob Angreifer manipulierte Anfragen an betroffene PHP-Endpunkte senden können.
Wie es funktioniert
Der im Umlauf befindliche Proof-of-Concept-Code, der angeblich mit diesen Schwachstellen in Verbindung steht, scheint die Verarbeitung von Multipart-Formular-Uploads durch PHP in Kombination mit der Verfolgung des Upload-Fortschritts in der Sitzung auszunutzen. PHP verfügt über eine Funktion, mit der der Upload-Fortschritt verfolgt werden kann, indem während der Verarbeitung eines Datei-Uploads Metadaten zum Upload in die aktive Sitzung geschrieben werden.
Der Proof-of-Concept basiert auf einem Muster mit zwei Anfragen:
- Eine erste mehrteilige POST-Anfrage sendet mehrere Dateiteile mit extrem großen Dateinamenwerten und setzt dabei das Feld „PHP_SESSION_UPLOAD_PROGRESS“ sowie ein festes „PHPSESSID“-Cookie.
- Eine zweite mehrteilige POST-Anfrage verwendet dieselbe Sitzungskennung für einen kleineren Upload, offenbar mit dem Ziel, die Verarbeitung der zuvor geschriebenen Daten zum Fortschritt des Sitzungs-Uploads auszulösen.
Dieses Verhalten scheint darauf ausgelegt zu sein, eine fehlerhafte Verarbeitung von durch Angreifer kontrollierten Upload- und Sitzungsdaten auszulösen. Ontinue hat jedoch nicht unabhängig bestätigt, dass der im Umlauf befindliche Code eine der beiden gemeldeten Sicherheitslücken erfolgreich auslöst. Die zugrunde liegende Schwachstellenklasse und der Mechanismus, über den eine Codeausführung erreicht werden könnte, wurden bislang noch nicht offiziell bekannt gegeben. Der von Ontinue untersuchte Code enthält zwar keine vollständige, für Angriffe nutzbare Nutzlast, ist jedoch für defensive Analysen und die Bedrohungssuche relevant, solange offizielle Empfehlungen des Anbieters noch ausstehen.
Bin ich davon betroffen?
Zu den potenziell betroffenen Umgebungen zählen unter anderem PHP-basierte Content-Management-Systeme, E-Commerce-Plattformen, maßgeschneiderte Webanwendungen und ähnliche Dienste. Die Einordnung in diese Kategorien bedeutet nicht, dass eine Ausnutzung der Schwachstelle bei einem bestimmten Produkt bestätigt wurde. Die Anfälligkeit hängt von der zugrunde liegenden PHP-Version, der Konfiguration und der Bereitstellungsarchitektur ab.
- Content-Management-Systeme wie WordPress, Drupal, Joomla, Magento oder ähnliche Plattformen.
- Maßgeschneiderte PHP-Anwendungen, die Multipart-Formularübermittlungen oder Datei-Uploads unterstützen.
- Öffentliche Webserver, auf denen PHP-FPM, Apache mit mod_php, NGINX mit PHP-FPM oder containerisierte PHP-Workloads ausgeführt werden.
- Anwendungen, bei denen PHP-Sitzungen aktiviert sind und eine Funktion zur Anzeige des Upload-Fortschritts verfügbar ist.
Kunden sollten extern zugängliche PHP-Dienste identifizieren und die eingesetzten PHP-Versionen sowie die Laufzeitkonfiguration überprüfen. Besondere Aufmerksamkeit sollte dabei Systemen gelten, bei denen „session.upload_progress.enabled“ aktiviert ist und bei denen Angreifer speziell gestaltete Multipart-Anfragen an PHP-Endpunkte senden können.
Ontinue-Antwort
Unsere derzeitigen Maßnahmen umfassen:
- Prüfung öffentlich zugänglicher technischer Details und Proof-of-Concept-Materials.
- Bewertung potenzieller Angriffswege und Szenarien für das Kundenrisiko.
- Durchführung von Threat Hunting anhand relevanter Kundendaten zur Erkennung verdächtiger Webaktivitäten und Indikatoren für Sicherheitslücken.
- Überwachung hinsichtlich weiterer Anweisungen des Anbieters, bestätigter betroffener Versionen, Patches und Anzeichen für eine Kompromittierung.
- Entwicklung einer Erkennungs- und Triage-Logik, sobald zuverlässige technische Details und Indikatoren vorliegen.
Sollte Ontinue verdächtige oder bestätigte Ausnutzungsaktivitäten in einer Kundenumgebung feststellen, werden wir den Vorfall gemäß unserem Standardprozess über das ION-Portal melden und bearbeiten.
Empfohlene Maßnahmen für Kunden
Ontinue empfiehlt seinen Kunden, vorrangig die folgenden Maßnahmen zu ergreifen:
- PHP-Sicherheitslücken im Bestand: Ermitteln Sie alle internetexponierten und internen Systeme, auf denen PHP ausgeführt wird, einschließlich in der Cloud gehosteter, containerisierter und von Drittanbietern verwalteter Anwendungen.
- Hinweise des Monitor-Anbieters: Verfolgen Sie offizielle PHP-Projektmitteilungen und distributionsspezifische Updates für bestätigte betroffene Versionen und Patches.
- Patches umgehend installieren: Sobald Hersteller-Patches veröffentlicht und geprüft wurden, sollten Sie Updates für PHP-Anwendungen mit Internetanbindung vorrangig durchführen.
- Erwägen Sie vorübergehende Vorsichtsmaßnahmen: Prüfen Sie – vorbehaltlich von Tests und offiziellen Empfehlungen des Anbieters –, ob „session.upload_progress.enabled“ deaktiviert oder eingeschränkt werden kann. In den Empfehlungen der Community wird zudem empfohlen, nach Möglichkeit eine strenge Sitzungsverwaltung zu aktivieren; diese Maßnahmen sollten als Schritte zur Risikominderung betrachtet werden und bieten keine Garantie dafür, dass eine Ausnutzung verhindert wird.
- Schränken Sie öffentlich zugängliche Dienste bei Bedarf ein: Falls eine rechtzeitige Installation von Patches nicht möglich ist, sollten Sie in Erwägung ziehen, den öffentlichen Zugriff auf die betroffenen PHP-Dienste vorübergehend einzuschränken, Whitelists oder Zugriffskontrollen auf Netzwerkebene anzuwenden oder den Dienst zu isolieren, bis offizielle Korrekturen bereitgestellt werden können.



