CrowdStrike schützt Kunden vor PHP2Shell-Bedrohungen

21. Oktober 2026  •  Amit Serper  •  Berichte von der Cyberfront

Zwei kritische Schwachstellen, die auf Speicherbeschädigung beruhen und eine Remote Code Execution (RCE) ermöglichen, wurden im PHP-Kern offengelegt. Sie werden gemeinsam als PHP2Shell bezeichnet. PHP ist eine grundlegende Technologie für zahlreiche Webanwendungen. Die CrowdStrike Falcon®-Plattform bietet standardmäßig Transparenz und Erkennungsfunktionen für Aktivitäten, die nach der Ausnutzung beider Schwachstellen stattfinden.

Die unter CVE-2026-109618 und CVE-2026-109619 geführten Schwachstellen haben beide einen CVSS-4.0-Score von 9,2 (kritisch) und sind als CWE-824: Access of Uninitialized Pointer klassifiziert. Beide ermöglichen es einem nicht authentifizierten Angreifer aus der Ferne, über HTTP beliebige Systembefehle auf einem betroffenen Webserver auszuführen.

Beiden Schwachstellen liegt dieselbe Ursache zugrunde. Tritt bei PHP ein schwerwiegender Fehlerzustand auf –etwa weil das konfigurierte Speicherlimit memory_limit erreicht, die maximalen Ausführungszeit überschritten oder die Verbindung zum Client unterbrochen wird–, wird kein Fehler über den Stapelaufruf (Call Stack) zurückgegeben. Stattdessen wird ein fataler Fehler ausgelöst, und mithilfe von longjmp() wird der aktuelle Ausführungskontext sofort beendet, wodurch die Anfrage abgebrochen wird. Jede C-Funktion, die mitten im Aufbau einer Datenstruktur unterbrochen wird, wird einfach verworfen: Es werden keine Destruktoren ausgeführt, keine Verwaltungsdaten werden zurückgesetzt, und es wird nicht protokolliert, dass die Struktur unvollständig ist. PHP geht anschließend zu einer ansonsten normalen Bereinigungssequenz über, die voraussetzt, dass sich jede Struktur in einem konsistenten Zustand befindet.

Bei den beiden CVEs beschreiben ist diese Annahme ungültig:

• CVE-2026-109618 (Remote Code Execution durch Speichermangel) betrifft Ausführungskontexte, in denen der für die Anfrage vorgesehene Speicher uninitialisiert bleibt. Eine Datenstruktur wird als mit einem Eintrag belegt markiert, bevor der dafür benötigte Speicher zugewiesen wurde. Überschreitet die anschließende Speicherzuweisung das konfigurierte Speicherlimit, enthält der Eintrag weiterhin zurückgebliebene Daten aus dem Heap-Speicher. Die eigene Bereinigungsroutine der fehlerhaften Anfrage liest diese Bytes anschließend und führt eine Verzweigung auf der Grundlage dieser Bytes durch.
• CVE-2026-109619 (RCE durch fatale Fehler) betrifft Ausführungskontexte, in denen der globale Zustand ungültig bleibt. Eine globale Variable auf Modulebene verweist weiterhin auf einen Speicherbereich im anfragespezifischen Heap, der vom Befehl „shutdown“ bereits freigegeben wurde. Gleichzeitig zeigt sie den betreffenden Vorgang weiterhin als aktiv an. Eine nachfolgende Anfrage, die vom selben Worker-Prozess bearbeitet wird, liest aus diesem freigegebenen Speicher oder führt Verzweigungen anhand dessen durch.

In beiden Fällen kontrolliert der Angreifer den Auslöser und, was entscheidend ist, die Daten, die PHP letztlich falsch interpretiert. CrowdStrike hat den gesamten Ablauf verifiziert: Eine einzige anonyme POST-Anfrage kann dazu führen, dass ein Apache mod_php-Worker einen Shell-Prozess startet und einen vom Angreifer vorgegebenen Befehl ausführt, ohne Authentifizierung, ohne Sitzung und ohne dass anfälliger Anwendungscode beteiligt ist.

