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

SignalWarum es wichtig istWo nachsehen
Fatale Memory-Limit-Fehler direkt nach Multipart-POSTsSpeichererschö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 ClientExploits brauchen mehrere Versuche, um sich an das Speicherlayout des Ziels anzupassen.Zugriffslog
Worker, die mit SIGSEGV / SIGABRT abstürzen, oder ungewöhnlich viel Worker-WechselFehlgeschlagene Use-after-free-Versuche bringen den Worker oft zum Absturz.FPM-Log, Apache-Fehlerlog, dmesg / journal
Ungewöhnlich lange oder prozentkodierte PHPSESSID in AntwortenDer 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-BenutzersKlassisches 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.

shell
# 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 -20

Nach 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.

Das Speicherleck am Proxy abfangen

nginx + shell
# Temporary: log Set-Cookie on responses to spot oversized PHPSESSID values.
# This writes session IDs to disk — restrict the file and remove it afterwards.
# In the http {} block:
log_format php2shell '$remote_addr [$time_local] "$request" $status "$sent_http_set_cookie"';
# In the server {} block:
access_log /var/log/nginx/php2shell.log php2shell;

# Then, from a shell, look for long or percent-encoded session cookies
grep -E 'PHPSESSID=[^;"]{64,}|PHPSESSID=[^;"]*%' /var/log/nginx/php2shell.log

Nach Spuren eines Einbruchs suchen

shell
# 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.

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

  1. Zuerst Beweise sichern: Logs kopieren und nach Möglichkeit einen Platten- / Speicher-Snapshot erstellen, bevor Sie neu aufbauen.
  2. Patchen oder isolieren Sie den Host. Ein Neuaufbau aus einem sauberen Image ist besser als Bereinigen vor Ort.
  3. 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.
  4. Sessions invalidieren, damit gestohlene Cookies nicht mehr funktionieren, und Admins neu anmelden lassen.
  5. Reichweite prüfen: Worauf diese Zugangsdaten sonst noch Zugriff geben (Cloud-Konten, interne APIs, andere Datenbanken).