PHP2Shell: Was die PHP-Lücke für deine WordPress-Seite bedeutet

Am 21. Oktober 2026 hat das PHP-Team zwei kritische Sicherheitslücken geschlossen, die unter dem Namen PHP2Shell bekannt wurden. Behörden haben daraufhin vorsorglich ihre Websites vom Netz genommen, die Tagesschau hat berichtet, und in deinem Postfach liegt vielleicht schon eine Warnmail deines Hosters.

Wenn du eine WordPress-Seite betreibst, betrifft dich das sehr wahrscheinlich. WordPress läuft auf PHP, und PHP2Shell sitzt genau dort: nicht in einem Plugin, nicht in WordPress selbst, sondern eine Ebene darunter. Dieser Artikel erklärt ohne Fachchinesisch, was passiert ist, woran du erkennst, ob deine Seite sicher ist, und was du jetzt tun solltest.

Stand dieses Artikels: 29. Oktober 2026. Alle Angaben stammen aus den Sicherheitshinweisen von PHP, CERT-EU, Tenable und heise, die Quellen stehen am Ende.

Die kurze Version für Eilige

Was: Zwei Lücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619), beide mit 9,2 von 10 Punkten als kritisch eingestuft. Angreifer können damit ohne Login eigenen Code auf dem Server ausführen.
Wer ist betroffen: Praktisch jede PHP-Installation, die Webseiten ausliefert, also auch fast jede WordPress-Seite. Laut der Analyse von Calif reicht der betroffene Code bis PHP 5.4 zurück.
Sicher sind: PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder neuer. Für 7.4 bis 8.1 gibt es nur Korrekturen im Quellcode, ältere Versionen bleiben ungepatcht.
Wird schon ausgenutzt: Erste Angriffsversuche gab es am 17. Oktober, vier Tage vor dem Patch. Am 26. Oktober hat die US-Behörde CISA beide Lücken als aktiv ausgenutzt eingestuft.
Was du tun musst: Deinen Hoster fragen oder selbst prüfen, ob PHP aktualisiert und neu gestartet wurde. Danach WordPress, Plugins und Theme aktualisieren.
Was wir daraus lernen: Eine WordPress-Seite ist so sicher wie ihr schwächstes Glied. Davon gibt es viele, und eines liegt nicht einmal in deiner Hand.

Ein Haus mit Rissen im Fundament neben einem Haus auf festem Grund

Was ist PHP2Shell?

PHP ist die Programmiersprache, in der WordPress geschrieben ist. Jedes Mal, wenn jemand deine Seite aufruft, startet dein Server PHP, und PHP baut die Seite aus Datenbank, Theme und Plugins zusammen.

PHP2Shell sind zwei Fehler in dieser Maschine:

CVE-2026-109618 betrifft den Umgang mit vollem Arbeitsspeicher. Läuft PHP mitten in der Verarbeitung einer Anfrage der Speicher aus, etwa beim Hochladen eines Formulars, kann ein halb fertiger Zustand übrig bleiben. Beim Aufräumen behandelt PHP diese Daten dann fälschlich als gültig, und Angreifer können genau diese Lücke mit eigenen Daten füllen.
CVE-2026-109619 ist ein sogenannter Use-after-free-Fehler: Reste einer früheren Anfrage zeigen auf bereits freigegebenen Speicher, und eine spätere Anfrage an denselben Prozess kann das ausnutzen.

Beide Lücken führen im schlimmsten Fall zum Gleichen: Ein Fremder schickt eine präparierte Anfrage an deine Website und bekommt eine Shell, also eine Kommandozeile auf deinem Server. Daher der Name. Laut PHP ist das Risiko bei Apache mit mod_php am höchsten, wo der Angriff schon funktioniert, bevor überhaupt WordPress-Code läuft. Betroffen sind aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.³

Die Entdecker bei Calif zeigten in einem kurzen Video, wie sie damit nach 38 Sekunden Systembefehle auf einem Webserver mit dem PHP-Framework Laravel ausführen.⁴

Ein Schichtenstapel aus Server, PHP, Plugins und Website, mit einer Bruchlinie in der PHP-Schicht

Warum das für WordPress so wichtig ist

Bei WordPress denken die meisten zuerst an Plugins, wenn es um Sicherheit geht. Das ist auch berechtigt: Allein 2025 wurden im WordPress-Umfeld 11.334 neue Lücken gefunden, 91 % davon in Plugins.¹

PHP2Shell zeigt aber, dass eine WordPress-Seite aus mehreren Schichten besteht, und jede davon kann brechen:

