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.
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
- PHP-Version herausfindenWordPress-Backend → Werkzeuge → Website-Zustand → Bericht → Server. Version notieren und schauen, ob sie 8.2 oder neuer ist.
- 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.
- 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.
- 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.
- 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.
Das übernehmen wir für dich
Standby-Website: statische Kopie für den Ausfall
Wenn deine Website vom Netz muss — kritische PHP-Lücke, Hack, Ausfall beim Hoster — schalten wir eine fertige statische Kopie live. Du bleibst erreichbar und behältst deine Rankings.
Mehr erfahrenWordPress Security Hardening: deine Website präventiv absichern
Wir überprüfen deine gesamte WordPress-Installation, reduzieren unnötige Angriffsflächen und setzen gezielte Sicherheitsmassnahmen für Login, Benutzerkonten, Dateien, Datenbank, Server und Firewall um.
Mehr erfahrenWordPress Audit: Technische Analyse für Website und WooCommerce-Shop
Wir untersuchen deine WordPress-Installation oder deinen WooCommerce-Shop und zeigen verständlich auf, wo technische Risiken, Leistungsengpässe und ungenutzte Potenziale liegen.
Mehr erfahrenWordPress Wartung. Damit deine Website einfach läuft.
Wir kümmern uns um Updates, Backups, Sicherheit und technische Probleme – bevor deine Kunden etwas davon bemerken.
Mehr erfahrenQuellen
- php.net: Release-Archiv
- CERT-EU Advisory 2026-018
- Patchstack: PHP major vulnerability alert
- The Repository: Exploit-Behauptungen vor der Veröffentlichung
- lilting.ch: warum der session.upload_progress-Workaround nicht reicht
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.