PHP2Shell: Wer handeln muss und wie sich das Update prüfen lässt

Die kurze Antwort

Ein Update von WordPress, Plugins oder Themes hilft hier nicht. Schließen lassen sich die Lücken nur mit einem Update von PHP selbst: auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf ein Paket der Linux-Distribution, das die Korrektur enthält. Bei einem Webhosting-Paket spielt das Update der Hoster ein, auf einem eigenen Server die Person, die ihn betreibt. Danach müssen alle PHP-Prozesse neu starten. Für PHP 8.1 und älter gibt es vom PHP-Projekt kein Update mehr.

Angriffsversuche gibt es seit dem 21. Oktober, das BSI sieht unverzüglichen Handlungsbedarf.

Schnelltest: Läuft die Website auf PHP?

Der Schnelltest ruft eine Website einmal ab und erkennt an Headern, Cookies und öffentlichen Merkmalen, ob und womit sie auf PHP läuft, etwa mit WordPress, Joomla oder Shopware. Die genaue Version nennt er, falls der Server sie im Header zeigt.

Mehr als ein Anhaltspunkt ist das nicht. Oft bleibt die Versionsnummer verborgen, und auch eine angezeigte sagt allein nichts über den Patch: Ubuntu etwa behält nach der Korrektur dieselbe Nummer. Sicher ist nur die Prüfung auf dem Server selbst, die der Abschnitt So lässt sich prüfen, ob das Update greift beschreibt.

Wer handeln muss: Hoster, Serverbetreiber oder Hersteller

Webhosting-Paket: Der Hoster spielt das Update ein

Bei Shared Hosting betreibt der Hoster PHP, und nur er kann es aktualisieren. Ob das schon geschehen ist, steht in seiner Statusmeldung oder lässt sich beim Support erfragen.

Am schnellsten geht der Blick auf die Statusseite. IONOS, Hetzner und Mittwald haben den Stand dort mit Uhrzeit gemeldet, Strato in seiner Hilfe. Die Entwarnung gilt nur für das Webhosting, nicht für VPS, und nicht immer für jede alte PHP-Version: Mittwald nahm Versionen unter 5.6 aus.

Selbst gefragt ist, wer im Kundenmenü noch PHP 8.1 oder älter eingestellt hat. Diese Versionen sind nur geschützt, wenn der Hoster sie selbst nachgebessert hat. Sicherer ist der Wechsel auf 8.3 oder neuer. Vorher lohnt ein Test, am besten auf einer Kopie der Website, denn ältere Plugins und Themes können mit einer neuen PHP-Version Fehler werfen.

Nach den Änderungslisten des PHP-Projekts rechne ich beim Sprung von 8.1 auf 8.3 eher mit Warnungen als mit einer ausgefallenen Seite, am ehesten zu dynamischen Eigenschaften, die PHP seit 8.2 als veraltet meldet. Bei WordPress schreiben WP_DEBUG und WP_DEBUG_LOG in der wp-config.php solche Meldungen samt Dateipfad nach wp-content/debug.log, also mit dem auslösenden Plugin oder Theme. Das gehört auf die Kopie, nicht auf die Live-Seite.

Vorsicht bei Mails, die mit Link oder Anhang zu einem dringenden PHP-Update auffordern. Echte Updates kommen über den Hoster oder die Paketquellen des Betriebssystems.

Für die Website vom Anfang bleibt also: beim Hoster nachfragen und die PHP-Version im Kundenmenü prüfen.

Eigener Server oder VPS: selbst aktualisieren

Wer einen Server selbst verwaltet, ob gemietet oder im eigenen Haus, spielt das Update selbst ein. Unter Ubuntu und Debian kommt es über die normalen Sicherheitsquellen, unter Ubuntu 20.04 nur noch mit Ubuntu Pro. Bei einem Managed Server regelt der Vertrag, ob der Anbieter das Betriebssystem pflegt; im Zweifel nachfragen.

Container: Image neu bauen

