php2shell: PHP-Sicherheitslücke prüfen - Gratis Check

Die Lage

Zwei Lücken, ein Weg zur Shell

Am Abend des 20. Oktober wurden erste Details öffentlich, am 21. Oktober veröffentlichte das PHP-Team die Patches. Seitdem gilt: Wer PHP öffentlich erreichbar betreibt, muss heute nachsehen, nicht nächste Woche.

CVE-2026-109618 trifft die Speicherverwaltung. Erreicht PHP das memory_limit, bricht es den Request per longjmp() ab und lässt Speicherstrukturen halb initialisiert zurück. Beim Aufräumen liest PHP diese Reste, es kommt zu Speicherkorruption. Ein präparierter Multipart-Upload oder tief verschachtelte Felder genügen als Auslöser.

CVE-2026-109619 sitzt in der Fehlerbehandlung. Hier braucht der Angreifer mindestens zwei Requests: Der erste bringt die Fehlerbehandlung aus dem Tritt, der zweite nutzt das aus. Nicht jeder Fatal Error ist dafür geeignet.

Der Haken für Angreifer: Es kann Tausende bis Zehntausende Requests dauern. Für Automaten ist das kein Hindernis. In einer Demo von Calif lief ein Systembefehl auf einem Laravel-Server nach 38 Sekunden.

Versucht wird es laufend. Amazon hat am 17. Oktober einen Ausnutzungsversuch in seinem MadPot-Honeypot gesehen, vier Tage vor der Veröffentlichung, und meldet seitdem breit gestreute Versuche. watchTowr hat beide Lücken nachgebaut und sieht ebenfalls Versuche, Cloudflare meldet Angriffe auf seine Kunden. Wer Logs hat, sieht ab dem 17. Oktober nach, nicht erst ab dem 21.

Was bis heute, dem 25. Oktober, niemand belegt: einen durchgedrungenen Angriff. Keine Webshell, kein bestätigter Einbruch, kein Datenabfluss. Sansec schreibt, die öffentlich kursierenden Exploits funktionierten gegen eine Standardinstallation nicht, Dataminr meldet keine bekannten Kompromittierungen. Im KEV-Katalog der CISA (Fassung 2026.10.23, 1.756 Einträge) stehen beide CVEs nicht. Das ist kein Grund zu warten — es ist der Grund, warum Sie jetzt noch in Ruhe patchen können statt im Vorfall.

Betroffen sind Apache mod_php, PHP-FPM, LSAPI und FrankenPHP - aber nicht gleich stark, und das entscheidet, womit Sie anfangen. Bei der ersten Lücke ist der vollständige Exploit gegen mod_php belegt; PHP-FPM beendet den Worker, wenn der Request-Start scheitert, und entgeht dieser Kette. Bei der zweiten Lücke hilft das nicht: Über den Session-Pfad ist die Codeausführung laut Advisory gegen mod_php und gegen FPM validiert. FrankenPHP gilt nach Quellenanalyse als wahrscheinlich betroffen, bei LSAPI steht die Prüfung aus. Wer FPM fährt, hat also etwas Luft bei der einen Lücke und keine bei der anderen. Red Hat schreibt dazu, Codeausführung über FPM sei in der Praxis schwierig, weil der Worker beim fehlgeschlagenen Start abbricht, und stuft mod_php mit Standardkonfiguration als höheres Risiko ein.

Ablauf

81 Tage vom Fund bis zum Patch — und vier Tage, die alles entschieden haben

Die beiden Lücken lagen seit dem 1. August bei PHP auf dem Tisch. Geplant war ein Notfall-Release für Donnerstag, den 22. Oktober. Dann sind die Details vorher geleakt, der Patch kam einen Tag früher — und die ersten Ausnutzungsversuche lagen schon vier Tage davor. Alles hier ist datiert und belegt; Uhrzeiten in UTC.

Der Check

php2shell-check: ein Skript, ein Urteil pro PHP

$ sudo ./php2shell-check.sh https://www.example.de

php2shell-check 3.0.1  CVE-2026-109618 / CVE-2026-109619, data as of 2026-10-22
web01.example.de (Ubuntu 24.04.3 LTS)

