Ein Mittwoch im Wartungsmodus
Am 21. Oktober 2026 hat das PHP-Projekt außerplanmäßig die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Lücken mit den Kennungen CVE-2026-109618 und CVE-2026-109619, über die Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen können. In den Release Notes stellt das PHP-Team klar, dass es keine vollständige Gegenmaßnahme gibt und nur das Update sicher ist. Die Lücken laufen inzwischen unter dem Namen PHP2Shell.
Das BSI rief Warnstufe Orange aus und riet, Webserver im Zweifel vom Netz zu nehmen. Viele folgten: die Charité, die Stadt Mainz, mehrere Unikliniken und Landesregierungen. Wie groß die Reichweite ist, zeigt eine einzige Zahl. Laut W3Techs läuft PHP auf rund 70 Prozent aller Websites, deren serverseitige Sprache sich überhaupt erkennen lässt.
Ich musste an diesem Tag auf datensm.art nichts tun. Nicht, weil ich klüger war als andere, sondern weil hier kein PHP läuft, wenn Du eine Seite aufrufst. Hugo baut jede Seite einmal, danach liefert der Server nur noch fertige Dateien aus.
Die sicherste Zeile Code ist die, die nicht läuft
In der nachhaltigen Webentwicklung sage ich gern: Die nachhaltigste Anfrage ist die, die gar nicht stattfindet. PHP2Shell zeigt, dass derselbe Satz auch für Sicherheit gilt. Nach Angaben der PHP Foundation stecken beide Fehler in der Speicherverwaltung und der Fehlerbehandlung, also in Teilen, die fast jede Anfrage berührt. Jede Seite, die bei jedem Aufruf neu berechnet wird, ist damit eine Gelegenheit für Angreifer. Eine statische HTML-Datei bietet diese Gelegenheit nicht.
Rechenzeit, Stromverbrauch und Angriffsfläche hängen am selben Faden. Wer weniger Code ausführt, braucht weniger Energie und muss weniger absichern. Das heißt nicht, dass jede Website statisch sein muss. Es heißt, dass Du bei jeder Funktion fragen solltest, ob sie wirklich bei jedem einzelnen Aufruf laufen muss.
Ganz ohne PHP komme ich übrigens auch nicht aus. Mein Newsletter läuft mit phpList, die Statistik mit Matomo. Beide musste ich patchen wie alle anderen auch. Der Unterschied liegt im Umfang: Betroffen waren zwei klar abgegrenzte Anwendungen und nicht jede einzelne Seite des Magazins.
Auch Effizienz-Technik ist Code
Am selben Tag hat Node.js eine zweite schwere Lücke geschlossen, diesmal in Brotli. Das Kompressionsverfahren steht auf jeder Checkliste für schlanke Websites, auch datensm.art liefert alle Dateien damit aus. Der Fehler (CVE-2026-111497) steckt im Brotli-Decoder der Versionen 1.0.3 bis 1.2.0: Speziell präparierte Daten bringen ihn dazu, über einen Speicherbereich hinaus zu schreiben, was im schlimmsten Fall Schadcode ermöglicht. Gefunden haben ihn Forschende von OpenAI Codex Security, behoben ist er in Brotli 1.0.10, 1.1.1 und 1.2.1.
Wichtig für die Einordnung: Gefährdet ist vor allem Software, die fremde Brotli-Daten entpackt, etwa Node.js- oder Python-Anwendungen, die komprimierte Anfragen annehmen oder Inhalte aus dem Netz laden. Ein Webserver, der vorkomprimierte Dateien ausliefert, entpackt nichts. Brotli abzuschalten wäre deshalb die falsche Lehre.
Die richtige Lehre ist unbequemer. Jede Optimierungsschicht ist zusätzliche Software, die gepflegt werden will. Die Korrektur lag schon seit Februar im Brotli-Quellcode und kam erst im Oktober als Sicherheitsupdate bei den Nutzern an. Kompression ist gut. Daten gar nicht erst zu erzeugen ist besser.
Zombie-Websites: Strom für niemanden
Die eigentlichen Stromfresser dieser Krise sind Server, um die sich niemand mehr kümmert. Vergessene Kampagnenseiten, alte Testinstallationen, Microsites von Projekten, die längst beendet sind. Sie laufen rund um die Uhr und verbrauchen Energie, ohne dass jemand sie braucht oder pflegt.
Wie groß dieser Bestand ist, deuten zwei Zählungen an. Der Scan-Dienst Modat fand rund 4,4 Millionen öffentlich erreichbare PHP-Dienste. Bei etwa 79 Prozent derer, deren Version sich auslesen ließ, lief ein Zweig, den das PHP-Projekt nicht mehr unterstützt. PHP 7.4, seit 2022 ohne Updates, kam allein auf rund 879.000 Dienste. Censys meldete knapp eine Woche nach dem Patch noch 32,5 Millionen verwundbare PHP-Dienste. Beide Zählungen arbeiten mit unterschiedlichen Methoden und lassen sich nicht miteinander verrechnen. Die Richtung ist trotzdem eindeutig.
Für diese Server gibt es keinen Patch, weil niemand ihn einspielt. Werden sie gekapert, rechnen und senden sie künftig für Botnetze, mit Strom, den ihre Betreiber weiter bezahlen. Eine Zahl in Kilowattstunden nenne ich hier bewusst nicht, denn belastbare Daten dazu gibt es nicht. Klar ist aber: Löschen ist die einzige Maßnahme, die zugleich für Sicherheit und Klima wirkt.
Angriffswellen: Traffic ohne jeden Nutzen
Der zweite Stromfresser ist der Angriffsverkehr selbst. Amazon registrierte auf seinen Lockvogel-Servern einen ersten Angriffsversuch bereits am 17. Oktober, vier Tage vor der Veröffentlichung. Cloudflare zählte kurz nach Bekanntwerden der Lücken Millionen Versuche. Inzwischen gilt die aktive Ausnutzung als bestätigt.
Jeder dieser Versuche ist eine Anfrage, die Firewalls prüfen und Server beantworten müssen. Über Bot-Traffic schreibe ich hier regelmäßig, meist über Crawler, die wenigstens Daten für irgendeinen Zweck sammeln. Angriffsverkehr erzeugt nicht einmal das. Und er wird mehr: Das BSI erwartet, dass Angreifer mit KI-Werkzeugen solche Lücken künftig innerhalb weniger Stunden ausnutzen.
Was bleibt
Die PHP Foundation hat offen eingeräumt, dass einer der Fehler schon 2024 bei einem Audit aufgefallen war und dass die Reparatur am Entscheidungsprozess und an fehlenden Mitteln scheiterte. Ein großer Teil des Webs ruht auf der Arbeit weniger Menschen. Umso wichtiger ist es, ihnen nicht mehr Code aufzubürden als nötig.
Suffizienz ist deshalb mehr als eine Klimastrategie. Jede Funktion, die Du weglässt, muss niemand berechnen, niemand absichern und niemand patchen. Wenn Du nach diesem Oktober Deine Websites durchgehst, stelle die Frage nicht nur bei der nächsten Lücke, sondern bei jedem neuen Feature: Muss das wirklich bei jedem Aufruf laufen?
Quellen: PHP: Release PHP 8.5.12 · PHP Foundation: Today’s PHP security release · CERT-EU: Security Advisory 2026-018 · W3Techs: Usage statistics of PHP · Node.js: October 2026 Security Releases · The Register: Hackers pile on PHP2Shell · Recorded Future: PHP2Shell Exploitation · Cybernews: 32.5 million services remain vulnerable