PHP2Shell: Was die kritische PHP-Lücke für Ihre Website bedeutet

PHP2Shell in Kürze

Läuft Ihre Website mit PHP, also zum Beispiel mit WordPress, ist sie betroffen, bis das Sicherheitsupdate eingespielt ist. Die korrigierten Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sind seit dem 21. Oktober 2026 verfügbar. Klären Sie heute, welche PHP-Version Ihre Website nutzt und wann Ihr Hoster aktualisiert. Läuft noch PHP 8.1 oder älter, gibt es vom PHP-Projekt kein reguläres Update mehr.

1. 01
   PHP-Version herausfinden

   Im WordPress-Backend unter „Website-Zustand“ oder im Kundenbereich Ihres Hosters.

2. 02
   Hoster fragen

   Wann wird das Update eingespielt, und bekommen Sie eine Bestätigung? Eine Mail-Vorlage steht weiter unten.

3. 03
   Alte Versionen umstellen

   PHP 8.1 und älter erhalten kein reguläres Update. Planen Sie den Wechsel auf PHP 8.3 oder neuer.

4. 04
   Update bestätigen lassen

   Ihre Website sollte mindestens 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 melden oder einen korrigierten Paketstand Ihrer Linux-Distribution nutzen.

Was über PHP2Shell bekannt ist

Das Sicherheitsteam von PHP hat am 20. Oktober 2026 ein außerplanmäßiges Sicherheitsupdate angekündigt und es am 21. Oktober 2026 veröffentlicht. Es schließt zwei Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Beide sind nach CVSS 4.0 mit 9,2 von 10 Punkten bewertet. CVSS ist die übliche Skala, mit der Sicherheitslücken nach Schwere eingestuft werden. Laut Advisory des PHP-Teams können beide Lücken Angreifern erlauben, ohne Anmeldung Code auf dem Server auszuführen.

• CVE-2026-109618: Wenn PHP der Arbeitsspeicher ausgeht, kann die Verarbeitung abbrechen, während interne Anfragedaten nur teilweise angelegt sind. Das Aufräumen danach behandelt diese Daten trotzdem als gültig.
• CVE-2026-109619: Interner Zustand einer Anfrage bleibt erhalten, obwohl sein Speicher schon freigegeben ist. Eine spätere Anfrage im selben PHP-Prozess kann ihn verwenden.

Betroffen sind laut php.net alle PHP-Installationen, die Webanfragen verarbeiten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php: Dort ist ein Angriff demonstriert, den eine einzige Anfrage ohne Anmeldung auslöst, bevor überhaupt Code der Website läuft.

Das BSI stuft die Lage mit Kritikalität 3 von 4 ein: Maßnahmen müssen unverzüglich ergriffen werden. Nach seiner Einschätzung ist eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches wahrscheinlich.

Details waren bereits vor dem Termin im Umlauf. Die Sicherheitsfirma watchTowr hat die Lücken bestätigt. Patchstack und Cloudflare berichten von ersten Angriffen, das BSI spricht in seiner Warnung von unbestätigten Berichten über Exploits. Der Name PHP2Shell lehnt sich an die Lücke Log4Shell aus dem Jahr 2021 an.

Wer betroffen ist

Die Lücken liegen im PHP-Interpreter, also in der Software auf dem Server, die PHP-Code ausführt. Damit ist nicht ein einzelnes System betroffen, sondern alles, was auf PHP aufbaut. Laut BSI sind nach aktuellem Stand alle PHP-Versionen bis mindestens PHP 5 verwundbar.

• Content-Management-Systeme: WordPress, TYPO3, Joomla, Drupal und Contao laufen mit PHP.
• Onlineshops: WooCommerce, Shopware und Magento ebenso.
• Einzelne Skripte: Auch eine sonst statische Website ist betroffen, wenn etwa das Kontaktformular über ein PHP-Skript verschickt wird.
• Weitere Anwendungen: Das BSI nennt unter anderem Nextcloud, pfSense und OPNsense.

Wie groß die Lücke bei älteren Systemen ist, zeigt die PHP-Statistik von WordPress.org: 36,4 Prozent der WordPress-Websites laufen mit PHP 8.1 oder älter, allein 16,1 Prozent mit PHP 7.4 (abgerufen am 21. Oktober 2026). Für diese Versionen gibt es vom PHP-Projekt kein reguläres Update mehr.

Nicht direkt betroffen sind Websites ohne PHP und gehostete Baukästen oder Plattformen wie Wix oder Shopify. Dort verwalten Sie keinen eigenen PHP-Server, die Absicherung liegt beim Anbieter.

So finden Sie Ihre PHP-Version heraus

In WordPress

Öffnen Sie im Backend „Werkzeuge“ und dann „Website-Zustand“. Im Reiter mit den Detailinformationen finden Sie im Abschnitt „Server“ die PHP-Version. WordPress zeigt auf derselben Seite auch eine Warnung, wenn die Version veraltet ist.

Beim Hoster

Hoster wie IONOS, Strato oder All-Inkl zeigen die eingestellte PHP-Version im Kundenbereich, meist unter Begriffen wie „PHP-Einstellungen“ oder „PHP-Version“. Dort lässt sich die Version häufig auch selbst umstellen. Machen Sie vorher eine Sicherung, denn ältere Plugins und Themes laufen nicht immer mit neueren PHP-Versionen.

Auf einem eigenen Server

Der Befehl php -v zeigt die installierte Version. Wichtig: Linux-Distributionen wie Debian, Ubuntu oder Red Hat übernehmen Sicherheitskorrekturen oft in ihre eigenen Pakete, ohne die Versionsnummer anzuheben. Gleichen Sie den Paketstand deshalb mit dem Sicherheitshinweis Ihrer Distribution ab, nicht nur mit der Nummer auf php.net.

Welche PHP-Versionen ein Update bekommen

Das PHP-Projekt pflegt nur die Versionszweige 8.2 bis 8.5. Die korrigierten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Linux-Distributionen und Anbieter mit Langzeitpflege haben die Korrekturen laut php.net vorab erhalten und liefern sie in eigenen Paketen aus.

Was Sie heute mit Ihrem Hoster klären sollten

Bei Shared Hosting und Managed Hosting spielt in der Regel der Hoster die neue PHP-Version ein. Sie müssen nichts installieren, sollten aber wissen, wann das passiert und ob Ihre Version überhaupt ein Update bekommt. Diese Nachricht können Sie übernehmen:

Viele Hoster beantworten solche Fragen in diesen Tagen mit einer Statusseite. Die Antwort sollte trotzdem Ihre Website betreffen, nicht nur das Rechenzentrum allgemein.

Eigener Server: die Reihenfolge

Wer einen eigenen Server oder einen VPS betreibt, ist selbst für das Update verantwortlich. Das BSI empfiehlt, die Patches unmittelbar nach Veröffentlichung einzuspielen und personelle Kapazität dafür bereitzuhalten.

1. 01
   Alle PHP-Installationen erfassen

   Auch Testumgebungen, Container, Altprojekte und Verwaltungsoberflächen wie Plesk oder cPanel.

2. 02
   Update über die Paketquelle einspielen

   Zum Beispiel mit apt oder dnf. Docker-Images mit PHP müssen neu gebaut werden.

3. 03
   PHP-Dienste neu starten

   PHP-FPM oder Apache neu laden, sonst läuft weiter die alte Version im Speicher.

4. 04
   Stand prüfen

   Version und Paketstand mit dem Hinweis von php.net und Ihrer Distribution abgleichen.

Wer PHP aus dem Remi-Repository bezieht, bekommt das Update dort laut php.net nicht am Tag der Veröffentlichung. Das PHP-Team rät, auf die Pakete der Distribution umzusteigen oder selbst zu kompilieren.

Wenn das Update nicht sofort möglich ist

Das PHP-Team nennt Übergangsmaßnahmen, betont aber: Sie verkleinern nur einzelne Angriffswege und machen eine Installation nicht sicher.

• Gegen CVE-2026-109619: session.upload_progress.enabled=0 in der php.ini, im FPM-Pool oder in der Serverkonfiguration setzen und alle PHP-Prozesse neu starten. Eine Einstellung per .user.ini oder ini_set() reicht nicht. Unter PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Gegen CVE-2026-109618: post_max_size niedrig halten, 8M ohne Datei-Uploads, 32M mit Uploads. Das Advisory beschreibt weitere Einstellungen zum Speicherlimit, die Erfahrung mit dem Serverbetrieb voraussetzen.
• Als letzte Möglichkeit: Lässt sich das Update nicht zeitnah einspielen, nennt das BSI die vorübergehende Trennung des Webservers vom Internet.

Was nicht vor PHP2Shell schützt

• WordPress-, Plugin- und Theme-Updates: Sie sind weiterhin wichtig, ändern aber nichts an der PHP-Version auf dem Server.
• Der Wartungsmodus des CMS: PHP verarbeitet die Anfrage, bevor der Code von WordPress oder Shop überhaupt läuft. Das PHP-Team beschreibt genau diesen Angriffsweg für mod_php.
• Inoffizielle „Fix“-Plugins und kopierte Code-Schnipsel: Patchstack rät davon ab.
• Eine vorgeschaltete Web Application Firewall allein: Cloudflare hat Filterregeln ausgerollt. Sie helfen nur, wenn der Server ausschließlich Anfragen über Cloudflare annimmt und nicht direkt erreichbar ist.

Wenn Sie einen Angriff vermuten

Verbindliche Angriffsmerkmale gibt es laut BSI noch nicht. Sicherheitsfirmen wie Huntress nennen typische Spuren nach einer Codeausführung auf Webservern: neue oder veränderte Dateien im Webverzeichnis, neue Administratorkonten, unbekannte Cronjobs und Programme, die vom Webserver aus gestartet werden.

• Nicht einfach aufräumen: Server vom Netz trennen, Web- und PHP-Logs sichern und erst dann untersuchen.
• Zugänge ändern: Passwörter für Backend, Datenbank, FTP und Hosting-Konto erneuern, nachdem die Lücke geschlossen ist.
• Meldepflicht prüfen: Sind personenbezogene Daten betroffen, etwa Kundenkonten oder Formulareingaben, verlangt Art. 33 DSGVO in der Regel eine Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden.

Quellen

• php.net: Security Advisory zu CVE-2026-109618 und CVE-2026-109619 (21.10.2026)
• GitHub-Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub-Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• BSI-IT-Sicherheitshinweis 2026-297981-1032, Version 1.0 (PDF)
• php.net: Unterstützte PHP-Versionen
• WordPress.org: PHP-Versionen der WordPress-Websites
• Sansec: Critical PHP RCE (CVE-2026-109618 und CVE-2026-109619)
• Patchstack: Major security alert für PHP
• Huntress: php2shell, Erkennung und Gegenmaßnahmen
• DSGVO, Art. 33: Meldung an die Aufsichtsbehörde

Häufige Fragen

Aktualisierungen dieser Seite

• 21. Oktober 2026, 16:30 UhrKorrigierte Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 ergänzt. Technische Einordnung und Übergangsmaßnahmen nach dem offiziellen Advisory von php.net aktualisiert.
• 21. Oktober 2026, 14:00 UhrErste Fassung auf Basis der Vorankündigung von php.net, der BSI-Warnung 2026-297981-1032 (Version 1.0) und erster Analysen von Sicherheitsfirmen.