PHP-Sicherheitslücke php2shell: Warum diesmal kein WordPress-Update hilft

Stand: 22. Oktober 2026, 9 Uhr

Zwei Lücken in PHP bedrohen seit dieser Woche Websites auf der ganzen Welt. Über sie können Angreifer ohne Passwort die Kontrolle über eine Website übernehmen. In Österreich und Deutschland haben Universitäten, Unternehmen und ganze Hoster am Mittwoch deshalb vorsorglich ihre Systeme abgeschaltet, darunter die Universität Wien. Seit dem Nachmittag gibt es ein Update, und seither zählt Cloudflare Millionen Angriffsversuche.

PHP ist zweierlei. Zum einen ist es eine Programmiersprache, in der unter anderem WordPress und WooCommerce geschrieben sind. Zum anderen ist es das Programm, das diesen Code auf dem Server ausführt: Ruft jemand Ihre Website auf, setzt es die Seite zusammen und schickt sie an den Browser. Die Lücken stecken in diesem Programm und damit eine Schicht unter WordPress. Deshalb hilft diesmal kein Update von WordPress oder einem Plugin. Das PHP-Update spielt bei einer gewöhnlichen Unternehmenswebsite der Hoster ein, also das Unternehmen, das den Server betreibt. Ob es bei Ihrer Website ankommt, hängt aber an einer Einstellung, die Sie oder Ihre Agentur vielleicht vor Jahren gewählt haben: der PHP-Version.

Im Folgenden erklären wir, wie die Lücken funktionieren, warum manche abgeschaltet haben und warum das für Ihre Website jetzt meist nicht mehr nötig ist, was Cloudflare und KI mit der Sache zu tun haben und was Sie heute prüfen sollten.

Was ist passiert?

Die beiden Lücken sind unter dem Spitznamen „php2shell“ bekannt (Kennungen CVE-2026-109618 und CVE-2026-109619). Laut BSI, der deutschen Bundesbehörde für IT-Sicherheit, erlauben sie Remote Code Execution: Ein Angreifer kann aus der Ferne eigenen Programmcode auf dem Server ausführen, ohne Passwort und ohne dass jemand etwas anklicken muss. Damit kann er laut ORF die Website übernehmen und Kundendaten abgreifen. Der Fehler steckt in dem Teil von PHP, der hochgeladene Formulardaten verarbeitet, also zum Beispiel ein Bild im Kontaktformular. Ein Angreifer schickt ein präpariertes Formular, und PHP gerät beim Verarbeiten in einen Zustand, in dem es fremden Code ausführt. Nach Angaben des PHP-Sicherheitsteams steckt der Fehler seit PHP 5.4 in der Software, also seit 2012.

Die Lücken sollten geordnet veröffentlicht werden: zuerst das Update, dann die Details. Am 20. Oktober tauchten die Details aber vorzeitig in einem Internetforum auf, dazu ein Video, das einen Angriff zeigt, ein sogenannter Leak. Das PHP-Projekt zog das Update daraufhin um einen Tag vor, auf Mittwoch, 16 Uhr. In den Stunden davor meldeten Cloudflare und der Sicherheitsdienst Patchstack bereits die ersten Angriffe. Nach der Veröffentlichung ging es schnell: Cloudflare-Chef Matthew Prince sprach am späten Mittwochabend von Zehntausenden Angriffsversuchen nach 45 Minuten, Hunderttausenden nach zwei Stunden und zuletzt von Millionen. Der österreichische Hoster Anexia bestätigte dem ORF Angriffsversuche auf seine eigenen Websites. Ab jetzt muss also jede Website damit rechnen, dass jemand die Lücke bei ihr ausprobiert.

Warum hilft ein WordPress-Update nicht?

WordPress ist ein Programm, das auf PHP aufsetzt. Ein Update von WordPress oder einem Plugin ändert nur dieses Programm, PHP darunter bleibt, wie es ist. Aus demselben Grund helfen Sicherheits-Plugins nicht: Sie arbeiten innerhalb von WordPress, die Lücke liegt eine Schicht tiefer. Zuständig für PHP ist, wer den Server betreibt.