Besonders gefährlich sind diese Schwachstellen aufgrund ihrer Position im Ausführungsstapel. PHP parst eingehende Anfragedaten, bevor Erweiterungen initialisiert werden und bevor auch nur eine einzige Zeile Anwendungscode kompiliert wird; daher hängt die Ausnutzung dieser Schwachstellen nicht davon ab, was auf dem Server gehostet wird. Eine akribisch gepflegte Anwendung ist genau im selben Maße gefährdet wie eine vernachlässigte. Der Angriff läuft zudem bemerkenswert unauffällig ab: Der Worker-Prozess stürzt nicht ab, der Server gibt eine standardmäßige HTTP-200-Antwort zurück und die Anwendungsprotokolle verzeichnen nichts Ungewöhnliches.

In unseren Tests entwickelten wir Exploit-Code, der auf x86-64- und ARM-Architekturen zuverlässig funktionierte, auch nach Neustarts von Workern zuverlässig blieb und auf ARM-basierten Hosts, die in Cloud-Flotten immer häufiger zum Einsatz kommen, die Address Space Layout Randomization (ASLR) allein durch HTTP-Anfragen aushebelte.

Technische Details

Die gemeinsame Ursache: longjmp() ohne Auflösung des Aufrufstapels

Beide Schwachstellen befinden sich in Zend, der Engine im Kern von PHP. Zend ist die in C geschriebene Implementierung, die PHP-Quellcode in Bytecode kompiliert, ihn in einer virtuellen Maschine ausführt und alles verwaltet, was die Sprache zur Laufzeit benötigt: Variablen, Arrays, Objekte, Referenzzählung und Speicherzuweisung. Es wurde ursprünglich von Zeev Suraski und Andi Gutmans (der Name ist eine Zusammenziehung ihrer Vornamen) geschrieben und mit PHP 4 eingeführt. Die Zend-Engine ist weder eine optionale Komponente noch ein Add-on eines Drittanbieters; sie ist in jeder PHP-Version enthalten, weshalb sich sein Quellcode im Verzeichnis Zend/ von php-src befindet. In der Praxis bedeutet das: Ein Fehler in Zend ist ein Fehler in der PHP-Engine selbst und betrifft jede Anwendung, jedes Framework und jede Erweiterung, die auf dem Interpreter ausgeführt wird – unabhängig davon, wie dieser Code geschrieben ist.

Zwei zentrale Komponenten der Zend-Kernarchitektur spielen bei den hier beschriebenen Problemen eine entscheidende Rolle: die HashTable, auf der jedes PHP-Array basiert – einschließlich der superglobalen Variablen $_POST – sowie der Zend Memory Manager (Zend MM), PHPs eigener, anforderungsspezifischer Speicherzuordner, der zwischen PHP und dem Betriebssystem angesiedelt ist. Der Ablauf bei schwerwiegenden Fehlern in PHP endet in zend_bailout(), das einen LONGJMP aus dem aktuellen C-Aufrufstapel heraus ausführt:

// Zend/zend.c
ZEND_API ZEND_COLD ZEND_NORETURN void _zend_bailout(const char *filename, uint32_t lineno)
{
...
CG(unclean_shutdown) = 1;
...
LONGJMP(*EG(bailout), FAILURE);
}

Zwischen dem fatalen Fehler und dem umschließenden zend_catch-Block wird nichts ausgeführt. Jede aufrufende Funktion, die Zustandsänderungen vorgenommen hat und darauf angewiesen ist, dass ihr eigener Bereinigungscode ausgeführt wird, hinterlässt diese Änderungen, wenn die Bereinigung ausbleibt. Dies ist nur dann sicher, wenn jede dieser aufrufenden Funktionen unter Berücksichtigung eines abrupten Abbruchs programmiert wurde – was bei einigen jedoch nicht der Fall ist.

CVE-2026-109618: Nicht initialisierter Anfragespeicher, der während derselben Anfrage verbraucht wird

Das kanonische Beispiel ist _zend_hash_str_add_or_update_i() in Zend/zend_hash.c, die Hilfsfunktion, die hinter jedem Einfügen eines Strings als Schlüssel in ein PHP-Array steht. Beim Einfügevorgang erhöht sie beide Elementzähler, nimmt einen Zeiger auf den neuen Bucket entgegen und weist erst dann eine Kopie des Schlüssels zu:

// Zend/zend_hash.c
add_to_hash:
   idx = ht->nNumUsed++;
   ht->nNumOfElements++;
   p = ht->arData + idx;
   p->key = key = zend_string_init(str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);

