PHP2Shell: Warum ein WordPress-Update diesmal nicht hilft und wie du deine PHP-Version prüfst

01 / Was passiert ist

Was hinter PHP2Shell steckt.

PHP ist die Programmiersprache, mit der WordPress läuft, ebenso Drupal, Joomla und viele andere Systeme [5]. Am 20. Oktober kündigte das PHP-Sicherheitsteam ein dringendes Update für den Folgetag an und bewertete beide Lücken mit 9,2 von 10 Punkten auf der CVSS-Skala, also als kritisch [2][4]. Am 21. Oktober folgten die Korrekturen [1].

Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Vereinfacht gesagt räumt PHP nach einer abgebrochenen Anfrage seinen Arbeitsspeicher nicht sauber auf, etwa wenn der Speicher beim Verarbeiten eines Formulars ausgeht. Eine spätere Anfrage kann diese Reste erreichen [1][4]. Wer den Speicher geschickt präpariert, kann laut Automattic eigene Befehle auf dem Server ausführen lassen, daher der Name PHP2Shell [4].

Drei Punkte machen die Sache ernst [1][4][5]:

• Kein Login nötig: Der Angriff funktioniert über ganz normale Webanfragen.
• Kein Fehler in deiner Website nötig: Die Forscher von Wiz haben funktionierende Angriffe auf aktuelle WordPress-, Drupal- und Joomla-Installationen gezeigt. Selbst eine einfache „Hello World“-Seite kann verwundbar sein.
• Sehr alte Versionen betroffen: Die Lücken reichen bis PHP 5.4 zurück, also mehr als zehn Jahre.

Betroffen sind laut PHP-Projekt alle Installationen, die Webanfragen verarbeiten, egal ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Das höchste Risiko sieht das Team bei mod_php [1]. Eine vollständige Abhilfe ohne Update gibt es nicht [1].

02 / Zuständigkeit

Warum ein WordPress-Update diesmal nicht hilft.

Bei den letzten Vorfällen, etwa dem Schadcode in Rank Math PRO oder der Lücke Click2Shell, lag die Lösung in WordPress selbst: Plugin tauschen, Kern aktualisieren. Diesmal sitzt das Problem eine Ebene tiefer, in der Laufzeitumgebung, die WordPress überhaupt erst ausführt. Automattic schreibt ausdrücklich, dass ein Update von WordPress, Theme oder Plugins allein nicht schützt [4].

Wer PHP aktualisieren muss, hängt von deinem Hosting ab (Einschätzung):

• Shared Hosting und Managed WordPress: Der Hoster betreibt PHP. Du kannst meist nur zwischen Versionszweigen wählen, etwa 8.3 oder 8.4, die Sicherheitsupdates innerhalb eines Zweigs spielt der Anbieter ein. Hier ist dein Teil, nachzufragen und dir die Aktualisierung bestätigen zu lassen [4].
• Eigener Server oder VPS: Du oder deine Agentur seid selbst zuständig. Linux-Distributionen haben die Korrekturen laut PHP-Projekt vorab erhalten, aktualisierte Pakete kommen also über den normalen Paketmanager [1].
• WordPress.com und verwandte Plattformen: Automattic meldet, dass Seiten auf WordPress.com, WordPress VIP, WP Cloud und Pressable bereits geschützt sind. Dort musst du nichts tun [4].

Wer PHP auf dem eigenen Server aus Fremdquellen installiert, sollte einen Hinweis kennen: Das von Freiwilligen gepflegte Repository rpms.remirepo.net bekam am 21. Oktober laut PHP-Projekt noch keine Updates. Das Team rät, auf Pakete der Distribution umzusteigen oder selbst zu kompilieren [1].

03 / Version prüfen

So prüfst du deine PHP-Version in WordPress.

Dafür brauchst du keinen Serverzugang. WordPress zeigt die Angaben zum Server im Website-Zustand an [10]:

1. Im Dashboard Werkzeuge > Website-Zustand öffnen.
2. Auf den Reiter Bericht (englisch „Info“) wechseln.
3. Den Abschnitt Server aufklappen. Dort steht die PHP-Version mit voller Nummer, zum Beispiel 8.3.36.

Läuft eine veraltete PHP-Version, meldet WordPress das zusätzlich im Reiter Status als Hinweis „veraltete PHP-Version“ [10]. Alternativ zeigt dir das Kundenmenü deines Hosters die eingestellte Version.

So liest du das Ergebnis:

• 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und höher: Der Zweig ist auf dem korrigierten Stand [1].
• 8.2 bis 8.5, aber eine niedrigere Endnummer: Nicht automatisch unsicher. Linux-Distributionen spielen Korrekturen oft in ihre eigenen Pakete ein, ohne die Versionsnummer anzuheben [1]. Ob das bei dir passiert ist, kann dir nur der Hoster sagen. Frag nach.
• 8.1, 8.0, 7.4 oder älter: Diese Versionen bekommen vom PHP-Projekt keine Updates mehr [1][3]. Dazu gleich mehr.

