Brotli-Schwachstelle in Node.js (CVE-2026-111497): Wir nutzten eine betroffene Version, haben sie gepatcht und keine Anzeichen einer Ausnutzung gefunden

Heute Morgen haben wir geschrieben, dass LFW.com von der PHP-Sicherheitslücke nicht betroffen war, weil auf unseren Servern kein PHP läuft.

Diese Lücke betraf uns: Auf unserem Server lief eine betroffene Version. LFW.com läuft auf Node.js, und das Node.js-Projekt hat heute um 6:38 Uhr (US-Ostküstenzeit) Sicherheitskorrekturen veröffentlicht. Wir haben unseren Server am selben Tag um 13:24 Uhr aktualisiert.

Was Node.js behoben hat

Das Release behebt zehn Schwachstellen in den Release-Linien 26.x, 24.x und 22.x. Vier davon sind als hoch eingestuft. Die für uns wichtigste:

• CVE-2026-111497, der Brotli-Decoder. Brotli ist ein verbreitetes Verfahren, um Webverkehr zu komprimieren. Ein Fehler darin, wie Node.js die Daten entpackt, kann über das Ende eines Speicherblocks hinaus schreiben. Laut dem Node.js-Projekt ermöglicht das Remotecodeausführung: fremden Code auf Ihrem Server auszuführen.

Mit Stand 14:00 Uhr (US-Ostküstenzeit) am 21. Oktober melden weder das Node.js-Projekt noch die Fachpresse für IT-Sicherheit tatsächliche Angriffe oder einen öffentlichen Exploit.

Aktualisieren Sie auf 22.23.4, 24.22.1 oder 26.12.1. Laut Node.js sind Versionen am Ende ihres Lebenszyklus immer betroffen und erhalten keine Korrektur. Stellen Sie diese also auf eine unterstützte Version um.

Wie es uns betraf

Der Großteil von LFW.com besteht aus vorab erzeugten Seiten. Der Server erledigt aber auch Aufgaben, bei denen er Websites anderer Leute abruft:

• das kostenlose Audit, das jede Website lädt, die jemand eingibt;
• unser Monitoring, das Websites nach Zeitplan prüft.

Wenn Node.js eine Seite abruft, entpackt es Brotli automatisch. Eine feindselige Website könnte also auf eine dieser Anfragen mit komprimierten Daten antworten, die gezielt den Speicher unseres Servers beschädigen sollen. Im schlimmsten Fall kann der Angreifer dann eigene Befehle auf unserem Server ausführen: lesen, was dort gespeichert ist, eine Hintertür einbauen oder den Server für Angriffe auf andere Websites nutzen. Das kostenlose Audit ist der riskanteste Teil, weil ein Fremder die Adresse auswählt.

Was wir getan haben, und wann

Der Ablauf, in US-Ostküstenzeit:

• 6:38 Uhr: Das Node.js-Projekt veröffentlichte die korrigierten Versionen.
• 13:24 Uhr: Wir haben Node.js auf unserem Server auf 22.23.4 aktualisiert und die Website neu gestartet.
• Direkt danach: Wir haben den Server auf Anzeichen geprüft, dass jemand den Fehler genutzt hat, solange er offen war.

Damit lagen etwa sechs Stunden und 45 Minuten zwischen der öffentlichen Bekanntgabe und unserem Update. Uns wäre eine kürzere Zeit lieber gewesen.

Wie wir geprüft haben, dass niemand die Lücke ausgenutzt hat

Wir haben mit dem begonnen, was unser Server in diesen Stunden tatsächlich abgerufen hat:

• Es liefen keine kostenlosen Audits. Niemand hat den Server veranlasst, eine externe Website seiner Wahl zu laden.
• Es liefen keine Website-Scans.
• Das Monitoring prüfte nur unsere eigenen Websites.

Die Spuren, die ein Angriff gewöhnlich hinterlässt

Dann haben wir auf dem Server danach gesucht:

