Kritische PHP-Sicherheitslücken: In unter 30 Minuten nach dem

Allgemein
Frank

21.10.2026

0 Kommentare

🛡️ Kritische PHP-Sicherheitslücken: In unter 30 Minuten nach dem Release gepatcht

Website und Kundeninterface nach 14 Minuten, die Webspace-Server nach 27 Minuten: So haben wir auf die PHP-Updates vom 21. Oktober reagiert.

Bei Sicherheitslücken zählt jede Stunde! ⚡️ Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht (CVE-2026-109618 und CVE-2026-109619). Unter bestimmten Bedingungen konnten Angreifer darüber aus der Ferne eigenen Code auf einem Webserver mit PHP ausführen. Das ist kein ZAP-Hosting-Problem: PHP steckt hinter einem großen Teil des Internets, die Lücken betreffen Websites und Webserver in der gesamten Hosting-Branche.

🔎 Das ist bekannt

Art der Lücke: Remote Code Execution, also das Ausführen von fremdem Code auf dem Server über eine präparierte Anfrage.
Behoben in: PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12.
Ohne Fix: PHP 8.1 und älter bekommen vom PHP-Projekt keine Sicherheitsupdates mehr und damit auch keine Korrektur für diese Lücken.

⏱️ Vor dem Release: vorbereitet und abgesichert

Die Veröffentlichung der Updates war vorab angekündigt. Unser Infrastruktur-Team hat diese Zeit genutzt, um unsere Systeme mit PHP zu erfassen: von unserer Website und dem Kundeninterface über die Webspace-Server bis zu den phpMyAdmin-Oberflächen unserer Datenbank-Produkte und internen Diensten. Bis zum Release haben wir vorübergehende Schutzeinstellungen gesetzt und zusätzliche Filterregeln am Rand unseres Netzwerks aktiviert. So war der bekannte Angriffsweg schon vor dem Fix eingeschränkt.

🚀 Release-Tag: in unter 30 Minuten gepatcht

Weil alles vorbereitet war, ging es nach dem Release schnell: Unsere Website und das Kundeninterface liefen nach rund 15 Minuten auf der neuen Version, die Webspace-Server nach knapp einer halben Stunde. Auch unter Zeitdruck sind wir Schritt für Schritt vorgegangen und haben jede Änderung zuerst getestet. Unsere übrigen Systeme folgten noch am selben Tag.

🌐 Webspace: darum haben wir uns gekümmert

Webspaces, die noch PHP 7.4, 8.0 oder 8.1 genutzt haben, haben wir auf PHP 8.2 umgestellt, denn für diese alten Versionen gibt es keinen Fix. Darüber haben wir per Service News im Kundeninterface und per E-Mail informiert. Die meisten Websites laufen ohne jede Änderung weiter. Braucht deine Anwendung Anpassungen für die neuere PHP-Version, hilft dir unser Support gerne weiter.

🔧 Eigener vServer, Dedicated Server oder Self-Hosting? Jetzt selbst updaten

Unsere Updates decken die Dienste ab, die wir für dich verwalten. Auf deinem eigenen vServer, Dedicated Server oder jedem anderen selbst betriebenen System bist du für die installierte Software selbst verantwortlich, egal ob bei uns, bei einem anderen Anbieter oder zu Hause. Läuft dort irgendwo PHP, zum Beispiel für eine Website, ein Forum, ein Panel oder in einem Docker-Container, prüfe es bitte jetzt:

Prüfe, welche PHP-Version auf deinem Server läuft. Korrigiert sind 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder neuer.
Spiele die Updates selbst über die Paketverwaltung deines Betriebssystems ein.
Docker-Container mit PHP: aktuelle Images ziehen bzw. neu bauen und die Container neu starten. Ein Update auf dem Host-System aktualisiert das PHP im Container nicht.
PHP-FPM bzw. den Webserver danach neu starten, damit die laufenden Prozesse auch wirklich die neue Version nutzen.
Läuft noch PHP 8.1 oder älter, ein Upgrade auf eine unterstützte Version einplanen. Diese Versionen bekommen keinen Fix mehr.

🛡️ Sicherheit hört nie auf

Das ist kein Einzelfall. Im August haben wir unsere KVM-Infrastruktur gegen Zapscape und Januscape abgesichert, zwei Schwachstellen, über die eine virtuelle Maschine unter bestimmten Bedingungen aus ihrer Isolation ausbrechen konnte. Jedes Mal gilt dasselbe Prinzip: schnell bewerten, sofort absichern und patchen, sobald ein stabiler Fix verfügbar ist. Die Sicherheitsforschung steht nie still, und unsere Arbeit für sichere Dienste auch nicht.