Ist meine WordPress-Seite von PHP2Shell betroffen?

Ja, sofern sie auf einer PHP-Version ohne den Fix vom 21. Oktober 2026 läuft. Die Lücke steckt in PHP selbst, nicht in WordPress oder einem Plugin. Sicher bist du erst mit PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder einem gepatchten Paket deiner Linux-Distribution.

Hilft ein Sicherheits-Plugin oder der Wartungsmodus gegen PHP2Shell?

Nein. Der Angriff greift, während PHP die Anfrage einliest, also bevor WordPress lädt. Weder ein Plugin noch der WordPress-Wartungsmodus kommen an diese Stelle heran. Das PHP-Team schreibt selbst, es gebe keine vollständigen Gegenmaßnahmen, nur das Update sei sicher.

Ich habe Shared Hosting. Muss ich selbst etwas tun?

Das PHP-Update spielt bei Shared Hosting der Hoster ein. Deine Aufgabe ist, die Statusseite oder Kundeninfo deines Hosters zu prüfen, im Hosting-Panel eine unterstützte PHP-Version (8.2 oder neuer) einzustellen und danach im WordPress-Backend unter Werkzeuge → Website-Zustand nachzusehen, welche Version tatsächlich läuft.

Was mache ich, wenn meine Seite noch PHP 8.1 oder älter braucht?

Für PHP 8.1, 8.0 und 7.4 hat das PHP-Projekt nur Quellcode-Korrekturen veröffentlicht, für noch ältere Versionen gar nichts. Manche Linux-Distributionen und LTS-Anbieter liefern zurückportierte Fixes. Ohne einen davon bleibt nur das Upgrade auf eine unterstützte Version oder die Seite bis dahin vom Netz zu nehmen.

PHP2Shell: Was die kritische PHP-Lücke für deine Website heißt

Q: Woran erkenne ich, ob meine Seite schon angegriffen wurde?

Wiz nennt als Hinweise ungewöhnliche Datei-Upload-Anfragen, auf die Memory-Limit-Fehler oder gehäufte 500-Fehler folgen, sowie auffällig große oder verstümmelte PHPSESSID-Cookies. Auf Anwendungsebene lohnt der Blick nach neuen Dateien in Upload-Ordnern, unbekannten Admin-Konten und geänderten Core-Dateien.

Heute, am 21. Oktober 2026, hat das PHP-Team zwei kritische Sicherheitslücken geschlossen, die unter dem Namen PHP2Shell laufen. Schon am Vormittag waren Behördenportale, Kliniken und Kommunalseiten vom Netz, und mehrere Hoster haben Funktionen abgeschaltet. Was dahintersteckt, wen es trifft und was du jetzt tun solltest, steht hier. Die Quellen nennen wir jeweils im Text.

Was passiert ist

PHP2Shell ist der Spitzname für zwei Lücken im Kern von PHP:

CVE-2026-109618: Läuft PHP beim Einlesen einer Anfrage der Speicher aus, bricht es ab, während interne Daten erst halb angelegt sind. Beim Aufräumen werden diese Daten trotzdem als gültig behandelt.
CVE-2026-109619: Ein interner Zustand überlebt das Ende einer Anfrage, obwohl sein Speicher schon freigegeben ist. Die nächste Anfrage im selben PHP-Prozess kann ihn verwenden.

Beide bewertet das PHP-Team nach CVSS 4.0 mit 9,2 von 10 Punkten. In beiden Fällen kann ein Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen, mit den Rechten des PHP-Prozesses. Die technische Analyse hat das Sicherheitsunternehmen Wiz veröffentlicht. Laut Wiz waren KI-Modelle an Fund und Exploit-Entwicklung maßgeblich beteiligt.

Der Zeitablauf laut Wiz, PHP-Team und Patchstack:

