PHP2Shell: Kritische PHP-Lücke – was WordPress-Nutzer jetzt tun müssen

c.birk

vor 60 Minuten

PHP2Shell: Kritische PHP-Sicherheitslücke, sicher ab PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35

Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßige Sicherheitsupdates veröffentlicht. Sie schließen zwei kritische Lücken, die unter dem Namen PHP2Shell bekannt geworden sind. Über sie können Angreifer ohne Anmeldung eigenen Code auf dem Webserver ausführen. Betroffen ist nicht WordPress selbst, sondern die Programmiersprache, auf der WordPress läuft. Damit steht praktisch jede WordPress-Website auf einem ungepatchten Server im Risiko, egal wie gut sie gepflegt ist.

In diesem Beitrag erfahren Sie, was hinter PHP2Shell steckt, warum ein WordPress-Update diesmal nicht hilft, wie Sie in wenigen Minuten prüfen, ob Ihre Website sicher ist, und was Sie je nach Hosting jetzt tun sollten.

Stand: 21. Oktober 2026. Die Lage entwickelt sich schnell, wir aktualisieren diesen Beitrag bei neuen Erkenntnissen.

Das Wichtigste in Kürze

Was: Zwei kritische Lücken in PHP (CVE-2026-109618 und CVE-2026-109619), beide mit der Bewertung 9,2 von 10 (CVSS v4.0).
Folge: Angreifer können ohne Benutzerkonto Code auf dem Server ausführen oder Speicherinhalte wie Passwörter auslesen. Für WordPress wurde das bereits vorgeführt.
Abhilfe: Nur ein Update von PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 schließt die Lücken.
WordPress-Updates helfen nicht: Die Lücke steckt im Server, nicht in WordPress, einem Plugin oder Theme.
Dringlichkeit: Details waren schon vor dem Update durchgesickert, erste Angriffe werden bereits beobachtet.
Ihre Aufgabe: PHP-Version prüfen und, wenn Sie nicht selbst den Server betreiben, beim Hoster nachfragen.

Was ist PHP2Shell?

PHP ist die Programmiersprache, in der WordPress geschrieben ist. Jedes Mal, wenn jemand eine Seite Ihrer Website aufruft, verarbeitet PHP auf dem Server die Anfrage, lädt WordPress, Ihr Theme und Ihre Plugins und liefert die fertige Seite aus. Genau in dieser Verarbeitung von Anfragen sitzen die beiden Fehler.

Nach Angaben der PHP-Entwickler handelt es sich um zwei Speicherfehler:

CVE-2026-109618: Wenn PHP beim Einlesen einer Anfrage der Speicher ausgeht, bricht die Verarbeitung an einer Stelle ab, an der interne Daten erst halb aufgebaut sind. Beim anschließenden Aufräumen behandelt PHP diese unfertigen Daten so, als wären sie gültig. Ein Angreifer kann das gezielt auslösen und ausnutzen.
CVE-2026-109619: Bestimmte Daten einer Anfrage bleiben im Arbeitsprozess erhalten, obwohl ihr Speicher schon freigegeben wurde. Die nächste Anfrage, die derselbe Prozess bearbeitet, kann auf diese Altlasten zugreifen. Das öffnet den Weg zum Auslesen fremder Speicherinhalte und ebenfalls zur Ausführung von Code.

Die Lücken wurden von Forschern von Wiz, OpenAI und Calif gefunden. Laut der Informationsseite php2shell.com reichen die betroffenen Versionen bis PHP 5.4 zurück. Die Fehler schlummerten also über ein Jahrzehnt im Code. Bemerkenswert ist, was Wiz laut Help Net Security dazu sagt: Erst moderne KI-Modelle hätten die bisher sehr aufwendige Ausnutzung so weit vereinfacht, dass daraus ein funktionierender Angriff wurde.

Warum jede WordPress-Website betroffen sein kann

Bei den meisten Sicherheitsmeldungen rund um WordPress geht es um ein bestimmtes Plugin oder Theme. Wer es nicht nutzt, ist raus. Bei PHP2Shell ist das anders, und zwar aus drei Gründen.

1. Die Lücke liegt unterhalb von WordPress

