PHP2Shell: Kritische Lücke in PHP — was WordPress-Betreiber jetzt prüfen müssen

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Lücken geschlossen, über die Angreifer ohne Anmeldung eigenen Code auf einem Webserver ausführen können. PHP ist die Programmiersprache, in der WordPress, WooCommerce, Joomla, Drupal und viele andere Systeme laufen. Unter dem Namen «PHP2Shell» kursierten die Einzelheiten bereits einen Tag vor der Korrektur. Bewertet sind beide Lücken mit 9,2 von 10 Punkten. Anders als bei den meisten WordPress-Lücken hilft hier kein Update im Dashboard: Schliessen kann sie nur, wer den Server betreibt, meistens also der Hoster. Ob Ihre Website geschützt ist, lässt sich prüfen, allerdings nicht zuverlässig an der Versionsnummer. Und wer bis zum Update angreifbar war, sollte wissen, wonach er suchen muss.

Das Wichtigste in Kürze

Sicher sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Für PHP 8.1 und älter liefert das PHP-Projekt kein Update mehr; geschützt sind solche Server nur, wenn der Anbieter die Korrektur selbst nachgerüstet hat.
Ein WordPress-Update ändert nichts. Der Fehler steckt in PHP selbst, nicht in WordPress oder einem Plugin. Die Entdecker haben die Übernahme unter anderem an einer aktuellen WordPress-Installation vorgeführt.
Angriffsversuche gibt es, bestätigte Einbrüche bisher nicht. Cloudflare meldet Angriffsverkehr seit dem Morgen des 21. Oktober, watchTowr Angriffsversuche auf beide Lücken. Ein erfolgreicher Einbruch war bis zum Abend nicht öffentlich belegt.
Die angezeigte PHP-Version kann täuschen. Unter Ubuntu 24.04 meldet ein bereits korrigiertes PHP weiterhin die Version 8.3.6. Verlässlich ist nur die Auskunft des Hosters, ob die Korrektur eingespielt ist und die PHP-Prozesse neu gestartet wurden.
Ein Update entfernt keinen Angreifer. Wer angreifbar war, prüft auf Spuren und wechselt Zugangsdaten. Über eine der Lücken lässt sich Arbeitsspeicher auslesen, und das hinterlässt keine veränderte Datei.

Was PHP2Shell ist

PHP ist das Programm auf dem Webserver, das den Code von WordPress ausführt. Ruft jemand eine Seite auf oder schickt ein Formular ab, nimmt PHP die Anfrage entgegen, zerlegt sie und übergibt sie an WordPress. In genau diesem Teil, bevor WordPress überhaupt beteiligt ist, sitzen die beiden Fehler. Das PHP-Projekt beschreibt sie in seinem Sicherheitshinweis so:

CVE-2026-109618, «RCE via OOM corruption». Geht PHP während einer Anfrage der Arbeitsspeicher aus, bricht es die Verarbeitung ab, während interne Daten erst halb eingerichtet sind. Beim anschliessenden Aufräumen behandelt PHP diese halbfertigen Daten als gültig. Auslösen lässt sich das über Formularanfragen, die Dateien mitschicken können (im Fachjargon multipart/form-data).
CVE-2026-109619, «RCE via stale global state». Bestimmte Zustände einer Anfrage bleiben erhalten, obwohl ihr Speicher schon freigegeben ist. Die nächste Anfrage, die derselbe PHP-Prozess bearbeitet, greift darauf zu. Der bestätigte Weg zur Übernahme nutzt die Funktion fatal_error_backtraces, die es nur in PHP 8.5 gibt; weitere Auslöser sind unter anderem die Upload-Fortschrittsanzeige der Sitzungsverwaltung und schwere Laufzeitfehler.

