Bislang liefen die Angriffe auf die PHP2Shell-Lücken ins Leere. Ein Honeypot zeigt nun, dass Angreifer tatsächlich Code ausführen können. Für eine dritte Schwachstelle gibt es derweil nur einen Workaround.
Aus Scans wird Ernst
PHP2Shell: Erfolgreicher Angriff auf ungepatchte PHP-Server belegt
Administratoren, die das PHP-Sicherheitsupdate vom 21. Oktober 2026 noch nicht eingespielt haben, sollten das nicht länger aufschieben: Für die beiden als PHP2Shell bekannten Lücken CVE-2026-109618 und CVE-2026-109619 liegt erstmals ein belastbarer Nachweis vor, dass Angreifer darüber auf fremden Servern Code ausgeführt haben. Bislang waren nur gescheiterte Versuche bekannt.
Der Nachweis stammt von Adel Karimi, der bei Perplexity für Detection and Response zuständig ist. Er betreibt Honeypots, also absichtlich verwundbare Lockserver, und hat die Mitschnitte auf Github dokumentiert. Getroffen wurde ein Apache-Webserver mit mod_php und PHP 8.4.26.
Erst Speicher auslesen, dann zuschlagen
Der Angriff lief in zwei Stufen. Zunächst brachten die Angreifer den Server dazu, Teile seines Arbeitsspeichers herauszugeben, verpackt in einer Cookie-Antwort, die dekodiert rund 800 KByte umfasste. In diesem Speicherabbild suchten sie mithilfe der Offsets aus einem öffentlich verfügbaren Exploit nach einer Funktionsadresse. Genau diese Adresse fand sich danach in dem Payload wieder, mit dem der Code zur Ausführung gebracht wurde. Für Karimi ist damit klar, dass es sich um echte Codeausführung handelt und nicht nur um einen Absturz mit anschließendem auffälligem Prozess.
Übertragbar ist das Ergebnis nur bedingt. Der Honeypot war mit einem einzigen mod_php-Worker bewusst angreiferfreundlich eingerichtet. Ob der Exploit auch bei mehr Workern, anderen PHP-Builds oder anderen Anwendungen zuverlässig funktioniert, belegen die Daten ausdrücklich nicht.
Marcus Hutchins, Sicherheitsforscher bei Expel, verfolgt eine ganze Reihe von Berichten über angebliche PHP2Shell-Treffer. Karimis Auswertung hält er für den mit Abstand überzeugendsten Beleg, der ihm bisher untergekommen ist.
Holpriger Start: Leak vor dem Patch
Die Vorgeschichte der Lücken verlief alles andere als geordnet. Am 20. Oktober kündigte das PHP-Team Notfall-Updates an, einen Tag später erschienen sie. Doch schon vorher waren Details durchgesickert, darunter die CVE-Nummern und Schutzempfehlungen, die einigen Betreibern kritischer Infrastruktur vorab zugegangen waren. Auch erste Proof-of-Concept-Exploits tauchten auf, funktionierten nach Angaben der PHP-Entwickler aber nicht.
Entsprechend früh begannen die Angriffe: Amazon Threat Intelligence registrierte sie bereits vier Tage vor dem Update. Cloudflare, Hadrian, watchTowr, Previdian und Patchstack meldeten ebenfalls Versuche, stuften sie aber durchweg als erfolglos ein. Auch Dataminr kam zu dem Schluss, dass die Angreifer bislang lediglich scannten, Systeme identifizierten und mit untauglichen Exploits hantierten – kompromittierte Server seien nicht bekannt gewesen.
Neue Schwachstelle vorerst ohne Update
Parallel muss sich die PHP-Gemeinde um eine weitere RCE-Lücke kümmern: CVE-2026-115560 ist noch nicht gepatcht. Angreifbar sind laut den Entwicklern allerdings nur Systeme, bei denen eine ungewöhnliche Konfiguration auf passenden Anwendungscode trifft. Als Übergangslösung empfiehlt das PHP-Team, session.upload_progress.enabled=0 zu setzen – dieselbe Einstellung, die schon vor den PHP2Shell-Patches als Schutz galt.
Wie groß die potenzielle Angriffsfläche ist, zeigen die Zahlen: PHP steckt nach Angaben von W3Techs hinter rund 70 Prozent aller Websites. Virustotal schätzt, dass über 5,1 Millionen PHP-Hosts im Netz erreichbar sind, gut 3,8 Millionen davon mit mindestens einem offenen Port.
(red)