PHP läuft auf jedem WordPress-Server. Die Entwickler nennen ausdrücklich alle gängigen Betriebsarten als betroffen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Damit ist praktisch jedes Hosting-Paket abgedeckt, vom günstigen Shared Hosting bis zum eigenen Server. Laut php2shell.com reicht schon eine simple „Hello World“-Anwendung auf einem verwundbaren PHP für einen Angriff. Wie sauber Ihr WordPress gepflegt ist, spielt dafür keine Rolle.

2. Angriffe auf WordPress sind bereits vorgeführt

Die Forscher haben nach eigenen Angaben eine Codeausführung ohne Anmeldung auf WordPress, Drupal und Joomla demonstriert. Ein Angreifer braucht also weder ein Benutzerkonto auf Ihrer Website noch ein verwundbares Plugin. Für die Variante mit mod_php gibt es laut PHP-Team einen Angriff, der greift, bevor überhaupt Anwendungscode ausgeführt wird.

3. Ihr WordPress-Update ändert nichts

Die automatischen Updates von WordPress kümmern sich um WordPress selbst, um Plugins und Themes. PHP gehört nicht dazu. Das ist Sache des Servers und damit in den meisten Fällen Sache Ihres Hosters. Auch ein Sicherheits-Plugin kann die Lücke nicht schließen: Es ist selbst ein Stück PHP-Code und startet erst, wenn PHP die Anfrage bereits verarbeitet hat. Warum WordPress-Sicherheit mehr ist als Plugins und Updates im Dashboard, erklären wir auch auf unserer Seite Wie sicher ist WordPress?

Wie gefährlich ist die Lage?

Sehr. Die Bewertung von 9,2 liegt im kritischen Bereich, und mehrere Umstände verschärfen die Situation:

Die Details waren vorzeitig öffentlich. Laut dem Sicherheitsdienstleister Huntress tauchten am Morgen des 20. Oktober erste Informationen im Netz auf, obwohl die Veröffentlichung erst später geplant war. Das PHP-Team zog die Updates daraufhin auf den 21. Oktober vor.
Erste Angriffe laufen. Cloudflare sah nach Angaben seines CTO schon vor dem Erscheinen der Updates erste Angriffsversuche, berichtet BleepingComputer. Auch watchTowr meldet in seinem FAQ beobachtete Ausnutzung über seine Honeypots.
Massenangriffe sind zu erwarten. Der Sicherheitsanbieter Sansec rechnete laut SecurityWeek damit, dass automatisierte Angriffe innerhalb von 15 Minuten nach Veröffentlichung der Updates beginnen.
Behörden warnen deutlich. Das britische National Cyber Security Centre rät, Systeme sofort zu aktualisieren oder vom Netz zu nehmen, wenn das nicht möglich ist.

Für Sie als Website-Betreiber heißt das: Angreifer suchen nicht gezielt nach Ihrer Website. Sie scannen das Netz automatisch nach verwundbaren Servern. Eine kleine, unbekannte Website ist dabei genauso ein Ziel wie ein großer Online-Shop.

Was ein erfolgreicher Angriff bedeutet

Gelingt der Angriff, läuft der Code des Angreifers mit den Rechten des Webservers. Er kann dann typischerweise Dateien Ihrer WordPress-Installation verändern, Schadcode oder Spam-Seiten einschleusen, auf die Datenbank mit Kundendaten und Bestellungen zugreifen oder sich einen dauerhaften Zugang einrichten. Über die zweite Lücke lassen sich außerdem Speicherinhalte auslesen. Darin können Passwörter, Anmelde-Tokens, API-Schlüssel und Zertifikate stehen, auch solche aus den Anfragen anderer Besucher.

Welche PHP-Versionen sind sicher?

Das PHP-Projekt hat für alle noch unterstützten Versionszweige ein Update veröffentlicht:

Versionszweig	Verwundbar	Sicher ab
PHP 8.5	bis 8.5.11	8.5.12
PHP 8.4	bis 8.4.26	8.4.27
PHP 8.3	bis 8.3.35	8.3.36
PHP 8.2	bis 8.2.34	8.2.35
PHP 8.1 und älter	alle	kein offizielles Update