Warum haben die Universitäten abgeschaltet?

Bis Mittwochnachmittag gab es kein Update, das man hätte einspielen können. Das BSI rät für diese Lage, Server vom Netz zu nehmen, die sich nicht sofort absichern lassen. CERT.at, das österreichische Computer-Notfallteam, hatte schon am Dienstag geraten, sich auf das Update vorzubereiten. Die Universitäten sind dem gefolgt, und einige Hoster ebenso: Mittwald und netcup in Deutschland haben am Mittwoch ihre gesamten Hosting-Systeme vorsorglich abgeschaltet und erst nach dem Update am späten Abend wieder eingeschaltet.

Abschalten heißt, ein paar Stunden Ausfall gegen das Risiko eines Einbruchs zu tauschen. Für eine Universität fällt diese Rechnung klar aus. Die Universität Wien betreibt ihre Server selbst, auf ihnen laufen viele Anwendungen mit PHP, und über sie gehen Daten von zehntausenden Studierenden und Beschäftigten. Ihr eigenes IT-Team muss jede dieser Anwendungen aktualisieren und danach prüfen. Ein paar Stunden ohne Lernplattform und Webmail sind dagegen ein überschaubarer Preis. Angriffe auf ihre Systeme hat die Universität nach eigenen Angaben nicht festgestellt.

Auch Ihre Website war bis zum Update angreifbar, wenn sie auf PHP läuft. Ob sich ein Abschalten am Mittwoch gelohnt hätte, hing davon ab, was auf ihr liegt, bei einem Shop etwa Kundenkonten und Bestellungen. Jetzt ist das Update aber da, und die Frage hat sich verschoben. Bei einer Website in einem Hosting-Paket spielt der Hoster das Update für alle seine Kund:innen ein. Abschalten müssen Sie deshalb in aller Regel nicht mehr. Wichtig ist, ob Ihre PHP-Version das Update überhaupt bekommt, und bei einem Shop zusätzlich, ob in den Stunden davor jemand eingedrungen ist. Beides erklären wir in den nächsten Abschnitten.

Wer ist bei Ihnen zuständig?

Die meisten Websites kleinerer Unternehmen liegen in einem Hosting-Paket, für das sie dem Hoster einen monatlichen Betrag zahlen. Der Hoster betreibt den Server und spielt das PHP-Update von sich aus ein. Welche PHP-Version für Ihre Website gilt, legt er aber nicht selbst fest. Das tut, wer das Hosting-Paket verwaltet, über eine Einstellung im Kundenbereich des Hosters, also im Konto, in dem auch die Rechnungen und die Domain stehen. Bei vielen Websites hat das die Agentur bei der Einrichtung erledigt, und seither hat niemand mehr nachgesehen.

Wer bei Ihnen zuständig ist, hängt deshalb davon ab, wer das Hosting verwaltet. Kümmert sich eine Agentur laufend um Ihre Website, ist sie Ihre erste Ansprechpartnerin. Hat die Agentur die Website nur gebaut, wenden Sie sich an den Hoster. Er sagt Ihnen auch, ob Sie selbst Zugang zum Kundenbereich haben. Läuft die Website auf einem eigenen Server, den Sie oder ein Dienstleister verwalten, liegt das ganze Update bei dieser Stelle.

Wer Shopify, Wix oder Squarespace nutzt, hat keinen eigenen Server und keine eigene PHP-Version. Dort kümmert sich der Anbieter um alles.

Wie Sie Ihre PHP-Version finden und lesen

