Update · Veröffentlicht am 21. Oktober 2026

php2shell: kritische Lücke in PHP selbst

Zwei Lücken in PHP — der Software, auf der fast jede Website läuft — erlauben Fremden, deine Seite zu übernehmen, auch ohne ein einziges Plugin. Automatische WordPress-Updates schliessen sie nicht: Das kann nur dein Hoster.

KritischGilt seit 21. Oktober 2026Fix veröffentlicht am 21. Oktober 2026, 14:00 UTC. Für PHP 8.1 und älter ist kein offizieller Fix zu erwarten.

BetrifftAlle WordPress-Websites · WooCommerce-Shops · Alles, was auf PHP läuft

Ein WordPress-Dashboard mit „alles aktuell" sagt in diesem Fall nichts. Die Lücke sitzt eine Ebene unter WordPress, in PHP selbst — und diese Ebene gehört dem Hoster.

Was passiert ist

Unter jeder WordPress-Seite läuft PHP — die Software, die deine Seiten überhaupt erst erzeugt. In genau dieser Software stecken zwei Lücken: Ein Angreifer kann eigenen Code auf deinem Server ausführen, ohne Passwort und ohne Login. Damit gehört die Website praktisch dem Angreifer. Geführt werden die beiden als CVE-2026-109618 und CVE-2026-109619, zusammen „php2shell" genannt, und beide sind als kritisch eingestuft (CVSS v4 9.2 von 10).

Die Lücken sitzen im PHP-Interpreter selbst — nicht in WordPress, nicht in einem Plugin, nicht im Theme. Genau das macht den Fall anders als die übliche Plugin-Warnung: Betroffen ist auch eine Seite ohne ein einziges Plugin, und der gemeldete Bereich reicht von PHP 5.4 bis 8.5, also praktisch über jede Version, die im Einsatz ist. Der Fix wurde am 21. Oktober 2026 um 14:00 UTC veröffentlicht.

  • Betroffen: PHP 5.4 bis 8.5, laut Meldung zur Veröffentlichung
  • Ohne Fix: Für PHP 8.1 und älter ist kein offizieller Patch zu erwarten
  • Unabhängig von Plugins, Theme und WordPress-Version

Wird die Lücke ausgenutzt?

Gemeldet ja — und das gehört genau so gesagt und nicht dramatischer. Die Live-Chronik von Patchstack sprach am Morgen des 21. Oktober von „multiple active exploitation incidents confirmed", ohne zu nennen, wer das beobachtet hat. watchTowr hat eine der beiden Lücken nachgebaut, aber zum Zeitpunkt der Meldung keine Ausnutzung in freier Wildbahn gesehen; ein Demo-Video zeigt die Code-Ausführung auf Testinstallationen von WordPress, Drupal und Magento.

Also: dringend, weil die Hürde niedrig und der Schaden total ist — nicht, weil deine Seite nachweislich angegriffen wird.

Warum WordPress-Updates hier nicht helfen

Das ist der Punkt, der am häufigsten falsch verstanden wird, und der eigentliche Grund für diesen Beitrag. Automatische WordPress-Updates aktualisieren WordPress, Themes und Plugins. PHP können sie nicht aktualisieren, denn PHP ist das Programm, das WordPress überhaupt ausführt.

PHP zu patchen ist Sache des Hosters. Bei Managed Hosting (Hostinger, Cloudways, SiteGround und ähnliche) wartet man auf ihn und prüft danach nach. Auf einem eigenen Server muss es jemand von Hand einspielen. In beiden Fällen sagt ein WordPress-Dashboard mit „alles aktuell" nichts über php2shell aus.

Drei Dinge, die beim Patchen unserer Server aufgefallen sind

Die Server, die wir betreuen, liefen am Tag der Veröffentlichung zwischen 14:46 und 17:00 UTC auf der gepatchten Version. Drei Dinge haben Zeit gekostet und sind vorher gut zu wissen:

  • Der Paket-Mirror hing hinterher. Bei Hetzner war das gepatchte Ubuntu-Paket noch nicht da; über eine temporäre Quelle direkt von security.ubuntu.com war es sofort verfügbar — und diese Quelle gehört danach wieder entfernt.
  • `php -v` sagt nichts über das Web. Kommandozeile und Webserver können unterschiedliche PHP-Builds fahren. Unter mod_php und unter PHP-FPM muss jeweils neu gestartet werden, und die Version gehört aus dem Web geprüft, nicht aus der Shell.
  • Die Interim-Mitigation ist ein Notbehelf, kein Fix. `session.upload_progress.enabled = 0` ist unofficial und blockiert möglicherweise nur eine der beiden Lücken; als `php_flag` in der `.htaccess` funktioniert es unter mod_php und liefert unter PHP-FPM einen 500er. Die Linie von PHP selbst: nur patchen hilft.

Was zu tun ist

  1. PHP-Version herausfindenWordPress-Backend → Werkzeuge → Website-Zustand → Bericht → Server. Version notieren und schauen, ob sie 8.2 oder neuer ist.
  2. Den Hoster schriftlich nach dem Patch fragenManaged Hosting patcht nach eigenem Zeitplan und sagt es selten an. Nach Datum und genauer PHP-Version fragen, damit es etwas zum Nachprüfen gibt.
  3. Den Patch aus dem Web prüfen, nicht aus der ShellNachdem der Hoster gepatcht hat, die Version im Website-Zustand erneut ansehen. Auf einem eigenen Server Apache oder PHP-FPM neu starten und bestätigen, dass das Web-PHP den gepatchten Build meldet.
  4. Alles auf PHP 8.1 oder älter umziehenDort ist kein offizieller Fix zu erwarten, Warten hilft also nicht. Diese Seiten brauchen ein Update auf PHP 8.3 oder 8.4, vorher auf einer Kopie getestet.
  5. Danach nach Spuren suchenNeue oder geänderte .user.ini-Dateien, unbekannte PHP-Dateien im Web-Root, in Plugins und mu-plugins, unerwartete Administratoren, PHP-Dateien mit Datum ab dem Vortag der Meldung.

Quellen

Technische Einordnung auf Basis der oben genannten Meldungen, Stand der Veröffentlichung. Welche PHP-Version deine Seite ausliefert und ob sie gepatcht ist, lässt sich nur auf deinem Server beantworten — der Beitrag ist also der Anlass nachzusehen, kein Urteil über deine Seite.

Unsicher, ob dein Server gepatcht ist?

Schick uns deine Domain. Wir sagen dir, welche PHP-Version sie ausliefert und ob der Patch drauf ist — zehn Minuten, kostenlos, ohne Verpflichtung.

Alle Updates