PHP-Sicherheitslücken: Warum regulär bei Webflow gehostete Websites nicht direkt betroffen sind

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht. Die unter dem Namen „PHP2Shell“ bekannten Lücken betreffen die serverseitige Verarbeitung von Webanfragen. Für Website-Betreiber stellt sich deshalb die Frage, welche Systeme überprüft und aktualisiert werden müssen.

Bei regulär auf Webflow gehosteten Websites besteht dieser konkrete PHP-Angriffsweg nicht. Externe Anwendungen und angebundene Dienste müssen allerdings gesondert betrachtet werden.

Was ist passiert?

Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 liegen in der Speicherverwaltung von PHP. Unter bestimmten Bedingungen können Angreifer ohne vorherige Anmeldung eigenen Code auf einem betroffenen Server ausführen.

Vereinfacht beschrieben entstehen die Fehler, wenn PHP bei der Verarbeitung von Anfragen mit unvollständig initialisierten oder bereits freigegebenen Speicherdaten arbeitet. Die technischen Einzelheiten unterscheiden sich, beide Schwachstellen betreffen jedoch die PHP-Laufzeit selbst. Sie sind in den offiziellen Sicherheitshinweisen zur Speicherbeschädigung und zum veralteten globalen Zustand dokumentiert.

Das Problem ist damit kein Fehler eines bestimmten WordPress-Plugins oder Themes. Auch andere Anwendungen können betroffen sein, wenn sie auf einer verwundbaren PHP-Installation laufen.

Warum ist eine Webflow-Website davon nicht direkt betroffen?

PHP wird auf dem Server ausgeführt. Eine PHP-Sicherheitslücke setzt deshalb voraus, dass der angegriffene Dienst die betroffene PHP-Laufzeit verwendet.

Webflow bietet für reguläre Websites keine Möglichkeit, eigenen PHP-Code auf dem Webflow-Hosting auszuführen. Die unterstützten Code-Erweiterungen bestehen aus HTML, CSS und JavaScript. Serverseitige Sprachen wie PHP werden dort ausdrücklich nicht unterstützt. Das beschreibt Webflow in seiner Dokumentation zu individuellem Code.

Für eine regulär bei Webflow gehostete Website ergibt sich daraus: Es gibt keine vom Website-Betreiber eingesetzte PHP-Installation, die wegen dieser Schwachstellen aktualisiert werden muss. Die konkrete PHP-Angriffsfläche einer selbst betriebenen PHP-Website entfällt.

Diese Einordnung bezieht sich auf den dokumentierten Hosting- und Funktionsumfang. Sie ist keine Aussage darüber, dass jede interne Komponente der Webflow-Plattform geprüft wurde oder Webflow grundsätzlich frei von Sicherheitslücken wäre.

{{callout}}

Externe Dienste können trotzdem relevant sein

Eine Webflow-Website kann mit Anwendungen verbunden sein, die außerhalb von Webflow laufen. Dazu gehören beispielsweise ein separat gehostetes Kundenportal, eine eigene Formularverarbeitung oder ein zusätzlicher WordPress-Blog auf einer Subdomain.

Verwendet ein solcher Dienst PHP, muss dessen Betreiber die eingesetzte Version und den Patchstand prüfen. Die Einbindung in eine Webflow-Website ändert daran nichts.

Entscheidend ist deshalb die gesamte technische Umgebung: Wo werden Anfragen verarbeitet, wo liegen Daten und wer betreibt die jeweiligen Systeme?

Was sollten Betreiber einer PHP-Website tun?

Das PHP-Projekt hat die Korrekturen in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 veröffentlicht. Betreiber sollten gemeinsam mit ihrem Hosting-Anbieter sicherstellen, dass die tatsächlich für Webanfragen verwendete PHP-Installation eine korrigierte Version oder ein entsprechend aktualisiertes Anbieterpaket nutzt. Ein Update des CMS allein ersetzt dieses PHP-Update nicht. Maßgeblich sind die offiziellen PHP-Sicherheitshinweise.

Für Webflow-Betreiber liegt der Prüfbedarf vor allem bei separat betriebenen Anwendungen und Integrationen. Wer ausschließlich die regulären Webflow-Funktionen nutzt, muss für die eigene Website keinen PHP-Patch einspielen.

Der Unterschied liegt hier in der technischen Architektur. Er erlaubt eine konkrete Einordnung dieser Sicherheitslücken, aber kein pauschales Urteil über die Sicherheit verschiedener Website-Systeme.

{{cta}}