Am 21. Oktober 2026 hat das PHP-Team Notfall-Updates 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 einem Webserver ausführen. Betroffen ist nicht ein einzelnes Plugin oder ein bestimmtes System, sondern PHP selbst – die Sprache, auf der WordPress, die meisten Onlineshops und unzählige weitere Websites laufen. Das PHP-Team rät allen Nutzern, sofort zu aktualisieren.
Für Betreiber stellen sich jetzt drei Fragen: Ist meine Seite betroffen? Was muss ich selbst tun und was erledigt mein Hoster? Und was mache ich, wenn die Seite nach dem Update nicht mehr richtig läuft? Dieser Beitrag beantwortet alle drei – mit einem Versions-Check zum Ausprobieren.
Was hinter PHP2Shell steckt
PHP2Shell besteht aus zwei Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Das PHP-Team bewertet beide nach dem Standard CVSS 4.0 mit 9,2 von 10 Punkten. Das liegt in der höchsten Stufe „kritisch“ und bedeutet: Ein Angriff ist aus der Ferne möglich, braucht kein Konto auf der Website und endet damit, dass fremder Code auf Ihrem Server läuft.
Technisch geht es um die Art, wie PHP Speicher für eine Anfrage verwaltet. Bei der ersten Lücke kann PHP mitten in der Verarbeitung einer Anfrage den Speicher verlieren, während die Anfragedaten nur teilweise vorbereitet sind – beim Aufräumen werden dann ungültige Daten wie gültige behandelt. Bei der zweiten kann ein Zustand aus einer Anfrage übrig bleiben, obwohl sein Speicher schon freigegeben ist, und eine spätere Anfrage im selben Prozess greift darauf zu. Für Angreifer sind beide Fehler ein Weg, eigenen Code einzuschleusen.
Die Lage ist ernst, weil es nicht bei der Theorie bleibt. Laut Help Net Security hat Amazons Sicherheitsteam bereits am 17. Oktober einen Angriffsversuch registriert – vier Tage, bevor die Lücke öffentlich wurde. Ein funktionierender Exploit existiert. Das britische Cyber-Sicherheitszentrum NCSC rät sogar, Systeme, die sich nicht sofort aktualisieren lassen, notfalls vom Netz zu nehmen.
Welche PHP-Versionen abgesichert sind
Die Korrekturen stecken in vier neuen Versionen. Alles darunter ist angreifbar.
| Versionsreihe | Abgesichert ab | Hinweis |
|---|---|---|
| PHP 8.5 | 8.5.12 | |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Sicherheitsupdates nur noch bis 31.12.2026 |
| PHP 8.1, 8.0, 7.4 und älter | keine regulären Updates | nur Minimal-Korrekturen für selbst kompilierte Installationen |
Für die alten Versionen 7.4, 8.0 und 8.1 hat das PHP-Team zwar kleine Korrekturen bereitgestellt. Die richten sich aber an Server, auf denen PHP selbst aus dem Quellcode gebaut wird. Bei normalen Hosting-Paketen kommen sie in der Regel nicht an. Wer dort noch eine dieser Versionen nutzt, wird mit dem Umstieg auf eine gepflegte Version sicher – nicht anders.
$ php -v
PHP2Shell-CheckStand der Korrekturen laut php.net vom 21.10.2026: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35
Bin ich betroffen? Es kommt darauf an, wo Ihre Seite läuft
Betroffen ist jede PHP-Installation, die Webanfragen beantwortet – egal ob WordPress, ein Shop oder eine eigene Anwendung. Am größten ist das Risiko laut PHP-Team bei Apache mit mod_php, betroffen sind aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. Was Sie tun müssen, hängt davon ab, wer Ihren Server betreibt.
Hosting-Paket
Bei klassischem Webhosting spielt in der Regel der Hoster das Sicherheitsupdate ein – Sie müssen dafür nichts installieren. Das gilt aber nur für Versionen, die noch gepflegt werden. Prüfen Sie deshalb, welche PHP-Version für Ihre Seite eingestellt ist. Steht dort 8.1 oder älter, bleibt Ihre Seite offen, bis Sie auf eine neuere Version umstellen. Fragen Sie im Zweifel beim Hoster nach, welcher Patchstand auf Ihrem Server läuft.
Eigener Server, VPS oder Docker
Wer einen eigenen Server, einen virtuellen Server oder Docker-Container betreibt, muss selbst aktualisieren – über die Sicherheitspakete der Linux-Distribution oder ein neues Container-Image mit einer abgesicherten PHP-Version. Danach müssen alle PHP-Prozesse neu gestartet werden, sonst läuft der alte Code weiter.
Alte PHP-Version im Einsatz
Der eigentliche Aufwand entsteht bei Seiten, die noch auf PHP 7.4, 8.0 oder 8.1 laufen. Der Sprung auf 8.3 oder 8.4 ist kein Knopfdruck: Alte Plugins, Themes und selbst geschriebener Code nutzen oft Funktionen, die es in neuen Versionen nicht mehr gibt. Dann bricht die Seite nach dem Umstieg mit einem Fehler ab. Deshalb lohnt es sich, den Wechsel zuerst auf einer Kopie der Seite zu testen.
So finden Sie Ihre PHP-Version heraus
- In WordPress: Werkzeuge → Website-Zustand → Bericht → Abschnitt „Server“. Dort steht die PHP-Version mit allen drei Stellen.
- Im Hosting: Im Kundenmenü Ihres Hosters unter den PHP-Einstellungen der Domain. Manche Hoster zeigen dort nur die Versionsreihe (etwa 8.3), nicht den Patchstand – dann hilft eine Nachfrage.
- Auf dem eigenen Server: mit dem Befehl
php -v. Beachten Sie, dass die Version auf der Kommandozeile von der abweichen kann, die der Webserver nutzt.
Legen Sie für die Prüfung keine öffentliche phpinfo-Datei auf den Server, oder löschen Sie sie sofort wieder. Sie verrät Angreifern genau die Details, die sie suchen.
Was jetzt zu tun ist
- Version prüfen. Stellen Sie fest, welche PHP-Version und welcher Patchstand auf dem Server laufen, auf dem Ihre Seite liegt.
- Sichern. Vor jeder Änderung eine vollständige Sicherung von Dateien und Datenbank anlegen – getrennt vom Server.
- Aktualisieren oder umsteigen. Auf eine abgesicherte Version aktualisieren oder, bei alten Versionen, auf PHP 8.3 oder 8.4 umstellen. Den Umstieg vorher auf einer Kopie testen.
- Prüfen, ob schon jemand drin war. Weil es Angriffe vor dem Update gab, ist ein frisch gepatchter Server nicht automatisch sauber.
- Dranbleiben. PHP 8.2 bekommt nur noch bis Ende 2026 Sicherheitsupdates. Wer jetzt ohnehin anfasst, plant den nächsten Schritt gleich mit.
Übergangsmaßnahmen, falls das Update warten muss
Für Server, die sich nicht sofort aktualisieren lassen, nennt das PHP-Team Übergangsmaßnahmen. Dazu gehört, in der php.ini oder im FPM-Pool session.upload_progress.enabled=0 zu setzen und alle PHP-Prozesse neu zu starten, unter PHP 8.5 zusätzlich fatal_error_backtraces=0, sowie post_max_size zu senken, wenn keine großen Uploads nötig sind. Das PHP-Team betont aber: Diese Maßnahmen verringern das Risiko, machen eine Installation jedoch nicht sicher – nur das Update tut das. Wer Cloudflare nutzt, bekommt laut Help Net Security erste Schutzregeln gegen bekannte Angriffswege, auch im kostenlosen Tarif. Auch das ersetzt das Update nicht.
Wenn die Seite nach dem PHP-Update kaputt ist
Gerade nach einem Versionssprung tauchen typische Meldungen auf: „Es gab einen kritischen Fehler auf dieser Website“, ein weißer Bildschirm, „HTTP ERROR 500“ oder Warnungen mit dem Wort „Deprecated“ mitten auf der Seite. Dahinter steckt fast immer Code, der mit der neuen PHP-Version nicht mehr zurechtkommt – meist ein veraltetes Plugin oder Theme.
Die naheliegende Reaktion ist, PHP wieder auf die alte Version zurückzustellen. Das bringt die Seite zwar zurück, lässt sie aber offen für genau den Angriff, um den es geht. Besser ist es, den Verursacher zu finden: WordPress schickt bei einem kritischen Fehler oft eine Mail mit einem Link in den Wiederherstellungsmodus an die Admin-Adresse, und das Fehlerprotokoll nennt Datei und Zeile. Dann lässt sich gezielt das eine Plugin aktualisieren, ersetzen oder reparieren. Wie Sie einen Fehler so beschreiben, dass er schnell gelöst wird, zeigt der Beitrag WordPress-Fehler richtig melden.
Woran Sie einen Einbruch erkennen
Ein Angriff über eine Lücke wie PHP2Shell hinterlässt oft Spuren, die im Alltag niemandem auffallen. Achten Sie auf diese Hinweise:
- neue oder unbekannte Administrator-Konten in WordPress
- PHP-Dateien im Upload-Ordner, wo eigentlich nur Bilder liegen
- Dateien mit auffällig neuem Änderungsdatum, die Sie nicht angefasst haben
- Weiterleitungen auf fremde Seiten, oft nur für Besucher, die über Google kommen
- Spam-Seiten in den Suchergebnissen oder eine Warnung von Google
- eine plötzlich hohe Serverlast oder eine Sperre des Mailversands durch den Hoster
Sicher sagt es nur eine Prüfung von Dateien, Datenbank und Protokollen. Löschen Sie bei einem Verdacht nichts auf eigene Faust: Die Spuren zeigen, wie der Angreifer hereingekommen ist, und ohne diese Information kommt er wieder.
Was das für WordPress-Betreiber bedeutet
WordPress selbst hat in diesem Fall keine Lücke. Die Schwachstelle steckt eine Ebene tiefer in PHP, deshalb kann auch ein Sicherheits-Plugin sie nicht schließen. Entscheidend ist allein die PHP-Version auf dem Server. Die Lücke zeigt aber ein Muster, das wir bei der WordPress-Fehlerbehebung immer wieder sehen: Seiten laufen jahrelang auf einer alten PHP-Version, weil der Umstieg ein Plugin zerlegen könnte. Irgendwann wird aus dem aufgeschobenen Update ein Notfall. Regelmäßige WordPress-Wartung mit getesteten Updates verhindert genau das.
Häufige Fragen
Muss ich bei Shared Hosting selbst etwas tun?
Das Sicherheitsupdate spielt in der Regel der Hoster ein. Prüfen Sie aber, welche PHP-Version für Ihre Seite eingestellt ist: Für 8.1 und älter gibt es keine regulären Updates mehr, dann hilft nur der Umstieg auf eine neuere Version.
Ist nur WordPress betroffen?
Nein. Betroffen ist jede PHP-Installation, die Webanfragen beantwortet – also auch Onlineshops, andere Content-Management-Systeme und selbst geschriebene PHP-Anwendungen.
Schützt mich ein Sicherheits-Plugin?
Nein. Die Lücke steckt in PHP selbst, nicht in WordPress oder einem Plugin. Ein Plugin kann sie deshalb nicht schließen – Schutz bietet nur eine abgesicherte PHP-Version.
Reicht eine Übergangslösung?
Die Übergangsmaßnahmen des PHP-Teams senken das Risiko, machen eine Installation aber nicht sicher. Das PHP-Team schreibt selbst, dass das Update der einzige sichere Weg ist.
Meine Seite ist nach dem Umstieg kaputt – soll ich zurückstellen?
Nur kurzfristig, um die Seite wieder erreichbar zu machen. Dauerhaft auf einer angreifbaren Version zu bleiben, ist riskanter als der Fehler selbst. Besser ist es, das Plugin oder Theme zu finden, das den Fehler auslöst, und es zu aktualisieren oder zu ersetzen.
Wie erkenne ich, ob meine Seite schon angegriffen wurde?
Hinweise sind unbekannte Admin-Konten, neue PHP-Dateien im Upload-Ordner, kürzlich geänderte Dateien und Weiterleitungen auf fremde Seiten. Sicherheit bringt nur eine Prüfung von Dateien, Datenbank und Protokollen.
Quellen: php.net, Security Releases vom 21. Oktober 2026; Help Net Security vom 21. und 22. Oktober 2026. Stand dieses Beitrags: 22. Oktober 2026.