Für PHP 7.4, 8.0 und 8.1 hat das Sicherheitsteam zwar minimale Korrekturen im Quellcode bereitgestellt. Die richten sich aber an Server-Administratoren, die PHP selbst kompilieren. Einige Linux-Distributionen und Anbieter mit Langzeit-Support liefern solche Korrekturen auch für ältere Versionen aus. Für Sie als WordPress-Nutzer gilt trotzdem: Wer noch auf PHP 8.1 oder älter unterwegs ist, sollte jetzt wechseln.

Ein Drittel aller WordPress-Websites läuft auf altem PHP

Die offizielle Statistik von WordPress.org zeigt, wie groß das Problem ist. Rund 36 Prozent der WordPress-Websites melden PHP 8.1 oder älter, allein 16 Prozent noch PHP 7.4. Weitere 24 Prozent laufen auf PHP 8.2, das am 31. Dezember 2026 seine letzten Sicherheitsupdates erhält. WordPress selbst empfiehlt PHP 8.3 oder neuer. PHP2Shell ist ein guter Anlass, den Wechsel nicht weiter aufzuschieben.

So prüfen Sie Ihre PHP-Version in WordPress

Dafür brauchen Sie keinen Serverzugang. WordPress zeigt die PHP-Version direkt im Dashboard an:

Melden Sie sich als Administrator in WordPress an.
Öffnen Sie Werkzeuge → Website-Zustand.
Wechseln Sie auf den Reiter Bericht.
Klappen Sie den Abschnitt Server auf.
Vergleichen Sie den Eintrag PHP-Version mit der Tabelle oben.

Zeigt WordPress zum Beispiel 8.3.36 oder höher an, ist Ihre Website auf der sicheren Seite. Steht dort 8.3.30, fehlt das Update.

Achtung, ein wichtiger Haken: Die Versionsnummer allein ist nicht immer aussagekräftig. Viele Linux-Distributionen und Hoster spielen Sicherheitskorrekturen in ihre eigenen PHP-Pakete ein, ohne die Versionsnummer zu ändern. Ihr Server kann also geschützt sein, obwohl WordPress eine scheinbar alte Nummer anzeigt. Umgekehrt zeigen manche Hosting-Oberflächen nur „8.3“ an, was gar nichts über den Stand verrät. Im Zweifel hilft nur eine Nachfrage beim Hoster.

Was Sie jetzt tun sollten

Was konkret zu tun ist, hängt davon ab, wo Ihre Website liegt.

Shared Hosting oder Managed WordPress Hosting

Das betrifft die meisten WordPress-Nutzer. Hier ist Ihr Hoster für PHP zuständig, und die großen Anbieter haben am 21. Oktober mit der Verteilung der Updates begonnen. Viele haben zusätzlich vorübergehende Schutzregeln in ihren Firewalls aktiviert. Verlassen Sie sich trotzdem nicht darauf, sondern fragen Sie aktiv nach. Ein Beispiel für eine kurze Anfrage an den Support:

„Guten Tag, ist der Server meiner Website [Domain] bereits gegen die PHP-Lücken CVE-2026-109618 und CVE-2026-109619 (PHP2Shell) abgesichert? Welche PHP-Version mit welchem Patchstand läuft dort? Vielen Dank.“

Bitten Sie um eine schriftliche Bestätigung, vor allem dann, wenn die angezeigte Versionsnummer nicht zu den sicheren Versionen passt.

Wenn Sie noch PHP 8.1 oder älter nutzen

In fast jedem Hosting-Panel können Sie die PHP-Version selbst umstellen. Wählen Sie dort am besten PHP 8.3 oder 8.4. Gehen Sie dabei aber nicht blind vor, denn ältere Plugins und Themes laufen nicht immer mit neuen PHP-Versionen:

Backup erstellen: Sichern Sie Dateien und Datenbank, bevor Sie etwas ändern. Wie das geht, zeigen wir in unserer Anleitung Backup einer WordPress Website erstellen.
WordPress, Plugins und Themes aktualisieren: Aktuelle Versionen sind in der Regel mit neuem PHP kompatibel. Mehr dazu in So können Sie WordPress aktualisieren.
Testen, wenn möglich: Viele Hoster bieten eine Staging-Umgebung an. Stellen Sie dort zuerst um und prüfen Sie die wichtigsten Seiten, Formulare und gegebenenfalls den Shop.
Umstellen und kontrollieren: Wechseln Sie die PHP-Version im Hosting-Panel und prüfen Sie anschließend unter Website-Zustand, ob die neue Version aktiv ist und keine Fehler gemeldet werden.