Wenn zend_string_init() memory_limit überschreitet, löst Zend MM einen fatalen Fehler aus, der in zend_bailout() mündet. Die Ausführung wird nie fortgesetzt, um den Bucket zu vervollständigen. Nun meldet die Tabelle einen Eintrag mehr, als sie tatsächlich enthält, und der Wert, der Hash sowie der Schlüsselzeiger dieses Eintrags entsprechen den Bytes, die der Allokator zuletzt in diesem Speicherbereich hinterlassen hat; das Bucket-Array wird mit einem nicht initialisierten emalloc() zugewiesen, wobei lediglich der Hash-Bereich explizit zurückgesetzt wird.

Während des Teardowns zerstört php_request_shutdown() die Superglobals, und zend_array_destroy() durchläuft nNumUsed Buckets. Der veraltete Eintrag wird an i_zval_ptr_dtor() übergeben, das die übrig gebliebenen Bytes als einen Wert mit Referenzzählung behandelt: Es dereferenziert den darin enthaltenen Zeiger, verringert die Referenzzählung an dieser Adresse und (falls diese Null erreicht) leitet den Vorgang über eine Funktionszeigertabelle weiter, die durch ein Typ-Tag indiziert ist, der ebenfalls aus den übrig gebliebenen Bytes stammt.

Um die Bedingung auszulösen, ist nichts weiter erforderlich als ein URL-kodierter POST-Body, denn PHP befüllt $_POST innerhalb von php_hash_environment(), das von php_request_startup() vor zend_activate_modules() und vor der Kompilierung eines Skripts aufgerufen wird. Ein Feld mit einem verschachtelten Namen wie ZZZZ…[x]=1 veranlasst php_register_variable_ex(), den äußeren Namen als neuen Array-Schlüssel einzufügen, sodass der Angreifer direkt die Länge des Schlüssels kontrolliert, der zugewiesen werden muss. Wird dieser Name so dimensioniert, dass er memory_limit überschreitet, tritt der Bailout genau bei der Schlüsselzuweisung auf.

Die Kontrolle über die übrig gebliebenen Bytes beruht auf dem Determinismus des Allocators. Zend MM weist kleine Speicherbereiche aus größenabhängigen Freilisten strikt nach dem LIFO-Prinzip zu und setzt freigegebene Blöcke niemals auf null. Ein früheres Feld in derselben Anfrage, dessen Wert PHP kopiert, dekodiert und sofort freigibt, kann daher so bemessen werden, dass sein freigegebener Inhalt genau den Block belegt, den das beschädigte Array anschließend beansprucht. Der veraltete Eintrag wird zu einem vollständig vom Angreifer bestimmten Wert, den wir dazu nutzten, ein gefälschtes Array zu erzeugen, dessen Destruktorzeiger auf die Funktion system() von libc verweist, während sich die Befehlszeichenfolge im selben Block befindet.

Das einzige serverseitige Artefakt eines erfolgreichen Versuchs ist ein allgemeiner fataler Fehler im Webserver-Protokoll:

PHP-Fatalfehler: Das zulässige Speicherlimit von 16777216 Bytes ist ausgeschöpft (es wurde versucht, 3670048 Bytes zuzuweisen) in Unknown on line 0

in Unknown on line 0 ist der entscheidende Hinweis: Er bestätigt, dass nie eine PHP-Datei ausgeführt wurde.

CVE-2026-109619: Ungültiger globaler Zustand, der von einer nachfolgenden Anfrage verbraucht wird

Die zweite CVE folgt demselben Mechanismus, doch der Schaden tritt in prozessbezogenem Zustand auf, wodurch sich das Zeitfenster für die Ausnutzung auf eine spätere Anfrage verschiebt. Hier ist die unterbrochene Operation eine, die den Zustand in einer globalen Variablen zwischenspeichert und darauf angewiesen ist, ihren eigenen Bereinigungsaufruf zu erreichen, um ihn zu löschen. PHP speichert die aktiven Serialisierungs- und Deserialisierungskontexte in globalen Modulvariablen zwischen und verwendet den zwischengespeicherten Zeiger erneut, wenn die Verschachtelungsebene ungleich null ist. Nur der passende Zerstörungsaufruf verringert diese Ebene und löscht den Zeiger, und nur eine Request-Initialisierungsroutine der Erweiterung setzt sie zurück. Die Sitzungsverwaltung funktioniert ähnlich: Sie hält die Sitzungs-ID, den Handler-Zustand, die Sitzungsvariablen und den Zustand des Upload-Fortschritts in globalen Variablen, die von speziellen Shutdown-Routinen gelöscht werden.