Das PHP-Projekt bewertet beide Lücken mit 9,2 von 10 Punkten nach dem Bewertungssystem CVSS 4.0. Die 10,0, die vor der Veröffentlichung im Umlauf war, stammt aus dem Leak und ist keine offizielle Bewertung. Laut Sicherheitshinweis führen beide Lücken im Ergebnis zum selben Schaden: Ein Angreifer ohne Konto führt Code mit den Rechten des Webserver-Kontos aus. Vorgeführt haben die Entdecker das mit Apache und dem Modul mod_php, wo der Angriff wirkt, bevor überhaupt Code der Website läuft. PHP-FPM, das viele Hoster einsetzen, gilt nach Analyse des Quellcodes ebenfalls als anfällig, FrankenPHP und LiteSpeed wahrscheinlich auch.

Gemeldet haben die Lücken im August 2026 unter anderem die Sicherheitsfirmen Calif und Wiz Research. Nach Angaben von Wiz ist jede PHP-Version seit 5.4 aus dem Jahr 2012 von mindestens einem der Fehler betroffen; das PHP-Projekt selbst nennt für ältere Versionen keinen genauen Bereich. Wiz gibt ausserdem an, dass KI-Modelle beim Finden der Fehler und beim Bau der Angriffe wesentlich geholfen hätten.

Ihr PHP-Zweig	Korrigierte Version	Hinweis
8.5	8.5.12	Einziger Zweig mit dem bestätigten Weg über `fatal_error_backtraces`
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	Der Sicherheitssupport endet am 31. Dezember 2026
8.1 und älter	keine vom PHP-Projekt	Nur Nachrüstungen von Linux-Distributionen und Anbietern mit Langzeitsupport; für 7.4, 8.0 und 8.1 gibt es Quellcode-Korrekturen zum Selbstkompilieren

Korrigierte Versionen laut der Sicherheitsmeldung des PHP-Projekts vom 21. Oktober 2026. Die Testversion PHP 8.6.0 RC4 enthält die Korrekturen ebenfalls, ist aber nicht für den Betrieb gedacht.

Warum ein WordPress-Update hier nichts ändert

Bei den Lücken der letzten Monate, etwa wp2shell im Juli, lag der Fehler in WordPress selbst, und das automatische Update von WordPress hat ihn geschlossen. Bei PHP2Shell ist das anders. WordPress ist das Programm, PHP die Maschine, auf der es läuft. Eine neue WordPress-Version, ein Plugin-Update oder ein Sicherheits-Plugin ändern an dieser Maschine nichts. Cloudflare formuliert es in seiner Analyse ausdrücklich: Code oder Plugins der Website zu aktualisieren, behebt diese Lücken nicht.

Dass WordPress-Websites betroffen sind, ist nicht nur theoretisch. Wiz hat die Übernahme ohne Anmeldung am offiziellen Docker-Image von WordPress vorgeführt, Calif laut dem Sicherheitsanbieter Sansec an WordPress 7.1.2, Drupal, Joomla, Magento, Nextcloud, phpMyAdmin und weiteren Anwendungen. Betroffen ist jede Website, die auf einer ungepatchten PHP-Version läuft, unabhängig davon, wie sorgfältig WordPress und seine Plugins gepflegt sind.

Wer das Update einspielt, hängt deshalb davon ab, wo Ihre Website liegt:

Webhosting und Managed Hosting: Der Hoster aktualisiert PHP für alle Kunden. Sie können nur nachfragen und abwarten.
Eigener Server oder virtueller Server: Wer den Server betreibt, spielt die Pakete der Linux-Distribution ein. Das sind Sie selbst oder die Agentur, die den Server für Sie betreut.
Docker und andere Container: Das Image muss neu gebaut oder neu gezogen und der Container neu gestartet werden. Ein laufender Container aktualisiert sich nicht von selbst.

In allen drei Fällen gilt, was auch das Bundesamt für Cybersicherheit (BACS) betont: Nach dem Update müssen die laufenden PHP-Prozesse neu gestartet werden. Ein Prozess, der vor dem Update gestartet wurde, arbeitet weiter mit dem alten Code im Arbeitsspeicher. Vorsicht ist auch bei angeblichen «Fix-Plugins» und kopierten Code-Schnipseln geboten. Patchstack rät ausdrücklich davon ab: Sie sind ungeprüft, können die Website lahmlegen und erreichen den Fehler in PHP ohnehin nicht.

