Lücke in PHP (PHP2Shell): Was Sie prüfen und dem Hosting auftragen

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Notfall-Korrekturen für zwei kritische Lücken in PHP selbst, genannt PHP2Shell. Auf PHP laufen WordPress, WooCommerce, PrestaShop und viele individuell programmierte Websites. Nutzt Ihre Website eines davon, betrifft die Sache auch Sie. Die gute Nachricht: Der Patch ist fertig, und die Prüfung, ob Sie ihn haben, dauert ein paar Minuten.

In diesem Ratgeber finden Sie: was passiert ist, wie Sie die PHP-Version ohne IT-Fachkraft prüfen, was Sie heute tun sollten und was Sie dem Hosting oder dem Dienstleister der Website auftragen sollten. Ich beschreibe den Stand vom 30. Oktober 2026. Die Versionen mit dem Patch können sich noch ändern, prüfen Sie sie daher vor dem Update in der Sicherheitsmitteilung auf php.net.

Was passiert ist

In PHP wurden zwei Fehler in der Speicherverwaltung gefunden: CVE-2026-109618 und CVE-2026-109619. Eine entsprechend präparierte Anfrage an die Website kann dazu führen, dass der Server fremden Code ausführt. Wer angreift, muss sich weder anmelden noch ein Passwort kennen. Es genügt, dass die Website auf einer verwundbaren PHP-Version läuft.

Das PHP-Team bewertete beide Lücken mit 9,2 auf der CVSS-Skala von 0 bis 10, also als kritisch. Die Firma Patchstack beschrieb Meldungen von Hosting-Firmen über Angriffe schon einige Stunden vor der Veröffentlichung der Korrekturen, und am 26. Oktober nahm die US-Behörde CISA beide Lücken in den Katalog der in Angriffen ausgenutzten Schwachstellen (KEV) auf. CERT Polska (das polnische Computer-Notfallteam) hat dazu eine Mitteilung veröffentlicht.

Es gibt keinen Grund zur Panik, aber einen Grund, die Website noch heute zu prüfen.

Wen die Lücke in PHP betrifft

Die Lücke steckt in PHP selbst, nicht in einem Plugin oder Theme. Deshalb betrifft sie jede Website, die auf PHP läuft:

• WordPress und WooCommerce, unabhängig von Plugins und Theme,
• PrestaShop, Joomla und andere in PHP geschriebene Systeme für Websites und Shops,
• eigene Skripte und Formulare in PHP, auch auf einfachen Websites,
• Tools auf dem Server wie phpMyAdmin.

Laut der Mitteilung von PHP sind alle PHP-Installationen gefährdet, die Websites ausliefern, unabhängig davon, wie PHP auf dem Server ausgeführt wird. Wichtig: Ein Update von WordPress oder Plugins behebt das nicht. Der Patch muss in PHP auf dem Server eingespielt werden, und beim gewöhnlichen Hosting macht das der Anbieter.

Die Versionen 8.1 und älter erhalten vom PHP-Projekt keine Releases mehr. Wegen der Schwere dieser Lücken hat das PHP-Team für 7.4, 8.0 und 8.1 nur minimale Patches für Personen bereitgestellt, die PHP selbst kompilieren. Auf einem typischen Hosting sollten Sie nicht darauf zählen: Der sichere Ausweg ist der Umstieg auf 8.3 oder 8.4.

So prüfen Sie, ob Ihre Website gefährdet ist

Es zählt die vollständige Versionsnummer mit der dritten Zahl am Ende. „8.3“ allein reicht nicht: Version 8.3.35 ist verwundbar, 8.3.36 nicht mehr.

WordPress: ohne Anmeldung auf dem Server

1. Melden Sie sich im WordPress-Dashboard an.
2. Öffnen Sie Werkzeuge → Website-Zustand und wechseln Sie zum Tab Bericht.
3. Klappen Sie den Abschnitt Server auf. Beim Eintrag „PHP-Version“ sehen Sie die vollständige Nummer, zum Beispiel 8.3.36.

In PrestaShop finden Sie die PHP-Version in den erweiterten Einstellungen, bei den Informationen zur Konfiguration des Shops.

Hosting-Panel

Im Hosting-Panel sieht man in den PHP-Einstellungen meist nur „8.3“ oder „8.4“, ohne die dritte Zahl. Das reicht, um zu prüfen, ob die Website nicht auf einer Version ohne Support läuft (8.1 oder älter). Nach der vollständigen Nummer und dem Patch fragen Sie das Hosting, eine fertige Nachricht steht weiter unten. Wo Sie die Version in den Panels von OVHcloud, home.pl und nazwa.pl ändern, beschreibe ich im Ratgeber zum Support-Ende für PHP 8.2.

