Erkennung & Reaktion
Wurde ich getroffen?
Keine einzelne Regel erfasst jede Variante, und der anfällige Code läuft unterhalb Ihrer Anwendung — Anwendungslogs zeigen also womöglich nichts. Nutzen Sie diese Signale zur Priorisierung, nicht zur Entwarnung.
Zuletzt geprüft 2026-10-22
Fehlende Signale sind kein Beweis für Sicherheit
Der Speicherleck-Pfad kann Geheimnisse stehlen, ohne jemals Code auf dem Server auszuführen. Patchen Sie unabhängig davon, was Sie finden.
Signale, die eine Untersuchung lohnen
| Signal | Warum es wichtig ist | Wo nachsehen |
|---|---|---|
| Fatale Memory-Limit-Fehler direkt nach Multipart-POSTs | Speichererschöpfung ist ein Auslöser. CVE-2026-109619 hat auch Pfade ohne OOM; fehlende OOM-Fehler schließen die Schwachstelle nicht aus. | PHP- / FPM-Fehlerlog + Zugriffslog des Webservers |
| Häufungen von HTTP 500 von einem Client | Exploits brauchen mehrere Versuche, um sich an das Speicherlayout des Ziels anzupassen. | Zugriffslog |
| Worker, die mit SIGSEGV / SIGABRT abstürzen, oder ungewöhnlich viel Worker-Wechsel | Fehlgeschlagene Use-after-free-Versuche bringen den Worker oft zum Absturz. | FPM-Log, Apache-Fehlerlog, dmesg / journal |
| Ungewöhnlich lange oder prozentkodierte PHPSESSID in Antworten | Der Speicherleck-Pfad URL-kodiert abgeflossenen Heap-Speicher in das Session-Cookie — selbst auf Seiten, die nie session_start() aufrufen. | Logs von Reverse Proxy / CDN / WAF mit Set-Cookie (nicht in Standard-Zugriffslogs) |
| Neue .php-Dateien im Web-Root, unerwartete Kindprozesse des PHP-Benutzers | Klassisches Verhalten nach einem Einbruch: Webshells, curl/wget, Reverse Shells von www-data. | Dateisystem, EDR, Prozess-Accounting |
Eine normale PHPSESSID ist kurz und alphanumerisch (standardmäßig 32 Zeichen). Hunderte Zeichen oder %xx-Bytefolgen darin sind nicht normal.
Logs durchsuchen
Die Pfade sind Debian/Ubuntu-Standards. Passen Sie sie an Ihr System an; decken Sie mindestens den Zeitraum seit Anfang Oktober 2026 ab.
# 1. Memory-limit fatals (PHP's exact message)
sudo grep -rh "Allowed memory size of" /var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ /var/log/nginx/ 2>/dev/null | tail -50
# 2. Workers killed by signals
sudo grep -rhE "exited on signal (6|11)|exit signal (Segmentation fault|Aborted)" \
/var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ 2>/dev/null | tail -50
sudo journalctl --since "2026-10-01" | grep -E "php.*segfault" | tail
# 3. Clients producing many 500s on POST (combined log format)
sudo awk '$6=="\"POST" && $9==500 {print $1}' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
| sort | uniq -c | sort -rn | head -20Nach dem Patch kann auch das neue harte Speicherlimit Worker abrupt beenden. Ein einzelner Worker-Abbruch ist kein Beweis für einen Angriff — achten Sie auf Häufungen beim selben Client oder Request-Muster.
Nach Spuren eines Einbruchs suchen
# PHP files changed in the web root since the bugs became known (adjust path/date)
sudo find /var/www -type f -name '*.php' -newermt '2026-08-01' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort | tail -100
# Processes the web user is running right now (shells and downloaders are red flags)
ps -u www-data -o pid,ppid,lstart,cmd | grep -vE 'php-fpm|apache2|httpd'
# Established connections owned by PHP / Apache — review every remote address
sudo ss -tpn state established | grep -E 'php|apache|httpd'WAF-Abdeckung
Verwaltete Regeln sind eine Notlösung, während Sie patchen. Prüfen Sie die PHP2Shell-Hinweise Ihres Anbieters. Cloudflare hat seine Regel-IDs veröffentlicht — siehe die Cloudflare-Seite.
Erkennungen von Herstellern
Wenn Sie eines dieser Produkte nutzen, beschreiben deren Beiträge die ausgelieferten Signaturen und Hunting-Abfragen.
- AkamaiCritical RCE vulnerabilities in PHP core
- ImpervaPHP2Shell vulnerability updates
- CorelightPHP2Shell detection
- CrowdStrikeProtecting customers from PHP RCE zero-days
- Unit 42CVE-2026-109618 / CVE-2026-109619
- Cisco TalosTwo critical RCEs in PHP core
- watchTowrPHP RCE FAQ: CVE-2026-109618
- SansecPHP2Shell: critical PHP RCE
Keine „PoC“-Skripte von GitHub auf Ihren Servern ausführen
Behandeln Sie Exploit- und Scanner-Repositories als nicht vertrauenswürdig. Öffentliche Verfügbarkeit belegt weder Funktion noch Sicherheit. Nutzen Sie Herstellerprüfungen und testen Sie unbekannte Skripte nie in Produktion.
Wenn Sie etwas finden
- Zuerst Beweise sichern: Logs kopieren und nach Möglichkeit einen Platten- / Speicher-Snapshot erstellen, bevor Sie neu aufbauen.
- Patchen oder isolieren Sie den Host. Ein Neuaufbau aus einem sauberen Image ist besser als Bereinigen vor Ort.
- Alles austauschen, was PHP im Speicher sehen konnte: Datenbankpasswörter, API-Schlüssel, OAuth-Client-Secrets, SMTP-Zugangsdaten, App-Schlüssel (
APP_KEY, WordPress-Salts), TLS-Private-Keys, falls PHP darauf Zugriff hatte. - Sessions invalidieren, damit gestohlene Cookies nicht mehr funktionieren, und Admins neu anmelden lassen.
- Reichweite prüfen: Worauf diese Zugangsdaten sonst noch Zugriff geben (Cloud-Konten, interne APIs, andere Datenbanken).