Wird PHP2Shell schon ausgenutzt?

Eigentlich hätten Einzelheiten erst nach dem Update öffentlich werden sollen. Am 20. Oktober tauchten die Kennungen der Lücken samt Einstufung aber in einem Forum auf, und am selben Tag kündigte das PHP-Projekt das Update für den nächsten Nachmittag an. Was danach geschah, lässt sich aus den Angaben der Beteiligten nachzeichnen. Alle Zeiten in Schweizer Sommerzeit, in Klammern die Weltzeit UTC:

Zeitpunkt 2026	Ereignis
1. bis 24. August	Calif und Wiz Research finden die Fehler und melden sie dem PHP-Projekt
20. Oktober	Leak der Kennungen; das PHP-Projekt kündigt das Update für den 21. Oktober an, watchTowr meldet, eine der Lücken nachgebaut zu haben
21. Oktober, 05:02 (03:02 UTC)	Cloudflare schaltet Filterregeln für alle Kunden frei, auch für die Gratisversion
21. Oktober, 09:43 (07:43 UTC)	Cloudflare meldet erste Angriffe
21. Oktober, 15:45	Der Basler Hoster cyon nimmt vorsorglich alle Webhostings vom Netz
21. Oktober, 15:57 (13:57 UTC)	Patchstack: in den eigenen Messdaten nur Abtastversuche, kein harter Beleg für Einbrüche
21. Oktober, 16:00 (14:00 UTC)	PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen
21. Oktober, 16:19 (14:19 UTC)	watchTowr meldet aktive Angriffsversuche auf beide Lücken

Zeitangaben aus den Veröffentlichungen von Sansec, Cloudflare, Patchstack, watchTowr, des PHP-Projekts und der Statusseite von cyon (Stand 21. Oktober 2026, abends).

Die Lage ist damit klarer, als manche Schlagzeile vermuten lässt. Angriffsversuche sind belegt: Cloudflare hat Angriffsverkehr auf Kunden beobachtet und berichtet, dass Angreifer ihre Anfragen laufend abwandeln, um die Filter zu umgehen. watchTowr spricht von aktiven Versuchen gegen beide Lücken. Ein erfolgreicher Einbruch ist bisher nicht öffentlich belegt. Cloudflare unterscheidet in seiner Meldung nicht zwischen Versuch und Erfolg, watchTowr spricht ausdrücklich von Versuchen, und Patchstack sah am Nachmittag nur Abtastversuche. Das kann sich schnell ändern. Sansec rechnet mit massenhaften Angriffen, seit Korrektur und technische Beschreibungen öffentlich sind, also seit dem Nachmittag des 21. Oktober.

Wie ernst die Lage in der Schweiz genommen wird, zeigte sich am selben Nachmittag. Der Hoster cyon nahm eine Viertelstunde vor dem Update seine Webhostings, Managed Server und das Kundenkonto vom Netz und kündigte an, sie nach Eintreffen der korrigierten Pakete seines Betriebssystem-Herstellers im Lauf der Nacht wieder einzuschalten. Das BACS rief dazu auf, die Updates sofort einzuspielen, betroffene Systeme auch ausserhalb der Website zu erfassen und nach Spuren eines Angriffs zu suchen. PHP steckt nach Hinweis des BACS auch in Verwaltungsoberflächen, Appliances und Containern, oft ohne dass die Betreiber davon wissen.

Ihre Website prüfen: Die Versionsnummer allein genügt nicht

Welche PHP-Version Ihre Website nutzt, zeigt WordPress unter Werkzeuge → Website-Zustand → Bericht → Server → PHP-Version. Steht dort 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder eine höhere Version desselben Zweigs, ist die Korrektur enthalten. Steht dort eine niedrigere Nummer, heisst das aber nicht zwingend, dass Ihre Website angreifbar ist.