24. August 2026: Meldung an das PHP-Sicherheitsteam.
20. Oktober: Details sickern vor dem geplanten Termin an die Öffentlichkeit. Das PHP-Team kündigt die Updates für den Folgetag an, das Notfallteam der EU-Institutionen (CERT-EU) warnt.
21. Oktober, 9:34 Uhr MESZ: Hoster melden Patchstack erste Angriffe. Kurz darauf bestätigt Cloudflare Angriffe und schaltet Filterregeln.
21. Oktober, 16:00 Uhr MESZ: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen.

Das BSI hat am selben Tag einen Sicherheitshinweis der Stufe 3/Orange herausgegeben.

Warum so viele Seiten offline gingen

CERT-EU hat Organisationen, die nicht schnell patchen können, geraten, ihre öffentlich erreichbaren Anwendungen bis zum Fix vom Netz zu trennen. Viele haben das wörtlich genommen. Laut The Record, NOS und Borns IT-Blog waren unter anderem DigiD und MijnOverheid in den Niederlanden, die Charité Berlin, Websites mehrerer Städte wie Köln, Düsseldorf und Dresden sowie Seiten von Landesämtern für Verfassungsschutz zeitweise nicht erreichbar.

Auch Hoster haben reagiert. Laut Borns IT-Blog hat IONOS Nextcloud-Instanzen vorsorglich deaktiviert, manitu hat Formular-Uploads mit Anhängen gesperrt. Das ist kein Zufall: Der Angriff läuft über genau die Art Anfrage, mit der Browser Dateien hochladen (multipart/form-data).

Der Grund für die Vorsicht: PHP läuft laut Wiz auf rund 70 Prozent aller Websites, und die anfällige Stelle gibt es seit PHP 5.4 aus dem Jahr 2012. Das betrifft praktisch jede WordPress-, Shopware-, Drupal- oder Laravel-Installation, aber auch Nextcloud, Roundcube oder phpMyAdmin.

Wer betroffen ist

Laut php.net jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das größte Risiko sieht das PHP-Team bei mod_php, wo ein einzelner Request ohne Login den Angriff auslösen kann, bevor überhaupt Anwendungscode läuft.

Das ist der entscheidende Punkt für Website-Betreiber: Dein CMS kann dich nicht schützen. WordPress, Laravel oder Shopware bekommen die Anfrage erst zu sehen, wenn PHP sie bereits verarbeitet hat. Ein Sicherheits-Plugin, eine Login-Sperre oder der Wartungsmodus kommen zu spät.

PHP-Version	Status
8.5, 8.4, 8.3, 8.2	Fix verfügbar: 8.5.12, 8.4.27, 8.3.36, 8.2.35
8.1, 8.0, 7.4	Nur Quellcode-Korrekturen vom PHP-Projekt, Pakete höchstens von Distribution oder LTS-Anbieter
7.3 und älter	Kein Fix

Was du jetzt tun solltest

Version auf dem Webserver prüfen, nicht im Terminal. Die Kommandozeile (php -v) nutzt oft eine andere PHP-Version als die Website. In WordPress zeigt Werkzeuge → Website-Zustand → Info → Server die Version, die wirklich Seiten ausliefert. Alternativ das Hosting-Panel.
Bei Shared Hosting den Hoster prüfen. Den Fix spielt der Hoster ein. Schau auf seine Statusseite oder in die Kundeninfo. Steht deine Seite noch auf PHP 8.1 oder älter, stell sie im Panel auf 8.2 oder neuer um. Wie das ohne Ausfall klappt, beschreibt unser Artikel PHP-Version in WordPress aktualisieren.
Auf eigenen Servern updaten und neu starten. Pakete der Distribution aktualisieren, dann alle PHP-FPM-Pools und den Webserver neu starten. Laufende Prozesse arbeiten sonst weiter mit dem alten Code.
Container neu bauen. Docker-Images bringen ihr eigenes PHP mit. Base-Image aktualisieren, neu bauen, neu ausrollen. Das gilt auch für Staging- und Testumgebungen, die öffentlich erreichbar sind.
Alle PHP-Installationen finden. Nicht nur die Hauptseite: alte Microsites, Kundenportale, phpMyAdmin, Nextcloud, ein vergessenes Shop-Testsystem. Laut Sophos ist genau dieses Auffinden für viele Organisationen die eigentliche Hürde.
Keine „Fix-Plugins“ installieren. Patchstack warnt ausdrücklich vor inoffiziellen Plugins, die behaupten, die Lücke zu schließen. Auf Anwendungsebene ist das nicht möglich.