Melden Sie sich als Administrator:in in WordPress an und öffnen Sie Werkzeuge → Website-Zustand → Bericht. Dort klappen Sie den Abschnitt „Server“ auf. In der Zeile „PHP-Version“ steht eine Nummer wie 8.3.36. Die Zahl vor dem zweiten Punkt (8.3) ist die Versionsreihe, die Zahl danach (36) der Stand innerhalb dieser Reihe. Für die Reihen 8.2 bis 8.5 hat das PHP-Projekt am Mittwoch neue Stände veröffentlicht, die das Update enthalten:

Steht bei Ihnen eine der Reihen 8.2 bis 8.5, aber mit einem älteren Stand als in der Tabelle, etwa 8.3.30, ist das Update wahrscheinlich noch nicht angekommen. Manche Hoster bauen es allerdings ein, ohne die Nummer zu ändern. In diesem Fall fragen Sie Ihren Hoster, ob das Update für php2shell bei Ihrer Website eingespielt ist. Das ist eine Frage, die jeder Hoster in dieser Woche kennt.

Bei den Reihen 7.4 bis 8.1 ist die Lage unübersichtlicher. Diese Versionen bekommen seit Jahren keine Updates mehr, deshalb gibt es auch jetzt kein offizielles. Zwei PHP-Entwickler haben aber den erwähnten Notbehelf veröffentlicht, eine Korrektur am Quellcode, die ein Hoster selbst in seine alten PHP-Versionen einbauen kann. Manche tun das: Hetzner hat am Mittwochabend auch 7.4 und 8.0 abgesichert, Uberspace hat alle Kund:innen auf 8.1 kurzerhand auf 8.2 umgestellt. Ob Ihr Hoster dazugehört, erfahren Sie nur bei ihm. Sagt er Nein oder antwortet er nicht, lassen Sie umstellen. Laut dem Fachmagazin Dr. Web lief vor dieser Woche gut ein Drittel aller WordPress-Websites auf PHP 8.1 oder älter. WordPress selbst empfiehlt PHP 8.3.

Was beim Umstellen zu beachten ist

Technisch ist das Umstellen eine Auswahl im Kundenbereich des Hosters. Ältere Plugins oder Themes vertragen eine neue Version aber nicht immer, und dann zeigt die Website Fehler oder bleibt weiß. Deshalb sollte das jemand machen, der die Website kennt und gleich danach prüft, ob alles läuft: Ihre Agentur, wenn sie die Website betreut, sonst der Hoster, dessen Support das auf Anfrage oft übernimmt. Verwalten Sie das Hosting selbst und trauen Sie sich das zu, stellen Sie um und rufen danach Startseite und Kontaktformular auf, bei einem Shop auch eine Produktseite, den Warenkorb und die Kasse bis zur Zahlungsseite. Bleibt etwas hängen, braucht die Website rasch Hilfe von Hoster oder Agentur. Das ist ärgerlich, aber eine Website mit Fehler ist das kleinere Problem als eine, die sich übernehmen lässt.

Für Shops kommt ein Schritt dazu. Angreifer suchen dort gezielt nach Zahlungsdaten, und Sansec, eine auf Onlineshops spezialisierte Sicherheitsfirma, rechnet mit Massenangriffen auf ungepatchte Shops. Lassen Sie deshalb in den nächsten Tagen von Hoster oder Agentur prüfen, ob auf dem Server unbekannte Dateien aufgetaucht sind und ob die Kasse unverändert ist. Gesucht wird dabei vor allem nach einem Skimmer, also eingeschleustem Code, der Zahlungsdaten bei der Eingabe mitliest. War die Website länger ungepatcht erreichbar, gehört auch ein Wechsel der Passwörter für WordPress, Datenbank und Hosting dazu. Über die Lücke lässt sich nämlich auch lesen, was der Server gerade im Arbeitsspeicher hat, und dort liegen solche Passwörter.

Welche Rolle spielt Cloudflare?

Cloudflare ist ein Dienst, über den rund ein Fünftel aller Websites im Hintergrund laufen. Er steht zwischen den Besucher:innen und dem Server und prüft jede Anfrage, bevor sie dort ankommt. Ob Ihre Website Cloudflare nutzt, wissen Ihr Hoster oder Ihre Agentur. Falls ja, hatte sie in den gefährlichen Stunden zwischen Leak und Update einen Vorteil, der aber nichts daran ändert, dass Sie die PHP-Version nachsehen sollten.

