PHP2Shell-Angriffe dauern an, keine WordPress-Kompromittierung festgestellt
Die PHP2Shell-Angriffe dauern an, doch mit Stand vom 28. Oktober 2026 war Wordfence keine WordPress-Website bekannt, die über CVE-2026-109618 oder CVE-2026-109619 kompromittiert worden war. Die Teams für Website-Bereinigung und Incident Response hatten keinen WordPress-Fall bearbeitet, der einer der beiden Sicherheitslücken zugeschrieben wurde. Diese Feststellung bedeutet nicht, dass ein ungepatchter Server sicher ist: Die weiterhin erforderliche Maßnahme besteht darin, die von der Website verwendete Programmiersprache PHP zu aktualisieren und den Dienst, der sie ausführt, neu zu starten.
Die beiden kritischen PHP-Sicherheitslücken erhielten unter CVSS v4.0, einer Standardskala zur Bewertung von Sicherheitslücken, jeweils 9,2 von 10 Punkten. Beide können eine nicht authentifizierte remote code execution ermöglichen. Das bedeutet, dass jemand, der nicht angemeldet ist, möglicherweise eigenen Code auf dem Server ausführen kann. Eine Sicherheitslücke betrifft den Umgang von PHP mit einer Anfrage, die den verfügbaren Speicher vollständig aufbraucht. Die andere kann Daten aus einer abgeschlossenen Anfrage in einem PHP-Prozess zurücklassen, sodass eine spätere Anfrage sie missbrauchen kann. Es handelt sich um Sicherheitslücken in PHP selbst, nicht in WordPress, plugins oder themes.
Wordfence erklärte, dass eine spezielle Überwachungsregel zwischen dem 23. und 27. Oktober auf den mehr als 5 Millionen von dem Unternehmen geschützten Websites rund 77.600 zugehörige Anfragen von mehr als 2.000 IP-Adressen erfasste. Bei der Überprüfung wurden keine Treffer gefunden, die normaler Besucher- oder Website-Aktivität ähnelten. Die Anfragen enthielten Angriffsindikatoren, bezeichneten sich selbst als Scanning-Tools oder schienen automatisierte Tests zu sein. Am 22. Oktober wurde außerdem eine koordinierte Gruppe von 27 IP-Adressen beobachtet, wobei 26 davon ihre Anfragen innerhalb eines Zeitraums von 13 Minuten begannen. Solche Anfragen belegen versuchte Aktivitäten, nicht aber, ob tatsächlich Code ausgeführt wurde.
Mit den Anfragen wurde versucht zu prüfen, ob Befehle ausgeführt werden konnten, Datenbankpasswörter und andere geheime Daten aus den Dateien wp-config.php und .env auszulesen, backdoor-Dateien für einen dauerhaften Zugriff in Upload-, plugin- oder theme-Verzeichnissen zu installieren und, seltener, weiteren Schadcode herunterzuladen und auszuführen. Wordfence beobachtete außerdem bereits etwa vier Stunden vor der öffentlichen Bekanntgabe am 21. Oktober Tools, die für diese Sicherheitslücken entwickelt worden waren. Amazon meldete ebenfalls schon vor der Bekanntgabe entsprechende Versuche gegen seine honeypots, also Täuschsysteme zur Beobachtung von Angriffen.
Die Berichte außerhalb von WordPress bleiben uneinheitlich. Dream erklärte, ein Angreifer habe einen PHP2Shell exploit an eine nicht genannte firewall-Plattform angepasst und anschließend eine privilege-escalation-Sicherheitslücke im Linux kernel verwendet, durch die ein Angreifer höhere Systemberechtigungen erlangen kann. Laut Dream übernahm der Angreifer die vollständige Kontrolle über 24 mit dem Internet verbundene firewalls und einen internen Management-Server, las das Passwort eines LDAP-Service-Accounts aus und listete Benutzer und Gruppen in einer mit der US-Regierung verbundenen Umgebung auf. Dream nannte weder den Anbieter noch veröffentlichte das Unternehmen die sichergestellten Artefakte, und Wordfence hatte den Vorfall nicht unabhängig überprüft. WordPress war nicht daran beteiligt.
Palo Alto Networks berichtete separat über eine aktive Ausnutzung, die auf über das Internet erreichbare PAN-OS-Management-Schnittstellen abzielte, ohne diese Aktivität mit dem Bericht von Dream in Verbindung zu bringen. Wiz erklärte am 27. Oktober, dass keiner der beobachteten Versuche erfolgreich gewesen sei und dass die stärksten öffentlich verfügbaren Belege, die das Unternehmen geprüft habe, erfolgreiche Angriffe auf honeypots betrafen. Morphisec meldete am 28. Oktober code execution bei einem Kunden, der Windows, IIS und PHP-CGI einsetzte – eine Konfiguration, bei der PHP Webanfragen über das Common Gateway Interface verarbeitet. Der öffentliche Bericht bezog sich weder auf WordPress noch enthielt er genügend technische Einzelheiten, damit Wordfence unabhängig überprüfen konnte, ob PHP2Shell dafür verantwortlich war.
Eine zuverlässige Ausnutzung scheint stark vom jeweiligen Ziel abzuhängen. Im Labor von Wordfence wurde Testcode gegen einen speziell konfigurierten PHP-Build ausgeführt, brachte einen normalen optimierten Build derselben Version jedoch lediglich zum Absturz. Wiz berichtete von Fehlschlägen in unterschiedlichen Phasen bei verschiedenen Konfigurationen, während Hacktron feststellte, dass ein exploit, der in einer Umgebung funktionierte, für eine andere erheblich verändert werden musste. PHP-Builds, Erweiterungen, Speicherlimits und die Verarbeitung von Anfragen können das Ergebnis beeinflussen. Address Space Layout Randomization, kurz ASLR, verändert zudem, wo ein Programm Daten im Speicher ablegt, sodass das Ziel eines Angreifers schwerer vorherzusagen ist. Linux-Administratoren können cat /proc/sys/kernel/randomize_va_space ausführen; das Ergebnis 2 bedeutet vollständige Randomisierung. Diese Hindernisse können einen Angriff erschweren, beheben aber keine der beiden Sicherheitslücken.
Die korrigierten PHP-Releases sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Laut der PHP-Sicherheitsmeldung ist jede Installation gefährdet, die Webanfragen verarbeitet, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP-FPM ist ein Dienst, der PHP-Prozesse für Websites verwaltet. Ein Anbieterpaket ist ebenfalls geeignet, wenn der Anbieter bestätigt, dass beide Korrekturen hinzugefügt wurden. Eine Aktualisierung von WordPress selbst aktualisiert PHP nicht.
Bei Managed Hosting oder Shared Hosting sollten Websitebetreiber nachfragen, ob der PHP-Dienst für ihr Konto gegen beide CVEs gepatcht und neu gestartet wurde. Administratoren eines eigenen Servers oder virtual private server, üblicherweise VPS genannt, sollten eine Sicherung erstellen, aktualisierte Pakete installieren und Apache, PHP-FPM oder den jeweiligen PHP-Dienst neu starten, damit kein alter Prozess weiterhin anfälligen Code verwendet. Container müssen aus einem aktualisierten Image neu erstellt und erneut bereitgestellt werden. Agenturen sollten Produktions-, Staging- und ältere Umgebungen überprüfen, nicht nur die öffentliche Hauptwebsite.
WordPress zeigt die PHP-Version unter Werkzeuge, Website-Zustand, Info und anschließend Server an. Dieser Wert kann von der Ausgabe von php -v an einer Eingabeaufforderung abweichen. Eine Versionsnummer allein beantwortet die Frage möglicherweise nicht abschließend, da Linux-Distributionen und Long-Term-Support-Anbieter manchmal Sicherheitspatches hinzufügen, ohne die Hauptversionsnummer zu ändern. Betreiber, denen eine ältere Nummer angezeigt wird, sollten nachfragen, ob genau dieses Paket beide Korrekturen enthält.
Zu den Warnzeichen gehören unbekannte PHP-Dateien in wp-content/uploads oder in plugin- und theme-Ordnern, insbesondere Dateien, die am oder nach dem 17. Oktober erstellt wurden, unbekannte Administratorkonten, unerwartete geplante Aufgaben, nicht erklärbare ausgehende Verbindungen, wiederholte PHP-Abstürze, ungewöhnlich große Formular-Uploads oder ein PHP- beziehungsweise Webserver-Prozess, der eine Command Shell startet. Bewahren Sie Sicherungen sowie Web-, PHP-, firewall- und Systemprotokolle mindestens ab dem 17. Oktober auf, bis PHP gepatcht und neu gestartet wurde. Ein unauffällig wirkendes Protokoll beweist nicht, dass nichts geschehen ist. Wenn verdächtige Hinweise auftreten, sichern Sie den aktuellen Zustand der Website, ändern Sie das Datenbankpasswort und die in wp-config.php oder .env gespeicherten geheimen Daten und beginnen Sie mit einer vollständigen Bereinigung.
PHP 8.1 und frühere Versionen erhalten keine Releases mehr vom PHP-Projekt. Betroffene Benutzer benötigen daher entweder eine vom Anbieter bereitgestellte Korrektur oder ein Upgrade. Minimale Quellcode-Patches wurden für PHP 7.4, 8.0 und 8.1 veröffentlicht, und einige Long-Term-Support-Anbieter könnten sie älteren Paketen hinzufügen. PHP 8.2 erreicht am 31. Dezember 2026 sein end of life, weshalb PHP 8.3 oder höher laut Wordfence der längerfristige Upgrade-Pfad ist.
Eine separate ungepatchte Sicherheitslücke, CVE-2026-115560, wurde am 23. Oktober bekannt gegeben. Sie gilt nur, wenn eine Anwendung während der Ausführung das session data format von PHP ändert und anschließend eine Session startet, während session upload progress aktiviert ist.