PHP installations on this host
  [ OK ] php-binary     /usr/sbin/php-fpm8.3
         package php8.3-fpm 8.3.6-0ubuntu0.24.04.13 (distribution fix from 8.3.6-0ubuntu0.24.04.13)

PHP in docker containers
  [VULN] container      shop-wordpress-1 (wordpress:latest)
         PHP 8.3.35, fixed in 8.3.36
         -> Update PHP to 8.3.36 or later (container: pull the new image and recreate)
  [WARN] sapi           shop-wordpress-1
         served by mod_php: the advisory demonstrates a complete unauthenticated exploit against exactly this setup
         -> Treat a vulnerable PHP behind mod_php as the most urgent case

Website https://www.example.de
  [ ?? ] php-level      https://www.example.de
         no PHP version and no PHP signal in the headers; this says nothing about the patch level
  [ OK ] waf            https://www.example.de
         proxied through Cloudflare (header and DNS)

Summary  1 vulnerable, 1 undecided, 2 warnings, 3 ok
  VULNERABLE  at least one PHP runtime needs an update now.

So starten Sie ihn

Einzeiler: lädt aktuellste Version herunter und startet den Check. Wer zuerst lesen will, findet im Repository die Schritt-für-Schritt-Variante.

sudo bash -c "$(curl -fsSL https://github.com/EXT-IT/php2shell-check/releases/latest/download/php2shell-check.sh)" - https://your-site.example

Für das Monitoring: 0 nichts Verwundbares, 1 verwundbar, 2 nicht entscheidbar, 3 Aufruffehler, mit --json maschinenlesbar.

Zum Repository

Was jetzt zu tun ist

Vier Schritte, in dieser Reihenfolge

Ihr braucht nicht alles zu lesen: Wer nur eine WordPress-Seite bei einem Hoster hat, springt direkt zu Schritt 3.

1. Bestand aufnehmenWelche Server, Container und Appliances führen PHP aus, und welche davon sind aus dem Internet erreichbar? Nextcloud, TYPO3, Drupal, MediaWiki und selbst entwickelte Anwendungen zählen mit. Der Check nimmt Ihnen den Host- und Container-Teil ab.
2. Erreichbarkeit einschränken, wo ein Update noch fehltDas RUS-CERT empfiehlt, betroffene Systeme bis zum Update offline zu nehmen oder abzuschotten. Das betrifft vor allem PHP 7.4 bis 8.1 ohne Distributionsfix. Für einen gepflegten Server mit Distributionspaketen halten wir das für überzogen, solange kein durchgedrungener Angriff belegt ist — abschotten ja, abschalten erst, wenn Sie den Patch nicht binnen Tagen schaffen. Prüfen Sie dabei die Webserver-Logs ab dem 17. Oktober: So früh hat Amazon den ersten Versuch gesehen.
3. Updaten und Dienst neu startenZuerst alles, was per mod_php ausgeliefert wird - dort ist der vollständige Exploit belegt, und wordpress:latest gehört dazu. PHP-FPM, lsphp oder Apache laufen nach dem Paketupdate mit der alten Binary weiter, bis Sie sie neu starten. Container: neues Image ziehen und neu erstellen, docker restart reicht nicht.
4. Temporäre Workarounds nur als ÜberbrückungGegen die erste Lücke nennt das PHP-Team memory_limit=-1 die wichtigste Stellschraube, gesetzt so, dass die Anwendung es nicht überschreiben kann (php_admin_value im FPM-Pool oder in der Apache-Konfiguration); ein Container- oder cgroup-Limit fängt den Speicher dann ab. Begrenzen Sie den Prozess nicht per ulimit -v oder RLIMIT_AS — davor warnt das Advisory ausdrücklich, denn damit bauen Sie den verwundbaren Pfad wieder ein. Gegen die zweite Lücke session.upload_progress.enabled=0 und unter PHP 8.5 fatal_error_backtraces=0. Dazu eine konservative post_max_size und ein niedriges max_input_nesting_level. Danach jeden PHP-Worker neu starten. Das PHP-Team nennt all das selbst eine temporäre Krücke, vollständig ist nur der Patch.

Danach den Check erneut laufen lassen und das Ergebnis ablegen. Wer NIS2-pflichtig ist, braucht diesen Nachweis ohnehin.