PHP2Shell trifft keine statischen Websites

Am 21. Oktober 2026 hat das PHP-Team zwei kritische Lücken im Kern von PHP geschlossen, die unter dem Namen PHP2Shell bekannt sind. Über sie kann ein Angreifer ohne Anmeldung eigenen Code auf dem Webserver ausführen – überall dort, wo PHP Webanfragen beantwortet, etwa bei WordPress, das PHP voraussetzt.

Was hinter PHP2Shell steckt

Es sind zwei Schwachstellen in PHP selbst, nicht in einem Plugin:

• CVE-2026-109618: Geht PHP während einer Anfrage der Speicher aus, bleibt Speicher in einem ungültigen Zustand zurück. Präparierte Formularanfragen können genau das auslösen.
• CVE-2026-109619: Ein PHP-Prozess behält Zustand aus einer früheren Anfrage, obwohl deren Speicher schon freigegeben ist. Eine spätere Anfrage kann diesen Zustand nutzen, um Code einzuschleusen.

PHP bewertet beide mit 9,2 von 10 Punkten nach CVSS 4.0. Nachgewiesen ist die Ausführung von Code mit den Rechten des Webservers bei Apache mit mod_php, bei der zweiten Lücke auch bei PHP-FPM. Die US-Behörde CISA führt beide seit dem 26. Oktober als aktiv ausgenutzt.

Was Betreiber jetzt tun sollten

• PHP aktualisieren auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 – laut PHP der einzige vollständige Schutz – und danach alle PHP-Prozesse neu starten.
• PHP 8.1 und älter bekommen keine Korrektur, weil diese Zweige nicht mehr unterstützt werden. Hier hilft nur der Wechsel auf einen unterstützten Zweig.
• Wer heute nicht aktualisieren kann, senkt das Risiko mit den Übergangsmaßnahmen aus den PHP-Meldungen, ohne es zu beseitigen: session.upload_progress.enabled=0, unter PHP 8.5 zusätzlich fatal_error_backtraces=0, und memory_limit=-1 zusammen mit engen Grenzen für die Größe von Anfragen am vorgelagerten Webserver.
• Auf geteiltem Hosting liegt das Update beim Anbieter – fragen Sie nach, welche PHP-Version läuft.

Wie wir Websites bauen

Unsere Websites enthalten kein PHP. Wir bauen sie mit Astro als statische Seiten: Jede Seite entsteht einmal beim Bau als fertige HTML-Datei, und der Webserver – nginx hinter Traefik – liefert nur noch Dateien aus. Bei einem Aufruf läuft auf dem Server kein Programm der Website, das Anfragen auswertet. Damit fehlt Lücken wie PHP2Shell der Angriffspunkt.

• Kein PHP, keine Datenbank, keine Admin-Anmeldung auf dem Webserver: Es gibt nichts, über das sich Inhalte von außen ändern ließen.
• Formulare schicken ihre Einsendungen an unseren eigenen Formulardienst, der Spam mit ALTCHA per Proof-of-Work abwehrt – ohne Cookies und ohne ausländische CAPTCHA-Anbieter (so funktioniert er). Die Website selbst braucht dafür keinen Servercode.
• Gebaut und ausgeliefert wird in GitLab: Jede Änderung durchläuft eine Typ-, SEO- und Linkprüfung; ausgeliefert wird nur der geschützte Hauptzweig.
• Abhängigkeiten prüft die Pipeline bei jeder Änderung und jede Woche auf bekannte Schwachstellen und auf ihre Lizenzen. Außerdem bauen wir jede Woche alle Seiten neu.
• Sicherheits-Header: Die Content Security Policy lässt Skripte nur von der eigenen Adresse und von zwei eigenen Diensten zu, der Besucherstatistik und dem Formulardienst. HSTS mit preload erzwingt HTTPS, und keine fremde Seite darf unsere Seiten einbetten.

Wo auch statische Websites Pflege brauchen

Statisch heißt nicht wartungsfrei: Webserver, Reverse Proxy und Betriebssystem brauchen weiter Sicherheitsupdates, ebenso der Formulardienst. Das sind aber wenige, überschaubare Bausteine – statt PHP, Datenbank, Theme und Plugins, von denen jeder einzelne angreifbar sein kann.

Gern bauen wir auch Ihre Website so.

Quellen

• PHP-Sicherheitsmeldung zu CVE-2026-109618 vom 21.10.2026: GHSA-w8hw-w9fx-j79w – Ursache, CVSS 4.0: 9,2, behobene Versionen, Übergangsmaßnahmen
• PHP-Sicherheitsmeldung zu CVE-2026-109619 vom 21.10.2026: GHSA-6wmf-4rv5-p3rp – Ursache, CVSS 4.0: 9,2, behobene Versionen, Übergangsmaßnahmen
• CISA, Known Exploited Vulnerabilities: beide CVEs aufgenommen am 26.10.2026 – Datensatz im offiziellen Repository cisagov/kev-data, Stand 28.10.2026
• Name „PHP2Shell“: Help Net Security, 21.10.2026
• PHP: unterstützte Versionen – am 29.10.2026 die Zweige 8.2 bis 8.5
• WordPress: Anforderungen – empfohlen ist PHP 8.3 oder neuer
• Astro: On-demand rendering – Seiten entstehen standardmäßig beim Bau als statische Seiten
• Response-Header von esn.ge: eigene Abfrage am 29.10.2026 (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options: deny)