Wird einer dieser Vorgänge durch einen fatalen Fehler unterbrochen, wird die zugehörige Teardown-Routine übersprungen. Die globale Variable behält ihren Zeiger, und der Verschachtelungszähler zeigt weiterhin an, dass der Vorgang aktiv ist. Beim Herunterfahren der Anfrage wird dann der gesamte anfragebezogene Heap freigegeben. Die globale Variable bleibt jedoch erhalten, da sie zum Prozess und nicht zur Anfrage gehört. PHP behält einen Zeiger auf Modulebene auf Speicher, den es bereits freigegeben hat.

Zwei Faktoren machen dies erreichbar und kontrollierbar:

• Wiederverwendung von Workern: In Deployments mit persistenten Workern wie Apache mod_php verarbeitet derselbe Prozess die nächste Anfrage. Die veraltete globale Variable ist noch intakt, der Vorgang gilt als laufend, und der freigegebene Zeiger wird gelesen, beschrieben oder zur Verzweigung verwendet. Die Daten, die sich zu diesem Zeitpunkt in dem Speicherbereich befinden, können vom Angreifer beeinflusst werden, da auch die zwischenzeitlich verarbeitete Anfrage von ihm stammt. Er bestimmt deren Größe und Inhalt, und das vorhersehbare Speicherzuweisungsverhalten des Zend Memory Managers (Zend MM) ermöglicht es, Daten zuverlässig an der gewünschten Stelle zu platzieren. PHP-FPM beendet einen Worker, wenn der Start der Anfrage fehlschlägt. Dadurch wird die Wiederverwendung bei Unterbrechungen während der Startphase verhindert. Eine Unterbrechung innerhalb eines bereits laufenden Skripts lässt den FPM-Worker dagegen am Leben und setzt ihn gleichermaßen dem Risiko aus.
• Startreihenfolge: php_request_startup() analysiert Request-Variablen, bevor die Request-Initialisierungs-Callbacks von Erweiterungen ausgeführt werden. Die Verarbeitung des Multipart-Upload-Fortschritts führt daher Sitzungs- und Serialisierungscode aus, bevor die Erweiterungen, zu denen diese globalen Variablen gehören, Gelegenheit hatten, sie zurückzusetzen. Dadurch kann bereits in der frühesten Phase einer Anfrage ein veralteter Zeiger verwendet werden.

Neben der Ausschöpfung des Speicherlimits kann dieser Zustand auch durch Zeitüberschreitungen bei der Ausführung und abgebrochene Client-Verbindungen erreicht werden, die jeweils denselben zend_bailout() -Pfad durchlaufen. Die Ausnutzung erfolgt daher in zwei Phasen: Eine Anfrage vergiftet den Worker, eine zweite löst den Zugriff auf den freigegebenen Speicher aus.

Auswirkungen der Schwachstellen

Die Schwere beider Schwachstellen ergibt sich daraus, dass sie früh in der Anfrageverarbeitung auftreten. Da die Beschädigung auftritt, während PHP noch interne Anfragevariablen zusammenstellt – vor der Initialisierung von Erweiterungen und bevor Anwendungscode ausgeführt wird –, stellt jeder erreichbare PHP-Endpunkt auf einem betroffenen Server eine aktive Angriffsfläche dar, einschließlich statischer Formulare, Anmelderouten und Health-Checks. Es gibt keine Authentifizierung, die umgangen, keine Sitzung, die gestohlen, und keinen anfälligen Endpunkt, der aufgespürt werden müsste. Das Risiko besteht unabhängig davon, welches CMS, Framework oder welche Plug-ins verwendet werden.

