PHP-Sicherheitslücke „PHP2Shell": Ist Ihre WordPress-Website betroffen?

Das Wichtigste in 30 Sekunden.

• Was: Zwei kritische Lücken in PHP selbst — nicht in WordPress, nicht in einem Plugin. Beide erlauben das Ausführen fremden Codes auf dem Server, ohne dass der Angreifer sich anmelden muss.
• Wer: Jede Website, die PHP ausführt. WordPress, WooCommerce, Joomla, Drupal, TYPO3, Shopware, viele Eigenentwicklungen. Alle PHP-Versionen bis einschließlich 8.5.11 sind verwundbar.
• Fix: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 — veröffentlicht am 21. Oktober 2026, 16:00 Uhr. Für PHP 8.1 und älter gibt es keine regulären Updates mehr.
• Reicht ein WordPress-Update? Nein. WordPress hat selbst klargestellt, dass kein WordPress-Update nötig oder geplant ist — die Lücke sitzt eine Ebene tiefer, beim Hoster.
• Was Sie tun müssen: Prüfen, welche PHP-Version Ihre Seite tatsächlich ausführt, und sicherstellen, dass Ihr Hoster die Korrektur eingespielt hat. Anleitung unten.
• Kunden von KL Design: Websites auf unserem System führen kein PHP aus und sind nicht betroffen. Sie müssen nichts unternehmen — kein Update, keine Prüfung.

Entwarnung: Unsere Websites sind nicht betroffen.

Was genau passiert ist.

Am 20. Oktober 2026 hat das PHP-Sicherheitsteam etwas getan, was es sonst praktisch nie tut: Es hat einen Tag im Voraus vor einer außerplanmäßigen Sicherheitsveröffentlichung gewarnt. Am 21. Oktober um 14:00 Uhr UTC folgten vier Updates gleichzeitig — für jede noch unterstützte PHP-Versionsreihe eines. Die Branche hat den Vorfall „PHP2Shell" getauft.

Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und sind beide mit 9,2 von 10 Punkten (CVSS v4.0) als „kritisch" eingestuft. Vereinfacht gesagt: In bestimmten Situationen — etwa wenn PHP während einer Anfrage der Speicher ausgeht oder Daten aus einer vorherigen Anfrage nicht sauber aufgeräumt werden — kann ein speziell gebauter Aufruf den Server dazu bringen, Code auszuführen, den der Angreifer mitschickt. Bei der häufigsten Konfiguration kleiner und mittlerer Webhoster, Apache mit mod_php, ist das laut PHP-Team nachweislich ohne Anmeldung möglich und greift, bevor überhaupt WordPress geladen wird.

Das PHP-Projekt schreibt wörtlich, dass es keine vollständigen Gegenmaßnahmen außer dem Update gibt. Cloudflare hat bereits vor Veröffentlichung der Patches erste Angriffsversuche beobachtet. Einige Unternehmen haben ihre Webserver am 20. und 21. Oktober vorsorglich komplett abgeschaltet.

Das ist keine Plugin-Lücke, die man wegklickt. Das ist die Laufzeit unter der gesamten Website — und sie liegt nicht in Ihrer Hand, sondern in der Ihres Hosters.

Ist meine Website betroffen?

Die ehrliche Antwort: Wenn Ihre Website auf WordPress oder einem anderen PHP-System läuft, war sie bis zum 21. Oktober verwundbar. Entscheidend ist jetzt nicht, ob Sie WordPress aktuell gehalten haben, sondern ob der Server, auf dem die Seite liegt, inzwischen eine der korrigierten PHP-Versionen ausführt.

