Prüfen Sie nur Systeme, die Ihnen gehören oder für die Sie verantwortlich sind. Diese Seite und unser Checker vergleichen nur Versionsnummern, die Sie selbst eintippen, direkt in Ihrem Browser. Es wird nichts getestet, gesendet oder gescannt. Unabhängige Seite, nicht mit der PHP Group, WordPress.org oder Automattic verbunden.
Kurzantwort
Die php2shell-Lücken (CVE-2026-109618 und CVE-2026-109619) stecken in PHP, der Software unter WordPress, nicht in WordPress, Ihrem Theme oder Ihren Plugins. Wordfence schreibt in seinem Hinweis nach der Veröffentlichung der PHP-Updates, dass WordPress-Autoupdates die Lücken nicht beheben und PHP vom Hoster oder auf dem eigenen Server aktualisiert werden muss (Wordfence). Ein WordPress-Update behebt das Problem also nicht.
So gehen Sie vor:
- Öffnen Sie im WordPress-Backend Werkzeuge > Website-Zustand > Info > Server und lesen Sie die PHP-Version ab.
- Liegt sie unter 8.2.35, 8.3.36, 8.4.27 bzw. 8.5.12 (oder sind Sie auf 8.1 oder älter), gilt die Nummer als nicht ausreichend; Hoster und Panels spielen Fixes teils ohne neue Nummer ein (siehe Tabelle unten). Fragen Sie in dem Fall Ihren Hoster, ob PHP aktualisiert ist, oder stellen Sie es selbst im Kundenmenü um.
- Danach Website-Zustand erneut öffnen und die Version kontrollieren.
Warum die Eile: Die PHP Group schreibt, die Lücken könnten unauthentifizierte Remote-Code-Ausführung erlauben, also das Ausführen von Code auf dem Server ohne Login (php.net). Das BSI führt die Meldung im CERT-Bund-Portal als “kritisch” (WID-SEC-2026-4055). Hintergrund: php2shell: Was ist das und was tun?
Schritt 1: PHP-Version in WordPress ablesen (Website-Zustand)
Die Version steht im Backend unter Werkzeuge > Website-Zustand > Info > Server (WordPress.org). Vergleichen Sie so:
| Was Sie sehen | Bedeutung |
|---|---|
| 8.5.12 oder höher, 8.4.27 oder höher, 8.3.36 oder höher, 8.2.35 oder höher | Mindestens der Stand der PHP Group für die jeweilige Reihe. |
| Gleiche Reihe (Branch), aber niedriger (z. B. 8.3.30) | Laut Versionsnummer allein betroffen, sofern Ihr Hoster keinen Fix ohne neue Nummer eingespielt hat (Backport, siehe letzte Zeile). Laut GitHub-Advisory der PHP Group sind 8.2.* unter 8.2.35, 8.3.* unter 8.3.36, 8.4.* unter 8.4.27 und 8.5.* unter 8.5.12 betroffen (GHSA-w8hw-w9fx-j79w); die NVD nennt in ihrer CPE-Konfiguration zusätzlich jede Version unter 8.2.35, also auch 8.1 und älter (NVD). PHP aktualisieren oder beim Hoster nachfragen. |
| 8.1, 8.0, 7.4 oder älter | Die PHP Group schreibt, dass 8.1 und älter keine Updates mehr erhalten. Für 7.4, 8.0 und 8.1 gibt es nur minimale Quellcode-Patches für Leute, die PHP selbst kompilieren, aber keine Release-Version. Für noch ältere Versionen nennt php.net nichts. Wechseln Sie auf eine unterstützte Version oder fragen Sie Ihren Hoster, ob er einen eigenen Fix ausliefert. |
| Zahl wirkt alt, PHP kommt aber aus einer Linux-Distribution, einem Hosting-Panel oder vom Hoster | Fixes werden dort teils zurückportiert (Backport), die Versionsnummer ändert sich dann unter Umständen nicht; Plesk nennt das für 7.4.33, 8.0.30 und 8.1.34; Hetzner meldet eingespielte Patches für 5.6, 7.3, 7.4 und 8.0 bis 8.5, ohne Versionsnummern zu nennen; und bei Ubuntu 24.04 steht der Fix in einer Paketversion wie 8.3.6-0ubuntu0.24.04.13. Vergleichen Sie mit der gepatchten Paketversion bzw. der Aussage des Anbieters, nicht mit der Upstream-Nummer (Fixversionen). |
Zwei Stolperfallen:
- “Hauptsache 8.3 oder neuer” reicht nicht mehr. Eine neue Reihe allein genügt nicht: Laut PHP Group sind 8.3 unter 8.3.36, 8.4 unter 8.4.27 und 8.5 unter 8.5.12 betroffen. Ob eine niedrigere Nummer bei Ihrem Hoster trotzdem gepatcht ist, sagt nur dessen Aussage.
- Kommandozeile und Website können abweichen.
php -vim Terminal zeigt manchmal ein anderes PHP als das, was Ihre Seite ausliefert. Der Website-Zustand wird im Kontext Ihres Webservers ermittelt, vertrauen Sie also ihm.
Tippen Sie Ihre Nummer in den Checker, um sie mit den Fixversionen zu vergleichen.
Schritt 2: Wer aktualisiert bei Ihnen PHP?
PHP liegt auf dem Server. Sie ändern es in den Einstellungen Ihres Hosters oder lassen es dort ändern (WordPress.org). Je nach Angebot macht das Ihr Hoster oder Sie selbst auf Ihrem Server (Wordfence). Bei Shared Hosting und Managed-Paketen fragen Sie den Hoster; auf einem eigenen VPS oder Root-Server sind Sie oder Ihre Agentur zuständig. Im Kundenmenü heißt die Einstellung je nach Anbieter etwa “PHP-Version” oder “PHP-Einstellungen”.
Deutsche und europäische Hoster
Stand unserer Prüfung: 22.10.2026, jeweils nach der eigenen Statusseite des Anbieters. Statusseiten ändern sich laufend, öffnen Sie den Link, bevor Sie sich verlassen.
| Hoster | Aussage des Anbieters (sinngemäß) | Quelle |
|---|---|---|
| IONOS | Laut IONOS sind die offiziellen PHP-Updates auf allen von IONOS selbst betriebenen Plattformen bereits eingespielt (Störungsmeldung am 22.10. um 10:10 UTC als behoben markiert); Kunden müssen nichts tun. Wer PHP selbst betreibt, etwa auf einem VPS oder Dedicated Server, muss selbst updaten. | IONOS Status |
| Hetzner | Hat laut Meldung Patches für PHP 7.4 und 8.0 bis 8.5 und danach auch für die übrigen PHP-Versionen 5.6 und 7.3 auf allen Webhosting- und Managed-Servern eingespielt. Dedicated- und Cloud-Server-Kunden werden per E-Mail informiert und patchen selbst. | Hetzner Status |
| netcup | Die Statusmeldung vom 21.10. („Our systems are temporarily unavailable“) ist als erledigt markiert. Laut Statusmeldung sind inzwischen alle Webhosting-Pakete (einschließlich Reseller) und alle Managed Server gepatcht und online; auf ihnen sei keine ungepatchte PHP-Version online. Root-Server, VPS und Managed Cloud müssen selbst gepatcht werden. | netcup Status |
| Infomaniak (CH) | Laut letzter Meldung (22.10., 07:42, Ortszeit laut Seite) sind die Sicherheitsfixes auf der gesamten Shared-Web-Hosting- und Cloud-Server-Infrastruktur für PHP 8.5, 8.4, 8.3, 8.2, 8.1, 8.0 und 7.4 ausgerollt; die PHP-Versionsnummern bleiben unverändert. Datei-Uploads sind bei mehreren Diensten vorübergehend eingeschränkt. Wer eine PHP-Version älter als 7.4 nutzt, muss upgraden. Die Meldung ist auf Französisch. | Infomaniak Status |
| Strato, ALL-INKL.COM, Host Europe, Mittwald | Kein Eintrag: Zu diesen Anbietern haben wir keine Quelle geprüft. Schauen Sie auf deren Statusseite oder fragen Sie den Support schriftlich. | – |
“Wird ausgerollt” oder “Schutzmaßnahme” heißt nicht, dass Ihr Paket schon eine gefixte PHP-Version nutzt. Zeigt der Website-Zustand weiter eine betroffene Nummer, fragen Sie den Support schriftlich, wann Ihr Tarif die korrigierte Version bekommt. Mehr Anbieter mit Prüfdatum: Hosting-Status.
Managed-WordPress-Hosting und Shared Hosting international
Auch hier gilt: Es sind die Worte des Anbieters, keine Garantie für Ihre Installation. “Protected” ist keine Versionsangabe.
| Anbieter | Aussage | Quelle |
|---|---|---|
| WordPress.com (Automattic) | Seiten auf der Automattic-Plattform seien “protected”. Gilt nicht für selbst gehostetes WordPress. | Automattic Status |
| Pressable | Sites seien bereits gegen beide Lücken geschützt, kein Handeln nötig. | Pressable |
| Pantheon | Gepatchte PHP-Builds sind auf allen Live-Umgebungen (PHP 8.2 oder neuer sowie alle LTS-Versionen), allen Umgebungen im SFTP-Modus und allen Pre-Production-Umgebungen eingespielt. Free-/Sandbox-Umgebungen sollen in den nächsten 24 bis 48 Stunden folgen. Kein Handeln nötig. | Pantheon Status |
| WP Engine | Das Einspielen der Sicherheitspatches sei abgeschlossen, die Patches seien auf die jeweilige PHP-Version angewendet, kein Handeln nötig. Genannte Versionen: 7.4.33.17, 8.2.35, 8.4.27, 8.5.12 (7.4.33.17 ist ein eigener WP-Engine-Build). | WP Engine |
| Flywheel | WP Engine habe das Einspielen der PHP-Sicherheitspatches auf der Flywheel-Plattform abgeschlossen, kein Handeln nötig. Schutzmaßnahmen auf CDN- und Host-Ebene waren zusätzlich aktiv. | Flywheel |
| Kinsta | Laut Kinsta sind alle Sites geschützt und die PHP-Sicherheitsupdates auf der gesamten Plattform ausgerollt (Störungsmeldung am 22.10. um 08:26 UTC als behoben markiert). Frühere Meldungen nannten Patches für PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 und 8.5 und kündigten an, dass Cloudflare-Firewall-Schutz und lokale Konfigurationsänderungen bis auf Weiteres aktiv bleiben; die letzte Meldung erwähnt sie nicht mehr. | Kinsta Status |
| Cloudways | Laut Cloudways ist der Rollout der PHP-Sicherheitspatches abgeschlossen und alle aktiven Server sind aktualisiert (22.10., 10:11 UTC); auf „Autonomous“ waren die Patches für alle Anwendungen bereits um 01:02 UTC eingespielt. Das Support-Team meldet sich proaktiv bei einer kleinen Gruppe von Kunden, deren Umgebungen zusätzliche Hilfe brauchen. Der Rollout umfasste alle unterstützten PHP-Versionen einschließlich veralteter ab 5.6; Kunden mussten laut Cloudways nichts tun. Zuvor hatte Cloudways die von der PHP Group empfohlenen Zwischenlösungen auf Konfigurationsebene eingespielt. | Cloudways Status |
| Nexcess | Laut Meldung vom 22.10. (10:42 EDT = 14:42 UTC) liefen Ausrollen und Prüfung der gepatchten PHP-Builds weiter; laut der Meldung von 15:28 EDT (19:28 UTC) würden die übrigen Umgebungen noch geprüft. Am 21.10. hatte Nexcess noch gemeldet, es seien keine Patches in die Produktion ausgerollt worden. | Nexcess Status |
| SiteGround | Schutz auf Serverebene, “nichts zu tun”. Meldung stammt von vor dem PHP-Release und nennt keine gefixten PHP-Builds. | SiteGround |
Hosting-Panels
Viele Hoster nutzen Plesk oder cPanel. Laut Plesk sind korrigierte Builds für PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 unter Linux und unter Windows verfügbar. Unter Linux behalten 7.4.33, 8.0.30 und 8.1.34 ihre Nummern; die am 21.10.2026 gebauten Versionen enthalten die Fixes. Plesk empfiehlt, Plesk auf die aktuelle Version zu aktualisieren (Plesk-KB). cPanel hat mit EasyApache 4 25.91 (21.10.) Fixes für ea-php82 bis ea-php85 und Backports für die abgekündigten ea-php74, ea-php80 und ea-php81 veröffentlicht (cPanel). Mehr dazu im Hosting-Leitfaden.
Schritt 3: Plugins und Themes vor einem PHP-Wechsel testen
Ein Update innerhalb derselben Reihe (z. B. 8.3.30 auf 8.3.36) ist ein Patch-Update und bricht selten etwas. Ein Wechsel der Reihe (z. B. 8.1 auf 8.3) kann alte Plugins und Themes lahmlegen. Gehen Sie so vor (WordPress.org-Anleitung):
- Backup von Dateien und Datenbank anlegen. Für eine Wiederherstellung muss der Hoster auch die alte PHP-Version wieder einstellen können.
- WordPress, Themes und Plugins aktualisieren (Dashboard > Aktualisierungen) und prüfen, ob die Seite normal läuft.
- Plugin “PHP Compatibility Checker” ausführen. WordPress.org weist darauf hin, dass es nicht perfekt ist und etwas übersehen oder fälschlich melden kann. Fragen Sie bei gemeldeten Plugins den Autor oder tauschen Sie sie aus.
- Wenn möglich, erst eine Staging-Kopie oder einen Testlauf zu einer ruhigen Zeit nutzen. Dann PHP im Kundenmenü umstellen; Startseite, Login, Formulare und gegebenenfalls den Checkout testen.
- Bei Fehlern (z. B. “kritischer Fehler”): PHP-Version beim Hoster zurückstellen, Backup einspielen, das Plugin beheben oder ersetzen, dann erneut versuchen. Bleiben Sie nicht dauerhaft auf einer betroffenen Version.
Prüfen Sie, ob Ihre WordPress-Version die Ziel-PHP-Version unterstützt (WordPress-Kompatibilitätstabelle):
| Ziel-PHP | Erste WordPress-Version mit Support laut Handbuch (anfangs teils nur Beta) |
|---|---|
| 8.2 | 6.1 |
| 8.3 | 6.4 |
| 8.4 | 6.7 |
| 8.5 | 6.9 |
PHP 8.2 bekommt laut php.net nur noch bis 31.12.2026 Sicherheitsfixes, 8.3 bis 31.12.2027, 8.4 bis 31.12.2028 und 8.5 bis 31.12.2029. Wenn möglich, springen Sie daher gleich auf 8.4 oder 8.5, falls Ihre Plugins mitspielen; 8.2 ist nur ein kurzer Zwischenstopp. Bleibt Ihr Paket auf einer PHP-Version ohne offizielle Fixversion, kann kein Plugin das ersetzen. Fragen Sie den Hoster nach einem eigenen Backport.
Schritt 4: Kontrollieren
- Website-Zustand > Info > Server erneut öffnen und die PHP-Version ablesen.
- Zahl im Checker eintippen. Für Distributionspakete zählt die gepatchte Paketversion des Anbieters, siehe PHP-Version prüfen.
- Startseite, Login und Formulare kurz durchklicken.
Plugins und Firewalls sind kein Ersatz
- Die PHP Group schreibt: “There are no complete mitigations, updating is the only safe choice” (php.net), sinngemäß: Es gibt keine vollständigen Gegenmaßnahmen; nur ein Update ist eine vollständige Lösung. Außerdem sehe sie das Risiko bei mod_php am höchsten.
- Patchstack: PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das gepatchte Paket des Anbieters aktualisieren, und vor inoffiziellen “Fix”-Plugins und kopierten Snippets wird gewarnt (Patchstack).
- Sucuri: “WAF protection does not replace patching PHP on your origin server” (Sucuri). Auch Cloudflare nennt seine WAF-Regeln nur eine zusätzliche Schicht (Cloudflare).
- Wordfence hat nach dem Release mitgeteilt, dass PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beide Lücken beheben. In einem Folgebeitrag (22.10.2026) schreibt Wordfence, seine Firewall schütze nur die WordPress-Anwendungsebene, und: “For these vulnerabilities, updating and restarting PHP is essential.” (Wordfence). Eine Firewall-Regel für diese CVEs kündigt Wordfence nicht an.
Offizielle Stellen
- BSI/CERT-Bund: WID-SEC-2026-4055, “PHP: Mehrere Schwachstellen ermöglichen Codeausführung” (zuerst ”… ermöglichen nicht spezifizierten Angriff”), Einstufung kritisch. Die Meldung erschien erstmals am 21.10.2026 vor dem Release und wurde am 22.10.2026 aktualisiert; Titel, Datum und CVE-Nummern haben wir bestätigt.
- CERT-EU: Advisory 2026-018. Nach CERT-EU kursieren erste Proofs of Concept; das erhöhe die Wahrscheinlichkeit, dass Angreifer die Lücken bereits ausnutzen.
- CERT.at (Österreich) hat laut ENISA-Liste eine eigene Meldung veröffentlicht; den Inhalt der Seite haben wir nicht geprüft.
- PHP-Projekt: Sicherheitshinweis, NVD.
- In der CISA-Liste ausgenutzter Lücken (KEV) standen die beiden CVEs bei unserer letzten Prüfung (22.10.2026, gegen 12:36 UTC) nicht; der aktuelle Katalog 2026.10.21 (freigegeben am 21.10.2026 um 14:04 UTC) war weiterhin der neueste. Der Katalog wird laufend aktualisiert, der Stand kann sich also ändern.
Persönlicher Patch-Plan
Wenn Sie die Schritte für Ihren Hoster und Ihre WordPress-Version nicht selbst zusammensuchen möchten: Für 49 US-Dollar erhalten Sie einen persönlichen Patch-Plan, schriftliche Schritte für genau Ihr Setup per E-Mail innerhalb von 24 Stunden. Wir loggen uns nie auf Ihrem Server ein. Details: Patch-Plan.