Der Angriff hinterlässt außerdem nahezu keine digitale Spur. Die Worker-Prozesse bleiben stabil, die Antworten liefern HTTP 200 und die Anwendungsprotokolle weisen keine Auffälligkeiten auf, da nie Anwendungscode ausgeführt wurde. Die einzige serverseitige Spur ist ein einzelner fataler Speicherlimitfehler im Fehlerprotokoll des Webservers, der routinemäßig als belangloses Rauschen abgetan wird. Dadurch fehlen den Sicherheitsverantwortlichen verwertbare Web-Telemetriedaten, um kompromittierte Endgeräte zu identifizieren. 

Bei Webservern mit mehreren Prozessen wie Apache prefork wird jeder Worker-Prozess von einem einzigen Elternprozess erzeugt. Dadurch bleibt das Speicherlayout, auf das ein Angreifer angewiesen ist, auch nach Neustarts von Worker-Prozessen gleich. Diese Stabilität ermöglicht es einem Angreifer, Payloads ohne zusätzliche Kosten weiter zu verfeinern. Ein fehlgeschlagener Versuch wird durch den Neustart eines Workers aufgefangen, den die Überwachung als normalen Vorgang einstuft.

Die beiden CVEs unterscheiden sich hinsichtlich ihrer betroffenen Bereiche und des Zeitpunkts ihrer Ausnutzung. Diese Unterschiede sind für die Angriffspraxis relevant. CVE-2026-109618 ist in sich geschlossen: Eine einzelne Anfrage beschädigt ihre eigenen Daten, und die daraus resultierende Aktion wird noch während der Bereinigung derselben Anfrage ausgeführt. Dadurch ist der Vorgang schnell, atomar und im Nachhinein schwer zu rekonstruieren. CVE-2026-109619 erstreckt sich über mehrere Anfragen und erfordert einen Vergiftungsschritt und einen Auslöseschritt am selben Worker. Dafür betrifft die Schwachstelle einen größeren Bereich des internen Zustands und lässt sich nicht nur durch die Ausschöpfung des Speicherlimits, sondern auch durch Timeouts und abgebrochene Client-Verbindungen auslösen. Das wesentliche Risiko für diese zweite Klasse besteht bei Deployments mit persistenten Workern.

Die erfolgreiche Ausnutzung einer der beiden Schwachstellen ermöglicht die Ausführung von Befehlen im Benutzerkontext des Webservers – ein typischer Ausgangspunkt für die Bereitstellung von Webshells, das Abgreifen von Datenbank- und API-Zugangsdaten aus Konfigurationsdateien und das Vordringen in interne Netzwerke. Das Einspielen von Patches bietet die einzige vollständige Behebung. Wenn ein sofortiges Einspielen von Patches nicht möglich ist, ist die verhaltensbasierte Überwachung von Endgeräten die wichtigste Verteidigungslinie. Denn auch wenn die Ausnutzung auf HTTP-Ebene unsichtbar ist, lassen sich ihre Folgen durchaus erkennen.

Bin ich betroffen?

Beide Schwachstellen sind in jeder PHP-Version der 7.x- und 8.x-Reihe enthalten. Die spezifische HashTable-Reihenfolge, die CVE-2026-109618 zugrunde liegt, wurde durch eine Leistungsoptimierung im Oktober 2017 eingeführt und erstmals mit PHP 7.3.0 ausgeliefert (Dezember 2018). Die Serialisierungs- und Sitzungspfade, die CVE-2026-109619 zugrunde liegen, reichen weiter zurück: bis PHP 7.1 beziehungsweise PHP 5.4. Mit anderen Worten: Diese Möglichkeit zur Ausnutzung besteht in veröffentlichten PHP-Versionen seit mehr als sieben Jahren. Keine der unterstützten Branches ist davon ausgenommen.

Die Version allein bestimmt nicht, ob eine Gefährdung besteht. Der Auslöser für eine Out-of-Memory-Situation muss erreichbar sein, während PHP Anfragedaten verarbeitet. Dafür muss ein Request-Body groß genug werden dürfen, um das Speicherlimit auszuschöpfen, bevor ein Skript ausgeführt wird. In der Praxis bedeutet das, dass die Konfiguration ungefähr Folgendes erfüllt:

 memory_limit < 4 × post_max_size