Ein Container-Image bringt sein eigenes PHP mit, ein Update des Hosts ändert daran nichts. Es muss mit einem aktuellen Basisimage neu gebaut und ausgerollt werden. Die offiziellen PHP-Images auf Docker Hub stehen in den korrigierten Versionen bereit, etwa php:8.4.27-fpm. Wer im Dockerfile eine feste ältere Version wie php:8.4.26-apache angibt, muss sie anheben.

Geräte und Software mit eingebautem PHP: Sache des Herstellers

PHP steckt auch in fertigen Produkten, etwa in Verwaltungsoberflächen von Netzwerkkomponenten oder in Anwendungen, die mit eigenem PHP geliefert werden. Dort kann nur der Hersteller aktualisieren. Bis dahin sollten solche Oberflächen nicht aus dem Internet erreichbar sein. Hersteller von Netzwerkkomponenten geben laut BSI eigene Meldungen heraus, das niederländische NCSC führt auf GitHub eine Liste betroffener und nicht betroffener Produkte.

Was PHP2Shell gefährlich macht

Beide Lücken ermöglichen Remote Code Execution: Ein Angreifer schickt eine präparierte Anfrage an den Webserver und bringt PHP dazu, seine Befehle auszuführen, mit den Rechten des Benutzerkontos, unter dem PHP läuft. Damit lassen sich Dateien der Website verändern, Zugangsdaten aus der Konfiguration lesen oder weitere Programme nachladen. Auch ohne Codeausführung ließ sich Speicher mit Passwörtern, Tokens und API-Schlüsseln aus anderen Anfragen auslesen. Das PHP-Projekt bewertet beide Lücken mit 9,2 von 10 Punkten nach CVSS 4.0.

Am stärksten gefährdet sind Server, auf denen PHP als Modul im Webserver Apache läuft (mod_php). Dort hat das PHP-Projekt einen vollständigen Angriff über das Netz nachvollzogen, der greift, bevor die Anwendung selbst eine Zeile Code ausgeführt hat. Auch für PHP-FPM, die verbreitete Variante mit eigenen PHP-Prozessen hinter Nginx oder Apache, ist ein Angriff nachgewiesen. Wiz, eines der Teams, die die Lücken gefunden haben, schreibt, dass schon eine schlichte „Hello World“-Anwendung angreifbar sein kann.

Geplant waren die Details für den 22. Oktober. Weil die CVE-Nummern und ein Video, das einen Angriff zeigte, schon am 20. Oktober im Netz kursierten, zog das PHP-Projekt die Updates um einen Tag vor. Angriffsversuche melden watchTowr und Cloudflare seit dem 21. Oktober. Die US-Behörde CISA hatte bei ihrer ersten Warnung noch keine erfolgreiche Ausnutzung beobachtet; seit dem 26. Oktober führt sie CVE-2026-109618 und CVE-2026-109619 in ihrem Katalog aktiv ausgenutzter Schwachstellen, hat also verlässliche Belege, dass die beiden Lücken tatsächlich ausgenutzt werden. Das BSI hat eine Cybersicherheitswarnung herausgegeben.

Technisch entsteht die erste Lücke (CVE-2026-109618), wenn PHP beim Aufbau einer Anfrage der Speicher ausgeht: Interne Daten bleiben halb fertig, und das Aufräumen am Ende der Anfrage behandelt sie als gültig. Bei der zweiten (CVE-2026-109619) bleiben Reste einer Anfrage im PHP-Prozess, der nacheinander viele Anfragen bearbeitet, und zeigen auf Speicher, der schon freigegeben ist.

Welche Versionen die Korrektur enthalten

Für 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam wegen der Schwere der Lücken nur minimale Korrekturen im Quellcode veröffentlicht. Sie richten sich an alle, die PHP selbst übersetzen, ein fertiges Update sind sie nicht. Wer einen dieser Zweige betreibt, braucht ein Paket der Distribution oder eines Anbieters mit verlängertem Support oder den Wechsel auf einen unterstützten Zweig. Weil 8.2 Ende 2026 ausläuft, ist 8.3 oder neuer die bessere Wahl.

Linux-Distributionen behalten oft ihre eigene Versionsnummer und übernehmen nur die Korrektur. Maßgeblich ist dann die Version des Pakets (Stand 26. Oktober 2026):