Das Unternehmen war in die Vorbereitung des Updates eingebunden und hatte seit Anfang Oktober Regeln entwickelt, die Angriffe auf die Lücken erkennen. Am Mittwoch um 5:02 Uhr unserer Zeit, rund elf Stunden vor dem Update, schaltete Cloudflare diese Regeln für alle Kund:innen ein, auch im kostenlosen Tarif und ohne dass jemand etwas tun musste. So entstanden auch die Zahlen zu den Angriffsversuchen: Cloudflare sieht, was an seinen Regeln hängen bleibt.

Ein Ersatz für das Update ist das nicht, und das sagt Cloudflare selbst. Die Regeln erkennen bekannte Angriffsmuster, und die Angreifer verändern ihre Muster laufend, um daran vorbeizukommen. Sie können den Umweg über Cloudflare auch ganz weglassen und den Server direkt ansprechen, wenn sie seine Adresse kennen. Cloudflare hat also Zeit gekauft. Geschlossen wird die Lücke nur durch das Update.

Was hat KI damit zu tun?

Gefunden haben die Lücken keine Menschen beim Lesen von Code, sondern Sicherheitsfirmen, die eine KI darauf angesetzt haben. Die US-Firma Calif entdeckte die erste Lücke im August 2026 mit einem Modell von OpenAI, im Rahmen eines Programms, mit dem OpenAI seit Juni die Prüfung wichtiger Open-Source-Software bezahlt. Wenige Wochen später stieß die Sicherheitsfirma Wiz, die zu Google gehört, unabhängig davon auf dieselben Lücken, ebenfalls mit KI-Modellen. Beide meldeten sie an das PHP-Projekt, das daraufhin gemeinsam mit OpenAI, Wiz und Cloudflare das Update vorbereitete. Dass die Lücken seit 2012 in PHP steckten und erst jetzt auffielen, ist die eigentliche Nachricht dahinter: Die Modelle finden Fehler, die über ein Jahrzehnt lang niemandem aufgefallen sind.

Wiz nennt die Funde die schwerwiegendsten Sicherheitslücken, die eine KI bisher entdeckt hat. Calif selbst bremst: Kein Modell finde mit einfachen Anfragen alle Fehler, entscheidend sei das Wissen der Forscher über PHP gewesen. Beides stimmt vermutlich. Für Ihre Website zählt etwas anderes: Dieselben Modelle stehen auch Angreifern offen. Diesmal stammten die Angriffsprogramme noch aus dem Leak. Beim nächsten Mal kann die Seite, die eine Lücke findet, die falsche sein. Das PHP-Projekt formuliert es so: Verteidiger und Angreifer finden Fehler heute schneller als je zuvor.

Kommt das jetzt öfter?

Wahrscheinlich ja. php2shell ist innerhalb von drei Monaten der zweite Fall, in dem eine mit KI gefundene Lücke zu Notfall-Updates für einen großen Teil des Webs geführt hat. Im Juli war es WordPress selbst: Ein Forscher ließ ein KI-Modell rund zehn Stunden lang den WordPress-Quellcode durchsuchen, für etwa 25 Dollar Rechenzeit, und fand eine Lücke, über die sich eine Website komplett übernehmen ließ. OpenAI erwartet, dass solche Funde in den kommenden Monaten stark zunehmen.

Für Sie als Betreiberin einer Website verschiebt das den Maßstab. Die Frage ist nicht mehr, ob in WordPress, einem Plugin oder PHP eine schwere Lücke steckt, sondern wie schnell das Update bei Ihrer Website ankommt, wenn sie gefunden wird. In dieser Woche lag zwischen Leak und Update ein Tag, zwischen Update und Millionen Angriffsversuchen wenige Stunden. In so einem Fall hilft nur, was vorher eingerichtet war: eine PHP-Version, die noch Updates bekommt, ein Hoster, der sie schnell einspielt, und automatische Updates, zu denen auch CERT.at rät.

