Am Dienstagabend, dem 20. Oktober, sind Details zu zwei Sicherheitslücken in PHP öffentlich geworden, die eigentlich noch unter Verschluss waren. PHP ist die Programmiersprache, in der WordPress geschrieben ist, und sie läuft auf praktisch jedem Webserver, der eine WordPress-Seite ausliefert. Die Lücken stecken also nicht in einem Plugin oder im Theme, sondern eine Ebene tiefer: in der Software, die den Code Ihrer Website überhaupt erst ausführt.
Seit Mittwoch, 16 Uhr, gibt es die Korrektur. Dieser Artikel erklärt ohne Fachchinesisch, was passiert ist, wer sich kümmern muss und wie Sie in zwei Minuten nachsehen, ob Ihre Website schon sicher ist.
Das Wichtigste in Kürze
- Zwei kritische Lücken im Kern von PHP, zusammen „PHP2Shell“ genannt (CVE-2026-109618 und CVE-2026-109619), Schweregrad 9,2 von 10. Angreifer können damit ohne Login Code auf dem Server ausführen.
- Betroffen ist praktisch jede Website, die mit PHP läuft, also auch jede WordPress-Seite. Ein aktuelles WordPress schützt nicht, weil der Fehler unterhalb von WordPress liegt.
- Sicher sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12, alle vom 21. Oktober 2026. Für PHP 8.1 und älter gibt es kein offizielles Update mehr.
- Bei Shared Hosting kann nur der Hoster PHP aktualisieren. Ihre Aufgabe ist, die Version zu prüfen und nachzufragen, nicht abzuwarten.
- Angriffe laufen bereits. Cloudflare hat Angriffsverkehr beobachtet, das BSI rechnet mit großflächiger Ausnutzung innerhalb weniger Stunden.
Was am 20. und 21. Oktober passiert ist
Normalerweise läuft so etwas still ab: Sicherheitsforscher melden eine Lücke, die Entwickler bauen die Korrektur, und erst wenn das Update bereitsteht, erfahren alle anderen davon. Diesmal ist die Reihenfolge durcheinandergeraten. Am Dienstagnachmittag tauchte auf der Plattform Hacker News ein Beitrag mit Details auf, dazu Screenshots eines Angriffswerkzeugs namens „PHP2Shell“. Der Beitrag war schnell wieder weg, die Screenshots nicht.
Das PHP-Sicherheitsteam reagierte noch am selben Abend und zog die Veröffentlichung der Korrektur um einen Tag vor: Mittwoch, 16 Uhr deutscher Zeit. Am Mittwochmittag warnte das BSI mit der zweithöchsten Stufe („orange“) und riet, die Updates sofort nach Erscheinen einzuspielen. Cloudflare, dessen Firewall vor vielen Websites sitzt, hatte seine Schutzregeln bereits um 5 Uhr morgens scharf geschaltet und meldete im Lauf des Tages, dass Angreifer die Lücken bereits ausprobieren und ihre Anfragen gezielt verändern, um Filter zu umgehen. Einige Kommunen und Unternehmen nahmen ihre Websites vorsorglich vom Netz.
Um 16 Uhr kamen die korrigierten PHP-Versionen. Seitdem gilt: Wer gepatcht ist, ist sicher. Wer nicht, ist es nicht.
Technisch geht es bei beiden Lücken um dasselbe Muster. Bricht PHP eine Anfrage mitten in der Verarbeitung ab, etwa weil der Arbeitsspeicher voll läuft, arbeitet es danach mit Daten weiter, die nur halb angelegt oder schon wieder freigegeben sind. Eine gezielt präparierte Anfrage reicht, um diesen Abbruch auszulösen. Entdeckt wurden die Lücken von Calif.io, Wiz, OpenAI und Quarkslab; betroffen sind nach deren Angaben alle PHP-Versionen seit 5.4, also alles, was in den letzten rund 14 Jahren auf einem Webserver gelaufen ist.
Warum das jede WordPress-Seite betrifft, auch gepflegte
Eine Website besteht aus mehreren Schichten. Ganz oben liegt das, was Sie kennen: WordPress, Ihr Theme, die Plugins, Ihre Inhalte. Darunter läuft PHP und führt den ganzen Code aus. Darunter wiederum der Webserver und das Betriebssystem. Eine Lücke in einem Plugin betrifft nur die Seiten, die dieses Plugin nutzen. Eine Lücke in PHP betrifft alles, was darüber liegt.
Deshalb hilft es diesmal nicht, WordPress und Plugins aktuell zu halten. Das PHP-Team beschreibt für die am weitesten verbreitete Betriebsart (Apache mit mod_php) sogar einen Angriff, der abläuft, bevor WordPress überhaupt gestartet ist. Die Anfrage kommt an, PHP stolpert, der Angreifer ist drin, und Ihre Website hat noch keine einzige Zeile Code ausgeführt. Kein Sicherheits-Plugin kann an dieser Stelle eingreifen, weil es noch gar nicht läuft.
Was ein Angreifer damit anfangen kann: Im schlimmsten Fall legt er eine sogenannte Webshell ab, eine kleine Datei, über die er den Server dauerhaft fernsteuert. Das PHP-Update schließt zwar die Tür, entfernt aber keine Hintertür, die vorher schon eingebaut wurde. Nach Angaben der Entdecker lässt sich über eine der beiden Lücken außerdem der Arbeitsspeicher des PHP-Prozesses auslesen. Dort können Passwörter, Sitzungsdaten und Schlüssel anderer Besucher liegen.
Wer die Lücke schließen kann
Die Korrektur muss auf dem Server eingespielt werden, in PHP selbst. Wer das tun kann, hängt davon ab, wie Ihre Website gehostet ist:
- Shared Hosting (die meisten Webhosting-Pakete für kleine und mittlere Unternehmen): Hier teilen sich viele Websites einen Server, und der Hoster verwaltet PHP. Nur er kann das Update einspielen. Sie können aber prüfen, ob er es getan hat, und Sie können in den meisten Kundenbereichen selbst festlegen, welche PHP-Version Ihre Website nutzt.
- Eigener Server (VPS, Dedicated, Docker-Container): Hier sind Sie oder Ihr Dienstleister zuständig. Das Update muss eingespielt und PHP danach neu gestartet werden, sonst läuft der alte Code im Speicher weiter.
- Baukasten (Wix, Jimdo, Squarespace): Der Anbieter kümmert sich, Sie können nichts tun.
Eine Firewall wie die von Cloudflare senkt das Risiko, weil sie bekannte Angriffsmuster abfängt. Cloudflare selbst schreibt aber, dass Angreifer ihre Anfragen laufend verändern, und rät ausdrücklich, trotzdem zu patchen. Das PHP-Team ist noch deutlicher: Es gibt keine vollständige Übergangslösung, nur das Update ist sicher.
So finden Sie in zwei Minuten heraus, ob Ihre Website sicher ist
Sie müssen dafür nichts installieren und niemanden anrufen. Es gibt drei Wege, vom einfachsten zum genauesten. Einer reicht.
1. In WordPress nachsehen. Melden Sie sich im Backend an und gehen Sie auf Werkzeuge → Website-Zustand → Reiter „Bericht“ → Abschnitt „Server“. Dort steht die PHP-Version, mit der Ihre Seite gerade läuft, zum Beispiel „8.3.36“. Vergleichen Sie die Zahl mit der Tabelle unten.
2. Beim Hoster nachsehen. Bei den meisten Hostern heißt der Punkt im Kundenbereich „PHP-Einstellungen“ oder „PHP-Version“. Dort sehen Sie, welche Version gewählt ist, und können sie in der Regel auch selbst umstellen.
3. Mit einer Prüfdatei. Das ist der einzige Weg, der wirklich zeigt, was der Webserver ausführt, und nicht, was irgendwo eingestellt ist. Legen Sie per FTP im Hauptverzeichnis Ihrer Website eine Datei mit zufälligem Namen an, etwa pruef-x7k2q.php, mit diesem Inhalt:
<?php echo PHP_VERSION;Rufen Sie die Datei im Browser auf (ihre-domain.de/pruef-x7k2q.php). Sie sehen die Version. Löschen Sie die Datei danach sofort. Sonst verrät sie jedem, der sie findet, Ihre Serverkonfiguration.
Welche Version sicher ist
| PHP-Zweig | Sicher ab | Was zu tun ist |
|---|---|---|
| 8.5 | 8.5.12 | Hoster spielt das Update ein; prüfen, ob es da ist |
| 8.4 | 8.4.27 | Hoster spielt das Update ein; prüfen, ob es da ist |
| 8.3 | 8.3.36 | Hoster spielt das Update ein; prüfen, ob es da ist |
| 8.2 | 8.2.35 | Wie oben; dieser Zweig läuft am 31.12.2026 aus, Wechsel auf 8.3 oder 8.4 ohnehin fällig |
| 8.1, 8.0, 7.4 | kein offizielles Update | Im Kundenbereich sofort auf 8.3 oder 8.4 umstellen |
| 7.3 und älter | kein Update | Umstellen, und vorher mit Ihrem Dienstleister klären, ob die Website das verkraftet |
Zwei Dinge sollten Sie dabei wissen. Erstens: Manche Hoster und Linux-Distributionen spielen die Korrektur ein, ohne dass sich die Versionsnummer ändert. Steht bei Ihnen also „8.3.35“, ist das nicht automatisch ein Alarm, sondern eine Frage an den Hoster: Ist der Patch vom 21. Oktober drin oder nicht? Zweitens: Wenn Ihre Seite noch auf 8.1 oder älter läuft, warten Sie nicht auf den Hoster. Dafür kommt kein Update mehr. Stellen Sie im Kundenbereich auf 8.3 oder 8.4 um und prüfen Sie danach kurz, ob die Seite noch normal aussieht und das Kontaktformular sendet. Bei einer gepflegten WordPress-Seite ist das in aller Regel unproblematisch, bei einer seit Jahren nicht angefassten Seite kann es haken. Dann lieber den Dienstleister fragen, aber heute, nicht nächste Woche.
Die Version anzusehen ist das eine. Patchen können Sie bei Shared Hosting nicht selbst. Ihre Aufgabe als Betreiber ist, nachzusehen, nachzufragen und nicht darauf zu vertrauen, dass sich schon jemand kümmert.
Keine Lust, selbst im Backend zu suchen? Auf unserer Übersichtsseite zu PHP2Shell können Sie sich 30 Minuten mit uns verabreden. Dann schauen wir uns Ihre Website gemeinsam per Video an und sagen Ihnen direkt, ob Sie etwas tun müssen.
Was wir für unsere Wartungskunden gerade tun
Wenn Ihre Website bei uns in der Wartung ist, müssen Sie nichts unternehmen. Wir gehen gerade folgendermaßen vor:
- Bestand erfassen. Wir gehen jede betreute Seite durch und notieren, welche PHP-Version sie tatsächlich nutzt.
- Alte Versionen sofort anheben. Seiten auf PHP 8.1 oder älter stellen wir auf einen unterstützten Zweig um und prüfen danach Darstellung und Formulare.
- Hoster in die Pflicht nehmen. Wo der Hoster PHP verwaltet, holen wir die Bestätigung ein, dass der Patch vom 21. Oktober eingespielt ist, und kontrollieren das mit einer Prüfdatei selbst.
- Eigene Server patchen. Systeme, die wir selbst betreiben, aktualisieren wir direkt und starten PHP neu.
- Nachsehen, ob jemand drin war. Für die Zeit seit dem 20. Oktober prüfen wir auf neue PHP-Dateien, neue Administrator-Konten und neue zeitgesteuerte Aufgaben auf dem Server. Wo eine Seite längere Zeit ungepatcht erreichbar war, tauschen wir vorsorglich Zugangsdaten und Schlüssel.
Sobald alles durch ist, bekommen Sie eine kurze Rückmeldung von uns, auch wenn nichts gefunden wurde.
Drei Fragen, die Sie morgen stellen sollten
Wenn sich jemand anderes um Ihre Website kümmert, eine Agentur, ein Freelancer oder die eigene IT, reicht eine kurze Mail mit diesen drei Fragen:
- Welche PHP-Version läuft auf unserer Website, und ist der Patch vom 21. Oktober drin? Eine klare Antwort ist eine Versionsnummer. „Wir schauen mal“ ist keine.
- Wann hat bzw. wann spielt unser Hoster das Update ein? Wenn Ihr Dienstleister das nicht weiß, weiß er auch nicht, ob Ihre Seite gerade offen steht.
- Wer prüft danach, ob in der Zwischenzeit jemand eingedrungen ist? Das Update schließt die Lücke. Eine Hintertür, die vorher eingebaut wurde, bleibt.
Wenn auf keine der drei Fragen eine Antwort kommt, haben Sie damit auch eine Antwort.
Häufige Fragen
Muss ich meine Website jetzt abschalten?
In der Regel nicht. Ist der Patch eingespielt, sind Sie sicher. Läuft Ihre Seite noch auf PHP 8.1 oder älter und lässt sich nicht sofort umstellen, kann eine vorübergehende Abschaltung oder ein Passwortschutz vor der ganzen Seite sinnvoll sein. Das BSI und das Notfallteam der EU-Institutionen nennen das ausdrücklich als Möglichkeit.
Reicht es, wenn ich WordPress und alle Plugins aktualisiere?
Nein. Die Lücke liegt in PHP, eine Ebene unter WordPress. Updates von WordPress, Theme und Plugins ändern daran nichts.
Meine Seite läuft hinter Cloudflare. Bin ich damit geschützt?
Teilweise. Cloudflare filtert bekannte Angriffsmuster seit dem frühen Morgen des 21. Oktober heraus, auch im kostenlosen Tarif. Angreifer verändern ihre Anfragen aber laufend, und Cloudflare rät selbst dazu, trotzdem zu patchen.
Woran erkenne ich, ob meine Seite schon angegriffen wurde?
Von außen meist gar nicht. Typische Spuren sind neue PHP-Dateien in Verzeichnissen, in denen sonst nur Bilder liegen, Administrator-Konten, die niemand angelegt hat, oder plötzlich auffälliger Datenverkehr. Wenn Sie unsicher sind, lassen Sie das prüfen, bevor Sie es ignorieren. Was im Ernstfall zu tun ist, beschreiben wir ausführlich im Ratgeber WordPress gehackt.
Sollte ich Passwörter ändern?
Wenn Ihre Seite längere Zeit ungepatcht im Netz war: ja. Über eine der beiden Lücken lässt sich der Arbeitsspeicher von PHP auslesen, und dort können Zugangsdaten liegen. Ändern Sie mindestens die WordPress-Administratorpasswörter und, falls vorhanden, gespeicherte Schlüssel für angebundene Dienste.
Mein Hoster sagt, er hat gepatcht, die Versionsnummer ist aber gleich geblieben. Stimmt das?
Das kann stimmen. Manche Hoster und Linux-Distributionen bauen die Korrektur in ihre eigenen PHP-Pakete ein, ohne die offizielle Versionsnummer zu übernehmen. Lassen Sie sich die Bestätigung schriftlich geben.
Kurzfassung, Versionstabelle und Terminbuchung finden Sie auf unserer Seite PHP2Shell: Ist Ihre Website betroffen?
Wenn Sie wissen möchten, in welchem Zustand Ihre Website insgesamt ist: Unser kostenloser Website-Check prüft von außen und ohne Zugangsdaten, wie aktuell WordPress und die eingesetzten Erweiterungen sind.