Die Lage ändert sich stündlich. Wir aktualisieren diesen Artikel, solange das so ist; das Datum oben zeigt den letzten Stand.
Die Kurzfassung
- Am 21. Oktober hat das PHP-Projekt zwei kritische Lücken in PHP selbst geschlossen. Nicht in WordPress, nicht in einem Plugin, sondern in der Sprache, in der WordPress, Joomla, TYPO3, Drupal, Shopware, Nextcloud und die meisten anderen Website-Systeme geschrieben sind.
- Ein Angreifer braucht kein Login. Angriffsversuche gab es schon am Vormittag des 21. Oktober, Stunden bevor das Update erschien.
- Die Lücke schließt nur ein PHP-Update: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Ein Update Ihrer Website-Software ändert nichts daran. WordPress.org hat das ausdrücklich gesagt: Es gibt kein WordPress-Update dafür, und es ist keines geplant.
- Wer das Update einspielt, hängt von Ihrem Hosting ab. Bei den meisten Paketen ist es der Hoster. Fragen Sie ihn heute, schriftlich.
Was passiert ist
20. Oktober. Gegen 17 Uhr unserer Zeit tauchen die Kennungen der beiden Lücken im Netz auf, ohne technische Details. Daraufhin kündigt das PHP-Projekt um 21:30 Uhr eine Sicherheitsveröffentlichung an, mit zwei Lücken der Bewertung 9,2 von 10: für den nächsten Tag um 16 Uhr, einen Tag früher als geplant.
21. Oktober, im Lauf des Tages. Ab 9:34 Uhr unserer Zeit melden Hoster der Sicherheitsfirma Patchstack Angriffe auf PHP-Websites, wenige Minuten später meldet auch Cloudflare erste Angriffsversuche. Amazon gab später an, schon am 17. Oktober einen ersten Versuch auf einem seiner Köder-Server bemerkt zu haben. Ein Beispiel-Exploit kursiert öffentlich. Ab etwa 14 Uhr klopfen Programme automatisch große Mengen von Websites ab. Das Update ist noch nicht da.
21. Oktober, Nachmittag. Die Updates erscheinen, kurz vor der angekündigten Zeit (16 Uhr). Das BSI hatte schon vorher gewarnt, mit Stufe Orange, der zweithöchsten von vier: „Maßnahmen müssen unverzüglich ergriffen werden.“
21. und 22. Oktober. Die Hoster spielen die Updates ein. Einige nehmen Websites vorsorglich vom Netz: netcup schaltete schon vor dem Update das gesamte Webhosting ab, bis alles gepatcht war, Mittwald fuhr alle Systeme herunter, Uberspace schaltete PHP ab, Datev nahm einzelne Anwendungen offline, in den Niederlanden ging die Behörden-Anmeldung DigiD vom Netz. Cloudflare-Chef Matthew Prince spricht auf X inzwischen von Millionen Angriffsversuchen. Dem BSI ist am 22. Oktober noch keine erfolgreiche Ausnutzung „in der Breite“ bekannt; erfolgreiche Angriffe schließt es aber nicht aus. Die Sicherheitsfirma Sansec hält eine massenhafte Ausnutzung inzwischen für weniger wahrscheinlich als am Tag der Veröffentlichung.
Was die Lücke ist, ohne Fachchinesisch
Es sind zwei Fehler, CVE-2026-109618 und CVE-2026-109619. Beim ersten gerät PHP durcheinander, wenn ihm mitten in einer Anfrage der Speicher ausgeht: Es räumt dann halbfertige Daten auf, als wären sie fertig. Beim zweiten überleben Daten einer Anfrage in den Speicher der nächsten. Beides lässt sich von außen mit präparierten Anfragen auslösen, ohne Login, und am Ende führt der Server fremden Code aus. Mit einer einzigen Anfrage hat das bisher niemand vorgeführt, mitunter braucht es Tausende. Die lassen sich aber automatisch verschicken. Deshalb der Name „PHP2Shell“, in Anlehnung an Log4Shell von 2021.
Gefunden haben die Lücken die Sicherheitsfirmen Wiz und Calif.io, nach Angaben des BSI gemeinsam mit OpenAI, also mit KI-Werkzeugen. Betroffen sind laut BSI alle PHP-Versionen bis zurück zu PHP 5, egal wie PHP auf dem Server läuft. Am gefährdetsten ist die Variante „mod_php“ unter Apache, bei der der Angriff ausgelöst werden kann, bevor überhaupt eine Zeile WordPress läuft.
Wer betroffen ist
Alles, was mit PHP läuft. Nach W3Techs sind das 69 Prozent aller Websites, deren Serversprache sich erkennen lässt, also rund sieben von zehn. Im Einzelnen:
- WordPress, mit großem Abstand das meistgenutzte System. WordPress.org: kein WordPress-Update nötig oder geplant, der Fix ist das PHP-Update.
- Joomla, TYPO3, Drupal, Contao. Dieselbe Lage. TYPO3 hat es am 21. Oktober ausdrücklich gesagt: Kein TYPO3-Update nötig, nur PHP muss aktualisiert werden, und zwar sofort. Drupal ebenso: Das PHP-Update ist die einzige vollständige Abhilfe. Joomla hat bis zum 22. Oktober keine eigene Stellungnahme veröffentlicht; es braucht auch keine, die Antwort ist dieselbe.
- Shopware, Magento, WooCommerce, also Online-Shops, bei denen auf dem Server Kundendaten liegen.
- Nextcloud, Matomo, phpMyAdmin, Roundcube und andere Werkzeuge, die oft nebenbei auf demselben Hosting laufen.
- Netzwerkgeräte und NAS-Boxen, in denen PHP steckt. Das BSI nennt unter anderem die Firewalls pfSense und OPNsense und die NAS-Systeme von QNAP und Synology, die am 22. Oktober eigene Warnungen veröffentlicht haben. Schauen Sie auf die Sicherheitsseite Ihres Geräteherstellers.
- Ihre vergessenen Installationen. Die Test-Kopie vom letzten Relaunch, das alte WordPress im Unterordner, die Seite des eingestellten Projekts. Jede davon ist ein offenes Fenster, auch wenn seit Jahren niemand hinsieht.
Nicht betroffen sind Websites, auf deren Domain kein PHP läuft: Seiten, die als fertige Dateien ausgeliefert werden, und Baukasten-Angebote wie Wix, Jimdo oder Squarespace, bei denen der Anbieter den gesamten Betrieb selbst verantwortet.
Warum das Update von WordPress, Joomla oder TYPO3 nicht hilft
Stellen Sie sich Ihre Website als Stapel vor. Ganz unten der Server, darauf PHP, darauf WordPress (oder Joomla, oder TYPO3), darauf Ihr Theme und Ihre Plugins. Jede Schicht braucht ihre eigenen Updates, und jede kann der Weg hinein sein.
Diesmal liegt das Loch in der zweiten Schicht von unten. Alles, was Sie darüber aktualisieren, ändert daran nichts. Auch ein Sicherheits-Plugin nicht: Es läuft selbst in PHP, also oberhalb des Lochs. Patchstack warnt ausdrücklich vor „Fix-Plugins“ und kopierten Code-Schnipseln, die gerade die Runde machen. Es gibt nur einen Fix, und das ist das PHP-Update.
Was Sie jetzt tun
1. Fragen Sie Ihren Hoster, und zwar schriftlich. Zum Beispiel so: „Ist der PHP-Sicherheitsfix vom 21. Oktober 2026 (CVE-2026-109618 und -109619) auf meinem Paket eingespielt, und zwar für die PHP-Version, die meine Website tatsächlich nutzt?“ Schriftlich, weil Sie die Antwort später brauchen könnten, und weil die Versionsnummer allein nicht reicht: Viele Hoster und Linux-Distributionen bauen den Fix in die bestehende Version ein, ohne die Nummer zu ändern. Eine gepatchte Website kann also weiter „8.5.11“ anzeigen.
2. Finden Sie Ihre PHP-Version. In WordPress unter Werkzeuge → Website-Zustand → Bericht → Server. In Joomla unter System → Systeminformationen. In TYPO3 im Admin-Werkzeug „Environment“. Wie das im Detail geht, auch im Kundenmenü Ihres Hosters, steht in unserem Ratgeber Welche PHP-Version hat meine Website?. Die geschlossenen Versionen:
| Ihre Version | Sicher ab |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 und älter | kein Update vom PHP-Projekt, siehe Punkt 3 |
3. PHP 8.1 oder älter? Für diese Versionen gibt es vom PHP-Projekt kein Update mehr, nur Quellcode-Flicken für Hoster und Distributionen. Einige Hoster haben damit auch alte Versionen gepatcht (All-Inkl und Hetzner nach eigenen Angaben, ebenso die Hosting-Software cPanel und Plesk für 8.0 und 8.1). Fragen Sie nach. Wenn Ihr Hoster die alte Version nicht gepatcht hat, bleibt nur die Umstellung auf 8.2 oder neuer: vorher ein Backup, danach jede Seite und jedes Formular prüfen. Bricht die Website, stellen Sie zurück und holen sich Hilfe. Aber lassen Sie sie nicht auf einer ungepatchten 8.1 stehen.
4. Eigener Server? Wer einen Root-Server oder VPS betreibt, spielt die PHP-Pakete seiner Distribution ein (Debian, Ubuntu, AlmaLinux und andere haben den Fix nachgeliefert) und startet PHP und den Webserver neu. Vergessen Sie Docker-Container und Staging-Umgebungen nicht. Geht das nicht sofort, empfehlen WordPress.org und das britische NCSC, die Website vorübergehend vom Netz zu nehmen. Für Administratoren gibt es Notbehelfe (Upload-Fortschritt abschalten, Speicherlimit anpassen), aber PHP selbst sagt: Es gibt keine vollständige Abhilfe außer dem Update.
5. Danach. Rufen Sie Ihre Website auf, testen Sie das Kontaktformular, schauen Sie in die Benutzerliste. Neue Admin-Konten, unbekannte Plugins, Dateien, die nicht hingehören? Dann war womöglich jemand schneller. Was dann zu tun ist, steht in WordPress gehackt: Was Sie in den ersten 24 Stunden tun. Und wenn auf dem Server Kundendaten liegen: Ein Einbruch ist nach Art. 33 DSGVO binnen 72 Stunden der Datenschutzbehörde zu melden.
Wie weit die Hoster sind
Eine Momentaufnahme vom Abend des 22. Oktober, aus den Statusseiten und Mitteilungen der Hoster. Verlassen Sie sich nicht darauf. Fragen Sie.
- All-Inkl: nach eigener Angabe alle angebotenen PHP-Versionen gepatcht, auch die alten, die das PHP-Projekt nicht mehr unterstützt.
- Hetzner: auf allen Webhosting- und Managed Servern am 21. Oktober um 19:50 Uhr PHP 7.4 und 8.0 bis 8.5 gepatcht, am 22. Oktober um 6:32 Uhr auch 5.6 und 7.3 (Statusseite).
- netcup: Webhosting und Managed Server am 21. Oktober schon vor dem Update vorsorglich abgeschaltet, um 22:51 Uhr alles gepatcht und wieder online, nach eigener Angabe ohne eine ungepatchte PHP-Version.
- Mittwald: am 21. Oktober um 16:17 Uhr alle Systeme heruntergefahren, in der Nacht fast alle PHP-Versionen gepatcht, ausgenommen die Versionen unter 5.6.
- STRATO: Mitteilung vom 22. Oktober: das offizielle Update auf allen Plattformen eingespielt, die STRATO selbst betreibt. Welche PHP-Versionen, steht nicht dabei.
- IONOS: am 22. Oktober um 13:03 Uhr fertig gemeldet: das offizielle Update auf allen selbst betriebenen Plattformen, ebenfalls ohne Angabe der Versionen.
- domainfactory: am 22. Oktober um 13:30 Uhr alle Versionen bei Managed Hosting, Reseller-Hosting und Managed Cloud Servern aktualisiert, auch die alten aus dem LegacyPHP-Zusatz, um 15:36 Uhr auch beim Webhosting. Die Versionsnummer bleibt teils die alte, etwa 8.4.26 statt 8.4.27.
- webgo: am 22. Oktober um 10:13 Uhr fertig für alle Webhosting-Server, auch für die älteren Versionen aus dem Extended Support; einige vServer liefen noch.
- Host Europe: am 22. Oktober um 17:07 Uhr als abgeschlossen gemeldet, ohne Angabe der Versionen.
- Uberspace: PHP am 21. Oktober abgeschaltet, gegen 19 Uhr alle Versionen gepatcht und wieder an; Websites auf PHP 8.1 wurden dabei auf 8.2 umgestellt.
- Raidboxes, world4you, Hostpoint: keine eigenen Angaben, die wir finden konnten.
Warum das immer wieder passiert
Das ist der dritte Alarm dieser Art in fünf Monaten.
- Juni: Eine Lücke im Joomla-Editor JCE (CVE-2026-48907, Bewertung 10 von 10) wird aktiv ausgenutzt, die US-Behörde CISA setzt eine Frist für Bundesbehörden. Die Schicht: ein Plugin.
- Juli: „wp2shell“, zwei Lücken im WordPress-Kern selbst (CVE-2026-63030 und -60137). Angreifer installieren Hintertüren, bevor die Notfall-Updates 7.0.2, 6.9.5 und 6.8.6 überall sind. Die Schicht: das System.
- Oktober: PHP2Shell. Die Schicht: die Sprache unter allem.
Jede Schicht hat ihren eigenen Update-Rhythmus, und Sie stehen am Ende der Kette: Erst wenn der Hoster, der Plugin-Hersteller und Sie selbst alle reagiert haben, ist die Tür wieder zu. Diesmal hatten die Hoster Stunden, nicht Tage. Und der nächste Termin steht schon fest: PHP 8.2 bekommt ab dem 31. Dezember 2026 keine Sicherheitsupdates mehr. Für 8.1 ist das seit dem 31. Dezember 2025 so.
Und bei Johnny?
Ehrlich gesagt: Zuerst das Update. Der Patch dauert eine Stunde, ein Umzug dauert länger. Also erst Punkt 1 bis 5 oben.
Danach die Frage, ob es beim nächsten Mal wieder so sein muss. Johnny zieht Ihre WordPress-Website um, gleicher Look, gleiche Adressen, auf eine Website, die als fertige Seiten ausgeliefert wird. Auf Ihrer Domain läuft dann kein PHP, es gibt keine Plugins, kein Admin-Login und keine Datenbank. Was jeder Angriff dieser Art braucht, ist nicht da. Wir sagen nicht „unhackbar“: Ihre Website ist weiter im Internet, hinter Ihrem Kontaktformular läuft eine kleine Funktion auf unserer Seite, und Johnny selbst ist Software. Das halten wir aktuell, das ist unsere Arbeit und im Monatspreis drin. Auf Ihrer Seite bleibt nichts, was Sie je wieder patchen müssten.
Wie der Umzug abläuft und was er kostet: Heute PHP aktualisieren. Dann nie wieder.
Quellen
- PHP: Sicherheitsveröffentlichungen vom 21. Oktober 2026 mit den Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp, und die Ankündigung vom 20. Oktober
- The PHP Foundation: Today’s PHP security release (der Leak und der frühere Termin)
- BSI: PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit, BITS-H 2026-297981-1232, Version 1.2 vom 22.10.2026
- WordPress.org: Critical PHP security release; Drupal: PSA-2026-10-20; TYPO3: TYPO3-PSA-2026-001
- Wiz: PHP2Shell: AI uncovers critical RCE vulnerabilities
- heise: php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP (wie viele Anfragen ein Angriff braucht)
- Sansec: PHP2Shell: PHP RCE (Stand 22.10.)
- Codeable: PHP security release, what WordPress site owners need to do (WordPress.org-Stellungnahme, Hoster-Liste, Stand 22.10., 18:23 UTC)
- Patchstack: PHP vulnerable to critical RCE, attacks ongoing (Zeitleiste des 21. Oktober)
- Wordify: PHP critical security release, live updates (das automatische Abklopfen ab etwa 14 Uhr)
- QNAP: QSA-26-18; Synology: Synology-SA-26:14
- Debian: Security Tracker zu CVE-2026-109618 (DSA-6574-1); Ubuntu: CVE-2026-109618 (USN-8948-1); AlmaLinux: Patched PHP packages released
- The Register: Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure (22. Oktober)
- The Next Web: PHP2Shell: millions of exploit attempts, no confirmed breaches (der Cloudflare-Chef auf X)
- Dr. Web: Kritische PHP-Lücken: Hoster melden Angriffe vor dem Update
- Borncity: php2shell: PHP-Updates und Nachlese (Leserberichte, darunter Datev)
- W3Techs: Usage statistics of PHP (Stand 22.10.2026)
- BleepingComputer: Critical wp2shell WordPress flaws exploited to install webshells (Juli 2026)
- Vulert: CISA warns of actively exploited Joomla JCE flaw (Juni 2026)