Viele Hoster verwenden PHP aus den Paketen ihrer Linux-Distribution. Distributionen wie Ubuntu frieren die Versionsnummer für die Lebensdauer einer Ausgabe ein und bauen Sicherheitskorrekturen nachträglich in diese alte Version ein. Wir haben das am 21. Oktober 2026 nachgestellt: In einem frischen Ubuntu 24.04 LTS installiert die Paketverwaltung das bereits korrigierte Paket 8.3.6-0ubuntu0.24.04.13. PHP selbst meldet trotzdem die Version 8.3.6, und genau diese Zahl würde WordPress im Website-Zustand anzeigen. Ein Vergleich mit 8.3.36 würde fälschlich «angreifbar» ergeben.

Distribution	Korrigiertes Paket	Was WordPress anzeigt
Ubuntu 24.04 LTS	8.3.6-0ubuntu0.24.04.13	8.3.6 (von uns nachgeprüft)
Ubuntu 22.04 LTS	8.1.2-1ubuntu2.28	8.1.2, obwohl das PHP-Projekt 8.1 nicht mehr korrigiert
Debian 12	8.2.35-1~deb12u1	8.2.35
Debian 13	8.4.27-1~deb13u1	8.4.27

Korrigierte Pakete laut den Sicherheitsdatenbanken von Ubuntu und Debian zu CVE-2026-109618, abgerufen am 21. Oktober 2026. Die Anzeige unter Ubuntu 24.04 haben wir in einem Testcontainer geprüft, die übrigen ergeben sich aus der Versionsnummer des Pakets.

Umgekehrt kann eine Nummer harmlos aussehen und trotzdem ungeschützt sein, etwa wenn ein Hoster PHP selbst kompiliert und das Update noch nicht eingespielt hat. Das BACS hält deshalb fest, dass die Hauptversion allein nichts darüber aussagt, ob ein Patch fehlt. Wie unterschiedlich PHP auf Servern zustande kommt und was das für den Sicherheitssupport bedeutet, haben wir im Beitrag zum Ende von PHP 8.2 ausführlich beschrieben.

Verlässlich ist am Ende nur die Auskunft dessen, der den Server betreibt. Eine Anfrage an den Hoster, die sich nicht mit einem allgemeinen «Wir halten unsere Systeme aktuell» beantworten lässt, lautet etwa so:

«Ist das PHP, auf dem meine Website läuft, gegen CVE-2026-109618 und CVE-2026-109619 korrigiert? Seit wann, und wurden die PHP-Prozesse danach neu gestartet?»

Die Frage nach dem Zeitpunkt ist wichtig, weil sie bestimmt, wie lange Ihre Website angreifbar war. Dazu weiter unten mehr.

Wie viele WordPress-Websites ohne Nachrüstung keine Korrektur bekommen können, zeigt die Statistik von wordpress.org. Am 21. Oktober 2026 meldeten 36,4 Prozent der WordPress-Installationen, die sich bei wordpress.org melden, PHP 8.1 oder älter, allein 16,1 Prozent PHP 7.4. Wie viele davon ein nachgerüstetes Paket ihrer Distribution nutzen, lässt sich aus dieser Statistik nicht ablesen. Sicher ist: Für diese Websites liefert das PHP-Projekt kein Update, und wer bei einem Hoster mit veraltetem, selbst kompiliertem PHP liegt, bleibt angreifbar.

Wenn das Update noch nicht eingespielt ist

Auf einem gewöhnlichen Webhosting haben Sie wenig Spielraum. Die Einstellungen, auf die es ankommt, lassen sich laut PHP-Projekt nicht über die Datei .user.ini oder per ini_set() setzen, sondern nur in der Server-Konfiguration. Was bleibt:

Beim Hoster nachfragen, mit der Frage von oben, und einen Termin für das Update verlangen.
Die Website vorübergehend abschalten, wenn sie heikle Daten verarbeitet, etwa einen Onlineshop oder ein Kundenportal. Das BACS nennt diese Möglichkeit für kritische Anwendungen ausdrücklich, und cyon hat es für seine Kunden so gehandhabt.
Einen vorgeschalteten Filter nutzen. Läuft Ihre Website bereits über Cloudflare, greifen dessen Regeln seit dem frühen Morgen des 21. Oktober automatisch, auch im Gratisplan. Cloudflare nennt das selbst eine Notlösung, und das BACS hält fest, dass eine Web Application Firewall allein nicht genügt.

Wer den Server selbst betreibt, kann laut PHP-Projekt einzelne Angriffswege verbauen, bis das Update installiert ist. Das Projekt betont, dass diese Massnahmen eine Installation nicht sicher machen, weil weitere Varianten existieren können:

session.upload_progress.enabled = 0 in der php.ini oder im FPM-Pool setzen und alle PHP-Prozesse neu starten.
Unter PHP 8.5 zusätzlich fatal_error_backtraces = 0 setzen und neu starten.
memory_limit = -1 so setzen, dass Anwendungen es nicht überschreiben können, zum Beispiel per php_admin_value im FPM-Pool. Damit steigt das Risiko, dass ein einzelner Prozess den Server auslastet; eine Speichergrenze für den Container oder die Prozessgruppe fängt das auf. Grenzen über RLIMIT_AS oder RLIMIT_DATA sind dafür ungeeignet, weil sie genau den verwundbaren Fehler auslösen können.
post_max_size niedrig halten: 8M ohne Datei-Uploads, 32M mit Uploads, upload_max_filesize jeweils darunter.

WordPress selbst öffnet keine PHP-Sitzungen und braucht deshalb auch die Upload-Fortschrittsanzeige nicht; sie abzuschalten, ändert für die meisten Websites nichts. Ausnahmen sind Plugins, die eigene Sitzungen verwenden. Bei der Speichergrenze sieht das anders aus: Auf einer Website mit vielen Plugins und knappem Server sollte jemand die Auslastung im Blick behalten, solange die Grenze aufgehoben ist.

Woran man einen Angriff erkennt — und woran nicht

Wiz und Patchstack nennen drei Auffälligkeiten, die auf einen Angriffsversuch hindeuten können. Beide betonen, dass keine davon für sich genommen ein Beweis ist, weder in die eine noch in die andere Richtung:

ungewöhnliche Formularanfragen mit Dateiteilen, auf die Fehlermeldungen zur Speichergrenze oder wiederholt Serverfehler mit dem Status 500 folgen;
auffällig grosse oder fehlerhafte Sitzungs-Cookies mit dem Namen PHPSESSID in den Antworten des Servers;
PHP-Prozesse, die ohne erkennbaren Grund abstürzen und neu gestartet werden.

Das Problem dabei: Die üblichen Zugriffsprotokolle halten weder Cookies noch den Inhaltstyp einer Anfrage fest. Wir haben die Protokolle unserer eigenen Website für den 20. und 21. Oktober durchgesehen. Serverfehler gab es nur während des Neustarts für das PHP-Update, und die Zahl der Anfragen, die Daten an die Startseite schicken (POST), lag im Rahmen der Vortage. Unsere Website läuft seit 20:04 Uhr am 21. Oktober auf PHP 8.5.12, gut vier Stunden nach Erscheinen der Korrektur. Mehr als «keine Auffälligkeit gefunden» lässt sich aus solchen Protokollen aber nicht ableiten. Wer genauer hinsehen will, braucht ausführlichere Protokolle, und die müssen schon vor einem Angriff eingeschaltet gewesen sein.

