PHP-Sicherheitsupdate beim Hoster: Was Hetzner, IONOS, mittwald und Co. erledigt haben und was bei Ihnen bleibt

Inhalt

1. Ausgangslage: Was die Hoster bestätigt haben
2. Drei Betriebsmodelle und wer wofür zuständig ist
3. Was bei Ihnen bleibt, auch wenn der Hoster gepatcht hat
4. Was Sie diese Woche klären sollten

Am 21. Oktober hat das PHP-Projekt zwei kritische Lücken geschlossen, bekannt geworden unter dem Namen PHP2Shell. In den Tagen danach kam bei vielen Agenturen und Shop-Betreibern dieselbe Frage auf: Hat unser Hoster das erledigt oder müssen wir selbst ran? Die Frage ist berechtigt. Wer ein Managed-Hosting-Paket bucht, erwartet zu Recht, dass sich jemand um die Plattform kümmert. Wer nachts eine Warnmeldung liest und nicht weiß, wo seine Zuständigkeit beginnt, hat ein ungutes Gefühl, auch wenn am Ende alles in Ordnung ist.

Die gute Nachricht vorweg: Die großen Anbieter haben schnell reagiert und das auch öffentlich dokumentiert. Die weniger bequeme Nachricht: Ein Hoster patcht die PHP-Laufzeit. Er patcht nicht Ihre Anwendung. Dieser Artikel zeigt, wo die Grenze verläuft, was die Anbieter selbst veröffentlicht haben und welche Punkte auch nach einem erfolgreichen Hoster-Patch bei Ihnen liegen.

Ausgangslage: Was die Hoster bestätigt haben

Die folgende Übersicht stützt sich ausschließlich auf das, was die Anbieter selbst veröffentlicht haben. Leistungsbeschreibungen und AGB sind darin nicht ausgewertet.

Für Strato, timmehosting und Host Europe lag zum Redaktionszeitpunkt keine öffentliche Primärquelle vor, die wir verlinken können. Von maxcluster haben wir keine Aussage gefunden. Für all-inkl gibt es eine eigene Beobachtung, siehe unten. Fehlt eine öffentliche Aussage, heißt das nicht, dass nicht gepatcht wurde. Es heißt, dass Sie sich den Stand beim Anbieter bestätigen lassen sollten.

Drei Betriebsmodelle und wer wofür zuständig ist

Ob Ihr Hoster gepatcht hat, hängt weniger am Anbieter als am Produkt, das Sie bei ihm gebucht haben. Die Grenze ziehen IONOS und mittwald in ihren Veröffentlichungen selbst sehr klar.

Shared- und Managed-Webhosting

Hier betreibt der Hoster die PHP-Laufzeit. Sie wählen eine Version im Kundenmenü, um Installation und Updates kümmert sich der Anbieter. Genau dieses Modell decken die Bestätigungen in der Tabelle ab. Wirtschaftlich ist das der bequemste Weg: Sicherheitsupdates der Laufzeit kosten Sie keine eigene Arbeitszeit. Dafür haben Sie wenig Einfluss darauf, wann gepatcht wird, und wenig Spielraum bei der Konfiguration.

VPS, Dedicated- und Root-Server

Sobald Sie PHP selbst installieren, sind Sie selbst zuständig. IONOS schreibt das ausdrücklich: Wer PHP selbst betreibt, etwa auf einem VPS oder einem Dedicated Server, muss sofort selbst handeln. Bei Hetzner beziehen sich die Patches auf der Statusseite ebenfalls auf Webhosting- und Managed-Server, nicht auf Cloud- oder Root-Server. Dieses Modell gibt Ihnen volle Kontrolle. Der Preis dafür ist, dass jemand bei Ihnen die Sicherheitsmeldungen verfolgt und am Release-Tag patcht.

Eigene Container

Viele Symfony- und Shopware-Projekte laufen heute in Docker-Containern, auch bei Managed-Anbietern. mittwald weist darauf hin, dass Kunden, die PHP selbst im Container betreiben, ihren Stand selbst prüfen müssen. Das gilt unabhängig vom Anbieter. Ein Container bringt seine PHP-Version im Image mit. Der Hoster patcht den Host, nicht Ihr Image. Ein neues Basis-Image, ein Rebuild und ein Deployment sind Ihre Aufgabe.

Ob Ihr Container betroffen ist, sehen Sie mit einem Befehl:

# PHP-Version im laufenden Container prüfen
docker compose exec app php -v

# Fix-Versionen vom 21.10.2026: 8.2.35, 8.3.36, 8.4.27, 8.5.12

Steht dort eine ältere Version derselben Reihe, ist das Image nicht aktualisiert, egal was der Hoster auf seinen eigenen Servern getan hat.

Was bei Ihnen bleibt, auch wenn der Hoster gepatcht hat

Keine der Anbieteraussagen, die uns vorliegen, nennt Anwendungscode, Composer-Abhängigkeiten oder Shopware-Plugins als Aufgabe des Hosters. Das ist auch folgerichtig: Ein Hoster kennt Ihre Anwendung nicht und kann sie nicht testen. Daraus ergeben sich vier Punkte, die auch bei einem vorbildlich gepatchten Managed-Hosting offen bleiben können.

