php2shell: kritische Sicherheitslücke in fast allen PHP-Versionen

Das PHP-Projekt hat am 21. Oktober 2026 zwei kritische Sicherheitslücken geschlossen, die sich ohne Login ausnutzen lassen. Updates gibt es für fast alle unterstützten PHP-Versionen. Unter dem Namen php2shell sorgen die Lücken seitdem dafür, dass Behörden, Kliniken und Universitäten ihre Webseiten vorsorglich vom Netz nehmen.

Betroffen ist praktisch jede Webseite, die mit PHP läuft. Dazu gehören WordPress und Joomla, Onlineshops mit WooCommerce oder Shopware, aber auch das Kontaktformular auf einer sonst statischen Webseite.

Was hinter der PHP-Sicherheitslücke php2shell steckt

php2shell ist der Spitzname für zwei Schwachstellen im Kern von PHP: CVE-2026-109618 und CVE-2026-109619. Beide stehen in der Bewertungsskala CVSS bei 9,2 von 10 Punkten und gelten damit als kritisch. So hoch landet eine Lücke nur, wenn sie aus dem Netz erreichbar ist, keine Anmeldung braucht und am Ende den ganzen Server gefährdet.

Bei php2shell trifft alles drei zu. Ein Angreifer kann mit präparierten Anfragen eigenen Code auf dem Webserver ausführen, mit den Rechten, unter denen PHP dort läuft. Von da aus kann er eine Hintertür ablegen, Zugangsdaten aus der Datenbank auslesen, Kundendaten abziehen oder Besucher auf fremde Webseiten umleiten.

Gefunden hat die Lücken das Team von Wiz Research, nach eigener Darstellung mit Unterstützung von KI-Werkzeugen. Wiz meldete beide Lücken am 24. August 2026 an das PHP-Projekt. Schon vor dieser Meldung hatten die Forscher gezeigt, dass sich damit eine unveränderte WordPress- und eine Drupal-Installation übernehmen lassen.

Welche PHP-Versionen betroffen sind

Fast alle. Die Fehler stecken in Code, der seit Jahren unverändert in PHP liegt, nach Angaben der Entdecker zurück bis PHP 5.4. Laut dem Security Advisory des PHP-Projekts ist jede Installation gefährdet, die Webanfragen beantwortet. Das gilt unabhängig davon, wie PHP auf dem Server eingerichtet ist, also auch für PHP-FPM, die übliche Variante auf Webhosting und in Plesk.

Am höchsten schätzt das PHP-Projekt das Risiko bei Servern ein, die PHP direkt im Webserver Apache ausführen (mod_php). Dort gibt es einen vorgeführten Angriff, der greift, bevor überhaupt Code der Webseite ausgeführt wird.

Diese PHP-Versionen schließen beide Lücken:

PHP-Zweig	Sichere Version	Unterstützt bis
PHP 8.5	8.5.12	31. Dezember 2029
PHP 8.4	8.4.27	31. Dezember 2028
PHP 8.3	8.3.36	31. Dezember 2027
PHP 8.2	8.2.35	31. Dezember 2026
PHP 8.1 und älter	kein offizielles Update	PHP 8.1 bis 31. Dezember 2025

Für PHP 8.2 ist es eines der letzten Sicherheitsupdates, die Unterstützung endet Ende 2026.

PHP 8.1 und älter: keine offizielle Lösung

Für PHP 8.1, 8.0 und 7.4 veröffentlicht das PHP-Projekt keine neuen Versionen. Das Sicherheitsteam hat lediglich Korrekturen im Quellcode auf GitHub bereitgestellt. Die muss jemand selbst einbauen und PHP neu übersetzen. Auf einem normalen Webhosting kann das nur der Hoster. Rechne nicht damit, dass er das für eine Version ohne offizielle Unterstützung macht.

Wer einen eigenen Server mit einer älteren Version als PHP 8.2 betreibt, soll laut WordPress.org erwägen, ihn vom Netz zu nehmen, bis er umgestellt ist. Mehrere nationale Sicherheitsbehörden empfehlen dasselbe.