Gelingt ein Angriff, sind die Spuren dieselben wie nach jeder anderen Übernahme: neue PHP-Dateien in wp-content/uploads/ oder wp-content/mu-plugins/, veränderte Kerndateien, unbekannte Administratorkonten, geplante Aufgaben, die niemand angelegt hat, und Einträge wie auto_prepend_file in einer .user.ini oder .htaccess, die vor jedem Seitenaufruf fremden Code laden.

Bereinigen nach PHP2Shell: was anders ist als nach einem Plugin-Hack

Bei einer gewöhnlichen WordPress-Lücke kommt ein Angreifer über ein bestimmtes Plugin oder eine bestimmte Funktion herein, und das begrenzt, was er erreicht. Bei PHP2Shell ist die Ausgangslage schlechter, aus zwei Gründen.

Erstens arbeitet der Angreifer mit den Rechten des Webservers. Er kann alles lesen, was PHP lesen kann, darunter die Datei wp-config.php mit dem Datenbank-Passwort und den geheimen Schlüsseln, mit denen WordPress Anmeldungen absichert. Er kann überall schreiben, wo PHP schreiben darf. Liegen mehrere Websites unter demselben Konto, sind alle betroffen, nicht nur die, über die er hereinkam.

Zweitens kann ein Angriff Daten abziehen, ohne eine Spur zu hinterlassen. Wiz hat gezeigt, dass sich über die Lücken Teile des Arbeitsspeichers eines PHP-Prozesses auslesen lassen, auch ohne Code auszuführen. Darin können laut Wiz Passwörter, Anmeldetoken, API-Schlüssel und Zertifikate aus fremden Anfragen stecken. Weil dabei nichts geschrieben wird, findet auch die gründlichste Dateiprüfung nichts.

Daraus ergibt sich ein Ablauf, der über das übliche Aufräumen hinausgeht:

Zeitfenster bestimmen. Kritisch ist die Zeit vom Leak am 20. Oktober bis zu dem Zeitpunkt, an dem auf Ihrem Server ein korrigiertes PHP lief und die Prozesse neu gestartet waren. Diesen Zeitpunkt kennt nur der Hoster.
Zustand sichern, bevor etwas geändert wird. Eine Kopie von Dateien, Datenbank und Protokollen dient als Beweismittel und als Grundlage für eine allfällige Meldung nach Datenschutzgesetz. Wer zuerst aufräumt, vernichtet die Spuren.
Protokolle des Zeitfensters auswerten. Gesucht werden Serverfehler, Meldungen zur Speichergrenze («Allowed memory size exhausted») im PHP-Fehlerprotokoll und gehäufte Formularanfragen an Adressen, an die sonst niemand etwas schickt.
Dateien gegen die Originale prüfen. Mit WP-CLI vergleichen wp core verify-checksums und wp plugin verify-checksums --all den Bestand mit den Originalen von wordpress.org. Zusätzlich von Hand: PHP-Dateien im Upload-Ordner, Dateien in mu-plugins, die Drop-ins db.php und advanced-cache.php, jede .user.ini und .htaccess.
Konten und Aufgaben prüfen. Administratorkonten, Anwendungspasswörter, geplante WordPress-Aufgaben und, soweit zugänglich, die geplanten Aufgaben des Server-Kontos.
Geheimnisse wechseln, auch ohne Fund. Datenbank-Passwort, die Sicherheitsschlüssel in wp-config.php (das meldet alle Benutzer ab), Administrator-Passwörter und jeden API-Schlüssel, der auf dem Server liegt: Mailversand, Zahlungsanbieter, Schnittstellen zu Buchhaltung oder Warenwirtschaft. Wegen des möglichen Speicherlecks ist das der eine Schritt, der sich nicht durch eine saubere Dateiprüfung ersetzen lässt.
Bereinigen oder neu aufsetzen. Findet sich eine Hintertür, ist ein sauberer Neuaufbau aus einer Sicherung von vor dem 20. Oktober oft verlässlicher als das Entfernen einzelner Dateien.

