PHP-Sicherheitslücke trifft auch WordPress-Websites

Am 21. Oktober 2026 gingen auffällig viele Websites vom Netz. Die Stadt Mainz schaltete ihr Portal ab, die Charité nahm ihre Website offline, auch Hochschulen, Feuerwehr und Banken waren zeitweise nicht erreichbar. Am 23. Oktober waren laut dpa nahezu alle vorsorglich abgeschalteten Websites wieder erreichbar, darunter Auftritte von Ministerien, Behörden und der Charité (t-online). Erledigt ist das Thema damit aber nicht. Jede Website, auf der das Update fehlt, bleibt angreifbar, und laut dpa wird die Welle automatisierter Angriffe voraussichtlich noch Wochen und Monate andauern (Tagesspiegel).

Dahinter steckt kein einzelner Hackerangriff, sondern eine Sicherheitslücke in PHP. Mit dieser Technik arbeitet ein großer Teil aller Websites, ausnahmslos alle WordPress-Websites eingeschlossen.

Was ist bei der Sicherheitslücke PHP2Shell passiert?

Wenn ein Besucher eine Website aufruft, sendet sein Browser eine Anfrage an den Webserver, auf dem die PHP-Dateien liegen. Der Server erkennt den PHP-Code, führt die darin enthaltenen Befehle aus und wandelt das Ergebnis in reinen HTML- und CSS-Code um. Diesen fertigen Code schickt er an den Browser zurück, der ihn als Seite darstellt. Der ursprüngliche PHP-Quelltext bleibt dabei für den Besucher unsichtbar und auf dem Server geschützt. Vom einfachen Blog über Nachrichtenportale bis zum Onlineshop arbeitet ein großer Teil des Internets so.

Genau in diesem Ablauf wurden zwei schwere Fehler gefunden. Am 21. Oktober 2026 hat das PHP-Projekt ein Update veröffentlicht, das beide Fehler behebt, angekündigt war es für 16 Uhr deutscher Zeit. Alle Betreiber sollten es sofort einspielen (php.net).

Angreifer können fremde Befehle auf dem Server ausführen

Die beiden Lücken haben den gemeinsamen Spitznamen PHP2Shell. Fachleute führen sie unter den offiziellen Kennungen CVE-2026-109618 und CVE-2026-109619. Beide setzen genau an dem Punkt an, an dem der Server eine Anfrage bearbeitet.

Vereinfacht gesagt läuft es so ab. Ein Angreifer schickt dem Server eine speziell präparierte Anfrage mit vielen ineinander verschachtelten Feldern. Besonders groß ist sie gar nicht, aber PHP muss für jede Verschachtelung zusätzlichen Speicher anlegen. Das passiert schon, bevor die eigentliche Seite überhaupt startet. Bei manchen Server-Einstellungen reicht deshalb eine Anfrage an irgendeine PHP-Seite, ein Formular ist nicht nötig. Bei anderen hängt es davon ab, wie die Website programmiert ist. PHP stößt dabei an seine Speichergrenze, bricht mittendrin ab und bringt beim anschließenden Aufräumen seine eigenen Daten durcheinander (Calif). Bei der zweiten Lücke bleiben Reste einer Anfrage im Speicher zurück, die eine spätere Anfrage wieder aufgreift (php.net).

Genau in diesem Durcheinander liegt die Gefahr. Statt nur eine Seite auszuliefern, führt der Server dann Befehle des Angreifers aus, ganz ohne Passwort und mit denselben Rechten, mit denen er sonst die Website betreibt. Der eigentlich geschützte Bereich auf dem Server steht dem Angreifer damit offen. Im schlimmsten Fall übernimmt er die Website, kommt an Kundendaten, Formulare oder Passwörter und nutzt den Server für weitere Angriffe.

Ganz einfach ist so ein Angriff nicht. Laut heise online sind dafür oft mehrere tausend Anfragen nötig. Für automatische Angriffsprogramme ist das aber kein Hindernis. In einem Video von Calif liefen schon nach 38 Sekunden fremde Befehle auf einem Server mit dem PHP-Framework Laravel.

Wie der Fehler entstanden ist

Ganz neu ist das Problem nicht. Eine ähnliche Lücke gab es bei PHP schon 2004 (Calif), und laut BSI sind alle bekannten PHP-Versionen betroffen, zurück bis mindestens PHP 5 (BSI). Ein Entwickler des PHP-Teams bemerkte den Fehler bereits 2024. Weil sich damals kein Angriffsweg fand und sich das kleine Team nicht auf eine Lösung einigen konnte, blieb er aber liegen. Die PHP Foundation nennt das heute selbst strukturelles Versagen (The Next Web).

