FL Pro Consulting KI-Beratung · KI-Magazin · KI in Europa
Termin buchen

PHP2Shell: Zwei kritische PHP-Lücken, und warum Docker-Websites selbst handeln müssen

Verfasst von

Flolu

in

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, über die Angreifer ohne Anmeldung Code auf einem Webserver ausführen können. Betroffen ist fast jede Website, die mit PHP läuft, also auch die meisten WordPress-Seiten. Wer eine solche Seite betreibt, sollte heute prüfen, welche PHP-Version tatsächlich läuft. Diese Website ist bereits auf dem gepatchten Stand.

Was heise berichtet

heise online hat am 21. Oktober über die Updates berichtet (Autor: Christopher Kunz). Die wichtigsten Punkte aus dem Artikel:

  • Das PHP-Projekt hatte die Updates für den 21. Oktober um 16 Uhr angekündigt. Technische Details wurden erst mit den Patches veröffentlicht.
  • Mehrere Stellen, darunter das CERT-EU, haben ihre Abonnenten vorab gewarnt und zu schnellen Updates gedrängt.
  • Ein bereits kursierender Exploit zielte nur auf die LiteSpeed-Schnittstelle und ließ sich im Labor von heise nicht nachvollziehen. Die eigentlichen Fehler stecken laut heise aber in jeder PHP-Version seit PHP 5.
  • Den oft genannten Workaround session.upload_progress.enabled = 0 hält der Autor für wirkungslos.
  • heise rechnet mit funktionierenden Angriffen innerhalb von Stunden, höchstens eines Tages. Wer nicht sofort aktualisieren kann und das Risiko nicht tragen will, sollte PHP-Webserver vom Netz nehmen.
  • In einer Ergänzung vom Abend heißt es, dass nicht nur Websites betroffen sein können, sondern auch Router und NAS-Geräte mit PHP-Weboberfläche.

Was die PHP-Entwickler selbst schreiben

Die Sicherheitsmeldung auf php.net nennt zwei Lücken:

  • CVE-2026-109618 (RCE durch Speicherfehler): Wenn PHP der Speicher ausgeht, kann die Verarbeitung an einer Stelle abbrechen, an der interne Daten einer Anfrage erst halb aufgebaut sind. Beim Aufräumen werden diese Daten dann als gültig behandelt.
  • CVE-2026-109619 (RCE durch veralteten Zustand): Interne Daten einer Anfrage können überleben, obwohl ihr Speicher schon freigegeben ist. Die nächste Anfrage im selben Prozess greift dann womöglich darauf zu.

Gefährdet ist laut php.net jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei Apache mit mod_php. Dort ist ein Angriff gezeigt worden, bei dem eine einzige Anfrage ohne Anmeldung genügt, noch bevor die eigentliche Anwendung läuft. Genau diese Kombination steckt in den offiziellen Docker-Images von WordPress und Nextcloud.

Die gepatchten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und älter bekommt vom PHP-Projekt keine Updates mehr. Die Workarounds auf php.net verringern nur einzelne Angriffswege und machen eine Installation ausdrücklich nicht sicher. Ein Update ist die einzige vollständige Lösung.

Was Du jetzt tun solltest

Wie Du vorgehst, hängt davon ab, wo PHP bei Dir läuft:

  • Managed Hosting oder Shared Hosting: Der Anbieter ist zuständig. Prüfe im Kundenmenü, welche PHP-Version aktiv ist, und frag nach, wenn sie unter den genannten Versionen liegt.
  • Eigener Server mit PHP aus Ubuntu oder Debian: Die Distributionen haben die Patches vorab bekommen. Automatische Sicherheitsupdates haben sie wahrscheinlich schon eingespielt. Prüfe es trotzdem und starte PHP-FPM bzw. Apache neu, damit kein alter Prozess weiterläuft.
  • Server-Panels wie CloudPanel: Deren PHP-Pakete laufen oft nicht über die automatischen Updates. Hier musst Du selbst aktualisieren.
  • Docker: siehe nächster Abschnitt. Hier helfen die Updates des Betriebssystems gar nicht.
  • Router, NAS und andere Geräte mit Weboberfläche: Prüfe in den nächsten Tagen, ob der Hersteller eine neue Firmware anbietet, und gib die Oberfläche bis dahin nicht ins Internet frei.

Die Docker-Falle

Einige Hoster haben ihre VPS-Kunden am 21. Oktober angeschrieben und beruhigt: Unter Ubuntu und Debian kämen die Sicherheitsupdates ohnehin automatisch. Für Websites in Docker-Containern stimmt das nicht. Dort steckt PHP im Container-Image, und das Betriebssystem des Servers weiß davon nichts. Auf dem Server selbst ist oft gar kein PHP installiert.

Ein Container bleibt auf seinem alten PHP, bis jemand das neue Image zieht und den Container neu anlegt. Ein Neustart des Containers allein genügt nicht, er startet dasselbe alte Image. Das Betriebssystem kann also tagesaktuell sein, während die Website noch auf einer PHP-Version vom letzten Jahr läuft.

So prüfst Du es:

  1. Die PHP-Version in jedem Container abfragen: docker exec <container> php -v
  2. Das neue Image ziehen, zum Beispiel docker pull wordpress:latest, und mit docker run --rm --entrypoint php wordpress:latest -v nachsehen, ob es schon die gepatchte Version enthält.
  3. Den Container neu anlegen: docker compose up -d im Projektordner. Die Inhalte bleiben erhalten, solange /var/www/html in einem Volume liegt. Das ist bei den offiziellen Images der Normalfall, ein Blick vorher schadet aber nicht.
  4. Danach noch einmal php -v im Container ausführen und die Seite aufrufen.

Eine zweite Falle sind fest gepinnte Versionen. Wer ein Image mit genauer Versionsnummer oder Prüfsumme festlegt, bekommt keinen Neubau. Bei Nextcloud wurde zum Beispiel das Image der alten Unterversion nicht neu gebaut. Der Patch kam erst mit dem nächsten Versionssprung.

Und diese Website?

fl-pro-consulting.de läuft in einem Docker-Container mit Apache und mod_php, also genau in der Konstellation mit dem höchsten Risiko. Der Container ist in der Nacht zum 22. Oktober auf PHP 8.3.36 umgestellt worden, wenige Stunden nachdem das gepatchte WordPress-Image erschienen war. Dasselbe gilt für alle anderen Websites, die ich betreue. Danach habe ich jede Seite einzeln geprüft: Startseite, Anmeldeseite und Schnittstelle antworten normal, und in den Protokollen gibt es keine Fehler.

Mit KI hat die Lücke selbst nichts zu tun. Viele KI-Anwendungen im Mittelstand hängen aber an genau solchen Webservern: das Intranet mit Chatbot, die Dateiablage, aus der ein Assistent Dokumente liest, das WordPress-Plugin für den Kundenchat. Ein KI-System ist nur so sicher wie der Server, auf dem es läuft.

Wenn Du unsicher bist, ob Deine Systeme betroffen sind, melde Dich. Die Prüfung dauert meist nur wenige Minuten.

Quellen

Weitere Beiträge