Testdatei, nur kurz

Wenn Sie per FTP Zugang zum Server haben, laden Sie eine Datei version.php mit diesem Inhalt hoch:

<?php
echo PHP_VERSION;

Öffnen Sie sie im Browser, notieren Sie das Ergebnis und löschen Sie die Datei sofort. Lassen Sie auch keine Datei mit phpinfo() auf dem Server: Sie ist ein fertiger Spickzettel für alle, die nach Schwachstellen suchen.

Vorsicht bei Servern mit Ubuntu

Auf VPS-Servern, auf denen PHP aus den Systempaketen stammt, kann die Nummer irreführend sein. Ubuntu spielt den Patch in eine ältere Version ein und behält deren Hauptnummer bei. In Ubuntu 24.04 hat das korrigierte Paket die Nummer 8.3.6-0ubuntu0.24.04.13 und nicht 8.3.36. In diesem Fall fragen Sie die Serveradministration oder den Dienstleister der Website nach dem Stand des Patches.

Was Sie heute tun sollten

1. Prüfen Sie die PHP-Version auf einem der oben beschriebenen Wege und vergleichen Sie sie mit der Tabelle.
2. Ist die Version niedriger als in der Tabelle, schreiben Sie dem Hosting. Beim Shared Hosting aktualisiert der Anbieter PHP, nicht Sie.
3. Haben Sie PHP 8.1 oder älter, wechseln Sie so schnell wie möglich auf 8.3 oder 8.4: Backup, Test an einer Kopie der Website, Umstellung im Panel. Das ist nicht mit einem Klick erledigt, denn alte Plugins können den Dienst versagen. CISA empfiehlt, solche Websites bis dahin abzuschalten, es sei denn, das Hosting bestätigt einen Patch für Ihre Version im Systempaket.
4. Haben Sie PHP 8.2, schließt die Version 8.2.35 diese Lücken, aber der Support für 8.2 endet am 31. Dezember 2026. Das ist ein guter Moment, gleich auf eine neuere Version umzusteigen.
5. Legen Sie ein frisches Backup der Dateien und der Datenbank an und speichern Sie es außerhalb des Servers.
6. Aktualisieren Sie bei der Gelegenheit WordPress, Theme und Plugins nach der Anleitung für sichere Updates. Das repariert PHP nicht, schließt aber andere Einfallstore.
7. Installieren Sie keine „Plugins, die PHP2Shell beheben“ und keine Skripte aus Foren. Ein Plugin ändert PHP auf dem Server nicht, und unbekannter Code kann Malware enthalten.

Nachricht an das Hosting zum Kopieren:

Guten Tag, meine Website [Adresse der Website] läuft auf Ihrem Hosting (Konto: [Login oder Kundennummer]). Bitte bestätigen Sie, dass PHP in meinem Konto bereits die Patches für die Lücken PHP2Shell (CVE-2026-109618 und CVE-2026-109619) hat, also mindestens die Version 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder ein Systempaket mit diesem Patch, und dass die PHP-Prozesse nach dem Update neu gestartet wurden. Bitte teilen Sie mir auch mit, ob in den Server-Logs seit dem 20. Oktober Angriffsversuche auf meine Website zu sehen sind. Vielen Dank.

Bestätigt das Hosting das Update auch nach einigen Tagen nicht und gibt es im Panel nicht einmal die Version 8.3 oder 8.4, ist das ein Signal, den Anbieter zu wechseln. Im Rahmen der Leistung Domain und Hosting (ab 390 PLN netto pro Jahr) ziehe ich die Website auf einen Server in Polen oder der EU mit aktuellem PHP um.

Was Sie dem Dienstleister der Website oder der Serveradministration auftragen sollten

Läuft die Website auf einem VPS-Server, in einem Container oder auf dem Server des Dienstleisters, aktualisiert PHP die Person, die diesen Server verwaltet. Die Liste für sie:

• PHP-Update auf eine Version aus der Tabelle oder auf das korrigierte Paket der Distribution (Ubuntu: USN-8948-1, Debian 13: DSA-6574-1, Debian 12: DLA-4848-1).
• Neustart aller PHP-Prozesse (PHP-FPM, Apache mit mod_php). Ohne Neustart läuft die alte Version im Speicher weiter.
• Zuerst Apache mit mod_php. Das PHP-Team schätzt, dass das Risiko dort am höchsten ist.
• Docker-Images mit PHP müssen auf der neuen Version neu gebaut und erneut deployt werden.
• Eine Web Application Firewall (WAF) kann laut CISA das Risiko bis zum Update teilweise senken, ersetzt es aber nicht.
• Server mit Windows: Am 26. Oktober veröffentlichte PHP neu gebaute Pakete 8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1 mit korrigierter Brotli-Bibliothek (CVE-2026-111497). Über diese Lücke schreibe ich im Ratgeber Sicherheitslücke in Node.js und Brotli (Node2Shell).