• Keine Abstürze. Ein gescheiterter Versuch, Speicher zu beschädigen, bringt das Programm meist zum Absturz. Die Protokolle des Webservers der vergangenen Woche zeigen keine Abstürze, Speicherfehler oder erzwungenen Neustarts.
• Nichts Zusätzliches in Betrieb. Das Dienstkonto führt nur den Webserver und die Suchmaschine aus, und keiner der beiden hat fremde Programme gestartet.
• Nichts Neues auf der Festplatte. Keine neuen Skripte oder Programme in den temporären Ordnern und keine Änderungen an geplanten Aufgaben oder Diensteinstellungen außer durch unser eigenes Deployment.
• Keine neuen Zugänge. Die Server-Anmeldungen der letzten 30 Tage kamen nur über unsere eigenen zwei Schlüssel, und die Liste der zugelassenen Schlüssel hat sich seit September nicht geändert.

Der Webverkehr selbst

Zuletzt haben wir jede Anfrage zwischen dem Release und dem Update gelesen:

• Ruhiger als am Vortag, ganz ohne Serverfehler.
• Jede Anfrage kam über Cloudflare. Unsere Firewall nimmt Webverkehr nur von Cloudflare an, also hat nichts den Server direkt erreicht.
• Etwa 200 routinemäßige Sondierungen, das Grundrauschen, das jede öffentliche Website abbekommt. Die meisten suchten nach PHP-Dateien auf einem Server ohne PHP. Jede erhielt die Antwort nicht gefunden oder nicht erlaubt.

Diese Prüfungen finden die üblichen Anzeichen eines Angriffs. Sie können nicht beweisen, dass nichts passiert ist, und das behaupten wir auch nicht. Wir haben nichts gefunden.

Wo Cloudflare hilft, und wo nicht

Unser Datenverkehr läuft über den Proxy von Cloudflare, der Anfragen filtert, bevor sie unseren Server erreichen. Das ist echter Schutz für alles, was hereinkommt.

Der Hauptweg dieses Fehlers verlief aber in die andere Richtung: unser Server, der Antworten anderer Websites liest. In dieser Richtung sitzt Cloudflare nicht, also hat das Update den Fehler behoben.

Unsere eigenen Arbeitsrechner

Auch auf unseren lokalen Arbeitsrechnern läuft Node.js. Sie sind nicht aus dem Internet erreichbar, daher war das Risiko geringer. Aus übergroßer Vorsicht haben wir aber auch sie vorrangig auf korrigierte Versionen aktualisiert.

Der Rest des Releases

Die übrigen Korrekturen sollten Sie kennen, wenn Sie Node.js einsetzen:

• Zwei Umgehungen der Hostnamenprüfung bei TLS-Zertifikaten (CVE-2026-105483 und CVE-2026-106069), beide als hoch eingestuft. Über die Zertifikatsprüfung weiß ein Programm, dass es mit dem richtigen Server spricht.
• Ein Fehler, der DNS-Namen abschneidet (CVE-2026-105482), als hoch eingestuft: Namen mit einem versteckten NUL-Zeichen werden gekürzt.
• Wiederholte Zufallswerte in Snapshots (CVE-2026-106074), als mittel eingestuft. Anwendungen, die als einzelne ausführbare Datei oder als Start-Snapshot verpackt sind, konnten in jedem Prozess dieselben „zufälligen“ IDs wiederholen.
• Aktualisierte Stammzertifikate. Das Release aktualisiert außerdem die in Node.js mitgelieferten Zertifikate nach der Kompromittierung einer Zwischenzertifizierungsstelle von eMudhra.

Die vollständige Liste steht in der Mitteilung von Node.js.

Was Sie selbst prüfen sollten

Wenn Ihre Website oder Ihre Werkzeuge auf Node.js laufen:

• Aktualisieren Sie auf 22.23.4, 24.22.1 oder 26.12.1. Ihre Build-Werkzeuge zählen auch.
• Beginnen Sie mit allem, was Inhalte von außen abruft: Linkprüfer, Bild-Proxys, Feedreader, Webhooks, Scraper. Genau das erreicht der Brotli-Fehler.
• Bauen Sie alles neu, was als einzelne ausführbare Datei oder als Snapshot verpackt ist. Ein Update von Node.js auf dem Server aktualisiert keine Kopie, die fest in ein Programm eingebaut ist.
• Nutzen Sie verwaltetes Hosting? Prüfen Sie die Statusseite Ihres Hosters. Viele aktualisieren Node.js für Sie.

Wenn Sie Unterstützung möchten

Wir helfen Ihnen gern bei allen diesen Punkten, vom Herausfinden, was auf Node.js läuft, bis zur Prüfung eines Servers nach einem Update. Schreiben Sie uns.