Wenn du nicht sofort patchen kannst

Das PHP-Team ist deutlich: Es gibt keine vollständigen Gegenmaßnahmen, nur das Update ist sicher. Als Überbrückung für wenige Stunden nennen Sansec und Dr. Web:

Seite vom Netz nehmen oder durch eine statische Wartungsseite ersetzen, die der Webserver ohne PHP ausliefert.
Datei-Uploads auf Webserver-Ebene sperren, also Anfragen mit Content-Type: multipart/form-data in nginx oder Apache abweisen. Das legt Kontaktformulare mit Anhang, Bild-Uploads und manche Checkouts lahm.
session.upload_progress.enabled abschalten. Das entschärft einen Teil des Angriffswegs, nicht alles.

Keine dieser Maßnahmen ersetzt das Update. Sie kaufen Zeit.

Woran du einen Angriff erkennst

Wiz nennt als Spuren in den Server-Logs ungewöhnliche Upload-Anfragen, auf die Memory-Limit-Fehler oder wiederholte 500-Fehler folgen, sowie auffällig große oder verstümmelte PHPSESSID-Cookies. Weil laut Patchstack und Cloudflare schon Stunden vor dem Patch angegriffen wurde, lohnt der Blick auch dann, wenn dein Hoster inzwischen aktualisiert hat.

Auf Anwendungsebene sind die Zeichen dieselben wie bei jedem anderen Einbruch: neue PHP-Dateien im Upload-Ordner, unbekannte Admin-Konten, geänderte Core-Dateien, Weiterleitungen auf fremde Seiten. Wie du dabei vorgehst, steht in WordPress gehackt? Malware erkennen und bereinigen. Das Update schließt die Tür, entfernt aber nichts, was schon drin ist.

Was PHP2Shell über Wartung sagt

Die Lücke selbst konnte niemand vorhersehen. Wie schwer sie einen trifft, schon. Laut The Record läuft ungefähr die Hälfte aller PHP-Websites auf veralteten Versionen, Dr. Web nennt für WordPress 36,4 Prozent auf PHP 8.1 oder älter. Wer heute auf 8.3 oder 8.4 steht, wartet auf seinen Hoster. Wer auf 7.4 steht, hat ein Migrationsprojekt unter Zeitdruck.

Drei Dinge, die sich aus dem Tag mitnehmen lassen:

PHP-Version ist Teil der Wartung. PHP 8.2 bekommt nur noch bis Ende 2026 Sicherheitsfixes. Wer jetzt auf 8.2 aktualisiert, sollte den Schritt auf 8.4 gleich einplanen.
Eine Liste aller Systeme haben. Wer weiß, wo überall PHP läuft, braucht an so einem Tag Minuten statt Stunden.
Statisch heißt nicht automatisch PHP-frei. Auch unsere eigene Website ist eine statische Astro-Seite, das Kontaktformular läuft aber über ein PHP-Skript beim Hoster. Solche Einzelskripte gehören ebenfalls auf die Liste.

Was regelmäßige Wartung abdeckt, inklusive PHP-Updates, beschreibt unser Überblick WordPress absichern.

Du weißt nicht, auf welcher PHP-Version deine Seite läuft, oder sie hängt noch auf 8.1 oder älter? Melde dich über unsere Seite WordPress-Notfall oder schreib uns kurz. Wir schauen uns an, was zu tun ist, und sagen dir ehrlich, wie lange es voraussichtlich dauert.