So lässt sich prüfen, ob das Update greift

Unter Ubuntu verrät die Versionsnummer nicht, ob die Korrektur installiert ist. php -v zeigt vor und nach dem Update „PHP 8.3.6“, die Website ebenso, weil Ubuntu die Korrektur in die bestehende Version übernimmt, statt auf 8.3.36 zu wechseln. Debian liefert hier die Versionen des PHP-Projekts aus (8.4.27 und 8.2.35), dort stimmt die Nummer.

Der folgende Ablauf prüft deshalb die Pakete selbst, getestet am 26. Oktober 2026 in einer frisch installierten Ubuntu-24.04-VM mit Apache und mod_php sowie PHP-FPM: zuerst mit dem ungepatchten Paket 8.3.6-0maysync1, das Ubuntu 24.04 bei seiner Veröffentlichung enthielt, danach mit dem Update 8.3.6-0ubuntu0.24.04.13.

1. Installierte PHP-Pakete anzeigen

   Der Befehl listet alle installierten Pakete mit „php“ im Namen samt Version. Die Versionen mit der Tabelle oben vergleichen.

   dpkg -l '*php*' | awk '/^ii/ {print $2, $3}'

2. Changelog nach der Lücke durchsuchen

   Ubuntu und Debian vermerken behobene Lücken im Changelog des Pakets. Der Befehl zählt, wie oft die Kennung dort steht; 0 heißt, die Korrektur fehlt. Im Test stand vor dem Update 0, danach 2. Die Versionsnummer im Pfad an die eigene anpassen, etwa php8.4-common.

   zgrep -c CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz

3. Alle PHP-Versionen auf dem Server finden

   php -v zeigt nur die Version für die Kommandozeile. Sind mehrere Versionen installiert, kann die Website eine andere nutzen. Die laufenden FPM-Dienste und ein in Apache geladenes PHP-Modul zeigen diese beiden Befehle; jede gefundene Version braucht das Update.

   systemctl list-units --type=service 'php*-fpm*'
   ls /etc/apache2/mods-enabled/ | grep php

4. Prüfen, ob alles neu gestartet ist

   Laufende Prozesse arbeiten mit dem Code weiter, den sie beim Start geladen haben. Im Test hat die Paketverwaltung Apache und PHP-FPM beim Update selbst neu gestartet. Ist das unterblieben, etwa weil Neustarts beim Update unterdrückt waren, nennt needrestart die betroffenen Dienste, im Test „apache2.service“ und „php8.3-fpm.service“. Unter Ubuntu Server ist das Werkzeug vorinstalliert, unter Debian lässt es sich nachinstallieren. Ein Neustart der genannten Dienste behebt das.

   sudo needrestart -r l
   sudo systemctl restart apache2 php8.3-fpm

Zeigt der erste Schritt nach dem Update weiter die alte Paketversion, hält womöglich eine Einstellung das Update zurück. Mit apt-mark hold festgehaltene Pakete aktualisiert die Paketverwaltung nicht, apt-mark showhold listet sie. Die automatischen Updates unter Ubuntu überspringen außerdem, was in /etc/apt/apt.conf.d/50unattended-upgrades unter Package-Blacklist steht.

Wenn das Update nicht sofort möglich ist

Eine Einstellung, die die Lücken vollständig schließt, gibt es laut PHP-Projekt nicht. Lässt sich ein Server nicht zeitnah aktualisieren oder läuft er mit PHP 8.1 oder älter, rät die CISA, ihn bis dahin vom Netz zu nehmen. Ob das für einen Shop oder ein Kundenportal vertretbar ist, muss die Geschäftsführung entscheiden.

Bleibt er am Netz, versperren diese Maßnahmen bekannte Angriffswege, verringern das Risiko aber nur:

• session.upload_progress.enabled = 0 schaltet die Fortschrittsanzeige für Datei-Uploads ab, die standardmäßig eingeschaltet ist. Das PHP-Projekt rät, sie auch nach dem Update ausgeschaltet zu lassen, wenn die Anwendung sie nicht braucht.
• Unter PHP 8.5 zusätzlich fatal_error_backtraces = 0.
• post_max_size klein halten: 8M für Anwendungen ohne Datei-Uploads, 32M mit Uploads, upload_max_filesize jeweils darunter.
• Eine Web Application Firewall (WAF) vor der Website filtert bekannte Angriffsmuster heraus. Cloudflare hat dafür Regeln in allen Tarifen mit WAF eingeschaltet, auch im kostenlosen; in bezahlten Tarifen sollte das verwaltete Regelwerk auf Blockieren stehen.

Das PHP-Projekt nennt außerdem memory_limit = -1. Ohne Speichergrenze kann eine einzelne Anfrage aber den ganzen Arbeitsspeicher belegen, deshalb rät das Projekt zusätzlich zu einer Grenze für Container oder cgroup. Das ist eher etwas für erfahrene Administratoren.

Die Einstellungen gehören in die php.ini, die der Webserver liest, oder in die Konfiguration des FPM-Pools. In .user.ini oder per ini_set() im Code wirken sie nicht früh genug. Unter Ubuntu und Debian hat jede Betriebsart eigene Dateien. Im Test meldete die Website nach der Änderung für Apache den Wert 0, php -i auf der Kommandozeile zeigte weiter „On“, weil die Kommandozeile ihre eigene Konfiguration liest.

session.upload_progress.enabled = 0

Für PHP-FPM liegt die Datei unter /etc/php/8.3/fpm/conf.d/. Danach Apache oder PHP-FPM neu starten.

Die dritte Lücke (CVE-2026-115560): dieselbe Einstellung hilft

Am 23. Oktober hat das PHP-Projekt eine weitere Lücke gemeldet. Wer session.upload_progress.enabled = 0 aus dem vorigen Abschnitt gesetzt hat, muss deswegen nichts weiter tun. Die Lücke steckt ebenfalls in der Fortschrittsanzeige für Uploads und betrifft laut Cloudflare auch die gerade korrigierten Versionen wie 8.5.12. Ausnutzbar ist sie nur bei einer ungewöhnlichen Kombination: Die Anwendung stellt session.serialize_handler in der Konfiguration auf php_binary oder php_serialize und schaltet im Code vor session_start() auf php um. Das PHP-Projekt hält das für unwahrscheinlich, schließt die Lücke mit der nächsten regulären Version und empfiehlt bis dahin genau diese Einstellung.

Wenn der Server schon angegriffen sein könnte

Das Update schließt die Lücken, entfernt aber nichts, was ein Angreifer vorher auf dem Server abgelegt hat. Bei öffentlich erreichbaren Servern, die nach dem 20. Oktober noch ungepatcht liefen, lohnt ein Blick auf die Anzeichen, die Sicherheitsfirmen und Behörden nennen:

• PHP- oder Webserver-Prozesse, die eine Shell, einen Skriptinterpreter oder Werkzeuge wie curl und wget starten
• neue oder veränderte PHP-Dateien im Verzeichnis der Website, neue Cronjobs oder Benutzerkonten
• gehäufte Fehler mit Status 500 und Meldungen über erschöpften Speicher in den Logs

Geänderte PHP-Dateien seit dem 20. Oktober findet dieser Befehl; der Pfad entspricht der Voreinstellung unter Ubuntu und Debian. Treffer sind nicht automatisch verdächtig, auch Updates von WordPress oder Plugins ändern Dateien.

sudo find /var/www -name '*.php' -newermt 2026-10-20 -ls

Stand ein Server nach dem 21. Oktober noch Tage ungepatcht im Netz, sollten die Zugangsdaten aus der Konfiguration der Website erneuert werden, etwa das Passwort der Datenbank: Über die Lücken ließ sich auch Speicher mit Passwörtern auslesen.

Finden sich Spuren, gehört der Server vom Netz. Die Logs werden gesichert, und die Aufarbeitung übernehmen am besten Fachleute für Sicherheitsvorfälle. Waren personenbezogene Daten zugänglich, etwa die Kundendaten eines Shops, kann eine Meldung an die Datenschutzaufsicht nötig sein: nach Art. 33 DSGVO binnen 72 Stunden, nachdem die Verletzung bekannt geworden ist, außer sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen.