Blog / PHP2Shell: Jeder PHP-Server braucht ein Update.

PHP2Shell: Jeder PHP-Server braucht ein Update.

#Shopware#PHP#Sicherheit 6 Min. Lesezeit

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, über die Angreifer ohne Anmeldung eigenen Code auf Webservern ausführen können. Das BSI rät, die Updates sofort einzuspielen. Betroffen ist PHP selbst, nicht ein einzelnes Shopsystem oder CMS. Stand: 21. Oktober 2026.

Serverschrank mit blauen Netzwerkkabeln. Zwei Anschlussplatten tragen die Kennungen CVE-2026-109618 und CVE-2026-109619, leuchtende Datenströme mit PHP-Code führen zu ihnen. — Bild: KI-generiert mit Google Gemini

Ein angekündigtes Update wurde zum Notfall.

Am 20. Oktober hat das PHP-Sicherheitsteam ein kritisches Sicherheitsrelease angekündigt, zunächst ohne technische Details. Geplant war es für Mittwoch, 21. Oktober, 14:00 UTC, also 16 Uhr deutscher Zeit. Alle PHP-Nutzer sollten sich vorbereiten, um sofort aktualisieren zu können. Das Team behielt sich vor, früher zu veröffentlichen, falls Details vorzeitig bekannt würden. Genau das ist passiert: Informationen zu den Lücken gelangten vor Ablauf der Sperrfrist an die Öffentlichkeit, die Updates kamen kurz vor dem angekündigten Termin.

Das BSI hat am selben Tag gewarnt und unverzüglichen Handlungsbedarf gesehen. Vizepräsident Thomas Caspers hält eine großflächige Ausnutzung innerhalb weniger Stunden nach Veröffentlichung für wahrscheinlich, weil sich Exploits mit KI-gestützten Werkzeugen schnell erstellen lassen. In Berichten heißen die Lücken inzwischen „PHP2Shell“, angelehnt an Log4Shell aus dem Jahr 2021.

Zwei Lücken, ein Ergebnis: fremder Code auf dem Server.

Beide Schwachstellen sind mit CVSS 4.0 9,2 von 10 bewertet. Laut Security Advisory auf php.net können sie eine Remote Code Execution ohne Authentifizierung ermöglichen. Eine Nutzerinteraktion ist nicht nötig.

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): Läuft PHP beim Aufbereiten einer Anfrage in ein Speicherlimit, bleiben interne Daten halb initialisiert. Die Aufräumroutine am Ende der Anfrage behandelt sie trotzdem als gültig. Auslöser sind unter anderem präparierte Multipart-Anfragen, wie sie bei Formularen und Datei-Uploads vorkommen.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): Interner Zustand einer Anfrage überlebt, obwohl der zugehörige Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Worker kann diesen veralteten Zustand nutzen, bevor er zurückgesetzt wird.

Der Angriff passiert also auf der Ebene, auf der PHP eine Anfrage entgegennimmt. Bei Apache mit mod_php wurde ein Exploit gezeigt, der greift, bevor überhaupt Anwendungscode läuft. Ein sauber gepflegter Shop schützt hier nicht: Der Fehler liegt eine Schicht darunter.

Betroffen ist praktisch jeder PHP-Webserver.

Laut php.net sind alle PHP-Installationen gefährdet, die Webanfragen bedienen. Das gilt für PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed; das höchste Risiko sieht das PHP-Team bei mod_php. Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Stände dieser Zweige sind verwundbar.

PHP 8.1 und älter bekommen vom PHP-Projekt keine Updates mehr. Für 7.4, 8.0 und 8.1 hat das Sicherheitsteam minimale Quellcode-Backports veröffentlicht; manche Distributionen und LTS-Anbieter liefern eigene Pakete. Nach Einschätzung des BSI reichen die betroffenen Versionen mindestens bis PHP 5 zurück.