Die mit PHP ausgelieferten Standardwerte (post_max_size = 8M, memory_limit = 128M) erfüllen diese Bedingung nicht, sodass eine Standardinstallation über den von uns demonstrierten URL-kodierten Pfad nicht erreichbar ist. Viele Produktionsumgebungen sind jedoch so konfiguriert, dass sie große Uploads akzeptieren. Gängige Wertepaarungen wie post_max_size = 64M mit memory_limit = 128M oder post_max_size = 100M mit memory_limit = 256M erfüllen diese Bedingung. Beachten Sie, dass post_max_size pro Verzeichnis in .htaccess festgelegt werden kann oder für einen virtuellen Host festgelegt werden kann, sodass eine einzelne Website bei Shared Hosting selbst die anfällige Konfiguration einrichten kann, ohne dass eine serverweite Änderung erforderlich ist. CrowdStrike hat das Problem reproduziert, indem memory_limit auf 16M gesenkt und post_max_size auf 64M erhöht wurde, ausschließlich um die Test-Payload klein zu halten; derselbe Fehler lässt sich auch mit größeren Payloads bei den oben genannten höheren Grenzwerten auslösen.

Um zu sehen, welche PHP-Version und Konfiguration auf Ihrem Server ausgeführt werden, führen Sie den Befehl php --version aus. Um die auf Ihrem Server für die oben aufgeführten Optionen festgelegten Werte anzuzeigen, führen Sie den folgenden Befehl aus:
php -i | grep -E "^(memory_limit|post_max_size|upload_max_filesize|Loaded Configuration File)”.

So schützt CrowdStrike Falcon Kunden

CrowdStrike setzt auf einen mehrschichtigen Ansatz zur Erkennung der Ausnutzung von Schwachstellen und der anschließenden Aktivitäten. Dabei kommen Machine Learning und verhaltensbasierte Erkennungsverfahren zum Einsatz, darunter Angriffsindikatoren (IOAs, Indicators of Attack). Die Falcon-Plattform bietet standardmäßig Transparenz und Erkennungsabdeckung für Aktivitäten nach der Ausnutzung von PHP-Schwachstellen. Vorhandene IOAs erkennen und verhindern gängige Aktivitäten nach einer Ausnutzung, darunter die Bereitstellung von Webshells, verdächtige untergeordnete Prozesse, die von PHP- oder Webserver-Prozessen gestartet werden, sowie die Ausführung bösartiger Befehle.

CrowdStrike erforscht weiterhin Techniken zur Ausnutzung dieser Sicherheitslücke.

Abbildung 1. Ausnutzungskette von PHP-Schwachstellen

Verwundbare PHP-Versionen mit Falcon Exposure Management identifizieren

CrowdStrike Falcon® Exposure Management bietet umfassende Transparenz über betroffene Umgebungen hinweg. Die Funktionen Network Scan (Netscan) und Verwaltung der externen Angriffsfläche (EASM) ermöglichen eine schnelle, bannerbasierte Erkennung internetexponierter Assets. Darüber hinaus ermöglicht die sensorbasierte Sichtbarkeit eine automatisierte Bewertung von nachgelagerten Patches, die Anbieter für unterstützte Linux-Distributionen sowie Windows- und macOS-Betriebssysteme bereitstellen.

Falcon® Exposure Management erkennt diese CVEs in allen unterstützten Sensorversionen mithilfe der bestehenden Paketmanager-Prüfungen und gezielten Anwendungsprüfungen. Für diese Prüfungen ist keine Mindestversion des Sensors erforderlich.

CrowdStrike hat außerdem die folgenden sensorbasierten Erkennungsfunktionen hinzugefügt. Sie erkennen PHP-Installationen, die bei den bestehenden Prüfungen möglicherweise übersehen werden, etwa benutzerdefinierte Installationen oder Installationen, die nicht über einen Paketmanager vorgenommen wurden. Sie sind nur in den aufgeführten Sensorversionen verfügbar:

• Windows (Falcon-Sensor 7.40 oder höher): Eine systemweite Suche nach PHP-Ausführungsdateien auf dem Standardlaufwerk. Dadurch werden zusätzliche PHP-Installationen sichtbar, die mit bestehenden Prüfungen möglicherweise nicht erkannt werden, darunter auch angepasste Installationen.
• Linux (Falcon-Sensor 7.31 oder höher): Prüfung laufender Prozesse zur Identifizierung von PHP-Installationen, die außerhalb des erwarteten Paketmanagers vorgenommen wurden.