Unsere Einschätzung

Für Websites mit PHP 8.2 oder neuer ist die Sache mit dem Update des Hosters erledigt. Schwierig wird es für Websites, deren PHP-Version seit Jahren niemand angesehen hat, weil alles lief. Für sie gibt es diesmal nur den Notbehelf, und ob der ankommt, hängt vom Hoster ab. Deshalb gehört die PHP-Version aus unserer Sicht zur Wartung einer Website dazu, genauso wie die Updates von WordPress und Plugins: Jemand sollte wissen, welche Version läuft und bis wann sie noch Updates bekommt.

Was jetzt

Quellen

1. BSI, 21.10.2026: PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit (Cybersicherheitswarnung, Stufe Orange, Empfehlungen), abgerufen am 21.10.2026
2. CERT.at, 20.10.2026: Bevorstehendes kritisches PHP-Sicherheitsupdate (Ankündigung, Empfehlung für Österreich), abgerufen am 21.10.2026
3. PHP, 2026: News-Archiv 2026 und ChangeLog 8 (Release, gefixte Versionen), abgerufen am 21.10.2026
4. ORF, 22.10.2026: PHP-Lücke: Millionen Angriffsversuche im Netz (Zahlen von Cloudflare, Anexia, CERT.at) und „PHP2Shell“: Sicherheitslücken bedrohen Websites (Entdeckung mit KI, Österreich), abgerufen am 22.10.2026
5. Cloudflare, 21.10.2026: Cloudflare deploys protections against php2shell vulnerability (Regeln ab 03:02 UTC, alle Tarife, Grenzen der WAF), abgerufen am 22.10.2026
6. The Next Web, 21.10.2026: PHP rushes out emergency patches for two critical bugs AI found first (Calif, Wiz, OpenAI, Zitate, Backports), abgerufen am 22.10.2026
7. Alexandre Daubois (PHP-Sicherheitsteam), 21.10.2026: What the PHP2Shell rumors got wrong (Ursache, Zeitlinie, betroffene Versionen), abgerufen am 22.10.2026
8. MeinBezirk, 21.10.2026: Universität Wien: Plattformen wegen „kritischer Sicherheitslücken“ offline und Webseiten von österreichischen Organisationen und Firmen down, abgerufen am 22.10.2026
9. Universität Wien, Zentraler Informatikdienst, 21.10.2026: Alle Wartungsarbeiten (präventive Abschaltung ab 10 Uhr), abgerufen am 21.10.2026
10. severint.net, 22.10.2026: Wie deutsche Webhoster auf PHP2Shell reagiert haben (Hetzner, Mittwald, netcup, Uberspace), abgerufen am 22.10.2026
11. Sansec, 21.10.2026: PHP2Shell: Critical PHP RCE (Shops, Backports, Speicherauslesen), abgerufen am 22.10.2026
12. Patchstack, 21.10.2026: Major security alert: PHP vulnerable to critical RCE (bestätigte Ausnutzung, WordPress), abgerufen am 22.10.2026
13. Dr. Web, 21.10.2026: Kritische PHP-Lücken: Hoster melden Angriffe vor dem Update um 16 Uhr (Anteil alter PHP-Versionen), abgerufen am 21.10.2026
14. CyberInsider, 20.07.2026: AI helped uncover WordPress wp2shell RCE (WordPress-Lücke im Juli, KI-Fund, Kosten), abgerufen am 22.10.2026
15. Let’s Data Science, 22.06.2026: OpenAI launches Patch the Planet (Programm, Anthropic-Zahl), abgerufen am 22.10.2026
16. WordPress Core, 09.01.2026: Dropping support for PHP 7.2 and 7.3 (empfohlene PHP-Version), abgerufen am 21.10.2026