Plugins, die seit Jahren kein Update mehr bekommen haben, sind beim Versionswechsel die häufigsten Störenfriede. Sie sind ohnehin ein Sicherheitsrisiko und sollten ersetzt werden.

Eigener Server, VPS oder Root-Server

Betreiben Sie den Server selbst, liegt die Verantwortung bei Ihnen:

Spielen Sie die aktualisierten PHP-Pakete Ihrer Distribution ein. Distributionen und Anbieter mit Langzeit-Support haben die Korrekturen vorab erhalten.
Starten Sie danach PHP-FPM, Apache und alle langlaufenden PHP-Prozesse neu. Erst dann ist der neue Code aktiv.
Prüfen Sie das Ergebnis mit php -v und zusätzlich im Website-Zustand von WordPress, denn Kommandozeile und Webserver nutzen nicht immer dasselbe PHP.
Falls Sie PHP aus dem Paketarchiv rpms.remirepo.net beziehen: Laut Help Net Security standen dort am Veröffentlichungstag noch keine Updates bereit. Weichen Sie in diesem Fall auf die Pakete Ihrer Distribution aus.
Denken Sie an alle PHP-Installationen, auch an vergessene Testumgebungen, alte Projekte und Server-Verwaltungsoberflächen.

Übergangsmaßnahmen, falls ein Update nicht sofort möglich ist: Das PHP-Team nennt einige Einstellungen in der php.ini, die einzelne Angriffswege erschweren, etwa session.upload_progress.enabled = 0, ein niedrigeres post_max_size (8M, oder 32M, wenn Uploads nötig sind) und memory_limit = -1. Vorsicht beim letzten Punkt: Ohne Speicherlimit kann ein fehlerhaftes Plugin den ganzen Server lahmlegen. php2shell.com empfiehlt deshalb, die Grenze dann auf Systemebene zu setzen, etwa über cgroup v2. Das PHP-Team betont ausdrücklich, dass diese Maßnahmen eine Installation nicht sicher machen. Sie sind eine Notlösung für Stunden, nicht für Wochen.

Aus der Praxis: So sind wir am 21. Oktober vorgegangen

Wir betreuen die WordPress-Websites unserer Kunden bei ganz unterschiedlichen Hostern: im Managed-WordPress-Hosting, im Shared Hosting und auf Servern, die die IT-Abteilung des Kunden selbst betreibt. Am 21. Oktober haben wir alle betreuten Websites systematisch durchgearbeitet. Auf diese Punkte haben wir dabei besonders geachtet.

Die PHP-Version prüfen, mit der die Website wirklich läuft. Wir verlassen uns weder auf das Hosting-Panel noch auf die Kommandozeile. Kommandozeile und Webserver nutzen häufig getrennte PHP-Installationen. Per SSH kann deshalb eine ältere Version erscheinen, obwohl der Webserver längst gepatcht ist, und umgekehrt. Hosting-Panels zeigen oft nur „8.3“ ohne den genauen Stand. Maßgeblich ist das PHP, mit dem die Website ausgeliefert wird. Das zeigt der Website-Zustand in WordPress.

Nur die Versionen mit Fix zählen. „Aktuell“ reicht nicht. Entscheidend ist, ob mindestens PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 läuft. Deshalb haben wir auch Websites, die erst kurz zuvor ein PHP-Update bekommen hatten, nach Erscheinen der Fixes erneut kontrolliert.

Der Managed-Hoster patcht, wechselt aber keine Versionen. Unser Managed-WordPress-Hoster hatte schon vor dem offiziellen Update eigene Schutzmaßnahmen auf seinen Servern aktiv und die korrigierten PHP-Versionen kurz nach Erscheinen bereitgestellt. Eine veraltete PHP-Version stellt er aber nicht von sich aus um. Websites auf PHP 8.1 hätten deshalb keinen Fix bekommen. Diese Websites haben wir identifiziert und selbst auf eine unterstützte Version gebracht.

