PHP2Shell: WTF ist passiert? (CVE-2026-109618 und CVE-2026-109619)
| Surendra Pathak
Zwei Speicherfehler in der PHP-Engine wurden zu nicht authentifizierter RCE, und die koordinierte Offenlegung fiel öffentlich auseinander. Was passiert ist, was betroffen ist und wie Sie reagieren.
Überblick
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Notfall-Patches für zwei kritische Schwachstellen in der PHP-Engine, CVE-2026-109618 und CVE-2026-109619, die vom PHP-Sicherheitsteam jeweils mit 9,2 auf CVSS v4.0 bewertet wurden. Jede kann unter nachgewiesenen Bedingungen nicht authentifizierte Remote Code Execution ermöglichen, über manipulierte HTTP-Anfragen gegen eine verwundbare PHP-Laufzeitumgebung. Das öffentliche Exploit-Toolkit, das die Schwachstellen kombiniert, trägt den Namen PHP2Shell.
Die Fehler liegen in der PHP-Laufzeitumgebung, nicht in einer einzelnen Anwendung, sodass ein Server selbst dann angreifbar ist, wenn sein eigener Code sauber ist. Die Forschung demonstrierte Remote Code Execution gegen aktuelle Versionen von WordPress, Drupal und Joomla. Der verwundbare Code stammt aus PHP 5.4.0, was bedeutet, dass die Angriffsfläche über ein Jahrzehnt lang latent vorhanden war.
Der Ablauf war ebenso bemerkenswert wie der Fehler selbst. Die koordinierte Offenlegung fiel öffentlich auseinander, gemeldete Ausnutzungsversuche lagen vor dem Patch, und die Episode entwickelte sich zu einem Streit zwischen der PHP Foundation und Chainguard. Der Nettoeffekt war ein verkürztes Reaktionsfenster. Dieser Beitrag behandelt beide Hälften: die technische, knapp gehalten, und die chaotische.
Die wichtigsten Fakten
Worum es geht: zwei Speicherschwachstellen in der PHP-Engine, CVE-2026-109618 und CVE-2026-109619, zusammengefasst unter dem Namen PHP2Shell. Jede ist mit CVSS v4.0 9,2 bewertet.
Auswirkung: jede kann nicht authentifizierte Remote Code Execution ermöglichen. CVE-2026-109618 ermöglicht zusätzlich die anfrageübergreifende Offenlegung von PHP-Worker-Speicher.
Warum sie so breit ist: die Fehler liegen in der Laufzeitumgebung, sodass auch Anwendungen mit sicherem Code angreifbar sind. Die Forschung demonstrierte RCE gegen WordPress, Drupal und Joomla.
Betroffen: PHP-Versionen zurück bis 5.4.0 sind von mindestens einer der offengelegten Schwachstellen betroffen, über PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed hinweg. Prüfen Sie das PHP-Advisory und Ihren Distributor für den genauen Status jeder Version.
Behoben: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, mit Quellcode-Backports für 7.4, 8.0 und 8.1. Die Zweige 5.4 bis 7.3 haben das Ende ihrer Lebensdauer erreicht und werden nicht behoben.
Ausnutzung: gemeldete Ausnutzungsversuche rund um das Offenlegungsfenster; bestätigen Sie den aktuellen Status anhand von Primärquellen, bevor Sie handeln.
Was zu tun ist: patchen Sie die Laufzeitumgebung, verifizieren Sie anhand der CVE-ID statt der Versionszeichenfolge, und untersuchen Sie jedes System, das vor dem Patchen exponiert war.
Was PHP2Shell ist
PHP2Shell bezeichnet zwei verschiedene Speicherschwachstellen im PHP-Interpreter, zusammen mit dem öffentlichen Toolkit, das sie ausnutzt. Es handelt sich nicht um eine Schwachstelle in WordPress, Drupal, Joomla oder einer anderen Anwendung. Die betroffene Sicherheitsgrenze ist die PHP-Laufzeitumgebung selbst, die eine Anfrage parst und verarbeitet, bevor die Anwendungslogik ausgeführt wird.
Beide Schwachstellen sind aus der Ferne und ohne Authentifizierung erreichbar, und das PHP-Advisory benennt PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed als betroffene Arten, PHP auszuliefern. Das Advisory benennt mod_php als die risikoreichste Konfiguration und verweist auf einen nachgewiesenen Exploit, der den Fehler auslösen kann, bevor Anwendungscode ausgeführt wird.
Der verwundbare Anfrageweg
Die nachgewiesenen Angriffswege nutzen manipulierte HTTP-Anfragen, einschließlich multipart/form-data-Anfragen. PHP parst Multipart-Bodys in nativem C-Code während der frühen Anfrageverarbeitung, bevor die normale Anwendungslogik läuft. Deshalb ist der verwundbare Code ohne ein legitimes Upload-Formular, eine gültige Sitzung oder eine verwundbare Funktion auf Anwendungsebene erreichbar. Eingabevalidierung in der Anwendung kann Code nicht schützen, der ausgeführt wird, bevor die Anwendung selbst läuft.
Zwei Engine-Funktionen liegen auf diesem Weg und liefern die Bedingungen, die die Fehler benötigen. Die erste ist Session Upload Progress, der Mechanismus, mit dem PHP meldet, wie weit ein Upload fortgeschritten ist und der während des Multipart-Parsings internen Zustand befüllt. Die zweite ist PHPs Fatal-Error-Behandlung, einschließlich des Backtrace, den die Engine aufbaut, wenn eine Anfrage abbricht, etwa wenn sie memory_limit überschreitet. Beide laufen in nativem Code und beide können von außerhalb der Anwendung angesteuert werden.
CVE-2026-109618: Use-after-free und Speicheroffenlegung bei Upload Progress
CVE-2026-109618 ist ein Use-after-free in PHPs Upload-Progress-Behandlung, gemeldet von Wiz Research und dem Forscher, der unter dem Namen Calif bekannt ist. Die veröffentlichte Forschung belegt, dass sie sowohl die anwendungsunabhängige Offenlegung von PHP-Worker-Prozessspeicher als auch nicht authentifizierte Remote Code Execution ermöglicht.
Der Fehler wird während des Multipart-Parsings erreicht. Ein Fatal Error zum falschen Zeitpunkt, meist ein Out-of-Memory-Zustand, wenn eine Anfrage memory_limit überschreitet, unterbricht die Engine in nativem Code, bevor die Aufräumarbeiten abgeschlossen sind, und hinterlässt eine Referenz auf bereits freigegebenen Speicher. Eine nachfolgende Operation verwendet dann diesen freigegebenen Speicher, und ein Angreifer, der den Zuteilungsfehler an einem gewählten Punkt herbeiführen kann, indem er einen multipart/form-data-Body so dimensioniert, dass er das Limit überschreitet, gewinnt Einfluss auf dessen Inhalt.
Im nachgewiesenen Weg zur Speicheroffenlegung kann PHPs Upload-Progress-Behandlung den Inhalt freigegebenen Worker-Prozessspeichers im PHPSESSID-Antwort-Cookie an den Client zurückgeben. Je nachdem, was im Speicher verbleibt, können die offengelegten Bytes Daten aus anderen Anfragen enthalten, die derselbe Worker bearbeitet hat, etwa Zugangsdaten, Sitzungstokens, API-Schlüssel oder andere sensible Anwendungsdaten. Die Forschung demonstriert anfrageübergreifende Offenlegung, nicht garantierten Zugriff auf jedes Geheimnis auf dem Server. Der Leak erfordert nicht, dass die Anwendung session_start() aufruft. Dies ist die Heartbleed-Analogie: unbeabsichtigte Speicheroffenlegung durch eine Anfrage, die ihn nie hätte lesen sollen.
CVE-2026-109619: Use-after-free im Fatal-Error-Backtrace
CVE-2026-109619 fasst verwandte Speicherprobleme in PHPs Fatal-Error-Backtrace-Behandlung und in OPcache zusammen, gemäß der Forschung von Wiz und Calif. Die veröffentlichte Arbeit demonstriert nicht authentifizierte Remote Code Execution über diese Schwachstelle. Die Probleme stützen verschiedene nachgewiesene Exploit-Ketten und sollten nicht als eine einzige Abfolge von Schritten gelesen werden, die ein Angreifer der Reihe nach ausführen muss.
Im Backtrace-Weg kann ein Fatal Error, etwa eine Anfrage, die memory_limit überschreitet, eine Referenz auf bereits freigegebenen Speicher hinterlassen, die eine spätere Operation dann verwendet; bei PHP 8.5 ist die Funktion fatal_error_backtraces konkret betroffen. Getrennt davon kann eine Type Confusion in OPcache dazu führen, dass die Engine falsch interpretiert, was ein Speicherbereich repräsentiert. Für jede wurde gezeigt, dass sie Code-Ausführung stützt.
Die beiden CVEs sind verschieden, und die Forschung demonstriert nicht authentifizierte RCE über jede einzelne. PHP2Shell kombiniert die Schwachstellen, aber Verteidiger sollten nicht annehmen, dass beide gemeinsam ausgenutzt werden müssen oder dass das Blockieren eines nachgewiesenen Wegs eine verwundbare Laufzeitumgebung sicher macht. Die öffentlichen Beschreibungen gehen nicht bis zur schrittweisen Waffenfähigkeit, und diese Analyse tut es ebenfalls nicht.
Wie die beiden CVE-Beschreibungen zusammenhängen
Die beiden CVEs werden in zwei Detailgraden beschrieben, die im Umlauf sind, und die Lücke dazwischen sorgt für Verwirrung. PHPs Advisory betitelt sie nach grober Kategorie: CVE-2026-109618 ist „RCE via OOM corruption" und CVE-2026-109619 ist „RCE via stale global state". Die Forschung von Wiz und Calif beschreibt die zugrunde liegenden Primitive: den Use-after-free im Upload-Progress-Unserializer mit Speicheroffenlegung und den Use-after-free im Fatal-Error-Backtrace mit OPcache-Type-Confusion.
Dies sind keine konkurrierenden Beschreibungen verschiedener Fehler; sie beschreiben dieselben Schwachstellen in unterschiedlicher Auflösung. Jedes CVE fasst zudem mehr als ein verwandtes Primitiv zusammen: CVE-2026-109618 deckt den Upload-Progress-Use-after-free und seine Speicheroffenlegung ab, und CVE-2026-109619 deckt verwandte Probleme in der Fatal-Error-Backtrace-Behandlung und in OPcache ab. Diese Primitive stützen verschiedene nachgewiesene Exploit-Ketten und sind keine einzelne Abfolge, die jeder Angreifer ausführen muss, was deshalb von Bedeutung ist, weil das Blockieren eines Wegs das Risiko des CVE nicht beseitigt. Nutzen Sie für die Behebung das PHP-Advisory, um betroffene und behobene Versionen zu bestimmen; nutzen Sie für die Mechanik die ursprüngliche Forschung. Eine kurze CVE-Zusammenfassung sollte nicht als vollständige Darstellung der Ausnutzung gelesen werden.
Betroffene und behobene Versionen
Der verwundbare Codeweg existiert seit PHP 5.4.0, veröffentlicht 2012, und ist in Standardkonfigurationen über jede wichtige Art, PHP auszuliefern, erreichbar, ohne dass nicht standardmäßige Einstellungen erforderlich wären. Jede ins Internet gerichtete Installation auf einer betroffenen Version sollte als potenziell exponiert behandelt werden, bis ihr Patch-Status und ihre Konfiguration verifiziert sind.
PHP veröffentlichte Fixes in 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Quellcode-Backports existieren für 7.4, 8.0 und 8.1, die keine offiziellen Updates mehr erhalten, sodass dort das Einspielen des Backports oder ein Upgrade erforderlich ist. Die Zweige 5.4 bis 7.3 haben das Ende ihrer Lebensdauer erreicht und werden nicht behoben. PHP 8.2 selbst erreicht am 31. Dezember 2026 das Ende seiner Lebensdauer, sodass 8.2.35 eine kurzlebige Position ist, keine dauerhafte.
Eine operative Falle: Distributions-Maintainer können den Fix zurückportieren, ohne die Upstream-Versionsnummer zu übernehmen. Verifizieren Sie den Status eines Pakets anhand des Advisorys und des Changelogs des Distributors, unter Verwendung beider CVE-IDs, statt sich allein auf die Upstream-Versionszeichenfolge zu verlassen. Dasselbe gilt für Container-Images und gebündelte Software: ein gepatchter Host belegt nicht, dass eine separat verpackte Laufzeitumgebung gepatcht ist.
Wie die koordinierte Offenlegung auseinanderfiel
Das Reaktionsfenster war kurz, weil das Embargo öffentlich auseinanderfiel, und dies ist der Teil, der die Reaktion „WTF ist passiert" hervorrief.
Die Forschung war wochenlang ruhig geblieben. Calif meldete PHP im August einen ersten Fehler, und Wiz Research meldete PHP die Schwachstellen am 24. August, wobei das Sicherheitsteam von OpenAI in der koordinierten Anstrengung mitgewirkt hat. Der Fix war schwer zu bauen, und die koordinierte Offenlegung war für den 22. Oktober angesetzt.
Dann brach das Embargo in Etappen. Am 20. Oktober begannen die beiden CVE-Kennungen in Foren und sozialen Medien mit falscher Schwere und falschem Zeitpunkt zu kursieren; zu diesem Zeitpunkt waren die Kennungen öffentlich, nicht die technischen Details. Kurz darauf veröffentlichte Calif versehentlich ein Video, das einen funktionierenden Proof-of-Concept enthielt, was technisches Material offenlegte und zur schnelleren unabhängigen Exploit-Entwicklung beitrug. Auch Mitigationshinweise, die die PHP Foundation privat mit Organisationen kritischer Infrastruktur geteilt hatte, könnten durchgesickert sein. Da das Embargo sichtbar auseinanderfiel, zog PHP seine Veröffentlichung um einen Tag vor, auf den 21. Oktober.
Die dritte Offenlegung wurde zu einem öffentlichen Streit, und es lohnt sich, beide Positionen klar darzulegen. Die PHP Foundation bezeichnete Chainguards Veröffentlichung gepatchter Container-Images um 07:41 UTC am 21. Oktober, rund sechs Stunden vor der koordinierten Veröffentlichung, als Bruch des Embargos: „Jeder Angreifer konnte nun den Fix in Binärform studieren, während jeder andere PHP-Nutzer noch auf die Veröffentlichung wartete", und fügte hinzu, dies habe „wochenlange Arbeit vieler Beteiligter an einer koordinierten Offenlegung missachtet". Chainguards CEO, Dan Lorenc, erwiderte, das Unternehmen habe nichts durchsickern lassen, bestreite den Zeitverlauf nicht, habe dieselben Schwachstellen unabhängig mit eigenem KI-Werkzeug entdeckt und beim Testen der Patches geholfen. Die beiden Aussagen schließen sich nicht gegenseitig aus, und die PHP Foundation hat die Darstellung der unabhängigen Entdeckung öffentlich nicht beantwortet.
Der Mechanismus hinter der Beschwerde der Foundation ist ein wiederkehrendes Lieferketten-Problem, das zu verstehen sich lohnt. Wenn ein gepatchtes Binary vor dem Advisory ausgeliefert wird, kann jeder es mit dem vorherigen Build vergleichen, den geänderten Code lokalisieren und rückwärts zum Fehler arbeiten. Patch-Diffing kann einen Fix in eine Karte des Fehlers verwandeln. Das Veröffentlichen eines gepatchten Binarys vor einem Advisory belegt für sich genommen nicht, dass der Veröffentlichende die Quelle des Lecks war oder dass jeder Angreifer diesen Weg nutzte, aber es kann die Hürde für jene senken, die es tun.
Die Ausnutzung bildet sich nicht sauber auf den Patch-Zeitstempel ab. Sicherheitsanbieter meldeten Ausnutzungsversuche, bevor die Patches eintrafen, wobei einige Aktivität auf den 17. Oktober datierten, und Cloudflare beobachtete Angriffsverkehr und erklärte, einige Angreifer hätten Payloads angepasst, um seinen WAF-Regeln auszuweichen. Am 21. Oktober hatte Cloudflare bis 03:02 UTC Regeln aktiviert, PHP lieferte die Fixes gegen 14:00 UTC aus, und watchTowr ging innerhalb von Minuten nach der Veröffentlichung von der Meldung „keine beobachtete Ausnutzung" zu aktiven Versuchen gegen beide CVEs über. Dies sind verschiedene Beobachtungen, nicht zwangsläufig eine Kampagne, und frühe Samples, nachgewiesene Ketten, Ausnutzungsversuche und bestätigte Kompromittierung sind nicht dasselbe. Zum Zeitpunkt der ersten Berichterstattung am 21. Oktober war keine bestätigte Kompromittierung veröffentlicht worden, und keines der beiden CVEs stand in CISAs Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities), obwohl mehrere Organisationen, darunter BambooHR und einige niederländische Regierungs- und Bildungsseiten, Dienste vorsorglich offline nahmen. Behandeln Sie diesen Status als zeitlich begrenzt und prüfen Sie ihn erneut, bevor Sie handeln.
Die praktische Lektion ist, dass der Zeitstempel der Patch-Veröffentlichung nicht der Zeitpunkt ist, an dem die Bedrohung begann. Öffentliche Forschung und Exploit-Werkzeuge reduzierten die Arbeit, die ein Angreifer sonst gebraucht hätte, um die nachgewiesenen Angriffe zu reproduzieren, erheblich. Das machte nicht jede Bereitstellung gleich ausnutzbar, aber es verkürzte den Weg von der Offenlegung zu praktischen Versuchen, und es bedeutet, dass jedes zuvor exponierte System eine Untersuchung braucht, nicht nur einen Patch.
Was einem ungepatchten Server droht
Für einen ungepatchten, ins Internet gerichteten Server folgen zwei Arten von Konsequenzen, und die erste braucht keine Code-Ausführung. Der Weg zur Speicheroffenlegung kann freigegebenen Worker-Speicher in der Antwort zurückgeben und so Geheimnisse aus anderen Anfragen offenlegen, die derselbe Worker bearbeitet hat, etwa Sitzungstokens und API-Schlüssel. Er hinterlässt möglicherweise keinen offensichtlichen Fehler auf Anwendungsebene, sodass Verantwortliche Webserver- und Proxy-Telemetrie neben PHP-Protokollen und Prozessaktivität prüfen sollten, statt einen klaren Protokolleintrag zu erwarten.
Die zweite Konsequenz ist vollständige Remote Code Execution, und von dort folgt die bekannte Kette: eine Webshell, Diebstahl von Zugangsdaten, laterale Bewegung, Datenexfiltration oder die Vorbereitung von Ransomware. Das Problem der alten Versionen macht dies an bestimmten Stellen dauerhaft. End-of-Life-Zweige werden diesen Fix niemals erhalten, und PHP, das in eine Appliance, ein Embedded-Gerät oder ein Herstellerprodukt gebündelt ist, hat möglicherweise ohne den Hersteller überhaupt keinen Patch, was Inventar und Lieferantenkoordination zur eigentlichen Arbeit macht, nicht zu einem Nachgedanken.
Erkennung und Threat Hunting
Da der Auslöser das Parsen von Anfragen und die Wirkung Speicherkorruption ist, gruppieren sich die beobachtbaren Signale um fehlerhafte Uploads und instabile Worker. Untersuchen Sie für einen Server, der vor dem Patchen exponiert gewesen sein könnte:
Ungewöhnliche
multipart/form-data-Anfragen, besonders solche, auf die kurz darauf Memory-Limit-Fehler in den PHP-Protokollen folgen.Wiederholte HTTP-500-Antworten, die die Fatal Errors begleiten, von denen der erste Fehler abhängt.
Unerwartet große oder fehlerhafte
PHPSESSID-Werte in Serverantworten. Hier zeigt sich der Weg zur Speicheroffenlegung, es ist also ein Artefakt der ausgehenden Antwort, kein überdimensioniertes Cookie, das vom Client eintrifft.Unerklärte Neustarts von PHP-Workern, die auf einen fehlgeschlagenen oder teilweisen Ausnutzungsversuch folgen können.
Keines davon ist für sich allein schlüssig. Gemessen an der normalen Baseline der Anwendung ist eine Häufung überdimensionierter Multipart-Anfragen, Memory-Limit-Fatals und Worker-Fluktuation gegen einen ungepatchten Server ein Untersuchungshinweis mit hoher Priorität. Ein erfolgreicher Speicherkorruptions-Exploit erzeugt möglicherweise nicht dieselben Symptome wie ein gewöhnlicher Fehler, korrelieren Sie also über Webserver-, Proxy- und PHP-Protokolle sowie Prozesstelemetrie hinweg, statt sich auf ein einzelnes Muster zu verlassen.
Reaktion auf PHP2Shell: Reihenfolge der Prioritäten
Handeln Sie in einer exponierten Umgebung in dieser Reihenfolge:
Identifizieren und patchen. Finden Sie jede ins Internet gerichtete PHP-Laufzeitumgebung, einschließlich der in Containern, Appliances und Drittanbieterprodukten gebündelten, und spielen Sie die vom Hersteller behobene Version ein. Das Aktualisieren des Anwendungsframeworks behebt die Laufzeitumgebung nicht.
Angriffsfläche während des Patchens reduzieren. Wenn ein sofortiges Update unmöglich ist, beschränken Sie den öffentlichen Zugriff oder isolieren Sie den betroffenen Dienst. Behandeln Sie WAF-Regeln und PHP-Konfigurationsänderungen als temporäre Risikoreduktion, nicht als vollständige Mitigationen.
Mögliche Kompromittierung untersuchen. Prüfen Sie Web-, Proxy- und PHP-Protokolle, Endpunkt-Telemetrie, unerwartete Prozesse, veränderte Dateien und verdächtige ausgehende Verbindungen. Das Patchen belegt nicht, ob ein Angreifer zuvor auf das System zugegriffen hat.
Das Ergebnis verifizieren. Starten Sie die relevanten Dienste und Worker neu, bestätigen Sie, dass die laufende Laufzeitumgebung ein behobener Build ist, und prüfen Sie Hersteller-Advisorys, wo Fixes zurückportiert sind.
Übergangsmitigationen und ihre Grenzen
Das PHP-Projekt stellt ausdrücklich klar, dass es keine vollständigen Mitigationen gibt und dass das Aktualisieren die einzig sichere Wahl ist. Die folgenden Maßnahmen reduzieren die Angriffsfläche für bestimmte Wege; sie machen eine ungepatchte Laufzeitumgebung nicht sicher. Starten Sie die betroffenen PHP-Worker und relevanten Auslieferungsprozesse nach dem Anwenden von Konfigurationsänderungen neu, wie es Ihre Bereitstellung erfordert. Verifizieren Sie die aktuellen Empfehlungen im Sicherheits-Release-Beitrag der PHP Foundation, statt sich auf eine Zusammenfassung zu verlassen.
Für CVE-2026-109618 empfiehlt PHP, memory_limit über eine Konfiguration, die Anwendungen nicht überschreiben können, etwa den FPM-Pool oder die Apache-Konfiguration, auf -1 zu setzen, was den steuerbaren Memory-Limit-Auslöser entfernt. Dies ist keine beiläufige Änderung: sie entfernt PHPs Speicherobergrenze pro Anfrage, sodass eine einzelne Anfrage erheblichen Systemspeicher verbrauchen kann, und externe Anfragelimits allein garantieren nicht, dass der verwundbare Zuteilungsweg nicht erreicht werden kann. Mildern Sie das Denial-of-Service-Risiko, indem Sie post_max_size niedrig und upload_max_filesize darunter halten, Anfragegrößen-Limits am Proxy durchsetzen und eine Container- oder cgroup-Speichergrenze um den Worker legen, die ihn beenden kann. Ersetzen Sie dies nicht durch RLIMIT_AS oder RLIMIT_DATA, die die Zuteilungsfehler neu erschaffen, die den Fehler erreichen.
Für CVE-2026-109619 empfiehlt PHP, Session Upload Progress zu deaktivieren, um bestätigte sitzungsbezogene Exploit-Wege zu blockieren. Setzen Sie session.upload_progress.enabled auf 0 auf Pool- oder Serverebene, damit es vor dem Parsen der Anfrage greift, und starten Sie dann die Worker neu; ein Setzen über ini_set() oder eine .user.ini kommt zu spät, um zu helfen. Setzen Sie bei PHP 8.5 auch fatal_error_backtraces auf 0, um den bestätigten Fatal-Backtrace-Weg zu blockieren. Diese Einstellungen adressieren bestimmte Wege, nicht jede mögliche Variante, und machen eine ungepatchte Installation nicht sicher.
Ein Hinweis zur Zeit nach dem Patch, gemäß der Berichterstattung über den Fix: er führt ein hartes Speicherlimit ein, das einen Prozess beenden kann, ohne die PHP-Shutdown-Handler auszuführen. Wenn Ihre Logik von Shutdown-Funktionen oder der ordnungsgemäßen Behandlung von Speichererschöpfung abhängt, bestätigen Sie das gepatchte Verhalten anhand der PHP-Release-Notes, bevor Sie annehmen, dass es dem alten entspricht.
Was das für Inventar und Reaktion bedeutet
PHP2Shell ist operativ ein Inventarproblem, bevor es ein Patch-Problem ist. Am 21. Oktober war die erste Frage für die meisten Teams nicht, wie der Fehler funktioniert. Sie lautete: wo betreiben wir PHP, welche Versionen, und welche Produkte, Dienste und Kunden sind exponiert.
Eine aktuelle, hinreichend vollständige Software Bill of Materials hilft, dies zu beantworten, indem sie die Produkte, Builds und Images identifiziert, die die betroffene PHP-Laufzeitumgebung enthalten. Dort versteckt sich PHP gern: gebündelt in Appliances und Embedded-Weboberflächen, eingebacken in Container-Basis-Images, hereingezogen als Abhängigkeit eines größeren Produkts, an Stellen, die ein Scan auf Manifest-Ebene gern übersieht. Eine SBOM ist nur so gut wie ihre Abdeckung. Sie weist Sie auf die prüfenswerten Assets hin; sie bestätigt für sich genommen nicht die genaue Version, die in der Produktion läuft, und beweist nicht, dass ein bestimmter Host ausnutzbar ist. Wenn SBOMs aktuell sind und die relevante Laufzeitumgebung erfassen, verwandeln sie eine tagelange Bestandsaufnahme in eine viel kürzere Liste zu verifizierender Assets.
Interlynk ist für dieses Muster gebaut. lynkctl erzeugt build-bewusste SBOMs, die die in Firmware, Appliances und Images eingebetteten Laufzeitumgebungen und Komponenten erfassen, weit über die Top-Level-Abhängigkeiten hinaus. Die Interlynk-Plattform nimmt diese SBOMs auf, bewertet Komponenten anhand von Schwachstellendaten im Hinblick auf das Risiko, sodass eine betroffene PHP-Version automatisch auftaucht, verwaltet VEX-Aussagen für die von Ihnen bewerteten Produkte und benachrichtigt Stakeholder, wenn eine neue Offenlegung die Exposition von etwas bereits Ausgeliefertem verändert. Wenn das nächste CVE auf Laufzeitebene eintrifft, ist das Inventar bereits vorhanden.
Fazit
PHP2Shell zeigt, wie ein Speicherfehler in einer weit verbreiteten Laufzeitumgebung die Sicherheit von Anwendungen untergraben kann, die nichts falsch gemacht haben. Zwei Speicherfehler, die seit über einem Jahrzehnt in PHP vorhanden waren, wurden zu nicht authentifizierter Remote Code Execution entwickelt, und eine koordinierte Offenlegung, die auseinanderfiel, ließ Verteidigern fast keine Schonfrist.
Patchen Sie die Laufzeitumgebung auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, starten Sie Ihre Worker neu, verifizieren Sie anhand der CVE-ID, und untersuchen Sie alles, was vor dem Patch exponiert war. Machen Sie dann die Inventarfrage im Voraus beantwortbar, denn wenn eine Schwachstelle in einer über Tausende von Produkten geteilten Laufzeitumgebung lebt, ist das Wissen, wo diese Laufzeitumgebung bereitgestellt ist, Teil der Incident Response, nicht der Aufräumarbeit danach.
Häufig gestellte Fragen
Was ist PHP2Shell? PHP2Shell ist der Name für zwei kritische Speicherschwachstellen in der PHP-Engine, CVE-2026-109618 und CVE-2026-109619, jeweils mit CVSS v4.0 9,2 bewertet, zusammen mit dem öffentlichen Toolkit, das sie ausnutzt. Beide ermöglichen nicht authentifizierte Remote Code Execution.
Müssen beide CVEs verkettet werden, um RCE zu erreichen? Nein. Die veröffentlichte Forschung demonstriert nicht authentifizierte Remote Code Execution über jede Schwachstelle unabhängig, mit verschiedenen Exploit-Ketten. CVE-2026-109618 legt zusätzlich PHP-Worker-Speicher offen. PHP2Shell kombiniert sie, aber sie müssen nicht gemeinsam verwendet werden.
Welche PHP-Versionen sind betroffen und behoben? Der verwundbare Code reicht zurück bis PHP 5.4.0. Fixes finden sich in 8.5.12, 8.4.27, 8.3.36 und 8.2.35, mit Quellcode-Backports für 7.4, 8.0 und 8.1. Die Zweige 5.4 bis 7.3 haben das Ende ihrer Lebensdauer erreicht und sind nicht behoben.
Wird PHP2Shell in freier Wildbahn ausgenutzt? Sicherheitsanbieter meldeten Ausnutzungsversuche rund um die Offenlegung, einschließlich Aktivität vor dem Patch und Versuchen gegen beide CVEs nach der Veröffentlichung, laut watchTowr. Bestätigte Kompromittierung ist eine separate Frage; prüfen Sie aktuelle Advisorys und CISAs KEV-Katalog, bevor Sie handeln.
Behebt das Deaktivieren von Datei-Uploads oder das Blockieren von Multipart-Anfragen das Problem? Nein. Diese Schritte reduzieren die Angriffsfläche für den nachgewiesenen Auslöser, machen aber eine ungepatchte Laufzeitumgebung nicht sicher. Das Aktualisieren ist der einzige vollständige Fix.
Wie finde ich jede betroffene PHP-Laufzeitumgebung? Inventarisieren Sie jeden Ort, an dem PHP läuft, einschließlich gebündelter und eingebetteter Instanzen, mit einer aktuellen SBOM, wo verfügbar, verifizieren Sie dann die Version in der Produktion und patchen Sie. PHP wird häufig in Appliances und Container-Images ausgeliefert, die eine Top-Level-Abhängigkeitsliste nicht zeigt.
Quellen
Wiz Research, PHP2Shell-Schwachstellenbericht (Platzhalter: genaue Bericht-URL vor der Veröffentlichung einfügen)
Sansec, „PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)"
Tenable, „PHP2Shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions"
SecurityWeek, „PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors"
Über Interlynk. Interlynk hilft Teams, SBOMs über die gesamte Software-Lieferkette zu generieren, zu verwalten und zu operationalisieren. lynkctl erzeugt build-bewusste SBOMs für Embedded- und Firmware-Software und erfasst gebündelte Laufzeitumgebungen sowie vendored, statische und SDK-Komponenten mit präzisen Identifikatoren. Die Interlynk-Plattform nimmt SBOMs und CBOMs auf, bewertet sie auf Vollständigkeit und Qualität, bewertet Komponenten anhand von Schwachstellendaten im Hinblick auf das Risiko, verwaltet VEX-Aussagen und benachrichtigt Teams, wenn sich die Exposition ändert.
Demo buchen · Kostenlos starten
Dieser Artikel dient der Information und stellt keine Sicherheits- oder Rechtsberatung dar. PHP2Shell ist ein sich schnell entwickelnder Vorfall; bestätigen Sie aktuelle Advisorys, betroffene Versionen, behobene Releases und den Ausnutzungsstatus anhand der Primärquellen, bevor Sie handeln.