2026 untersuchte das Sicherheitsunternehmen Calif PHP ab Ende Juli im Rahmen eines Sicherheitsprogramms von OpenAI gezielt mit KI-Hilfe. Am 11. August meldete es die Lücke an das PHP-Team (Calif).

Warum die Angriffe genau jetzt begannen

Bis Oktober wussten nur wenige Beteiligte von der Lücke, etwa die Entdecker, das PHP-Team und Anbieter, die Updates vorbereiteten. Ohne Hinweis findet kaum jemand einen einzelnen Fehler im riesigen Programmcode von PHP. Kurz vor dem Update platzte diese Geheimhaltung teilweise. Am 20. Oktober gegen 17 Uhr deutscher Zeit kursierten die Kennungen der Lücken im Netz, technische Details noch nicht. Das PHP-Team zog sein Update daraufhin um einen Tag auf den 21. Oktober vor (heise online). Am selben Abend veröffentlichte Calif versehentlich ein Video des Angriffs. Am 21. Oktober stellte dann ein Software-Anbieter korrigierte Pakete schon mehr als sechs Stunden vor dem offiziellen Termin bereit (The Next Web).

Mit dem Update wurde dann endgültig sichtbar, welche Stelle im Code repariert wurde. Das BSI hielt es für wahrscheinlich, dass Angreifer die Lücke mit KI-Werkzeugen schon wenige Stunden nach Erscheinen des Updates großflächig ausnutzen (BSI). Amazon beobachtete auf einem eigenen Lockvogel-Server sogar schon am 17. Oktober einen ersten Angriffsversuch. In der Nacht zum 21. Oktober, noch vor dem Update, tauchten erste Beispielangriffe auf, wenige Stunden nach dem Update weitere, und inzwischen beobachtet Amazon breite Angriffsversuche im Netz (AWS Security Blog). Wer erst Tage später aktualisiert hat, sollte deshalb nicht davon ausgehen, dass nichts passiert ist.

Welche Rolle KI dabei spielt

KI hat auf beiden Seiten eine Rolle gespielt. Am 19. August, gut eine Woche nach Califs Meldung, stieß auch das Sicherheitsunternehmen Wiz unabhängig auf die Fehler. Nach eigenen Angaben setzte Wiz dabei KI-Modelle ein, um die Lücken aufzuspüren und das Update zu prüfen (Wiz). Fehler, die früher als zu kompliziert zum Ausnutzen galten, werden mit KI-Hilfe plötzlich angreifbar. Was Sicherheitsforschern hilft, hilft aber genauso Angreifern.

Für Website-Betreiber bedeutet das vor allem, dass zwischen dem Bekanntwerden einer Lücke und den ersten Angriffen teilweise nur noch Stunden liegen. Sicherheitsupdates gehören deshalb nicht auf die lange Bank.

Warum gingen so viele Websites offline?

Die Betreiber hatten ihre Seiten vorsorglich vom Netz genommen, bis das Update eingespielt war. Solange eine Website offline ist, kommt auch keine Anfrage eines Angreifers beim Server an. Das war für Besucher ärgerlich, in dieser Lage aber die vernünftigste Entscheidung.

Das BSI riet im Zweifel zum Abschalten

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Lage mit der Warnstufe „3 / Orange“ als außerordentlich hoch eingestuft. Wer das Update nicht sofort einspielen konnte, sollte laut BSI erwägen, die Website vorübergehend vom Internet zu trennen (Tagesspiegel). Marc Henrichmann, Vorsitzender des Parlamentarischen Kontrollgremiums für die Geheimdienste, sprach von einer der ernstesten Sicherheitslücken der vergangenen Jahre (Tagesspiegel).

Viele Organisationen sind dieser Empfehlung gefolgt. Laut dpa waren unter anderem die Websites der Charité, der Berliner Feuerwehr, der Berliner Tafel, der Universität Potsdam und des Ernst-von-Bergmann-Klinikums nicht erreichbar. Die Stadt Mainz schaltete mehrere Online-Dienste ab, darunter ihr Portal mainz.de (Tagesspiegel). Laut ZDFheute waren auch die Websites von Banken und Sparkassen teilweise einige Stunden offline. Das eigentliche Online-Banking war nicht betroffen, weil es mit ganz anderen technischen Komponenten gebaut ist.