Mailvorlage an deinen Hoster

Wenn du unsicher bist, schick deinem Hoster diese Nachricht. Ersetze die Angaben in eckigen Klammern:

Betreff: PHP2Shell (CVE-2026-109618 und CVE-2026-109619) – Stand für [Domain]

Hallo, auf meinem Paket [Vertragsnummer] läuft laut WordPress PHP [Version]. Bitte bestätigt mir, ob die Korrekturen für CVE-2026-109618 und CVE-2026-109619 auf diesem Server eingespielt sind, entweder als PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder als zurückportierter Patch. Falls nicht: Wann ist das geplant? Und auf welche PHP-Version kann ich wechseln, die bis mindestens Ende 2027 Sicherheitsupdates bekommt? Danke!

04 / Alte Versionen

PHP 8.1 oder älter? Dann plan den Umzug jetzt.

Für PHP 8.1 und ältere Zweige veröffentlicht das PHP-Projekt keine fertigen Updates mehr. Wegen der Schwere der Lücken hat das Team zwar minimale Korrekturen für PHP 7.4, 8.0 und 8.1 bereitgestellt, aber nur als Quellcode für Leute, die PHP selbst bauen [1]. Einige Distributionen und Anbieter mit Langzeitsupport liefern solche Korrekturen nach [1][4]. Darauf solltest du dich bei einer Geschäftswebsite nicht dauerhaft verlassen (Einschätzung).

Auch PHP 8.2 ist kein gutes Ziel mehr: Der Zweig bekommt nur noch bis zum 31. Dezember 2026 Sicherheitskorrekturen [1][3]. Automattic empfiehlt deshalb mindestens PHP 8.3 [4]. WordPress selbst empfiehlt ebenfalls PHP 8.3 oder neuer, läuft aber noch ab PHP 7.4, mit dem Hinweis, dass solche Versionen ihr Lebensende erreicht haben [9]. Die Unterstützungszeiten im Überblick [3]:

• PHP 8.2: Sicherheitsupdates bis 31. Dezember 2026
• PHP 8.3: Sicherheitsupdates bis 31. Dezember 2027
• PHP 8.4: Sicherheitsupdates bis 31. Dezember 2028
• PHP 8.5: Sicherheitsupdates bis 31. Dezember 2029

Der Wechsel des Versionszweigs ist bei den meisten Hostern ein Klick im Kundenmenü. Das Risiko liegt woanders: Alte Plugins oder ein selbst angepasstes Theme vertragen eine neue PHP-Version nicht immer. Mein Vorgehen (Einschätzung): Backup ziehen, auf einer Staging-Kopie umstellen, Startseite, Formulare, Kasse und Login durchklicken, erst dann die Live-Seite umstellen. Bietet dein Hoster gar keine aktuelle PHP-Version an, ist das ein Grund, den Anbieter zu wechseln.

05 / Wartung und Google

Seite offline nehmen? Warum Google dann eine 503 sehen will.

Laut Reuters haben einige Behörden, Schulen und Kliniken in Europa ihre Websites am 21. Oktober vorsorglich abgeschaltet, bis die Updates eingespielt waren [6]. Wenn du das auch tust, achte auf den Statuscode. Googles John Mueller hat dazu auf Bluesky geraten, solche Seiten mit HTTP 503 zu beantworten, statt Anfragen ins Leere laufen zu lassen oder 404 oder 500 auszugeben. Das gehe auch außerhalb von PHP, über den Webserver, eine andere DNS-Adresse oder das CDN [6].

Der Hintergrund: Ein 503 steht für „vorübergehend nicht erreichbar“. Bei Serverfehlern im 5xx-Bereich drosselt Google das Crawling, ignoriert die ausgelieferten Inhalte und behält bereits indexierte URLs zunächst im Index, entfernt sie aber irgendwann, wenn der Fehler bleibt [8]. Ein 404 oder 410 dagegen sagt Google, dass die Seite weg ist, ebenso ein noindex. Beides führt laut Google dazu, dass URLs aus der Suche fallen [7].

Google selbst rät, eine Website möglichst gar nicht abzuschalten. Wenn es sein muss, dann mit 503 für ein bis zwei Tage. Für die Wartungsseite empfiehlt Google [7]:

• den Header Retry-After mit einer realistischen Dauer oder Uhrzeit,
• statisches HTML mit Inline-CSS und möglichst wenigen externen Dateien,
• einen klaren Hinweis für Besucher, wann die Seite zurück ist und wie sie dich erreichen,
• die robots.txt nicht mit 503 auszuliefern, weil das jedes Crawling blockiert, und sie auch nicht auf „alles sperren“ zu stellen,
• den Statuscode vorher mit curl -I -X GET "https://www.deine-domain.de/" zu prüfen.