• Sicher: Ihre Seite läuft auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 (oder neuer).
• Vermutlich sicher, aber nachfragen: Ihr Hoster nennt eine ältere Versionsnummer, hat die Korrektur aber „zurückportiert" (bei großen Anbietern und Linux-Distributionen üblich). Lassen Sie sich das schriftlich bestätigen.
• Nicht sicher: Ihre Seite läuft auf PHP 8.1, 8.0 oder 7.4. Diese Versionen bekommen vom PHP-Projekt keine regulären Updates mehr. Es gibt zwar Notfall-Quellcode-Patches, aber nur Hoster, die PHP selbst kompilieren, können sie einbauen. Für die meisten Websites heißt das: Versionswechsel — und damit oft kaputte Plugins und Themes.
• Gar nicht betroffen: Websites, die kein PHP ausführen — also als fertige Dateien ausgeliefert werden, ohne Server-Programm dahinter. Dazu gleich mehr.

In fünf Minuten prüfen — ohne Technikwissen.

Sie brauchen dafür nur Ihren WordPress-Login. Es wird nichts verändert, Sie schauen nur nach.

1. Melden Sie sich im WordPress-Backend an (meist ihre-domain.de/wp-admin).
2. Links im Menü: Werkzeuge → Website-Zustand.
3. Oben auf den Reiter „Bericht" wechseln.
4. Den Abschnitt „Server" aufklappen und die Zeile „PHP-Version" suchen.
5. Steht dort 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 (oder höher): gut. Steht dort etwas Kleineres oder eine 8.1, 8.0, 7.x: weiter mit Schritt 6.
6. Loggen Sie sich bei Ihrem Hoster ein (IONOS, Strato, All-Inkl, Hetzner, GoDaddy, Raidboxes …) und suchen Sie den Punkt „PHP-Version" oder „PHP-Einstellungen". Dort sehen Sie, welche Versionen angeboten werden — und ob eine korrigierte dabei ist.
7. Wenn Sie unsicher sind: Support des Hosters anschreiben mit dem Satz „Ist auf meinem Paket die Korrektur für CVE-2026-109618 und CVE-2026-109619 eingespielt?" Das ist eine Ja/Nein-Frage, die jeder Hoster beantworten kann.

Wichtig: Haben Sie mehrere Domains oder mehrere Installationen beim selben Hoster, kann jede eine andere PHP-Version nutzen. Jede einzeln prüfen.

Was Sie jetzt tun sollten.

• Backup sichern, bevor Sie etwas ändern. Dateien und Datenbank. Wenn Ihr Hoster tägliche Backups macht, prüfen Sie, dass eines von vor dem 20. Oktober noch da ist — falls die Seite bereits kompromittiert wurde, ist das Ihr sauberer Stand.
• PHP-Version beim Hoster auf eine korrigierte Version umstellen. Bei den meisten Anbietern ein Dropdown im Kundenbereich. Bleiben Sie, wenn möglich, in Ihrer Versionsreihe (z. B. 8.3 → 8.3.36), dann ist das Risiko für Plugin-Probleme am kleinsten.
• Danach die Seite durchklicken. Startseite, Kontaktformular, Login, bei Shops den Warenkorb bis zur Kasse. Ein Versionssprung kann alte Plugins und Themes brechen — besser Sie merken es jetzt als Ihre Kunden morgen.
• Wenn Ihr Hoster keine korrigierte Version anbietet: Das ist ein ernstes Warnsignal. Fragen Sie nach einem Termin. Gibt es keinen, ist ein Hosterwechsel überfällig — oder der Moment, grundsätzlich über das Setup nachzudenken.
• Wenn Sie auf PHP 7.4, 8.0 oder 8.1 sitzen: Hier hilft kein kleines Update. Die Seite muss auf eine unterstützte Version, und erfahrungsgemäß bricht dabei bei älteren WordPress-Installationen die Hälfte der Erweiterungen. Planen Sie das als Projekt, nicht als Klick.

Was Sie nicht tun sollten: Nur WordPress, Plugins und Themes updaten und sich sicher fühlen. Das löst dieses Problem nicht. Und: keine „Fix-Tools" oder Code-Schnipsel aus Foren einspielen. Die vom PHP-Team genannten Übergangsmaßnahmen sind Servereinstellungen, die ausdrücklich nur Teilangriffe blockieren und in falscher Hand mehr kaputt machen als sie schützen.