Abschalten ist Vorsicht, kein Zeichen für einen Angriff

Für Behörden und Kliniken ist die Abwägung einfach. Eine Website, die ein paar Stunden fehlt, ärgert Besucher. Wenn Angreifer dagegen an Patientendaten oder Bürgeranträge kommen, entsteht echter Schaden. Eine abgeschaltete Seite war in diesen Tagen deshalb eher ein Zeichen von Verantwortung. Das BSI hatte bis zum 22. Oktober keine Fälle festgestellt, in denen die Lücke ausgenutzt wurde. Erfolgreiche Angriffe konnte die Behörde aber nicht ausschließen (Tagesspiegel). Kritisch bleiben deshalb Seiten, die ohne Update einfach weiterlaufen.

Welche Websites sind von der PHP-Sicherheitslücke betroffen?

Betroffen ist jede Website, deren Server Anfragen mit PHP bearbeitet und die das Update noch nicht bekommen hat. Das sind sehr viele. Laut W3Techs nutzen 69,3 Prozent aller Websites, deren Technik bekannt ist, PHP.

Ausnahmslos jede WordPress-Website ohne PHP-Update

Die Lücke steckt in PHP selbst und nicht in einem bestimmten Redaktionssystem. Ein Redaktionssystem wie WordPress ist im Grunde eine große Sammlung von PHP-Dateien, die der Server bei jedem Seitenaufruf ausführt. Deshalb sind alle Systeme betroffen, die auf PHP aufbauen. Dazu gehören WordPress, Typo3, Joomla, Drupal, die Lernplattform Moodle und viele Shop-Systeme. Allein mit WordPress laufen laut einer Schätzung von Experten 400 bis 500 Millionen Websites weltweit (Tagesspiegel). Laut Wiz ist jede PHP-Version der vergangenen zehn Jahre von mindestens einer der Lücken betroffen, die älteste betroffene Version ist PHP 5.4 (Wiz).

Für WordPress-Betreiber ist es schon die zweite kritische Lücke binnen weniger Monate, auch wenn PHP2Shell nicht in WordPress selbst steckt. Im Juli 2026 musste WordPress mit der Version 7.0.2 eine Lücke schließen, über die Angreifer ebenfalls fremden Code ausführen konnten (WordPress.org). Bekannt wurde sie unter dem Namen wp2shell, auch damals stufte das BSI die Lage mit Orange ein (IT-Administrator). Der Unterschied ist wichtig. wp2shell steckte in den PHP-Dateien von WordPress selbst, deshalb hat ein WordPress-Update geholfen. PHP2Shell steckt eine Ebene tiefer in der Technik, die diese Dateien ausführt. Deshalb muss diesmal PHP selbst aktualisiert werden.

Auch Geräte zu Hause und im Büro

PHP steckt auch in Geräten, an die man zuerst nicht denkt. Viele Router, Firewalls und Netzwerkspeicher (NAS) haben eine Einstellungsseite, die man im Browser öffnet. Hinter dieser Seite arbeitet oft ebenfalls PHP, wie heise online für Geräte verschiedener Hersteller berichtet. Wer solche Geräte nutzt, sollte automatische Updates einschalten (ZDFheute).

Wer nur im Internet surft, muss am eigenen Computer oder Handy nichts tun. Der Browser bekommt vom Server ja nur fertiges HTML und CSS, der PHP-Code läuft ausschließlich auf dem Server. Die Lücke betrifft deshalb Server, nicht die Geräte der Besucher.

Wie prüfen und schützen Sie Ihre Website jetzt?

Für einen ersten Website-Sicherheitscheck brauchen Sie keine Technikkenntnisse. Die folgenden drei Schritte zeigen, ob Ihre Website betroffen ist und was zu tun ist.

Schritt 1: Herausfinden, worauf Ihre Website läuft

Läuft Ihre Website auf WordPress, Typo3, Joomla oder einem Shop-System wie Shopware oder WooCommerce, nutzt sie fast sicher PHP. Bei WordPress können Sie das selbst nachsehen. Unter „Werkzeuge“ finden Sie den „Website-Zustand“. Der Reiter „Info“ zeigt im Bereich „Server“ die genaue PHP-Version. Der Reiter „Status“ warnt zwar vor veralteter Technik (WordPress.org), laut Dokumentation aber nicht gezielt vor fehlenden Sicherheitsupdates wie bei PHP2Shell. Vergleichen Sie die Versionsnummer deshalb selbst.