Läuft deine Webseite auf einem gemieteten Webhosting noch mit PHP 7.4 oder 8.1, stell sie jetzt um. Bei WordPress sind PHP 8.3 und 8.4 eine gute Wahl, mit aktuellem Theme und aktuellen Plugins gibt es dabei selten Probleme.

Wie die PHP-Lücken funktionieren

Beide Fehler hängen mit der Speicherverwaltung zusammen, die PHP für jede einzelne Anfrage betreibt. Vereinfacht beschrieben:

CVE-2026-109618 betrifft den Fall, dass PHP der Speicher ausgeht. Bricht PHP an dieser Stelle ab, sind interne Daten der Anfrage nur halb angelegt. Die Aufräumroutine danach hält die unvollständigen Daten trotzdem für gültig und arbeitet mit ihnen weiter.

CVE-2026-109619 betrifft Daten, die eine Anfrage hinterlässt. Unter bestimmten Bedingungen bleibt ein Verweis auf Speicher bestehen, der schon freigegeben ist. Die nächste Anfrage an denselben PHP-Prozess kann diesen Rest benutzen, bevor er neu gesetzt wird.

Ein Angreifer verkettet beide Fehler. Er schickt eine präparierte Anfrage mit Datei-Upload, die PHP gezielt in den Speicherengpass treibt, und nutzt mit einer zweiten Anfrage die Reste aus. Ein Schlüssel dabei ist die Fortschrittsanzeige für Uploads, die PHP seit Version 5.4 standardmäßig mitbringt. Sie ist eingeschaltet, obwohl die meisten Webseiten sie nicht nutzen.

So ein Angriff ist aufwendig, weil er an Version und Speicheraufbau des Servers angepasst werden muss. Laut Wiz hat gerade dabei KI die Hürde gesenkt. Die technischen Details stehen in den Advisories auf GitHub, etwa GHSA-6wmf-4rv5-p3rp.

Seit wann die PHP-Sicherheitslücke angegriffen wird

Die ersten Angriffsversuche gab es schon vor dem Update. Das PHP-Projekt hatte das Sicherheitsrelease am 20. Oktober angekündigt, veröffentlicht wurde es am 21. Oktober um 16 Uhr deutscher Zeit. Da waren technische Details bereits durchgesickert.

Nach Berichten, die heise online zusammengetragen hat, sah Amazon erste Angriffsversuche schon vier Tage vor der Veröffentlichung und spricht inzwischen von breiter Ausnutzung. Cloudflare registrierte weltweit Millionen Versuche, beginnend rund zehn Stunden vor dem Release. Erfolgreiche Angriffe waren am Morgen des 22. Oktober noch nicht bestätigt.

Solche Angriffe laufen automatisiert gegen jede erreichbare Adresse. Deshalb trifft es auch kleine Firmenwebseiten.

Warum Behörden ihre Webseiten abgeschaltet haben

Viele Behörden betreiben eigene Server und konnten das Update nicht sofort einspielen. Das PHP-Projekt stellt den Quellcode bereit, auf den Servern installiert wird PHP aber meist über die Linux-Systeme wie Debian oder SUSE. Deren fertige Pakete kamen erst im Laufe des 21. Oktober, bei Debian am Abend, bei SUSE noch später.

Das BSI hatte dazu geraten, das Update unverzüglich zu installieren. Wer das nicht konnte, ging lieber offline. In Deutschland nahm die Charité ihre Webseiten komplett vom Netz, bei berlin.de waren Teile abgeschaltet, ebenso Webseiten der Stadt Mainz und mehrerer Behörden in Bayern und Niedersachsen. Erste Angebote sind inzwischen wieder erreichbar.

Für eine Firmenwebseite ist das Abschalten selten nötig. Die meisten Webseiten liegen bei einem Hoster, und der ist für PHP zuständig.

So prüfst du die PHP-Version deiner Webseite

In WordPress dauert das eine Minute:

1. Im Dashboard links auf Werkzeuge, dann Website-Zustand.
2. Oben den Reiter Bericht öffnen.
3. Den Abschnitt Server aufklappen. Dort steht die PHP-Version.

Ohne WordPress hilft die Oberfläche deines Hostings. In Plesk steht sie bei der Domain unter PHP-Einstellungen, bei anderen Anbietern meist unter einem ähnlich benannten Punkt.