Der Server mit Betriebssystem und Webserver
PHP, das alles ausführt ← hier sitzt PHP2Shell
WordPress selbst
Plugins und Theme
Deine Inhalte und Zugangsdaten

Auf die Schichten 3 bis 5 hast du als Seitenbetreiber Einfluss. Die Schichten 1 und 2 gehören bei den meisten kleinen Websites dem Hoster. Wenn er nicht schnell genug aktualisiert, hilft es dir nichts, dass du alle Plugins aktuell hältst.

Was bisher passiert ist

17. Oktober: Amazon Threat Intelligence beobachtet einen ersten Angriffsversuch, vier Tage bevor die Lücken öffentlich sind.³
20. Oktober: Die CVE-Nummern tauchen auf Hacker News und in sozialen Medien auf. Das PHP-Team kündigt für den nächsten Tag ein Sicherheitsupdate an und zieht es um einen Tag vor.³
21. Oktober, 14 Uhr UTC: PHP veröffentlicht die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.² Behörden, Kliniken und Hoster in Europa nehmen vorsorglich Websites vom Netz.
23. Oktober: Der Scanner von Censys findet weltweit über 41 Millionen PHP-Dienste mit anfälligen Versionsnummern, davon rund 4,2 Millionen in Deutschland, dem zweitgrößten Land nach den USA.⁵
26. Oktober: CISA nimmt beide Lücken in ihren Katalog aktiv ausgenutzter Schwachstellen auf. Trail of Bits bestätigt funktionierende Exploits gegen PHP 8.2 bis 8.5 vor dem Patch.³
27. Oktober: heise berichtet über erste bestätigte erfolgreiche Angriffe.⁶

Eine Zeitleiste, auf der sich nach dem Patch Angriffswellen ausbreiten

Welche PHP-Versionen sind sicher?

PHP-Zweig	Sicher ab	Hinweis
8.5	8.5.12	offizielles Update
8.4	8.4.27	offizielles Update
8.3	8.3.36	offizielles Update
8.2	8.2.35	offizielles Update, Support endet am 31.12.2026
7.4 bis 8.1	kein Release	nur Korrekturen im Quellcode, Hoster muss selbst bauen
5.4 bis 7.3	nie	bleiben offen

Ein Haken: Linux-Distributionen wie Debian oder Ubuntu spielen Sicherheitskorrekturen oft in ältere Versionsnummern ein. Eine angezeigte „8.2.30“ kann bei ihnen also schon gepatcht sein. Umgekehrt nützt das Update nichts, solange PHP nicht neu gestartet wurde, denn laufende Prozesse arbeiten mit dem alten Code weiter.³

So prüfst du deine WordPress-Seite

1. Im WordPress-Admin nachsehen. Unter Werkzeuge → Website-Zustand → Bericht → Server steht die PHP-Version, die WordPress gerade benutzt.

2. Von außen prüfen. Mit unserem kostenlosen WordPress-Sicherheitscheck siehst du, ob dein Server seine PHP-Version verrät und ob sie den Fix enthält. Der Check zeigt auch, welche Plugins von außen sichtbar sind, ob Benutzernamen öffentlich abrufbar sind und welche Sicherheits-Header fehlen. Er prüft nur öffentlich, ohne Login-Versuche. Rund 54 % der PHP-Server verbergen ihre Version allerdings, dann kann kein externer Check PHP2Shell sicher beurteilen.⁵

3. Beim Hoster nachfragen. Die zuverlässigste Antwort ist eine kurze Mail: „Ist PHP auf meinem Paket gegen CVE-2026-109618 und CVE-2026-109619 gepatcht und neu gestartet?“ Seriöse Hoster haben dazu inzwischen eine Statusseite.

Eine Lupe über einem Server mit Statuslampen neben einer Checkliste

Was du jetzt tun solltest

PHP aktualisieren lassen (oder selbst aktualisieren) und den PHP-Dienst neu starten.
WordPress, Theme und alle Plugins aktualisieren. PHP2Shell ist ein guter Anlass, endlich auch den Rest auf Stand zu bringen.
Ungenutzte Plugins löschen, nicht nur deaktivieren. Jedes Plugin ist zusätzlicher Code.
Auf Spuren achten: neue Administratoren, die du nicht kennst, unbekannte Dateien im Ordner wp-content, plötzliche Weiterleitungen auf fremde Seiten. Lief dein Server ungepatcht, als die Angriffe begannen, lohnt sich ein Blick, auch wenn alles normal aussieht.
Passwörter wechseln, wenn es Hinweise auf einen Einbruch gibt: WordPress-Admins, FTP/SFTP und die Datenbank.
Backup prüfen: Hast du ein Backup von vor dem 17. Oktober, das du im Notfall einspielen kannst?