Für Shopware, WordPress, Kirby, Laravel oder Symfony heißt das: Ein Update des Shops oder der Plugins behebt nichts. Aktualisiert werden muss PHP auf dem Server, bei gemietetem Hosting also durch den Hoster.

Was jetzt zu tun ist.

Die richtige Version prüfen. php -v zeigt nur die Kommandozeilen-Version. Der Webserver kann eine andere nutzen, etwa ein separates FPM-Paket. Maßgeblich ist, was Apache oder FPM tatsächlich ausliefern. Distributionen spielen Sicherheitsfixes oft ein, ohne die PHP-Versionsnummer anzuheben; dort zählt die Paketversion aus dem Sicherheitshinweis der Distribution.
Aktualisieren und neu starten. Pakete der Distribution oder des Hosters einspielen, Quellcode und Windows-Builds gibt es auf der Downloadseite von php.net. Danach PHP-FPM bzw. Apache neu starten, damit keine alten Worker weiterlaufen. Docker-Images neu bauen und ausrollen.
Alle Installationen erfassen. Neben dem Shop gehören Staging-Systeme, alte Microsites, phpMyAdmin, Admin-Panels, NAS-Systeme und mitgelieferte Software dazu. Was nicht mehr gebraucht wird, sollte vom Netz.
Beim Hoster nachfragen. Bei Shared Hosting und Managed Servern liegt das Update beim Anbieter. Eine schriftliche Bestätigung mit Version und Zeitpunkt hilft auch bei der eigenen Dokumentation.
Auffälligkeiten beobachten. Huntress empfiehlt, auf ungewöhnliche Kindprozesse von PHP-Workern zu achten, etwa Shells, curl, wget oder Befehle wie whoami. Bei einem Verdacht Web- und PHP-Logs sichern, bevor etwas bereinigt wird.

Bestätigte Angriffe waren zum Zeitpunkt der BSI-Warnung nicht bekannt, wohl aber unbestätigte Berichte über Exploits. CERT-EU verweist auf kursierende Proof-of-Concepts. Wer noch nicht aktualisiert hat, sollte nicht auf weitere Bestätigungen warten.

Wenn das Update nicht sofort möglich ist.

Das PHP-Team nennt einige Übergangsmaßnahmen und betont ausdrücklich: Sie verkleinern die Angriffsfläche, machen eine Installation aber nicht sicher. Nur das Update schließt die Lücken.

session.upload_progress.enabled=0 in der php.ini oder im FPM-Pool setzen und alle Worker neu starten. ini_set() oder .user.ini genügen nicht.
Unter PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen.
memory_limit=-1 serverseitig festlegen, etwa per php_admin_value, und post_max_size niedrig halten: 8M ohne Datei-Uploads, 32M mit. Ein Container- oder cgroup-Limit fängt den Speicherverbrauch dann ab.
Nicht benötigte Anwendungen abschalten oder vorübergehend hinter Passwortschutz, VPN oder IP-Filter legen.

Die vollständige Liste mit Hinweisen zu Proxy-Limits steht im Advisory auf php.net. Diese Schritte sind für ein paar Stunden gedacht, nicht als Dauerlösung.

Die PHP-Version gehört in die laufende Wartung.

Der Fall zeigt, wie viel an einer Schicht hängt, auf die im Alltag kaum jemand schaut. Wer weiß, welche PHP-Version auf welchem System läuft und wer sie aktualisiert, braucht an einem Tag wie dem 21. Oktober Minuten statt Stunden. Dazu gehören eine aktuelle Liste aller Systeme, klare Zuständigkeiten mit dem Hoster und ein Testsystem, auf dem sich ein Update schnell prüfen lässt.

Ein Termin steht schon fest: PHP 8.2 erhält nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr. Wer noch auf 8.2 oder älter arbeitet, sollte den Wechsel jetzt planen, bevor die nächste Lücke kommt. Wenn Sie unsicher sind, ob Ihr Shop betroffen ist oder wie ein Wechsel aussieht, sprechen Sie uns an.