KIungefiltert

· 4 Min. Lesezeit · Read in English

PHP2Shell: Aus Scans werden funktionierende Shells

Die PHP2Shell-Lücken werden jetzt erfolgreich ausgenutzt, CISA führt sie als aktiv angegriffen. Patches gibt es seit dem 21. Oktober. Unit 42 hat die Zuordnung eines Behördenangriffs zurückgenommen.

SicherheitSelfhosting

Bei PHP2Shell gab es eine Wende. Bis vor wenigen Tagen sah man vor allem Scans, Fingerprinting und Exploits, die nicht funktionierten. Inzwischen starten Angreifer echte Shells. Für alle, die PHP-Server betreiben, ist das die Meldung, die zählt.

Was passiert ist

PHP2Shell ist der Sammelname für zwei kritische Lücken in PHP: CVE-2026-109618 und CVE-2026-109619. Beide erlauben Remote Code Execution (RCE), also das Ausführen von beliebigem Code auf dem Server aus der Ferne, und das ohne Anmeldung. Laut BleepingComputer waren Details und Proof-of-Concept-Code schon vor den Patches im Umlauf. Das PHP-Team hielt keinen davon für funktionsfähig. Amazon Threat Intelligence meldete Angriffsversuche bereits vier Tage vor der Veröffentlichung der Patches. Cloudflare, watchTowr, Patchstack und andere stuften die frühen Versuche als erfolglos ein.

Dann kam der Nachweis aus Honeypots. Ein Honeypot ist ein absichtlich verwundbares Ködersystem, das Angriffe protokolliert. Der Forscher Adel Karimi (Perplexity) beobachtete einen Angriff auf eine Apache-mod_php-Installation mit PHP 8.4.26. Die Kette bestand aus vier Stufen von HTTP-Anfragen: Speicher erschöpfen, Speicherinhalte auslesen, am Ende einen Shell-Befehl ausführen. Laut SecurityWeek wurden am 24. Oktober 35 Shells auf drei Honeypots gestartet. Sie kamen von zwei IP-Adressen: Eine erzeugte 3 Shells, die andere 32. Einen nachgeladenen Schadcode (Second Stage) hat man dabei nicht beobachtet. Marcus Hutchins (Expel) bestätigte die Auswertung.

Bei der Einordnung hilft eine Unterscheidung. Das sind Honeypot-Zahlen und keine Zahl bestätigter Opfer. Karimi weist selbst darauf hin, dass sein Aufbau mit nur einem Worker-Prozess für Angreifer günstig war. Wie zuverlässig der Exploit auf anderen Konfigurationen funktioniert, zeigen die Daten nicht. Klar ist aber: Aus Versuchen ist erfolgreiche Codeausführung geworden.

Was sich seit unserem Post geändert hat

Drei Punkte muss ich nachtragen oder korrigieren:

  • Es gibt Patches. Im Post stand der Patch-Status als offen da. Tatsächlich hat das PHP-Team die Lücken schon am 21. Oktober geschlossen. Laut mehreren Distributions- und Fachquellen, etwa AlmaLinux und computingforgeeks, sind die korrigierten Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
  • CISA bestätigt die Ausnutzung. Am 23. Oktober meldete die US-Behörde noch keine erfolgreichen Angriffe und veröffentlichte eine Sigma-Erkennungsregel. Am 26. Oktober hat sie beide CVEs in ihren Katalog aktiv ausgenutzter Lücken (KEV) aufgenommen. Das berichten BleepingComputer und SecurityWeek.
  • Unit 42 rudert zurück. Palo Alto Unit 42 hatte einen Angriff auf eine europäische Behörde mit PHP2Shell in Verbindung gebracht. Inzwischen heißt es laut The Hacker News, man könne nicht bestätigen, dass der Erstzugriff über diese CVEs lief. Der Angriff selbst ist damit nicht vom Tisch, nur seine Zuordnung zu PHP2Shell.

Wer betroffen ist

Betroffen ist PHP, und PHP läuft auf einem großen Teil des Webs. VirusTotal schätzt laut BleepingComputer mehr als 5,1 Millionen öffentlich erreichbare PHP-Hosts. Wie viele davon tatsächlich verwundbar sind, nennen die Quellen nicht. Besonders heikel sind ältere Zweige ab 8.1 abwärts, die offiziell keine Updates mehr bekommen (End of Life). Für sie gibt es nur Backports von Distributionen oder kommerziellen Anbietern wie TuxCare.

Dazu kommt eine dritte, eigenständige Lücke: CVE-2026-115560. Für sie gibt es noch keinen Patch, nur eine Empfehlung zur Abhilfe. Laut PHP ist sie nur bei einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode ausnutzbar.

Was du tun solltest

  1. PHP aktualisieren, und zwar auf die oben genannten Versionen oder die gepatchten Pakete deiner Distribution. Achtung: Debian, Ubuntu und andere übernehmen den Fix oft in ihre Pakete, ohne die Versionsnummer anzuheben. Maßgeblich ist das Sicherheitsupdate der Distribution, nicht die angezeigte PHP-Version.
  2. PHP-Prozesse neu starten. Gemeint sind PHP-FPM, Apache mit mod_php oder was sonst bei dir läuft. Laufende Worker behalten den alten Code im Speicher.
  3. Übergangslösung nutzen, wo du nicht sofort patchen kannst. PHP empfiehlt session.upload_progress.enabled=0. Das ist auch die empfohlene Abhilfe für CVE-2026-115560. Laut Fachquellen deckt die Einstellung aber nicht alle PHP2Shell-Angriffswege ab und ersetzt kein Update.
  4. Auf Spuren prüfen. Durchsuche Logs nach auffälligen Häufungen von Out-of-Memory-Fehlern und abgestürzten Workern. Prüfe Webverzeichnisse auf unbekannte PHP-Dateien, also mögliche Webshells. Wer ein SIEM betreibt, kann die Sigma-Regel der CISA einbinden.
  5. EOL-Versionen ernst nehmen. Wer noch PHP 7.x oder 8.0/8.1 betreibt, sollte das jetzt als Anlass für ein Upgrade nehmen.

Meine Einschätzung: Die Lücken sind für Angreifer anspruchsvoll, und die Honeypot-Erfolge stammen aus einem günstigen Aufbau. Darauf würde ich mich trotzdem nicht verlassen. Mit KEV-Eintrag, öffentlichem Exploit und funktionierenden Shells gilt: Patch einspielen, Prozesse neu starten, Logs prüfen. Bei Selfhosting-Systemen mit PHP-Webanwendungen am besten heute.

Quellen