Muss das Update warten, nennt die PHP-Mitteilung eine vorübergehende Einstellung. Sie muss in php.ini oder in der Konfiguration des PHP-FPM-Pools eingetragen werden (nicht über ini_set() oder eine Datei .user.ini), danach starten Sie die PHP-Prozesse neu:

session.upload_progress.enabled = 0

Das ist nur ein teilweiser Schutz. Laut dem PHP-Team blockiert die Einstellung die bestätigten Angriffswege über die Sitzung, aber nicht alle Varianten, und laut Tanium schützt sie nicht vor CVE-2026-109618. Vollen Schutz bietet nur das Update.

Die dritte Lücke: CVE-2026-115560

Am 23. Oktober beschrieb das PHP-Team eine weitere Lücke, ebenfalls im Zusammenhang mit dem Upload-Fortschritt in der Sitzung. Die Versionen vom 21. Oktober beheben sie nicht. Laut PHP ist sie nur bei einer ungewöhnlichen Kombination aus Servereinstellungen und Anwendungscode gefährlich, daher kommt der Patch in das nächste reguläre Release und nicht in ein Notfall-Release.

Bis dahin empfiehlt PHP die Einstellung session.upload_progress.enabled = 0, dieselbe wie oben. Ist diese Einstellung auf dem Server bereits aktiv, lassen Sie sie auch nach dem Update bestehen. Prüfen Sie nach der Änderung die Formulare, über die Ihre Kundschaft Dateien sendet. An dem Tag, an dem ich diesen Ratgeber abschließe, gibt es den Patch noch nicht, sehen Sie also in den Neuigkeiten auf php.net nach.

Könnte schon jemand eingedrungen sein?

Die ersten Angriffsversuche wurden registriert, bevor die Korrekturen überhaupt erschienen waren. Deshalb lohnt es sich, nach dem Update zu prüfen, ob niemand rechtzeitig eine Hintertür hinterlassen hat. Warnsignale:

• neue Administratorkonten, die in der Firma niemand angelegt hat,
• unbekannte Dateien auf dem Server, besonders .php-Dateien im Bilderverzeichnis,
• Weiterleitungen auf fremde Websites oder seltsame Unterseiten in den Google-Ergebnissen,
• Mitteilungen des Hostings über Malware oder ein plötzlicher Anstieg der Serverlast.

Bitten Sie das Hosting oder den Dienstleister, die Logs seit dem 20. Oktober durchzusehen. CISA weist unter anderem auf PHP-Prozesse hin, die eine System-Shell starten oder Tools herunterladen. Finden Sie Spuren eines Einbruchs, ändern Sie die Passwörter, spielen Sie ein sauberes Backup ein und melden Sie den Vorfall bei CERT Polska über das Formular auf incydent.cert.pl. Den Aktionsplan Schritt für Schritt beschreibe ich in einem eigenen Ratgeber: „Lücke in der Firmenwebsite: Was in den ersten 24 Stunden zu tun ist“.

Wie Sie die Versionen von PHP, CMS und Plugins Ihrer Website prüfen, zeige ich im Ratgeber So prüfen Sie die PHP-Version und worauf Ihre Website läuft.

Zusammenfassung

PHP2Shell sind zwei kritische Lücken in PHP selbst und nicht in WordPress oder Plugins. Prüfen Sie die vollständige PHP-Versionsnummer, vergleichen Sie sie mit der Tabelle und bitten Sie das Hosting, den Patch zu bestätigen. Ersatzeinstellungen senken nur das Risiko, vollen Schutz bietet das Update.

Wenn Sie das nicht selbst im Blick behalten möchten, überwache ich im Rahmen der technischen Betreuung die Website, mache Backups und spiele Sicherheitsupdates ein, dringende innerhalb von 2 Tagen. Das Paket Wache kostet ab 149 PLN netto pro Monat, Standard (ab 349 PLN) und Pro (ab 749 PLN) bieten eine schnellere Reaktion und Arbeitsstunden im Monat. Wenn Sie prüfen möchten, wie die Website über PHP hinaus abgesichert ist, beauftragen Sie ein Sicherheitsaudit oder schreiben Sie mir einfach. Ich antworte innerhalb von 24 Stunden, und wer zum ersten Mal mit mir arbeitet, erhält 20 % Rabatt auf den ersten Auftrag.