Folgen PHP-Administratoren stehen vor einem dringenden Sicherheitsupdate, nachdem die Wartungsteams eine außerplanmäßige Veröffentlichung angekündigt haben, die zwei kritische Sicherheitslücken behebt. Die Schwachstellen, die von Sicherheitsforschern als CVE-2026-109618 und CVE-2026-109619 verfolgt werden, erhielten vom PHP-Sicherheitsteam jeweils eine CVSS v4.0-Bewertung von 9,2. Forscher bei watchTowr beschreiben beide Probleme als Schwachstellen zur Ausführung von Remote-Code.
Die Notfallveröffentlichung ist für den 21. Oktober 2026 um 14:00 UTC geplant. PHP hat die Veröffentlichung vorgezogen, nachdem Informationen über die Schwachstellen angeblich vor dem koordinierten Veröffentlichungstermin durchgesickert waren. Zum Zeitpunkt der Erstellung dieses Textes hat PHP weder die verwundbaren Komponenten, die Exploit-Anforderungen, betroffene Veröffentlichungen noch technische Ursachen offengelegt und sagt, dass diese Details die Sicherheitsupdates begleiten werden.
Forscher haben das Schwachstellenpaar informell ‚PHP2Shell‘ genannt, obwohl dieser Name nicht vom PHP-Projekt stammt. Das frühe Leck behauptete, die Mängel könnten PHP-Veröffentlichungen betreffen, die bis zu PHP 5 zurückreichen, und gab ihnen CVSS 10.0-Bewertungen. Die offizielle Bewertung von PHP beträgt jedoch 9,2 und der angegebene Versionsbereich wurde noch nicht durch einen offiziellen Herstellerhinweis bestätigt.
Die potenziellen Auswirkungen sind dennoch erheblich. PHP betreibt eine massive Anzahl von Websites, Webanwendungen, Content-Management-Systemen, E-Commerce-Plattformen, APIs, Hosting-Panels und kundenspezifischen Unternehmensservices. Wenn die Ausführung von Remote-Code bei gängigen eingesetzten Konfigurationen bestätigt wird, könnte ein erfolgreicher Exploit Angreifern eine direkte Route von einer exponierten Webanwendung zur Kompromittierung auf Serverebene geben.
Sicherheitsteams, die nach Möglichkeiten zur Erkennung von CVE-2026-109618 suchen, sollten verhaltensbasierte Überwachung priorisieren, während Exploit-spezifische Signaturen noch nicht verfügbar sind. Verdächtige Aktivitäten umfassen PHP- oder Webserver-Prozesse, die unerwartet Shells, Interpreten, Befehlszeilen-Utilities oder Download-Tools starten.
Kunden von SOC Prime können die AI-native Detection Intelligence Platform nutzen, um auf kontinuierlich aktualisierte Erkennungsinhalte für die Ausnutzung von Schwachstellen und damit verbundene Post-Compromise-Verhaltensweisen zuzugreifen. Erkennungsregeln können in mehreren SIEM-, EDR- und Data-Lake-Umgebungen angewendet und mit dem MITRE ATT&CK®-Framework abgestimmt werden.
Klicken Sie Entdeckungen erkunden um auf relevante SOC-Inhalte zu neuen Schwachstellen zuzugreifen. Um CVE-2026-109619 und damit verbundene Exploit-Versuche zu erkennen, sollten Verteidiger Verhaltensanalysen mit Webserver-, Endpunkt- und Netzwerktelemetrie kombinieren, sobald technische Informationen verfügbar werden.
Sicherheitsteams können auch Prime Architect verwenden, um neue Schwachstelleninformationen in Sigma-Regeln und benutzerdefinierte Suchanfragen zu verwandeln, Erkennungslogik zu validieren, potenzielle Angriffsflüsse zu visualisieren und Erkennungsinhalte schnell über unterstützte Sicherheitsplattformen zu übersetzen.
Analyse von CVE-2026-109618 und CVE-2026-109619
Am 20. Oktober 2026 gab das PHP-Sicherheitsteam eine Vorwarnung heraus, dass zwei kritische Schwachstellen durch ein außergewöhnliches Sicherheitsupdate am folgenden Tag behoben würden. Beide erhielten eine CVSS v4.0-Bewertung von 9,2, und Administratoren wurden aufgefordert, sich auf sofortige Upgrades vorzubereiten. PHP behielt sich auch die Option vor, Korrekturen früher zu veröffentlichen, falls technische Informationen öffentlich werden oder eine aktive Ausnutzung festgestellt wird.
Die Ankündigung folgte einem Informationsleck über zwei unter Embargo stehende Schwachstellen. Das durchgesickerte Material identifizierte CVE-2026-109618 und CVE-2026-109619 und charakterisierte beide als Schwachstellen zur Ausführung von Remote-Code. watchTowr bestätigte gegenüber BleepingComputer, dass die Schwachstellen real sind und sagte, dass seine Forscher glauben, einen davon erfolgreich reproduziert zu haben.
Es gibt jedoch wichtige Unterschiede zwischen den durchgesickerten Informationen und dem, was PHP offiziell bestätigt hat.
PHP hat beiden Schwachstellen eine CVSS v4.0-Bewertung von 9,2 zugewiesen, anstatt der CVSS 10.0-Bewertung, die im Leck zirkulierte. PHP hat auch nicht bestätigt, welche Zweige verwundbar sind, ob die Ausnutzung ein bestimmtes PHP-Deployment-Modell oder eine Konfiguration erfordert oder ob eine Authentifizierung erforderlich ist.
Die Behauptung, dass CVE-2026-109618 PHP-Versionen 5, 6, 7 und 8 betrifft, stammt von Forschern und durchgesickerten Informationen, nicht jedoch von PHPs offiziellem Hinweis. watchTowr selbst stellt fest, dass dieser Umfang vom Anbieter noch nicht bestätigt wurde.
Eine sorgfältige Analyse von CVE-2026-109618 muss daher bestätigte Fakten von vorläufiger Forschung trennen. Derzeit ist bestätigt, dass PHP zwei Schwachstellen als kritisch ansieht, beide mit 9,2 bewertet und das Risiko rechtfertigt eine außerplanmäßige Sicherheitsveröffentlichung. Forscher charakterisieren die Schwachstellen als RCE-Schwachstellen, aber ihre zugrunde liegenden Mechanismen bleiben unter Embargo.
Diese Unterscheidung ist auch wichtig, wenn es um die Bewertung von Legacy-PHP-Umgebungen geht. Das PHP-Projekt bietet derzeit nur Sicherheitsupdates für unterstützte Zweige 8.2 bis 8.5 an. PHP 8.2 und 8.3 erhalten Sicherheitskorrekturen, während 8.4 und 8.5 unter aktivem Support stehen. Ältere Zweige, einschließlich PHP 8.1, 8.0, PHP 7.x und PHP 5.x, sind end of life und erhalten keine Upstream-Patches, falls sie letztendlich als verwundbar bestätigt werden.
Dies könnte ein besonders herausforderndes Behebungsszenario für Organisationen darstellen, die alte Anwendungen betreiben, die nicht einfach migriert werden können. Im Internet zugängliche alte PHP-Systeme wären ein erhebliches Anliegen, wenn die gemeldete breite Versionsexposition bestätigt wird.
Zum Zeitpunkt der Erstellung dieses Textes ist kein öffentliches CVE-2026-109618 PoC verfügbar. watchTowr sagt, dass es glaubt, das Problem erfolgreich reproduziert zu haben, aber absichtlich technische Informationen zurückhält, bis Sicherheitsupdates verfügbar werden. Huntress hatte ebenfalls die Schwachstellen nicht reproduziert und war sich keines öffentlich verfügbaren Exploit-Codes bewusst.
Bis zum 21. Oktober hatten die in beiden Berichten genannten Forscher keine aktive Ausnutzung beobachtet. Die Schwachstellen waren zum Zeitpunkt des Berichts in The Hacker News auch nicht im Katalog der bekannten ausgenutzten Schwachstellen von CISA aufgeführt.
Folglich wurden CVE-2026-109619 IOCs noch nicht veröffentlicht. Derzeit gibt es keine bestätigten bösartigen IP-Adressen, Domains, Payload-Hashes, Exploit-Anforderungsmuster oder andere kampagnenspezifische Indikatoren, die direkt mit der Ausnutzung dieser Schwachstelle verbunden sind.
Bis Exploit-Details verfügbar werden, sollten Verteidiger stattdessen nach allgemeinen Anzeichen eines PHP-Server-Compromise überwachen. Hochwertige Verhaltensweisen umfassen das Starten von php-fpm, php-cgi, httpd oder apache2 Shells, Skript-Engines, Download-Utilities oder andere unerwartete ausführbare Dateien. Neue Web-Shells, unerklärliche Änderungen im Web-Root, Cron-Jobs, geplante Aufgaben, neu erstellte Konten und anomale ausgehende Verbindungen sollten ebenfalls eine Untersuchung auslösen.
Die genauen Details für CVE-2026-109619 werden erwartet, um das verwundbare PHP-Komponente, die Angriffsvoraussetzungen, betroffene Zweige, Konfigurationsabhängigkeiten und behobene Versionen zu klären, sobald PHP die Sicherheitsveröffentlichung veröffentlicht.
Minderung von CVE-2026-109618 und CVE-2026-109619
PHP-Administratoren sollten zuerst eine genaue Bestandsaufnahme jeder PHP-Bereitstellung in der Umgebung erstellen. Dies umfasst konventionelle Linux- und Windows-Webserver sowie in Appliances, Drittanbieteranwendungen, Hosting-Plattformen und Verwaltungsprodukten wie cPanel oder Plesk eingebettete PHP-Laufzeiten.
Für die sofortige Minderung von CVE-2026-109619 sollten Organisationen bereit sein, das Notfall-Sicherheitsupdate von PHP zu implementieren, sobald die gepatchten Versionen verfügbar werden. Internetzugängliche Anwendungen sollten höchste Priorität haben, da remote erreichbare Systeme typischerweise die größte Exploit-Möglichkeit darstellen.
Organisationen, die von der Distribution bereitgestellte PHP-Pakete verwenden, sollten bei ihrem Linux-Anbieter oder Hosting-Provider nach zurückportierten Sicherheitsupdates suchen, anstatt davon auszugehen, dass allein die Upstream-PHP-Versionsnummer die Exposition bestimmt.
Legacy-PHP-Installationen erfordern besondere Aufmerksamkeit. Wenn eine anfällige Anwendung eine end-of-life PHP-Version ausführt, für die kein offizielles Patch verfügbar wird, sollten Organisationen die Migration zu einem unterstützten Zweig priorisieren. Wo eine sofortige Migration unmöglich ist, sollte die Exposition durch Einschränkung des externen Zugriffs verringert werden, indem die Anwendung hinter angemessene Netzwerkkontrollen gestellt oder das System vorübergehend isoliert wird.
Vom Hacker News referenzierte CERT-EU-Leitlinien empfehlen, die Isolation von internetzugänglichen Anwendungen aus öffentlichen Netzwerken in Betracht zu ziehen, wenn ein Fix nicht sofort angewendet werden kann.
Verteidiger sollten zudem die Überwachung rund um die PHP-Ausführung verstärken. Alarmieren Sie, wenn PHP-Worker oder Webserver-Prozesse Dienste wie Shells, PowerShell, Bash, Python, Perl, curl, wget oder andere Programme starten, die für die Anwendung unerwartet sind.
Wenn ein Exploit vermutet wird, isolieren Sie den betroffenen Server und bewahren Sie Beweise vor der Behebung auf. Relevante Artefakte umfassen:
- Web-Server-Zugriffs- und Fehlerprotokolle
- PHP-Anwendungs- und Laufzeitprotokolle
- Endpunkt- und Prozess-Telemetrie
- Kürzlich erstellte oder geänderte Dateien
- Web-Root-Inhalt
- Cron-Jobs und geplante Aufgaben
- Neu erstellte Konten oder SSH-Schlüssel
- Ausgehende Netzwerkverbindungen
- Authentifizierungs- und Verwaltungstätigkeit
Sicherheitsteams sollten auch nachträglich nach technischen Indikatoren jagen, nachdem diese veröffentlicht wurden. Wenn explizit spezifische HTTP-Anforderungsmuster oder Payload-Merkmale öffentlich werden, könnten historische Web- und Proxy-Telemetrien Kompromissversuche identifizieren, die vor der Anwendung von Patches auftraten.
Organisationen sollten vermeiden, sich ausschließlich auf eine WAF als dauerhaften Ersatz für Patching zu verlassen. Bis die technischen Ursachen offengelegt sind, gibt es keine bestätigte generische WAF-Regel, die beide Schwachstellen zuverlässig blockieren kann, ohne deren Exploit-Mechanismen zu kennen.
Mit der Nutzung der AI-native Detection Intelligence Platform von SOC Prime können Sicherheitsteams kontinuierlich ihre Erkennungsbereitschaft verbessern, wenn neue Informationen über diese PHP-Schwachstellen bekannt werden.
Haftungsausschluss: Erkennungsinhalte sind möglicherweise nicht für jede CVE verfügbar. Überprüfen Sie die SOC-Prime-Plattform für die aktuelle Abdeckung. Wenn relevante Erkennungen noch nicht verfügbar sind, sollten Sie zurückkommen, da fortlaufend neue Bedrohungsinformationen und Erkennungsinhalte hinzugefügt werden.
FAQ
Was sind CVE-2026-109618 und CVE-2026-109619 und wie funktionieren sie?
CVE-2026-109618 und CVE-2026-109619 sind zwei kritische PHP-Schwachstellen, die von Forschern bei watchTowr als Fehler bei der Ausführung von Remote-Code beschrieben werden. PHP hat offiziell zwei kritische Probleme mit CVSS v4.0-Bewertungen von 9,2 bestätigt, jedoch noch nicht deren technische Ursachen oder Exploit-Mechanismen offengelegt. Zum Zeitpunkt der Erstellung ist es daher nicht möglich, den genauen Angriffsfluss zuverlässig zu beschreiben. PHP wird voraussichtlich die technischen Informationen mit seinem Notfall-Sicherheitsupdate veröffentlichen.
Wann wurden CVE-2026-109618 und CVE-2026-109619 erstmals entdeckt?
Informationen über die Schwachstellen wurden am 20. Oktober 2026 öffentlich, nachdem Details zu zwei unter Embargo stehenden PHP-Schwachstellen angeblich vor ihrer geplanten Offenlegung durchgesickert waren. PHP gab seine offizielle Vorwarnung später an diesem Tag heraus und plante ein Notfall-Sicherheitsupdate für den 21. Oktober 2026 um 14:00 UTC.
Welche Auswirkungen haben CVE-2026-109618 und CVE-2026-109619 auf Systeme?
Sicherheitsforscher charakterisieren beide Schwachstellen als Probleme bei der Ausführung von Remote-Code. Sollte diese Einschätzung von PHP bestätigt werden, könnte ein erfolgreicher Exploit einem Angreifer potenziell ermöglichen, Code auf einem anfälligen PHP-Server auszuführen und mit Malware-Deployment, Anmeldeinformationsdiebstahl, Persistenz, lateraler Bewegung oder Datenzugriff je nach den Rechten des betroffenen Dienstes fortzufahren. PHP hat die genauen Ausbeutungsbedingungen bisher nicht veröffentlicht, sodass die genauen Auswirkungen und Voraussetzungen dem bevorstehenden Herstellerhinweis vorbehalten bleiben.
Können mich CVE-2026-109618 und CVE-2026-109619 im Jahr 2026 noch betreffen?
Ja. Zum Zeitpunkt des Schreibens, am 21. Oktober 2026, ist die Notfall-Sicherheitsveröffentlichung für 14:00 UTC geplant und die Schwachstellen bleiben in derzeit eingesetzten Versionen ungepatcht. Forscher haben behauptet, dass PHP-Versionen, die bis zu PHP 5 zurückreichen, betroffen sein könnten, aber PHP hat diesen Versionsbereich nicht offiziell bestätigt. Organisationen sollten alle Bereitstellungen inventarisieren und den kommenden Herstellerhinweis verwenden, um die tatsächliche Exposition zu bestimmen.
Wie kann ich mich vor CVE-2026-109618 und CVE-2026-109619 schützen?
Bereiten Sie sich darauf vor, die PHP-Sicherheitsupdates sofort zu installieren, wenn sie veröffentlicht werden, wobei Server mit Internetzugang Priorität haben sollten. Inventarisieren Sie PHP-Installationen, einschließlich Laufzeiten, die mit Anwendungen und Appliances gebündelt sind, und identifizieren Sie Systeme, die End-of-Life-Versionen ausführen. Bis Korrekturen implementiert sind, erhöhen Sie die Überwachung auf ungewöhnliche PHP-Kindprozesse und serverseitige Befehlsausführungen. Systeme, die nicht sofort gepatcht werden können, sollten in ihrer externen Exposition eingeschränkt oder, wo operationell möglich, vorübergehend isoliert werden. Wenn verdächtige Aktivitäten gefunden werden, isolieren Sie den Server und bewahren Sie Web-, PHP-, Endpunkt- und Netzwerktelemetrie zur forensischen Untersuchung auf.