Wie wir eine befallene Website im Einzelnen bereinigen und wann ein Neuaufbau die bessere Wahl ist, steht in unserem Leitfaden WordPress gehackt: der Bereinigungsablauf. Ob ein Vorfall dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten zu melden ist, behandelt derselbe Beitrag im Abschnitt zur Meldepflicht. Gut ist, wer dafür eine Sicherung ausserhalb des Servers hat; wie man sie einrichtet, beschreibt der Beitrag zum Einrichten von Backups.

Wenn Sie nicht sicher sind, ob Ihre Website in den letzten Tagen angreifbar war, oder wenn Sie Auffälligkeiten sehen, helfen wir Ihnen weiter. In einer Erstdiagnose sehen wir uns Server, Protokolle und Dateien an und sagen Ihnen, ob eine Bereinigung nötig ist und was sie umfasst. Schreiben Sie uns über das Kontaktformular.

Fazit

PHP2Shell ist keine WordPress-Lücke, trifft WordPress-Websites aber genauso hart. Die Korrektur liegt beim Betreiber des Servers, und die Versionsnummer im Website-Zustand gibt darauf keine verlässliche Antwort. Wer eine Website betreibt, holt deshalb heute eine klare Auskunft beim Hoster ein. Wer angreifbar war, sucht nach Spuren und wechselt seine Zugangsdaten, auch wenn er nichts findet. Wer auf PHP 8.1 oder älter sitzt, hat jetzt einen konkreten Anlass für den Wechsel, denn die nächste Lücke dieser Art wird für diese Versionen wieder niemand schliessen.

Häufige Fragen zu PHP2Shell

Muss ich in WordPress etwas aktualisieren?

Für diese Lücken nicht. Die Korrektur steckt ausschliesslich in PHP. WordPress und Plugins aktuell zu halten, bleibt trotzdem richtig, nur schützt es hier nicht.

Meine Website läuft auf PHP 7.4. Bin ich betroffen?

Nach Angaben von Wiz ja. Das PHP-Projekt liefert für 7.4 kein Update mehr, nur eine Quellcode-Korrektur für Administratoren, die PHP selbst kompilieren. Geschützt sind Sie nur, wenn Ihr Hoster oder Ihre Distribution die Korrektur nachgerüstet hat. Fragen Sie nach, und planen Sie den Wechsel auf eine unterstützte Version.

Schützt mich ein Sicherheits-Plugin wie Wordfence?

Nicht zuverlässig. Ein Plugin läuft selbst in PHP und kommt erst zum Zug, nachdem PHP die Anfrage verarbeitet hat. Beim vorgeführten Angriff über mod_php wirkt der Angriff, bevor überhaupt Code der Website ausgeführt wird. Ein vorgeschalteter Filter wie der von Cloudflare kann bekannte Angriffsmuster abfangen, ersetzt das Update aber nicht.

Was ist der Unterschied zu wp2shell?

wp2shell war im Juli 2026 eine Lücke in WordPress selbst und wurde mit einem WordPress-Update geschlossen. PHP2Shell steckt in PHP und betrifft damit jede Anwendung, die darauf läuft. Gemeinsam ist beiden nur der Name, der auf dasselbe Ergebnis verweist: eine Shell, also Befehlszugriff auf den Server.

Sind auch Onlineshops und andere Systeme betroffen?

Ja. WooCommerce läuft auf WordPress und damit auf PHP, ebenso Magento, Shopware, Drupal, Joomla, Nextcloud und viele Verwaltungsoberflächen. Das BACS weist darauf hin, dass PHP auch in Geräten und gekaufter Software stecken kann, ohne dass es nach aussen sichtbar ist.

Mein Hoster sagt, er habe aktualisiert. Muss ich trotzdem etwas tun?

Fragen Sie nach dem Zeitpunkt. Lag er erst am 21. Oktober abends oder später, war Ihre Website einige Zeit angreifbar, während bereits Angriffsversuche liefen. Dann lohnt sich ein Blick auf Konten und Dateien, und Zugangsdaten mit Zugriff auf Zahlungs- oder Kundendaten sollten Sie wechseln.

