Cloudflare: Auch die Antwort zählt
Cloudflare beschreibt Transaktionserkennung aus Anfrage und Origin-Antwort, die passende Antworten vor möglichem Datenabfluss blockiert. Das ist auch ohne Shell-Start relevant. Historische Rollout-Zeiten garantieren keinen Schutz Ihres Kontos. Regeln, Routing, Ausnahmen und Ereignisse prüfen. Direkte Origin-Zugänge und nicht proxied Hosts bleiben zu patchen.
CloudflareOriginal lesen ↗Akamai, Imperva und Unit 42 prüfen
Akamai nennt Adaptive Security Engine 3000991 v1, Unit 42 Threat ID 543004 und Inventarhinweise; Imperva beschreibt mehrschichtigen Schutz. Das sind produktspezifische Angaben, keine universellen WAF-Regeln. Aktuellen Hinweis, aktivierte Policy und tatsächlichen Verkehrsweg prüfen. Eine blockierte Anfrage beweist nicht, dass frühere Versuche scheiterten.
AkamaiOriginal lesen ↗ImpervaOriginal lesen ↗Palo Alto Networks Unit 42Original lesen ↗Corelight und Cisco Talos einordnen
Corelight veröffentlicht Zeek-/Suricata-Regeln. Potentially_Affected_PHP_Version ist Inventar, getrennt von Request-/Sitzungserkennung. Zeek braucht HTTP-Sichtbarkeit; einige Repository-Grenzen heißen noch vorläufig. Aktuelle Advisories prüfen. Cisco Talos nennt Snort 67359, 67360, 67375. Fehlende Alarme oder verborgene Header belegen keine Sicherheit.
CorelightOriginal lesen ↗Cisco TalosOriginal lesen ↗Was Endpoint-Belege zeigen
CrowdStrike beschreibt Schutz vor nachgelagerten Aktivitäten. Unerwartete PHP-Kindprozesse, Shells, Verbindungen und Persistenz mit der Web-Zeitleiste abgleichen. Das kann einen Verdacht erhärten, aber fehlende Shell-Prozesse schließen Speicherlecks nicht aus. Angaben an Produkt und Publikationsdatum binden; Netzwerk und Host zusammen prüfen.
CrowdStrikeOriginal lesen ↗Primärquellen & weiterführende Informationen
PHP security teamOriginal lesen ↗CVE-2026-109618Original lesen ↗CVE-2026-109619Original lesen ↗Forschung & Praxisanleitungen
PHP2Shell-Werkzeuge
Öffentliche Websites prüfen, lokale Konfigurationen und Logs untersuchen oder Open-Source-Werkzeuge finden. Jedes Ergebnis nennt Belege und Grenzen.
01PHP2Shell einfach erklärt
PHP ist die Laufzeit hinter WordPress, Laravel und Plugins. Ein Plugin-Update aktualisiert PHP nicht. Zwei Speicherfehler können bei fehlerhafter Request-Bereinigung Daten offenlegen oder Code ausführen. Eine öffentliche Prüfung liefert nur Hinweise; die tatsächliche Web-Laufzeit und den Patch muss der Administrator bestätigen.
02Angriffsversuch oder erfolgreicher Einbruch?
Auffällige Multipart-Anfragen oder WAF-Alarme können Versuche anzeigen. OOM, SIGSEGV/SIGABRT und HTTP-500-Spitzen haben auch harmlose Ursachen. Unerwartete PHP-Kindprozesse, Verbindungen, Dateiänderungen oder Konten dringend untersuchen. Speicherlecks müssen keine Webshell oder Datei hinterlassen; ein sauberer Dateiscan schließt sie nicht aus.
03Beweise vor Änderungen sichern
Entdeckungszeit, Domain, Instanz, Laufzeit, Symptome und letzten vertrauenswürdigen Zustand notieren. Originale Zugriffs-, Fehler-, WAF- und Prozesslogs samt Zeitzone sowie Cloud-Auditdaten und autorisierte Snapshots sichern. Kopien beschränken und hashen. Keine Tokens oder Kundendaten an öffentliche Scanner senden. Logs und verdächtige Dateien vor Sicherung nicht löschen.
04Wiz und Calif richtig einordnen
Die Forschung erklärt Fehler über Request-Grenzen hinweg. GHSA zu CVE-2026-109618 bestätigt mod_php-RCE; FPM-Anfälligkeit beruht auf Quellanalyse ohne vollständigen FPM-Exploit für diese CVE. CVE-2026-109619 bestätigt separat einen anwendungsabhängigen FPM-Upload-Progress-Pfad. Belege je SAPI anhand der jeweiligen offiziellen Advisory unterscheiden.
05Cloudflare: Auch die Antwort zählt
Cloudflare beschreibt Transaktionserkennung aus Anfrage und Origin-Antwort, die passende Antworten vor möglichem Datenabfluss blockiert. Das ist auch ohne Shell-Start relevant. Historische Rollout-Zeiten garantieren keinen Schutz Ihres Kontos. Regeln, Routing, Ausnahmen und Ereignisse prüfen. Direkte Origin-Zugänge und nicht proxied Hosts bleiben zu patchen.