Lücken in der Anwendung selbst

PHP2Shell betraf die Laufzeit. Parallel gab es für Shopware 6.7 eine Lücke auf Anwendungsebene: CVE-2026-104937, eine Stored-XSS-Schwachstelle, veröffentlicht am 13.10.2026 von CERT/CC unter VU#157374. CERT/CC gab dazu an, dass derzeit kein Patch verfügbar sei. Zur Schwere gibt es widersprüchliche Angaben, genannt werden CVSS 8,1 und 6,1. Ein Herstellerfix für Self-Hosted-Installationen war zum Redaktionszeitpunkt nicht dokumentiert. Für diese Lücke ist kein Hoster zuständig. Ob und wie Sie sie absichern, entscheiden Sie mit Ihrem Entwicklungsteam.

Composer-Abhängigkeiten und Plugins

Symfony-Komponenten, Bibliotheken und Shopware-Plugins bekommen eigene Sicherheitsupdates. Ein Hoster spielt diese nicht ein, weil jedes Update die Anwendung verändern kann. Ein regelmäßiges composer audit in der CI zeigt bekannte Schwachstellen in den installierten Paketen. Wer Plugins selbst entwickelt und vertreibt, hat seit September 2026 zusätzlich die Meldepflichten des Cyber Resilience Act im Blick. Was das für Agenturen bedeutet, steht im Artikel zur CRA-Meldepflicht.

Konfiguration, die der Patch nicht abdeckt

Nach PHP2Shell ist mit CVE-2026-115560 eine weitere Lücke im Bereich Session Upload Progress bekannt geworden. php.net empfiehlt bis zum nächsten regulären Release, session.upload_progress.enabled auf 0 zu setzen. Diese Empfehlung gilt auch dann, wenn Ihr Hoster PHP2Shell bereits gepatcht hat. Bei Managed-Hosting können Sie die Einstellung je nach Anbieter selbst setzen oder müssen beim Support nachfragen. Fragen Sie gezielt, ob sie gesetzt ist.

Nachwirkungen einer möglichen Kompromittierung

Ein Patch schließt die Lücke für die Zukunft. Er entfernt nichts, was vorher eingeschleust wurde. IONOS empfiehlt für den Fall einer Kompromittierung, auf einen Stand vor Anfang Oktober 2026 zurückzusetzen und alle Zugangsdaten zu erneuern. Ob Ihr System betroffen war, lässt sich nur über Logs und einen Abgleich der Dateien beurteilen. Diese Prüfung übernimmt kein Hoster für Sie.

Woran erkennen Sie, ob Ihre Aufteilung trägt? Wenn Sie für jedes Projekt sagen können, wer die Laufzeit patcht, wer die Abhängigkeiten aktualisiert und wer im Ernstfall die Logs prüft, ist die Grundlage da. Fehlt bei einem dieser Punkte ein Name, liegt dort Ihr Risiko. Wer diese Aufgaben auslagern will, sollte sie in einem Wartungsvertrag mit festem Patch-Takt festhalten, damit beim nächsten Release-Tag niemand suchen muss.

Aus der Praxis

Meine eigenen Projekte und die meiner Kunden liegen bei Hetzner und bei all-inkl im Webhosting. all-inkl hatte die PHP-Laufzeit im Laufe des 21. Oktober gepatcht, Hetzner laut Statusseite am selben Abend. Für die Laufzeit gab es danach weder bei mir noch bei den Kunden etwas zu tun. Genau das ist der Vorteil von Webhosting, bei dem der Anbieter PHP betreibt: Der Release-Tag kostet keine eigene Arbeitszeit. Die Punkte aus dem vorigen Abschnitt bleiben davon unberührt. Abhängigkeiten, Plugins und Konfiguration prüfe ich trotzdem im normalen Wartungstakt.

Was Sie diese Woche klären sollten

PHP2Shell war für die meisten Managed-Kunden nach einem Abend erledigt, weil die großen Hoster schnell gepatcht haben. Das ist ein guter Grund, die Aufteilung jetzt einmal schriftlich festzuhalten, solange kein Druck da ist. Gehen Sie Ihre Projekte durch und notieren Sie für jedes, wo PHP läuft: im Webhosting des Anbieters, auf einem eigenen Server oder in einem Container. Prüfen Sie für die letzten beiden Fälle die tatsächlich laufende Version. Klären Sie mit Ihrem Hoster, ob session.upload_progress.enabled gesetzt ist. Und legen Sie fest, wer sich um Shopware-Plugins und Composer-Abhängigkeiten kümmert. Den aktuellen Stand der PHP-Patches führt die Patchstand-Seite. Wenn Sie dafür jemanden suchen, der die Arbeit übernimmt, finden Sie unter Symfony-Entwicklung den Einstieg, für akute Fälle über die Notfall-Lösung.