Der Haken am WordPress-Wartungsmodus

WordPress hat einen eingebauten Wartungsmodus, den es bei Updates nutzt. Er liefert korrekt einen 503 mit Retry-After: 600, also zehn Minuten [11]. Nur läuft er, wie fast alle Wartungsmodus-Plugins, selbst in PHP. Genau das willst du in diesem Fall vermeiden, solange PHP ungepatcht ist. Deshalb Muellers Hinweis, den 503 außerhalb von PHP zu erzeugen [6]. Praktisch heißt das (Einschätzung): Bitte deinen Hoster, die Seite auf Serverebene in Wartung zu setzen, oder nutze eine Wartungsregel im CDN, falls du eines davorgeschaltet hast. Auf Apache-Servern geht es auch mit einer Regel in der .htaccess, die alle Anfragen außer robots.txt und einer statischen Wartungsseite mit 503 beantwortet. Teste so eine Regel aber vorher, ein Tippfehler legt die ganze Seite lahm.

Danach: Search Console prüfen

Ist die Seite zurück, prüfst du in der Google Search Console zwei Berichte (Einschätzung): Unter Einstellungen > Crawling-Statistiken siehst du, ob Googlebot Serverfehler erhalten hat und ob die Antworten wieder normal sind. Im Bericht Seiten (Indexierung) erkennst du, ob URLs mit „Serverfehler (5xx)“ oder „Nicht gefunden (404)“ auftauchen. Startseite und wichtige Unterseiten kannst du mit der URL-Prüfung neu crawlen lassen, für viele Seiten reicht die Sitemap [7]. Sobald der Server wieder mit 200 antwortet, fährt Google das Crawling schrittweise hoch [8].

FAQ

Häufige Fragen zu PHP2Shell.

Reicht es, WordPress auf die neueste Version zu bringen?

Nein. Die Lücken stecken in PHP, nicht in WordPress. Updates von Kern, Theme und Plugins bleiben sinnvoll, schließen PHP2Shell aber nicht [4].

Was kann ich tun, wenn mein Hoster noch nicht aktualisiert hat?

Die Zeit überbrücken, mehr nicht. Automattic nennt eine Web Application Firewall, für die etwa Cloudflare bereits Regeln ausgeliefert hat, und das Abschalten von Datei-Uploads, wo keine gebraucht werden [4]. Das PHP-Projekt beschreibt weitere Einstellungen für Serveradmins, betont aber, dass nur das Update vollständig schützt [1].

Schadet eine kurze Wartung meinem Ranking?

Ein paar Stunden mit sauberem 503 gelten bei Google als vorübergehend, indexierte URLs bleiben zunächst erhalten [7][8]. Riskant wird es, wenn die Seite über Tage Fehler liefert oder mit 404, 410 oder noindex abgeschaltet wird [7].

Quellen

Quellen

1. PHP: „Security advisory: Critical remote code execution vulnerabilities, update now“ (CVE-2026-109618, CVE-2026-109619; PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35), 21. Oktober 2026 – php.net · abgerufen 22.10.2026.
2. PHP: „Upcoming Critical PHP Security Release“ (CVSS v4.0 9.2), 20. Oktober 2026 – php.net · abgerufen 22.10.2026.
3. PHP: „Supported Versions“ – php.net · abgerufen 22.10.2026.
4. Automattic: „Your Sites Are Protected Against the PHP2Shell Vulnerabilities“, 21. Oktober 2026 – automattic.com · abgerufen 22.10.2026.
5. Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld, Tomer Schwartz): „PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet“, 21. Oktober 2026 – wiz.io · abgerufen 22.10.2026.
6. Search Engine Roundtable (Barry Schwartz): „Google On Taking Sites Down When Fixing The Emergency PHP Exploit – PHP2Shell“ (mit Zitat von John Mueller und Verweis auf Reuters), Oktober 2026 – seroundtable.com · abgerufen 22.10.2026.
7. Google Search Central: „Temporarily pause or disable a website“, zuletzt aktualisiert 10. Dezember 2025 – developers.google.com · abgerufen 22.10.2026.
8. Google Search Central: „How HTTP status codes, and network and DNS errors affect Google Search“ – developers.google.com · abgerufen 22.10.2026.
9. WordPress.org: „Requirements“, zuletzt geändert 7. Mai 2026 – wordpress.org · abgerufen 22.10.2026.
10. WordPress.org Documentation: „Site Health screen“, zuletzt geändert 12. Juli 2026 – wordpress.org · abgerufen 22.10.2026.
11. WordPress Developer Resources: „wp_maintenance()“ – developer.wordpress.org · abgerufen 22.10.2026.

Alle Quellen am 22. Oktober 2026 abgerufen. Aussagen ohne belastbare Quelle sind im Text als Einschätzung gekennzeichnet; die Ziffern in eckigen Klammern verweisen auf die Nummern dieser Liste.