php2shell: Der aktuelle Stand – Angriffe laufen, was jetzt zu prüfen ist

*Stand: 24. Oktober 2026*

Vor zwei Tagen haben wir über php2shell berichtet, die beiden kritischen PHP-Lücken CVE-2026-109618 und CVE-2026-109619 (CVSS je 9,2). Inzwischen ist klarer, wie groß das Problem ist und was tatsächlich passiert. Hier der aktuelle Stand.

Werden die Lücken schon ausgenutzt?

Ja, aber die Quellen sind sich über das Ausmaß nicht einig:

• watchTowr meldet, seine Honeypots hätten seit dem 21. Oktober Ausnutzung beobachtet. Zu Umfang, Zielen und Schadcode nennt der Anbieter keine Details.
• Amazon Threat Intelligence berichtet von einem Versuch bereits am 17. Oktober, also vier Tage vor der Veröffentlichung. Ob solche Versuche gegen echte Systeme erfolgreich gewesen wären, ist offen.
• Huntress hatte am 21. Oktober noch keine Ausnutzung bei den eigenen Kunden gesehen. Auch The Hacker News schreibt, dass bisher kein erfolgreicher Einbruch bestätigt ist.
• In den Katalog der bekannten, ausgenutzten Lücken der US-Behörde CISA (KEV) waren die Lücken nach Angaben von watchTowr am 22. Oktober noch nicht aufgenommen.

Kurz gesagt: Es wird scharf geschossen, ein großer Schaden ist öffentlich noch nicht belegt. Das kann sich schnell ändern.

Wie kam es zu dem Zeitdruck?

Der geplante Zeitplan der Veröffentlichung ist am 20. Oktober durchgesickert. Kurz darauf tauchte ein Proof-of-Concept-Werkzeug namens „PHP2Shell" auf, noch bevor das PHP-Projekt am 21. Oktober die Updates ausgeliefert hat. Vorsicht bei solchen Werkzeugen: Tenable warnt, dass öffentlich kursierender Exploit-Code ungeprüft ist und manchmal selbst Schadsoftware enthält. Wer ihn „zum Testen" ausführt, riskiert den eigenen Rechner.

Wie groß ist die Angriffsfläche?

• Fast jede PHP-Installation: Betroffen sind alle Versionen bis zurück zu PHP 5.4. Laut Wiz basieren rund 70 Prozent aller Websites auf PHP. Diese Zahl stammt vom Anbieter selbst und ist nicht unabhängig belegt, die Größenordnung ist aber plausibel.
• Der Fehler steckt im PHP-Kern, nicht in WordPress, Laravel oder Drupal. Auch Seiten mit sauberem eigenen Code sind betroffen, und ein WordPress-Update allein hilft nicht. Wiz hat die Angriffe an aktuellen Container-Images von WordPress, Drupal und Joomla gezeigt.
• Jede Betriebsart: PHP-FPM, Apache mod_php, php-cgi, LiteSpeed und FrankenPHP. Am höchsten ist das Risiko bei Apache mit mod_php, weil der Angriff dort greifen kann, bevor der Anwendungscode überhaupt startet.
• Keine Anmeldung nötig. Es genügt, dass der Server erreichbar ist.
• Mehr als Code-Ausführung: Angreifer können auch Speicherinhalte des PHP-Prozesses auslesen, etwa Passwörter, Tokens oder API-Schlüssel.
• Die Fehler sind über zehn Jahre alt. Laut Wiz hat KI bei der Suche und beim Verknüpfen mehrerer Fehler zu einer funktionierenden Angriffskette stark geholfen. Das ist der eigentliche Wendepunkt: Was früher Monate Expertenarbeit gebraucht hat, geht heute in Tagen.

Was die Technik für Ihre Gegenmaßnahmen bedeutet

• Die Funktion „Session Upload Progress" ist standardmäßig an und ein bestätigter Weg zu CVE-2026-109619, aber nicht der einzige. Sie abzuschalten reicht deshalb nicht. Das bestätigen mehrere Quellen.
• Änderungen an php.ini gelten nur als Notlösung. Sie ersetzen kein Update.
• Prüfen Sie die Version, die tatsächlich Webanfragen bedient. Die Version auf der Kommandozeile (php -v per SSH) kann von der des Webservers abweichen.

Wer bekommt ein Update?

Heise hatte Backports für 7.4 bis 8.1 angekündigt. Fragen Sie Ihren Distributions- oder Hosting-Anbieter, ob sie schon vorliegen. Wer noch auf so einer Version läuft, sollte auf einen unterstützten Zweig wechseln.

Woran Sie einen Angriff erkennen

• ungewöhnlich große oder stark verschachtelte Multipart-Anfragen, gefolgt von Fehlern wegen des Speicherlimits
• wiederholte HTTP-500-Antworten, abgestürzte oder neu gestartete PHP-Worker
• übergroße oder fehlerhafte PHPSESSID-Cookies
• unbekannte PHP-Dateien im Webroot, neue Cron-Jobs, neu angelegte Benutzer, ausgehende Verbindungen von PHP-Prozessen

Ein Update entfernt keinen bereits eingeschleusten Schadcode. Wer in den letzten Tagen ungepatcht erreichbar war, sollte deshalb nach dem Update prüfen, ob etwas dazugekommen ist, und Zugangsdaten, die auf dem Server lagen, im Zweifel erneuern.

Was das für Hosting-Kunden heißt

Fragen Sie Ihren Anbieter konkret, welche PHP-Version aktuell läuft und wann sie aktualisiert wurde. Manche Hoster haben als Zwischenlösung den Upload-Fortschritt abgeschaltet. Das ist besser als nichts, aber kein Patch. Einen verlässlichen Gesamtüberblick, welche Anbieter schon gepatcht haben, gibt es nicht.

Was wir aus der Praxis mitnehmen

Bei uns waren die offiziellen WordPress-Container-Images der Engpass: Das Image mit PHP 8.3.36 lag erst am Morgen nach der PHP-Veröffentlichung auf Docker Hub. Außerdem reichte bei einer Seite ein Neustart des Containers nicht, weil Kubernetes mit der Einstellung imagePullPolicy: IfNotPresent das alte Image aus dem Cache wiederverwendet hat. Erst nach imagePullPolicy: Always und einem neuen Rollout lief dort wirklich 8.3.36. Wir prüfen deshalb nach jedem Update die laufende PHP-Version im Container selbst, nicht nur den Status der Pods. Alle unsere WordPress-Seiten laufen inzwischen auf PHP 8.3.36.

Der Tipp gilt für jeden, der Container betreibt: Ein grüner Deployment-Status sagt nichts darüber, welche Version läuft.

Fazit

• Heute noch PHP aktualisieren und die laufende Version prüfen, auch bei Nebensystemen mit PHP-Oberfläche wie NAS, Router, Firewalls oder Dashboards.
• Logs der letzten Tage auf die oben genannten Spuren durchsehen.
• Nicht auf Zwischenlösungen verlassen und keine Exploit-Skripte aus dem Netz ausführen.

Sie wissen nicht, welche PHP-Version Ihre Website nutzt oder ob sie schon gepatcht ist? Schreiben Sie uns, wir prüfen das.

Quellen: watchTowr, The Hacker News, Wiz, Tenable, heise online