Was PHP2Shell über WordPress lehrt

PHP2Shell ist kein Sonderfall. Es ist nur ein besonders sichtbarer Fall eines Musters, das WordPress-Betreiber seit Jahren kennen: Die Seite ist nie fertig. Irgendwo in Server, PHP, WordPress oder einem der Plugins steckt immer die nächste Lücke, und Angreifer sind schnell. Bei schweren WordPress-Lücken vergehen im Mittel fünf Stunden bis zur massenhaften Ausnutzung, und 46 % der Lücken hatten noch keinen Patch, als sie öffentlich wurden.¹

Für einen Onlineshop oder ein Portal mit Login ist dieser Aufwand der Preis für die Funktionen. Für die typische Firmen-, Praxis- oder Vereinsseite stellt sich aber eine ehrliche Frage: Braucht diese Seite überhaupt PHP? Öffnungszeiten, Leistungen, Team, ein Kontaktformular: Das lässt sich auch als fertige, statische Seite ausliefern. Ohne PHP, ohne Datenbank und ohne Plugins gibt es für Lücken wie PHP2Shell schlicht nichts, woran sie ansetzen könnten.

Ein glatter Block, an dem Angriffe abprallen, als Symbol für eine statische Website

Genau das machen wir mit getmind: Wir bauen deine bestehende WordPress-Seite 1:1 als statische Website neu, mit gleichen Inhalten und gleichen Adressen, damit dein Google-Ranking bleibt. Du bekommst einen Admin, in dem du Texte selbst änderst oder der KI sagst, was sich ändern soll. Um Server und Technik kümmern wir uns. Der Umbau kostet einmalig 99 €, danach ist das Hosting drei Monate gratis und kostet ab dem vierten Monat 4,99 € im Monat, inklusive 150 KI-Credits. Und wenn du nicht zufrieden bist, bekommst du innerhalb von 30 Tagen dein Geld zurück, bedingungslos.

Häufige Fragen

Ist meine WordPress-Seite von PHP2Shell betroffen?

Sehr wahrscheinlich war sie es, wenn sie vor dem 21. Oktober 2026 mit einer üblichen PHP-Version lief. Ob sie es noch ist, hängt davon ab, ob dein Hoster PHP auf 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder eine gepatchte Distributionsversion aktualisiert und neu gestartet hat.

Muss ich selbst etwas tun, wenn ich Shared Hosting habe?

PHP aktualisiert in der Regel der Hoster. Du solltest trotzdem nachfragen, ob das passiert ist, und WordPress, Theme und Plugins selbst aktuell halten.

Reicht ein Sicherheits-Plugin wie Wordfence?

Gegen PHP2Shell nicht zuverlässig. Bei mod_php greift der Angriff, bevor WordPress und damit jedes Plugin überhaupt geladen ist. Sicherheits-Plugins helfen gegen viele andere Angriffe, ersetzen aber kein PHP-Update.

Betrifft PHP2Shell auch meinen Windows-PC?

Nein, solange du dort keinen Webserver mit PHP betreibst. Es geht um Server, die Webseiten mit PHP ausliefern.

Mein Hoster sagt, die Versionsnummer sei alt, aber gepatcht. Stimmt das?

Das kann stimmen. Linux-Distributionen spielen Fixes oft in ältere Versionsnummern ein. Lass dir im Zweifel bestätigen, dass das Distributionspaket den Fix für beide CVEs enthält.

Wie erkenne ich, ob meine Seite schon angegriffen wurde?

Typische Spuren sind unbekannte Administratoren, neue oder veränderte PHP-Dateien in wp-content, Weiterleitungen auf fremde Seiten und Spam-Seiten in der Google-Suche zu deiner Domain. Im Zweifel hilft dein Hoster oder ein Sicherheitsdienstleister.

Ist eine statische Website wirklich sicherer?

Gegen diese Art von Lücke ja: Ohne PHP und ohne Datenbank kann niemand über eine Anfrage Code auf deiner Website ausführen. Den Server dahinter muss trotzdem jemand pflegen, bei getmind übernehmen wir das. Für Shops, Buchungen mit Bezahlung oder Mitgliederbereiche ist eine statische Seite allerdings nicht das Richtige.