Gegen PHP2Shell geschützt sind die PHP-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Steht dort eine ältere Nummer, sprechen Sie sofort Ihren Hoster oder Ihre Agentur an. Bei manchen Linux-Servern wirkt die Nummer älter, obwohl der Hoster die Korrektur bereits eingespielt hat, fragen Sie im Zweifel nach. Wenn Sie nicht wissen, auf welcher Technik Ihre Website läuft, fragen Sie ebenfalls dort nach.

Schritt 2: Das Update einspielen lassen

PHP ist auf dem Server installiert, nicht in Ihrer Website. Deshalb kümmert sich bei einem normalen Hosting-Paket in der Regel der Hoster um das Update. Große Anbieter wie IONOS haben es laut ZDFheute bereits eingespielt. Läuft Ihre Website auf einem eigenen Server, ist Ihr IT-Dienstleister oder Ihre Agentur zuständig.

Übergangslösungen gibt es zwar, etwa bestimmte PHP-Einstellungen oder Schutzfilter, die verdächtige Anfragen abfangen. Das PHP-Projekt betont aber, dass es keinen vollständigen Schutz außer dem Update gibt (php.net). Unabhängig davon empfiehlt das PHP-Projekt seit dem 23. Oktober, auch auf bereits aktualisierten Servern die Einstellung „session.upload_progress.enabled“ vorerst abzuschalten. Hintergrund ist eine weitere, eigene Lücke, die nur bei einer ungewöhnlichen Kombination von Einstellungen ausnutzbar ist und erst mit dem nächsten regulären PHP-Update geschlossen wird. Auch das kann Ihr Hoster oder Ihre Agentur übernehmen. Wenn das Update nicht sofort möglich ist, bleibt der Rat des BSI, die Website kurz vom Netz zu nehmen. Für PHP 8.1 und älter liefert das PHP-Projekt keine regulären Updates mehr, manche Linux-Anbieter liefern eigene Korrekturen nach. Auf Dauer hilft nur der Umstieg auf eine aktuelle Version.

Schritt 3: Nachsehen lassen, ob vorher jemand eingedrungen ist

Das Update schließt die Lücke, entfernt aber nichts, was ein Angreifer vorher schon auf dem Server hinterlassen hat. Weil erste Angriffe schon vor dem Update liefen, empfiehlt Amazon, Spuren ab dem 17. Oktober zu prüfen und nicht erst ab dem Tag des Updates (AWS Security Blog). Server zeichnen in der Regel auf, welche Anfragen bei ihnen angekommen sind. Bitten Sie Ihren Hoster oder Ihre Agentur, diese Aufzeichnungen auf Auffälligkeiten zu prüfen. Bei WordPress können Sie außerdem selbst nachsehen, ob es Administrator-Konten gibt, die Sie nicht kennen.

Wie ein ausführlicher, professioneller Website-Sicherheitscheck abläuft, erklären wir im Beitrag So schließen Sie die größten Sicherheitslücken auf Ihrer Website.

Was macht eine Website dauerhaft sicher?

PHP2Shell wird nicht die letzte große Lücke bleiben. Sichere Websites entstehen deshalb nicht durch ein einzelnes Update, sondern durch die richtige Technik und klare Abläufe.

Vier Grundsätze für sichere Websites

Erstens sollte auf dem Server so wenig Software wie möglich laufen. Jedes Programm und jedes Plugin, das bei einem Seitenaufruf mitarbeitet, verarbeitet die Anfrage des Besuchers und ist damit eine mögliche Schwachstelle. Zweitens müssen Sicherheitsupdates innerhalb von Stunden ankommen, nicht erst nach Wochen. Bei PHP2Shell begannen die ersten Angriffe sogar schon vor der Veröffentlichung des Updates.

Drittens braucht es eine klare Zuständigkeit. Viele Organisationen mussten in diesen Tagen erst herausfinden, wer ihre Website betreut und welche Technik dort läuft. Diese Zeit fehlt im Ernstfall. Viertens gehören aktuelle Backups dazu, damit sich eine Website nach einem Angriff schnell wiederherstellen lässt. Worauf Sie bei einem Partner für die laufende Betreuung achten sollten, lesen Sie in Wie Sie eine Agentur für Website-Pflege richtig auswählen.

Was Evelan-Websites sicher macht

Die Websites, die wir heute bei Evelan bauen, folgen diesen Grundsätzen. Das schützt nicht nur vor einer einzelnen Lücke wie PHP2Shell, sondern macht die ganze Website weniger anfällig:

• Kein klassisches Backend auf dem Server: Die Website läuft mit Next.js. Inhalte, Anmeldung und Daten liegen getrennt beim Cloud-Dienst Sanity. Es gibt kein WordPress-Backend und keine Plugins, die Angreifer auf dem Webserver ausnutzen könnten. Lücken wie PHP2Shell oder wp2shell treffen diese Websites nicht, weil dort weder PHP noch WordPress läuft.
• Fertige Seiten aus einem weltweiten Servernetz: Die Seiten werden in der Regel schon vorab in fertiges HTML und CSS umgewandelt und von Vercel ausgeliefert, so auch unsere eigene Website evelan.de. Ruft ein Besucher eine Seite auf, schickt der Server nur noch diese fertige Datei. Dabei läuft kaum Code, den man angreifen könnte. Frei von Lücken ist aber auch Next.js nicht, Ende 2025 musste etwa die Lücke React2Shell geschlossen werden (Vercel).
• Updates ohne Wartungsstress: Auf Ebene der Infrastruktur spielt Vercel wichtige Sicherheitsupdates laut eigener Dokumentation automatisch ein (Vercel). Niemand muss nachts einen Server aktualisieren. Die Bausteine, aus denen die Website selbst besteht, halten wir zusätzlich aktuell.
• Geschützte Inhalte: Sanity ist laut eigener Angabe für den Bereich Sicherheit nach SOC 2 Type 2 zertifiziert und DSGVO-konform. Zugriffe lassen sich über Rollen genau regeln, und Sanity zeichnet je nach Tarif eine Versionshistorie der Änderungen auf. Außerdem sichert Sanity die Datenbank laufend und kann sie auf jeden Zeitpunkt der letzten 30 Tage wiederherstellen (Sanity).
• Betreuung aus einer Hand: Auf Wunsch kümmern wir uns um Hosting, Betrieb und Updates, sodass Sie sich nicht selbst darum kümmern müssen.

Auch sichere Technik braucht Updates

Unangreifbar ist trotzdem keine Technik. Am selben 21. Oktober bekam auch Node.js, die Laufzeitumgebung von Next.js, Sicherheitsupdates (Aikido). Der Unterschied liegt darin, wer es einspielt und wie schnell. Vercel spielt solche Updates von Node.js laut Dokumentation bei Bedarf automatisch ein, die übrigen Bausteine der Website halten wir bei Bedarf aktuell und veröffentlichen sie neu. Wie sich beide Ansätze unterscheiden, zeigt unser Vergleich Headless CMS vs. klassisches CMS.

Verwandte Evelan-Artikel

• So schließen Sie die größten Sicherheitslücken auf Ihrer Website
• Headless CMS vs. klassisches CMS: Welches System passt zu Ihrem Unternehmen?
• Website-Relaunch als Investition in die Zukunft

Quellen

• https://www.php.net/archive/2026.php
• https://www.heise.de/en/news/php2shell-Critical-flaws-allow-code-injection-in-PHP-11494897.html
• https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/261021_PHP-kritische-Schwachstelle.html
• https://www.tagesspiegel.de/wirtschaft/dpa-bsi-warnt-und-rat-im-zweifel-zum-trennen-der-server-vom-netz-16184490.html
• https://www.tagesspiegel.de/gesellschaft/medien/dpa-viele-webseiten-wieder-online--aber-noch-keine-entwarnungwas-sie-zur-php-sicherheitslucke-wissen-mussen-16186542.html
• https://www.t-online.de/digital/aktuelles/id_101494558/php-sicherheitsluecke-viele-betroffenen-webseiten-wieder-online.html
• https://www.zdfheute.de/politik/php-sicherheitsluecke-faq-websites-internet-100.html
• https://w3techs.com/technologies/details/pl-php
• https://thenextweb.com/news/php-foundation-structural-failure-2024-flaw-leak
• https://calif.io/php2shell/
• https://www.wiz.io/blog/php2shell-php-rce
• https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• https://wordpress.org/documentation/wordpress-version/version-7-0-2/
• https://wordpress.org/documentation/article/site-health-screen/
• https://www.it-administrator.de/wordpress-bsi-alarmstufe-orange-schwachstelle-websites
• https://www.aikido.dev/blog/node2shell-nodejs-brotli-rce-cve-2026-111497
• https://www.sanity.io/security
• https://vercel.com/blog/resources-for-protecting-against-react2shell
• https://vercel.com/docs/functions/runtimes/node-js/node-js-versions