Zeigt die Anzeige 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder höher, ist deine Webseite geschützt. Steht dort eine niedrigere Nummer innerhalb desselben Zweigs, ist das noch kein Beweis für eine offene Lücke. Linux-Distributionen spielen Sicherheitsfixes oft ein, ohne die sichtbare Versionsnummer zu ändern. Dann hilft nur die Nachfrage beim Hoster.

Was du bei der PHP-Sicherheitslücke jetzt tun solltest

Was zu tun ist, hängt davon ab, wer deinen Server betreibt.

Deine Webseite liegt bei einem Hoster (der Normalfall):

1. PHP-Version nachsehen, wie oben beschrieben.
2. Beim Hoster nachfragen, ob das PHP-Update vom 21. Oktober eingespielt ist. Viele Anbieter haben ihre Kunden schon informiert, eine kurze Mail an den Support klärt den Rest.
3. Alte PHP-Versionen verlassen. Läuft deine Webseite auf PHP 8.1 oder älter, stell sie in der Hosting-Oberfläche auf 8.3 oder 8.4 um. Vorher ein Backup anlegen und danach die wichtigsten Seiten und das Kontaktformular testen.
4. Auf Auffälligkeiten achten, wenn deine Webseite länger ungeschützt war: unbekannte Administratorkonten, neue PHP-Dateien im Upload-Ordner, ungewohnte Weiterleitungen. Bei einem Verdacht hilft die Anleitung WordPress gehackt, was tun.

Du betreibst einen eigenen Server:

1. PHP sofort aktualisieren, über die Paketquellen deiner Distribution oder bei Plesk über die Systemupdates.
2. Alle PHP-Prozesse neu starten, also PHP-FPM beziehungsweise den Webserver. Erst danach arbeiten sie mit der neuen Version.
3. Nach vergessenen PHP-Installationen suchen. Das BSI weist darauf hin, dass PHP oft unbemerkt als Abhängigkeit mitläuft, etwa auf einem Raspberry Pi mit Weboberfläche.

Übergangslösungen in der PHP-Konfiguration

Wer nicht sofort aktualisieren kann, kann einzelne Angriffswege verschließen. Das PHP-Projekt nennt dafür mehrere Einstellungen, betont aber, dass keine davon das Update ersetzt:

; Fortschrittsanzeige für Uploads abschalten (gegen CVE-2026-109619)
session.upload_progress.enabled = 0

; Größe von Anfragen begrenzen (gegen CVE-2026-109618)
post_max_size = 8M

Die Einstellungen müssen in der zentralen php.ini oder in der Konfiguration des PHP-FPM-Pools stehen. Eine .user.ini im Webverzeichnis oder ein ini_set() im Code reicht laut PHP-Projekt nicht, beide wirken zu spät. Starte danach alle PHP-Prozesse neu.

Auf einem gemieteten Webhosting hast du auf diese Dateien keinen Zugriff. Das ist dann Aufgabe des Hosters. Dasselbe gilt für Firewall-Regeln vor dem Server, wie sie Cloudflare und einige Hoster inzwischen ausrollen. Sie fangen bekannte Angriffsmuster ab, aber nicht jede Variante.

Brauchst du ein WordPress-Update wegen php2shell?

Nein. Die Lücke steckt in PHP, nicht in WordPress, und WordPress.org hat ausdrücklich erklärt, dass kein WordPress-Update nötig oder geplant ist. Ein aktuelles WordPress schützt hier also nicht.

Auch ein Sicherheits-Plugin ändert nichts. Der Angriff läuft ab, während PHP die Anfrage entgegennimmt, deshalb bekommt ein Plugin ihn gar nicht mit.

Prüfen solltest du trotzdem die PHP-Version und sie falls nötig umstellen. Wie sich die laufende Pflege von WordPress, Plugins und PHP organisieren lässt, steht im Beitrag über WordPress-Wartung.

Hilfe bei der PHP-Umstellung

Schick mir die Adresse deiner Webseite, wenn du nicht sicher bist, wo sie steht. Ich sage dir, welche PHP-Version dort läuft und ob du handeln musst.