Anzeichen, dass es schon passiert ist.

Keines der folgenden Zeichen ist allein ein Beweis, aber jedes ist Grund für einen genauen Blick:

• Neue Administrator-Konten in WordPress, die niemand angelegt hat.
• Dateien mit Endung .php an Orten, wo sie nicht hingehören — etwa im Uploads-Ordner.
• Die Seite leitet Besucher auf fremde Domains weiter oder zeigt Werbung, die Sie nie eingebaut haben.
• Google Search Console meldet Sicherheitsprobleme oder plötzlich Hunderte neuer URLs, die Sie nicht kennen.
• Ihr Hoster meldet ungewöhnlichen Traffic, Spam-Versand oder hat die Seite gesperrt.

Wenn Sie eines davon sehen: Das PHP-Update allein reicht dann nicht mehr. Dann muss die Seite aus einem sauberen Backup wiederhergestellt, alle Passwörter und Schlüssel getauscht und die Ursache geschlossen werden. Das ist Arbeit für jemanden, der das schon öfter gemacht hat — melden Sie sich, wir schauen gemeinsam drauf.

Das eigentliche Problem ist nicht diese Lücke.

PHP2Shell wird gepatcht, die Nachrichten ziehen weiter. Aber das Muster bleibt: Eine klassische WordPress-Website ist ein Programm, das bei jedem Seitenaufruf auf einem Server läuft — mit Datenbank, Login, Dutzenden Erweiterungen von Dutzenden Herstellern und einer Laufzeitumgebung, die Ihnen gar nicht gehört. Jede dieser Schichten hat eigene Lücken, eigene Update-Zyklen und eigene Abhängigkeiten. Im Juli war es „wp2shell", jetzt ist es PHP2Shell, und PHP 8.2 fällt zum 31. Dezember 2026 ohnehin aus dem Support. Die nächste Runde ist nur eine Frage der Zeit.

Für ein Unternehmen, das eine Website hat, weil es Kunden gewinnen will, ist das eine absurde Situation: Sie betreiben Infrastruktur, ohne es zu wollen, und tragen das Risiko, ohne es steuern zu können.

Wir bauen Websites deshalb seit einiger Zeit anders. Die Seite wird als fertige Dateien ausgeliefert — es läuft kein Programm auf dem Server, es gibt keine PHP-Version, kein Admin-Login, das jemand knacken könnte, keine Plugins, die veralten. Jede Website, die wir in diesem System gebaut haben, war von PHP2Shell nicht betroffen, nicht von wp2shell und wird es von der nächsten Lücke dieser Art auch nicht sein — nicht, weil wir schneller gepatcht hätten, sondern weil es nichts zu patchen gab. Sie ist nebenbei schneller und braucht keinen Wartungsvertrag, der nur Updates einspielt. Formulare, Buchungen und Inhalte, die sich ändern, laufen über abgeschottete Dienste, die wir für Sie betreiben.

Sicherheit ist bei uns kein Wartungspaket. Sie ist eine Eigenschaft der Bauweise.

Wenn Sie nach dieser Woche das Gefühl haben, dass Ihre Website Ihnen mehr Sorgen macht als Kunden bringt: Genau dafür gibt es unser Angebot ohne einmalige Aufsetzgebühr, nur mit einer monatlichen Pauschale. Wir übernehmen Ihre bestehende Seite, bauen sie in das neue System um, Inhalte und Rankings bleiben, und ab dann müssen Sie nie wieder einen Artikel wie diesen lesen. Erstgespräch anfragen →

Was gerade alle fragen.

• PHP-Projekt: Security advisory, Critical remote code execution vulnerabilities (21.10.2026)
• Advisory CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)
• Advisory CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)
• BSI: Cybersicherheitswarnung 2026-297981-1032 (PDF)
• Windows-FAQ: PHP2Shell — PHP-Sicherheitsupdates jetzt verfügbar (21.10.2026)