Quellen

PHP-Projekt: Security advisory: Critical remote code execution vulnerabilities, update now ↗ — Meldung vom 21. Oktober 2026 und Vorankündigung vom 20. Oktober; Quelle für die korrigierten Versionen, die betroffenen Betriebsarten, die Quellcode-Korrekturen für 7.4 bis 8.1 und alle Übergangsmassnahmen
PHP-Projekt: Sicherheitshinweis GHSA-w8hw-w9fx-j79w (CVE-2026-109618) ↗ — Quelle für die Beschreibung des Speicherfehlers, die Bewertung 9,2 nach CVSS 4.0 und die Einschätzung zu mod_php, PHP-FPM, FrankenPHP und LiteSpeed
PHP-Projekt: Sicherheitshinweis GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) ↗ — Quelle für den bestätigten Weg über fatal_error_backtraces unter PHP 8.5 und die weiteren Auslöser
Bundesamt für Cybersicherheit BACS: Kritische Schwachstellen in PHP: Sicherheitsupdates sofort einspielen ↗ — Warnung vom 21. Oktober 2026; Quelle für die Hinweise zu Neustart, nachgerüsteten Paketen, eingebettetem PHP, vorübergehender Abschaltung und Web Application Firewalls
Wiz Research: PHP2Shell ↗ — Quelle für die Vorführung am Docker-Image von WordPress, das Auslesen von Arbeitsspeicher, die betroffenen Versionen ab PHP 5.4, die Rolle der KI-Modelle und die Erkennungsmerkmale
Sansec: PHP2Shell ↗ — Quelle für die von Calif angegriffenen Anwendungen einschliesslich WordPress 7.1.2, den Zeitablauf der Meldungen ab August und die Erwartung massenhafter Angriffe
Cloudflare: Cloudflare deploys protections against php2shell vulnerability ↗ — Quelle für den beobachteten Angriffsverkehr, die Freischaltung der Regeln um 03:02 UTC und die Aussage, dass Updates der Website die Lücke nicht schliessen
Patchstack: Major security alert: PHP vulnerable to critical RCE ↗ — laufend nachgeführter Bericht vom 21. Oktober 2026; Quelle für den Stand um 13:57 UTC, die Warnung vor Fix-Plugins und die Erkennungsmerkmale
watchTowr: PHP2Shell: PHP Remote Code Execution Exploited ↗ — veröffentlicht am 21. Oktober 2026 um 14:19 UTC; Quelle für die beobachteten Angriffsversuche auf beide Lücken
BleepingComputer: PHP warns admins of two critical flaws, emergency patches coming tomorrow ↗ — Bericht vom 20. Oktober 2026; Quelle für den Leak und die Einstufung mit 10,0, die nicht vom PHP-Projekt stammt
cyon: Statusmeldung vom 21. Oktober 2026 ↗ — Quelle für die Abschaltung um 15:45 Uhr und die erwartete Wiederinbetriebnahme im Lauf der Nacht
Ubuntu: CVE-2026-109618 ↗ und Debian Security Tracker: CVE-2026-109618 ↗ — Quelle für die korrigierten Paketversionen der Distributionen
wordpress.org: Statistik der PHP-Versionen ↗ — abgerufen am 21. Oktober 2026; Quelle für die Anteile von PHP 8.1 und älter (36,4 Prozent) und PHP 7.4 (16,1 Prozent)

Stand: 21. Oktober 2026, abends. Die Anzeige der PHP-Version unter Ubuntu 24.04 haben wir am selben Tag in einem Testcontainer geprüft, die Angaben zu unserer eigenen Website beruhen auf ihren Zugriffsprotokollen und der laufenden PHP-Version. Werden erfolgreiche Einbrüche über PHP2Shell belegt oder weitere Angriffswege bekannt, ergänzen wir diesen Beitrag.