Kunden mit älteren Sensorversionen sind weiterhin durch Paketmanager-Prüfungen und gezielte Anwendungsprüfungen abgedeckt. Die zusätzlichen systemweiten Prüfungen und Prüfungen laufender Prozesse stehen ihnen erst nach einem Upgrade zur Verfügung.

Abbildung 2. Identifizierung verwundbarer PHP-Versionen in Falcon® Exposure Management

Identifizierung von Bedrohungen mit Next-Gen SIEM

Falcon Next-Gen SIEM: Dashboard zur Reaktion auf zukünftige Bedrohungen

Die Erkennungsabdeckung von CrowdStrike Falcon® Next-Gen SIEM für diese Bedrohung (neuer Abschnitt „PHP-Schwachstellen bezüglich Remote-Codeausführung (CVE-2026-109618/109619)“ im CrowdStrike Falcon-Dashboard zur Reaktion auf zukünftige Bedrohungen) wurde im Rahmen des Releases der NG-SIEM-Content-Pakete für die Produktion freigegeben.

Das Dashboard „Response bei zukünftigen Bedrohungen“ ist ein spezialisiertes Tool, mit dem CrowdStrike-Kunden sofort erkennen können, welche aktiven Kampagnen oder neu entdeckten Schwachstellen ihre Umgebung beeinträchtigen könnten. Auf Basis umfangreicher Telemetriedaten aus Falcon-Plattformmodulen und in Falcon Next-Gen SIEM aufgenommenen Daten von Drittanbietern stellt dieses Dashboard sofort einsatzbereite Abfragen für Erkennung und Threat Hunting bereit. Damit können Sicherheitsteams schnell feststellen, in welchem Umfang sie Bedrohungen ausgesetzt sind, und potenziell kompromittierte Assets identifizieren.

• Siehe Next-Gen SIEM > Log-Management > Dashboards

Abbildung 3. Identifizierung des Dashboards zur Reaktion auf zukünftige Bedrohungen in Falcon Next-Gen SIEM

Vorlagen für Korrelationsregeln von Falcon Next-Gen SIEM

Wir haben eine neue Falcon® Next-Gen SIEM-Vorlage für Korrelationsregeln (CRT, Correlation Rule Template) hinzugefügt, um die CVEs CVE-2026-109618 und CVE-2026-109619 zu erkennen und darauf zu reagieren. Diese Regeln decken Ausnutzungsversuche im Zusammenhang mit diesen Sicherheitslücken ab. 

Allgemein - Web - PHP-Speichererschöpfung beim Start einer Anfrage (CVE-2026-109618 & CVE-2026-109619)

Diese Erkennung identifiziert fatale PHP-Fehler aufgrund von Speichermangel, die auftreten, bevor ein PHP-Skript ausgeführt wird. Konkret zielt sie auf ein charakteristisches Muster ab, das in Webserver-Fehlerprotokollen als “Allowed memory size of N bytes exhausted” in Kombination mit “in Unknown on line 0.” auftritt. Die "Unknown on line 0”-Markierung unterscheidet Fehler in der Startphase von der wesentlich unübersichtlicheren Vielzahl von Speicherfehlern innerhalb eines Skripts und liefert den Sicherheitsverantwortlichen ein präziseres Signal dafür, dass etwas den PHP-Interpreter dazu bringt, den Speicher aufzubrauchen, bevor Anwendungscode ausgeführt wird. Muster wie dieses können auf eine versuchte Ausnutzung der PHP-Engine hindeuten. Kunden können die Vorlage hier einsehen ([US-1]  [US-2]  [US-3]  [EU-1]  [US-GOV-1]  [US-GOV-2]).

Fazit und Empfehlungen

CrowdStrike beobachtet die sich entwickelnde Lage aktiv und wird über neue Entwicklungen informieren, sobald neue Informationen verfügbar sind. Parallel dazu entwickeln und stellen wir weiterhin neue Verhaltenslogik auf der Falcon-Plattform bereit, um bösartige Aktivitäten im Zusammenhang mit den offengelegten PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619 zu erkennen und zu verhindern.

Wir empfehlen Kunden, alle Systeme zu identifizieren, auf denen verwundbare PHP-Versionen laufen, und gemäß den offiziellen Empfehlungen von PHP oder des jeweiligen Anbieters die neuesten Sicherheitsupdates einzuspielen.