Versionswechsel mit Prüfung vorher und Kontrolle danach. Als Ziel haben wir PHP 8.3 gewählt, nicht 8.2. PHP 8.2 bekommt nur noch bis Jahresende Sicherheitsupdates, ein zweiter Wechsel in wenigen Wochen wäre absehbar gewesen. Vor der Umstellung haben wir den Code der Website automatisiert auf Kompatibilität mit der neuen PHP-Version geprüft und die Änderungsprotokolle der eingesetzten Plugins durchgesehen. Nach der Umstellung haben wir Fehlerprotokolle und Erreichbarkeit der Website bis in den Abend überwacht. Die Umstellung lief ohne neue Fehler.

Schutz auch dann, wenn der Hoster nicht erreichbar ist. Bei einem Online-Shop auf einem Shared-Hosting-Paket waren Kundenbereich und Support des Hosters an diesem Tag nicht erreichbar. Wir haben dort zuerst ein Backup gezogen und dann die Übergangseinstellungen aus dem Sicherheitshinweis des PHP-Teams über eine .user.ini gesetzt. Der Weg ist dabei wichtig: Läuft PHP wie bei diesem Hosting als FastCGI, führen dieselben Einstellungen in der .htaccess zu einem Serverfehler. Diese Einstellungen erschweren einzelne Angriffswege, ersetzen aber nicht das Update. Sobald der Hoster die korrigierte PHP-Version einspielt, nehmen wir sie wieder heraus und testen Shop, Anmeldung und Uploads.

Klare Anweisungen, wo wir keinen Serverzugriff haben. Ein Kunde betreibt seinen Server über die eigene IT-Abteilung. Ihr haben wir konkret mitgeteilt, was zu tun ist: auf welche PHP-Version aktualisiert werden muss, dass die PHP-Prozesse danach neu gestartet werden müssen und welche Übergangsmaßnahmen bis dahin helfen.

Kurz und verständlich informieren. Unsere Kunden haben wir persönlich und ohne Fachchinesisch informiert: was passiert ist, was wir für ihre Website tun, wo ihr Hoster oder ihre IT gefragt ist und wie der aktuelle Stand ist.

Unser Fazit: Die eigentliche Arbeit steckt weniger im Update selbst als im verlässlichen Überblick. Wer weiß, wo seine Website liegt, welche PHP-Version wirklich läuft und wer beim Hoster zuständig ist, kann in solchen Situationen schnell und sicher handeln.

Was Firewalls und Sicherheits-Plugins leisten

Cloudflare hat Regeln gegen bekannte Angriffsmuster in seine Web Application Firewall aufgenommen, die allen Kunden zur Verfügung stehen. Auch viele Hoster filtern verdächtige Anfragen bereits vor dem Server. Das senkt das Risiko, ersetzt aber das Update nicht: Solche Regeln erkennen nur bekannte Muster, und Angreifer passen ihre Methoden laufend an.

Klassische Sicherheits-Plugins wie Wordfence, Sucuri oder Solid Security können die Lücke selbst nicht schließen, weil sie innerhalb von PHP arbeiten. Sinnvoll bleiben sie trotzdem, etwa um veränderte Dateien zu entdecken. Welches Plugin was kann, lesen Sie in unserem Vergleich der WordPress Sicherheits-Plugins.

Wurde meine Website schon angegriffen?

Eindeutige Erkennungsmerkmale gibt es noch nicht. Die Sicherheitsforscher nennen einige Hinweise, die Ihr Hoster oder Administrator in den Server-Logs prüfen kann: ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies, Anfragen mit Datei-Uploads, auf die Speicherfehler oder gehäufte 500-Fehler folgen, sowie unerklärliche Abstürze von PHP-Prozessen. Huntress empfiehlt außerdem, darauf zu achten, ob PHP-Prozesse plötzlich Kommandozeilen oder Programme wie curl und wget starten.

Auch ohne Serverzugang können Sie selbst einiges prüfen:

Benutzer: Gibt es Administratoren, die Sie nicht kennen? Kontrollieren Sie die Liste unter Benutzer. Hilfe dazu finden Sie in unserem Ratgeber zur WordPress Benutzerverwaltung.
Dateien: Melden Sicherheits-Plugins neue oder veränderte Dateien im WordPress-Verzeichnis, vor allem PHP-Dateien im Upload-Ordner?
Inhalte: Tauchen unbekannte Seiten, Weiterleitungen oder Spam-Links auf? Eine Suche nach site:ihredomain.de bei Google zeigt manchmal Seiten, die Sie nie angelegt haben.
Verhalten: Ist die Website auffällig langsam, verschickt sie Spam-Mails oder warnt Ihr Browser beim Aufruf?

Fehlen diese Anzeichen, heißt das allerdings nicht, dass alles in Ordnung ist. Und umgekehrt beweist ein einzelner Hinweis noch keinen Angriff. Haben Sie einen konkreten Verdacht, ändern Sie nach dem PHP-Update alle Passwörter, auch die der Datenbank und des Hosting-Kontos, und erneuern Sie API-Schlüssel, etwa von Zahlungsanbietern. Denn über die zweite Lücke könnten Zugangsdaten aus dem Speicher abgeflossen sein. Was im Ernstfall sonst noch zu tun ist, beschreiben wir in Was tun, wenn die eigene WordPress Seite gehackt wurde?

Ihre Checkliste für heute

PHP-Version unter Werkzeuge → Website-Zustand → Bericht → Server ablesen.
Mit den sicheren Versionen 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 vergleichen.
Beim Hoster nachfragen und den Patchstand schriftlich bestätigen lassen.
Bei PHP 8.1 oder älter: Backup erstellen, Plugins aktualisieren und auf PHP 8.3 oder 8.4 wechseln.
Bei PHP 8.2: Wechsel auf 8.3 oder neuer bis Jahresende einplanen.
Benutzerliste, Dateien und Inhalte auf Auffälligkeiten prüfen.
Bei Verdacht: Passwörter und API-Schlüssel erneuern.

Häufige Fragen zu PHP2Shell

Muss ich WordPress aktualisieren, um mich zu schützen?

Nein, nicht wegen PHP2Shell. Die Lücke steckt in PHP und wird nur durch ein PHP-Update geschlossen. Ein aktuelles WordPress ist trotzdem wichtig, schon weil es den Wechsel auf eine neuere PHP-Version erleichtert.

Bin ich sicher, wenn mein Hoster eine Firewall hat?

Sicherer, aber nicht sicher. Firewall-Regeln wehren bekannte Angriffsmuster ab. Erst das PHP-Update beseitigt die Ursache.

Hilft es, ein Sicherheits-Plugin zu installieren?

Gegen diese Lücke nicht direkt, weil das Plugin selbst in PHP läuft. Es kann aber helfen, die Folgen eines Angriffs zu erkennen.

Meine Website läuft auf PHP 7.4. Was nun?

Für PHP 7.4 gibt es kein offizielles Update mehr. Fragen Sie Ihren Hoster, ob er selbst Korrekturen einspielt, und planen Sie den Wechsel auf PHP 8.3 oder 8.4 so schnell wie möglich. Erstellen Sie vorher ein Backup und testen Sie die Website nach der Umstellung.

Fazit: Sicherheit endet nicht im Dashboard

PHP2Shell zeigt, dass zur Sicherheit einer WordPress-Website mehr gehört als das Dashboard. Updates für WordPress, Plugins und Themes bleiben wichtig, aber sie schützen nur die oberste Schicht. Darunter laufen PHP, Webserver und Betriebssystem, und auch die müssen aktuell sein. Bei den meisten Websites kümmert sich der Hoster darum. Ihre Aufgabe ist, das zu kontrollieren und eine veraltete PHP-Version nicht jahrelang mitzuschleppen. Weitere Grundlagen finden Sie in unserem Ratgeber zur WordPress Sicherheit.

Sie sind unsicher, ob Ihre Website betroffen ist, oder möchten den Wechsel auf eine aktuelle PHP-Version nicht allein angehen? Die WordPress-Helden aus Köln prüfen Ihre Installation, stimmen sich mit Ihrem Hoster ab und stellen PHP sicher um. Nehmen Sie einfach Kontakt mit uns auf.