Was PHP2Shell für Ihre Website bedeutet und was Sie noch heute überprüfen sollten
Zuletzt aktualisiert: 21. Oktober 2026, 18:00 UTC · Von Struc Răzvan, STNS Development
Kurz gesagt
PHP2Shell ist der Name für zwei kritische PHP-Schwachstellen, CVE-2026-109618 und CVE-2026-109619, die beide vom PHP-Projekt mit einem CVSS-Wert von 9,2 eingestuft wurden.
Die Schwachstelle liegt in PHP selbst, nicht in Ihren Plugins oder Ihrem Theme.
Behobene Versionen: 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21. Oktober 2026.
Die Ausnutzung wird von einigen Anbietern gemeldet (Cloudflare, watchTowr) und von anderen nicht bestätigt (Huntress, NCSC-NL).
Heute: Finden Sie heraus, welche PHP-Version auf Ihrer Website läuft, und fragen Sie Ihren Hoster, wann diese aktualisiert wird.
Was ist PHP2Shell?
PHP2Shell bezeichnet zwei Fehler bei der Speicherverwaltung in der PHP-Engine, die es Angreifern ermöglichen können, ohne vorherige Anmeldung aus der Ferne Schadcode auf einem Webserver auszuführen.
Da das Problem in PHP selbst liegt, lässt es sich nicht durch das Aktualisieren eines Plugins oder Themes beheben. Sansec und Wiz haben nicht authentifizierte Angriffe auf aktuelle Versionen von WordPress, Drupal, Joomla, Magento, Laravel, Nextcloud und anderen demonstriert; Wiz zeigte zudem, dass selbst eine minimale „Hello World“-PHP-Seite ausgenutzt werden kann.
Sansec ergänzt, dass CVE-2026-109618 Passwörter, Token oder API-Schlüssel aus dem Serverspeicher lecken kann. Die beruhigende Nachricht: NCSC-NL stuft die Komplexität des Angriffs als hoch ein, und ein vollständiger Fix ist bereits verfügbar.
Ist meine Website betroffen?
Wenn Ihre Website auf PHP läuft und noch nicht auf eine korrigierte Version umgestellt wurde, sollten Sie davon ausgehen, dass sie betroffen ist, bis Ihr Hosting-Anbieter oder Entwickler das Gegenteil bestätigt.
Laut php.net ist jede PHP-Installation betroffen, die Webanfragen verarbeitet, wobei das höchste Risiko bei Apache mod_php besteht. Ob eine bestimmte Website gefährdet ist, können wir nicht sagen, ohne sie zu überprüfen, und wir scannen niemals Websites ohne die Erlaubnis des Eigentümers.
Welche PHP-Versionen beheben die Sicherheitslücke?
Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für alle älteren Versionen dieser Zweige ist weiterhin das PHP-Update erforderlich.
PHP-Branch
Korrigierte Version
Notizen
8,5
8.5.12
Veröffentlicht am 21. Okt. 2026
8,4
8.4.27
Veröffentlicht am 21. Okt. 2026
8,3
8.3.36
Veröffentlicht am 21. Okt. 2026
8,2
8.2.35
Veröffentlicht am 21. Okt. 2026; Ende des Lebenszyklus am 31. Dez. 2026
8,1, 8,0, 7,4
Keine offizielle Veröffentlichung
Minimale Backports für das Erstellen aus dem Quellcode; Linux-Distributionen und LTS-Anbieter haben Patches vorab erhalten
Älter
Keine Lösung
Sansec und Wiz führen den anfälligen Code auf PHP 5.4 zurück; führen Sie ein Upgrade auf einen unterstützten Branch durch
Führen Sie unter 8.2 jetzt das Patching durch und planen Sie den Wechsel auf einen neueren Branch vor Jahresende. Wenn Ihr Host PHP-Pakete aus einer Linux-Distribution oder von einem LTS-Anbieter verwendet, stimmt die Versionsnummer möglicherweise nicht mit der Tabelle überein. Fragen Sie daher nach, ob das Paket Korrekturen für beide CVEs enthält.
Wie finde ich heraus, welche PHP-Version meine Website verwendet?
Am schnellsten geht es über das Control Panel Ihres Hosters oder bei WordPress unter Werkzeuge → Website-Zustand → Bericht → Server, wo die PHP-Version angezeigt wird.
Hosting-Panel: Die meisten Panels zeigen die PHP-Version pro Domain an.
WordPress: Werkzeuge → Website-Zustand → Tab „Bericht“ → Server.
Individuelle Software: Fragen Sie Ihren Entwickler.
Entwickler: Befehlszeilen-PHP kann sich von dem PHP unterscheiden, das die Website bereitstellt; überprüfen Sie daher auch den Web-Handler.
Die vollständige Versionsnummer ist entscheidend: „8.3“ reicht nicht aus, Sie benötigen 8.3.36 oder neuer. Denken Sie auch an Staging-Kopien und vergessene Tools wie etwa ein altes phpMyAdmin.
Was sollte ich meinen Hosting-Anbieter fragen?
Fragen Sie nach, ob Ihre PHP-Version bereits gepatcht ist, und wenn nicht, wann dies der Fall sein wird und wie Sie bis dahin geschützt sind.
Sie können diese Fragen in ein Ticket einfügen:
Welche PHP-Version und welchen Handler verwendet mein Konto?
Ist es Version 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder ein Anbieter-Paket mit den Fixes für CVE-2026-109618 und CVE-2026-109619?
Wenn nicht, wann ist die Aktualisierung geplant und welche vorübergehenden Maßnahmen sind bis dahin aktiv?
Haben Sie Anzeichen einer Kompromittierung festgestellt und können Sie die Protokolle der letzten Tage aufbewahren?
Senden Sie Passwörter niemals per E-Mail oder Webformular; vereinbaren Sie stattdessen zuerst einen sicheren Kanal.
Warum ist eine vorübergehende Abhilfemaßnahme keine echte Lösung?
Vorübergehende Sicherheitsmaßnahmen erschweren zwar das Auslösen der Fehler, laut php.net machen sie eine Installation jedoch nicht sicher, da erst das Update die Schwachstelle behebt.
php.net listet Konfigurationsänderungen auf (siehe Infokasten), und Cloudflare hat WAF-Regeln veröffentlicht. Sie sind nützliche Übergangslösungen, können jedoch legitime Uploads beeinträchtigen, müssen auf jedem PHP-Worker angewendet werden und beheben den Fehler nicht an der Wurzel. Nutzen Sie sie, um Zeit zu gewinnen. Für PHP 8.1 oder älter ist für die meisten Unternehmen der einzig realistische Weg ein Upgrade auf eine unterstützte Version.
Was sind die Anzeichen dafür, dass ein Server kompromittiert sein könnte?
Bislang wurden noch keine bestätigten Kompromittierungsindikatoren (Indicators of Compromise) veröffentlicht, aber einige Auffälligkeiten sollten Sie gemeinsam mit Ihrem Hosting-Anbieter oder Entwickler prüfen. Huntress und Patchstack weisen auf folgende übergeordnete Signale hin:
Webserver-Prozesse (PHP-FPM, Apache), die Befehlszeilen-Shells oder Download-Tools starten;
ungewöhnliche Upload-Anfragen, gefolgt von Speicherlimit-Fehlern (Memory-Limit) oder wiederholten HTTP-500-Fehlern;
sehr große oder fehlerhafte Session-Cookies, unerklärliche Worker-Neustarts;
neue Dateien im Website-Ordner, neue geplante Aufgaben (Scheduled Tasks) oder neue Benutzerkonten.
Wenn Sie eines davon bemerken, bewahren Sie die Protokolle auf, stufen Sie den Server als möglicherweise kompromittiert ein und ändern Sie Datenbankpasswörter, API-Schlüssel sowie andere Zugangsdaten. Wir werden diese Seite aktualisieren, sobald Huntress die angekündigten Erkennungsregeln veröffentlicht.
Ist der WordPress-Vorfall bei UpdraftCentral Teil von PHP2Shell?
Nein, es handelt sich um einen separaten Vorfall aus derselben Woche und nicht um eine Code-Schwachstelle.
Patchstack hat eine Kampagne vom 18. bis 19. Oktober dokumentiert, bei der ein Angreifer mit gültigen, wahrscheinlich durchgesickerten UpdraftCentral-Schlüsseln Backdoor-Plugins auf verbundenen WordPress-Websites installiert hat. Wenn Sie UpdraftCentral verwenden, lassen Sie Ihren Entwickler die Verbindungsschlüssel entfernen und nach unbekannten Plugins wie „Site Health Cache“ suchen. Zwei verschiedene Probleme, eine schwierige Woche für WordPress.
Brauchen Sie Hilfe beim PHP-Update?
Ja: STNS Development kann das PHP-Update für Sie durchführen und auf grundlegende Anzeichen einer Kompromittierung prüfen.
Das umfasst das Versionsinventar, das Update- oder Anbieterpaket, temporäre Maßnahmen zur Risikominderung, wo nötig, und einen schriftlichen Upgrade-Plan. Es handelt sich nicht um eine vollständige forensische Untersuchung, und niemand kann ehrlich einen „100 % sicheren“ Server versprechen; wir bringen Sie auf eine fehlerbereinigte Version und reduzieren das Risiko. Erfahren Sie in unseren Fallstudien, wie wir arbeiten, oder kontaktieren Sie uns.
Technischer Kasten
CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): RCE über Speicherbeschädigung bei Speichermangel (Out-of-Memory); die Bereinigung behandelt teilweise initialisierte Anforderungsdaten als gültig. Ebenso Offenlegung von Speicherinhalten, selbst ohne session_start() (Sansec).
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): RCE über veralteten globalen Zustand, der von einer späteren Anforderung auf demselben Worker wiederverwendet wird.
Betroffene SAPIs: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed. Bekannte Auslöser: multipart/form-data-Anforderungen.
Vorläufige Abhilfemaßnahmen (php.net, kein Fix): für 109618, nicht überschreibbares memory_limit=-1 (php_admin_value), post_max_size 8M (32M mit Uploads), Proxy-Anforderungsbegrenzungen, kein RLIMIT_AS/RLIMIT_DATA; für 109619, session.upload_progress.enabled=0 mit einem Neustart aller Worker, plus fatal_error_backtraces=0 auf 8.5.
EOL-Backports: Branches PHP-<ver>-CVE-2026-109618-109619, nur Quellcode-Builds.
Häufig gestellte Fragen
Wird PHP2Shell aktiv ausgenutzt?
Die Ausnutzung wird von einigen Anbietern (Cloudflare, watchTowr) gemeldet und von anderen (Huntress, NCSC-NL) bisher nicht bestätigt. Zum Zeitpunkt der Erstellung dieses Textes sind die CVEs noch nicht im KEV-Katalog der CISA aufgeführt. In jedem Fall ist die Aktualisierung von PHP der sicherste Schritt.
Ich habe WordPress und alle Plugins aktualisiert. Bin ich geschützt?
Nicht gegen PHP2Shell. Die Sicherheitslücke liegt in PHP selbst, daher kann sie nur durch ein PHP-Update auf eine bereinigte Version oder ein gepatchtes Herstellerpaket behoben werden.
Auf meiner Website läuft PHP 8.1 oder älter. Was sollte ich tun?
Für diese Versionen gibt es keine offizielle Veröffentlichung, sondern lediglich minimale Backports für die Erstellung aus dem Quellcode sowie Patches, die Linux-Distributionen und LTS-Anbietern vorab bereitgestellt werden. Erkundigen Sie sich bei Ihrem Hosting-Anbieter, was davon zutrifft, und planen Sie ein Upgrade auf eine unterstützte Version.
Schützt eine Web Application Firewall (WAF) meine Website?
Eine WAF kann das Risiko verringern, und Cloudflare hat Regeln für diese Schwachstellen veröffentlicht. Es handelt sich dabei um eine vorübergehende Schutzschicht, nicht um eine endgültige Lösung.
Stand der Informationen: 21. Oktober 2026, 18:00 Uhr UTC, basierend auf den genannten Quellen. Sie ersetzen keine individuelle Beurteilung.
