PHP (ein rekursives Akronym für PHP: Hypertext Preprocessor) ist eine kostenlose, quelloffene serverseitige Skriptsprache, die hauptsächlich für die Webentwicklung verwendet wird. Nach Angaben des Web-Technologie-Trackers W3Techs wird PHP auf „fast 70 % aller Websites ausgeführt, deren Programmiersprache identifiziert werden kann.“
PHP2Shell ist ein Paar kritischer Fehler im PHP-Interpreter selbst, jeweils mit einem CVSS v4.0-Score von 9,2. Beide ermöglichen es einem nicht authentifizierten Angreifer, Code auf einem Webserver mit einer einzigen handwerklich erstellten Webanfrage oder einem Paar davon auszuführen, bevor ein Anwendungscode ausgeführt wird.
- CVE-2026-109618 missbraucht die Fehlerbehandlung von PHP bei Speichermangel;
- CVE-2026-109619 missbraucht den Status, der von einer früheren fehlgeschlagenen Anfrage auf demselben Worker übrig bleibt.
Da der Fehler in PHP und nicht in WordPress, Drupal oder Magento vorhanden ist, ist jeder erreichbare PHP-Endpunkt auf einem betroffenen Server exponiert, einschließlich Anmeldeseiten, statischer Formulare und Integritätsprüfungen.
Jede PHP-Version aus dem letzten Jahrzehnt ist betroffen (zurück bis 5.4). Behobene Versionen sind 8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP 8.1 und älter erhalten nur minimale Quellcode-Backports.
PHP2Shell-Offenlegungszeitplan
Zwei kritische PHP-Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619, gingen innerhalb weniger Tage von privater Forschung zu aktiver Ausnutzung über. Nachfolgend finden Sie den Zeitplan der Ereignisse:
- August 2026: Calif findet die ersten Remote-Code-Execution-Pfade (RCE) während eines KI-gestützten Audits und meldet sie PHP. Wiz findet die Fehler unabhängig davon und meldet sie PHP.
- Anfang Oktober 2026: Cloudflare beginnt mit der Entwicklung von Web Application Firewall (WAF)-Schutzmaßnahmen.
- 17. Oktober 2026: AWS meldet erste bekannte Exploit-Versuche gegen Amazon MadPot, vier Tage vor der geplanten koordinierten Offenlegung.
- 20. Oktober 2026: Details der zwei kritischen Remote-Code-Sicherheitslücken in PHP, CVE-2026-109618 und CVE-2026-109619, wurden vor der von der PHP Foundation geplanten koordinierten Offenlegung am 22. Oktober 2026 durchgesickert.
- 21. Oktober 2026: Die PHP Foundation gibt die Sicherheitslücken vorzeitig bekannt und empfiehlt allen, ein Update durchzuführen. Notfall-Updates für die betroffenen Softwareversionen werden später an diesem Tag veröffentlicht.
- 21. Oktober 2026 und danach: Forscher berichten von umfangreichen Exploit-Versuchen.
Wie suche ich nach PHP2Shell-Aktivitäten in meiner Umgebung?
Lassen Sie uns mit Sumo Logic nach PHP2Shell-Aktivitäten suchen. Für jeden Aktivitätstyp finden Sie zwei Suchanfragen: eine gegen Rohprotokolle verschiedener Typen und eine gegen normalisierte Datensätze für Kunden, die Sumo Logic Cloud SIEM haben.
Zwei Hinweise, bevor Sie beginnen:
- Rohprotokoll-Suchanfragen müssen angepasst werden. Die Beispiele für Rohprotokoll-Suchanfragen enthalten Parsing-Operationen, die für einen Protokollquellentyp spezifisch sind, z. B. Apache-Zugriffsprotokolle. Sie beschränken sich auch auf eine Protokollkategorisierung (z. B.
_sourceCategory=linux/system webserver), die Sie beim Onboarding der Protokollquelle zuweisen. Wenn Sie die hier enthaltenen Beispiele für Rohprotokoll-Suchanfragen verwenden möchten, müssen Sie diese wahrscheinlich für Ihre Umgebung anpassen. - Datensatz-Suchanfragen funktionieren wie geschrieben. Sie basieren auf dem normalisierten Schema von Sumo Logic Cloud SIEM, daher sind sie ohne Änderungen verwendbar.
Diese Suchanfragen suchen nach Verhalten auf dem Webserver nach dem anfänglichen Exploit. Sie suchen nicht nach HTTP-Transaktionen, die Exploit-Payloads enthalten könnten. In vielen Fällen haben Sie Sicherheitsprodukte wie Web Application Firewalls „vor“ Ihren Internet-exponierten Webservern, und diese Produkte haben ihre eigenen Erkennungen rund um Webserver-Exploits mit HTTP-Analyse. Die Telemetrie von diesen Produkten sollte in Sumo Logic für Korrelation, Alarmierung und weitere Analyse aufgenommen werden.
Der Fokus der Detection Engineering in diesem Blog liegt auf Verhaltensbeobachtungen auf dem Webserver im Zusammenhang mit dem anfänglichen Exploit und der Folgemaßnahmen nach einem erfolgreichen Angriff. Diese Beobachtungen können dann mit der Telemetrie von Ihren anderen Sicherheitsprodukten korreliert werden.
Suchen Sie nach Spitzen bei Webserver-Fehlern
Die PHP2Shell-Sicherheitslücken stammen aus Fehlern in der PHP-Fehlerbehandlung, daher werden Exploit-Versuche als Fehler auf Ihren Webservern angezeigt. Mit dem timeslice-Suchoperator von Sumo Logic können Sie leicht beurteilen, ob es Spitzen bei der Fehleraktivität auf Ihren Webservern gegeben hat.
Im folgenden Beispiel zählen wir die Anzahl der serverseitigen Fehler (die einen HTTP-Antwortcode im Bereich 500–599 generieren) pro Stunde. Wir können die Ergebnisse visuell auf Spitzen überprüfen.
Beispiel 1: (Syslog-umschlossene) Apache-Zugriffsprotokolle
(_sourceCategory=linux/system webserver_system=apache webserver_farm=* OR _sourceCategory=linux/syslog) httpd-access HTTP (50* OR 51* OR 52* OR 53* OR 54* OR 55* OR 59*)
| parse "httpd-access: *" as mesg nodrop
| parse regex field=mesg "^(?<src_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s+(?<vhost>\S+)" nodrop
| parse regex field=mesg "\"(?<method>[A-Z]+)\s(?<uri>\S+)\sHTTP\/[\d\.]+\"\s(?<status_code>\d+)\s(?<size>[\d-]+)" nodrop
| where !isNull(status_code) and status_code >= 500 and status_code <= 599
| timeslice 1h
| count by _timeslice, _sourceHost
| sort by _timeslice, _count descBeispiel 2: Sumo Logic Cloud SIEM-Datensätze
Beachten Sie, dass die folgende Abfrage davon abhängt, dass entweder die Standard-Match-Listen web_servers oder http_servers in Ihrer Bereitstellung erstellt und gefüllt werden.
_index=sec_record*
| where http_response_statusCode >= 500 and http_response_statusCode <= 599
| where jsonArrayContains(listMatches, "web_servers") or jsonArrayContains(listMatches, "http_servers")
| timeslice 1h
| count by _timeslice, dstDevice_ip
| sort by _timeslice, _count desc
Abbildung 1: Anstieg der Fehleraktivität des Webservers
Identifizieren Sie Webserver-Prozesse, die eine Shell starten
Wenn ein Angreifer PHP2Shell erfolgreich ausnutzt, kann er bösartigen Code über einen untergeordneten Prozess des Webservers oder des PHP-Prozesses ausführen. Die folgende Abfrage identifiziert häufige Webserver-Prozesse, die in Windows- und Linux-Umgebungen eine vollständige Betriebssystem-Shell starten.
Beispiel 1: Windows-Prozessprotokolle
_sourceCategory ="windows/eventlogs"
| parse "<EventID>*</EventID>" as eventId
| where eventId = "4688"
| parse "<Data Name='ParentProcessName'>*</Data>" as parentBaseImage nodrop
| parse "<Data Name='NewProcessName'>*</Data>" as baseImage nodrop
| parse "<Data Name='CommandLine'>*</Data>" as commandLine nodrop
| parse "<Data Name='SubjectUserName'>*</Data>" as user_username nodrop
| parse "<Data Name='SubjectDomainName'>*</Data>" as user_domain nodrop
| parse regex "<Computer>(?<device_hostname>[^<]+)</Computer>" nodrop
| where parentBaseImage matches /(?i).*(w3wp\.exe|httpd\.exe|nginx\.exe|php-cgi\.exe|tomcat\.exe)$/
| where baseImage matches /(?i).*(cmd\.exe|powershell\.exe|bitsadmin\.exe|pwsh\.exe|powershell_ise\.exe)$/
| fields device_hostname, user_domain, user_username, parentBaseImage, baseImage, commandLineBeispiel 2: Sumo Logic Cloud SIEM-Datensätze
_index=sec_record*
| where parentBaseImage matches /(?i).*(w3wp\.exe|httpd\.exe|nginx\.exe|php-cgi\.exe|tomcat\.exe|\/httpd|\/nginx|\/php-cgi|\/tomcat|\/apache2|\/apache)$/
| where baseImage matches /(?i).*(cmd\.exe|sh\.exe|bash\.exe|powershell\.exe|bitsadmin\.exe|pwsh\.exe|powershell_ise\.exe|\/bash|\/sh|\/dash|\/zsh|\/ksh|\/csh|\/python3?|\/perl)$/
| fields device_hostname, device_ip, user_username, parentBaseImage, baseImage, commandLine
Abbildung 2: Auffinden einer Shell, die von nginx gestartet wird
Suchen Sie nach Webserver-Prozessen, die häufige Web-Shell-Befehle ausführen
Der Webserver kann auch Shell-Befehle direkt ausführen, anstatt über eine vollständige Betriebssystem-Shell. Die folgende Abfrage identifiziert häufige Discovery-, Credential-Harvesting- und Exfiltrationsbefehle, die als untergeordnete Prozesse des Webserver-Prozesses ausgeführt werden.
Beispiel 1: Windows-Prozessprotokolle
_sourceCategory ="windows/eventlogs"
| parse "<EventID>*</EventID>" as eventId
| where eventId = "4688"
| parse "<Data Name='ParentProcessName'>*</Data>" as parentBaseImage nodrop
| parse "<Data Name='NewProcessName'>*</Data>" as baseImage nodrop
| parse "<Data Name='CommandLine'>*</Data>" as commandLine nodrop
| parse "<Data Name='SubjectUserName'>*</Data>" as user_username nodrop
| parse "<Data Name='SubjectDomainName'>*</Data>" as user_domain nodrop
| parse regex "<Computer>(?<device_hostname>[^<]+)</Computer>" nodrop
| where parentBaseImage matches /(?i).*(w3wp\.exe|httpd\.exe|nginx\.exe|php-cgi\.exe|tomcat\.exe|apache).*/
| where commandLine matches /(?i).*(whoami|net user |ping |systeminfo |netstat |arp -a|ipconfig |ifconfig |curl |wget ).*/
| fields device_hostname, user_domain, user_username, parentBaseImage, baseImage, commandLineBeispiel 2: Sumo Logic Cloud SIEM-Datensätze
_index=sec_record*
| where parentBaseImage matches /(?i).*(w3wp\.exe|httpd\.exe|nginx\.exe|php-cgi\.exe|tomcat\.exe|apache|\/httpd|\/nginx|\/php-cgi|\/tomcat|\/apache2).*/
| where commandLine matches /(?i).*(whoami|net user |ping |systeminfo |netstat |arp -a|ipconfig |ifconfig |curl |wget |id |uname |cat \/etc\/passwd|nc -).*/
| fields device_hostname, device_ip, user_username, parentBaseImage, commandLine
Abbildung 3: Ein Remote-wget-Befehl als untergeordneter Prozess von Internet Information Server
Sumo Logic Cloud SIEM-Erkennungen
Es gibt mehrere sofort einsatzbereite Sumo Logic Cloud SIEM-Regeln, die Web-Shell-Aktivitäten erkennen und dabei helfen, Webserver zu identifizieren, die erfolgreich durch PHP2Shell ausgenutzt wurden. Die Erkennungstheorien der Regeln sind dieselben wie die oben besprochenen Abfragen: ungewöhnliche untergeordnete Prozesse von Webserver-Prozessen und Spitzen in den Fehlerraten auf Webservern.
Die folgenden Erkennungen können Ihnen bei der Untersuchung potenzieller Kompromittierungen helfen:
| Cloud SIEM-Regel-ID | Regelname |
|---|---|
| MATCH-S00164 | Verdächtige Shells, die von Webservern erzeugt werden |
| MATCH-S00174 | Webdienste, die häufige Web-Shell-Befehle ausführen |
| MATCH-S00539 | Webserver, die verdächtige Prozesse ausführen* |
| OUTLIER-S00036 (neu) | Anstieg von HTTP-Serverfehlern von Quell-IP |
| OUTLIER-S00037 (neu) | Anstieg von HTTP-Serverfehlern zu Ziel-IP |
Wie bereits erwähnt, können Sie eine höherwertige Erkennung für erfolgreiche PHP2Shell-Exploits erstellen, indem Sie CHAIN-Regeln erstellen. Eine CHAIN-Regel korreliert eine Edge-Device-Beobachtung von PHP2Shell (z. B. eine WAF-Warnung) für eine Entität mit der Web-Shell-Erkennungslogik in der obigen Tabelle.
Beachten Sie, dass diese Regeln die Erstellung und Befüllung von Standard-Match-Listen erfordern. MATCH-S00539 verwendet die Match-Liste „web_servers“, um die Erkennung auf die Prozessausführung auf Ihren Webservern zu beschränken.
OUTLIER-S00036 und OUTLIER-S00037 benötigen die Match-Listen „web_servers“ oder „http_servers“, um serverseitige Fehler zu verfolgen. Erfahren Sie, wie Sie eine Match-Liste erstellen und befüllen.
Empfehlungen zur Behebung und Entschärfung von PHP2Shell
Die Anleitung der PHP-Gruppe ist klar: Aktualisieren Sie jetzt.
„Wer ist gefährdet: alle PHP-Installationen, die Webanfragen verarbeiten, einschließlich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Wir halten das Risiko für mod_php am höchsten, mit einem nachgewiesenen Exploit, bei dem eine nicht authentifizierte Anfrage den Angriff auslösen kann, bevor ein Anwendungscode ausgeführt wird.“ Lesen Sie die vollständige Empfehlung der PHP-Gruppe hier.
Die Analyse der Community zeigt, dass eine erfolgreiche Ausnutzung Angreifern die Befehlsausführung im Kontext des Webserver-Benutzers ermöglicht. Von dort aus können sie Web-Shells bereitstellen, API- und Datenbankzugangsdaten aus Konfigurationsdateien sammeln und in interne Netzwerke eindringen.
Eine sofortige Aktualisierung wird empfohlen. Wenn Sie noch nicht aktualisieren können, verwenden Sie die oben genannten Suchanfragen und Erkennungen, um betroffene Server auf Post-Exploitation-Aktivitäten zu überwachen, die auf eine erfolgreiche Ausnutzung hindeuten.
Wenn Sie noch nicht über Cloud SIEM verfügen und verstehen möchten, wie es Ihnen bei der Erkennung und Reaktion auf Bedrohungen wie diese helfen kann, buchen Sie eine Demo, um mehr zu erfahren.
Referenzen und weitere Ressourcen
NIST-Schwachstelleninformationen
Anleitung von PHP
Ressourcen und Berichte der Cybersicherheits-Community
- https://calif.io/php2shell/
- https://www.wiz.io/blog/php2shell-php-rce
- https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
- https://www.crowdstrike.com/en-us/blog/crowdstrike-protects-customers-from-php-rce-zero-days/
- https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html
- https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/
- https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
- https://blog.checkpoint.com/security/php2shell-what-we-know-about-the-leaked-critical-php-vulnerabilities-cve-2026-109618-cve-2026-109619/
- https://blog.cloudflare.com/php-vulnerabilities-waf-protection
- https://research.jfrog.com/post/php2shell-all-you-need-to-know-about-cve-2026-109618-and-cve-2026-109619/
- https://www.reuters.com/technology/what-is-php-why-did-it-take-government-websites-offline-2026-10-21/
