Brotli-Sicherheitslücke betrifft .NET und Node.js: So prüfen und aktualisieren Sie Ihre Anwendungen

Eine Anwendung kann gewöhnlichen HTTPS-Datenverkehr entgegennehmen und dennoch gefährliche Eingaben verarbeiten, wenn sie von Nutzern bereitgestellte Brotli-Daten entpackt. Am 25. Oktober 2026 veröffentlichte Microsoft außerplanmäßige .NET-Updates, um einen Pufferüberlauf im Brotli-Decoder zu beheben; die Sicherheitslücke trägt die Kennung CVE-2026-111497. Node.js nahm die Behebung derselben Sicherheitslücke in ein separates Sicherheitsupdate vom 21. Oktober auf. Für Entwickler besteht der erste Schritt darin, den Weg von externen Daten zum Decoder zu ermitteln und anschließend die Runtime zu aktualisieren sowie die Anwendung neu zu erstellen oder neu zu starten.

Laut der Beschreibung von Microsoft kann die .NET-Sicherheitslücke einem nicht authentifizierten Angreifer ermöglichen, den Prozessspeicher auszulesen oder zu beschädigen. Dies kann zur Offenlegung von Daten, zu einem Denial-of-Service oder zur Erhöhung von Berechtigungen führen. Korrekturen wurden für .NET 8, 9 und 10 sowie .NET 11 Release Candidate 3 veröffentlicht. Für .NET 8 sind Runtime 8.0.33 und SDK 8.0.133 oder 8.0.427 angegeben. .NET Framework ist von dieser Sicherheitslücke nicht betroffen.

Wo das Risiko entsteht

Ein Risiko besteht, wenn eine Anwendung einen nicht vertrauenswürdigen Brotli-Datenstrom an einen anfälligen Decoder übergibt. In .NET kann dies durch die Verwendung der ASP.NET-Core-Anforderungsdekomprimierung, die automatische Dekomprimierung von Antworten über HttpClient oder den direkten Aufruf von APIs aus System.IO.Compression geschehen, etwa BrotliStream und BrotliDecoder. Die .NET-Sicherheitsempfehlung führt diese Wege auf und weist darauf hin, dass die Dekomprimierung eingehender Anfragen und die automatische Dekomprimierung von Antworten standardmäßig deaktiviert sind.

Die Paketinventur ist nur der Anfang der Prüfung. Suchen Sie nach Middleware- und HTTP-Client-Konfigurationen, direkten Decoder-Aufrufen und Drittanbieterkomponenten, die komprimierte Daten entgegennehmen. Ermitteln Sie, ob solche Daten von Clients, Webhooks, Proxys oder externen APIs stammen und welche Größen- und Zeitlimits vor dem Entpacken gelten. So lässt sich feststellen, an welchen Stellen anfälliger Code von außen kontrollierte Daten erhält.

.NET aktualisieren

Installieren Sie das Update für den verwendeten Zweig: .NET 8 auf 8.0.33, .NET 9 auf 9.0.22, .NET 10 auf 10.0.14 und .NET 11 auf Release Candidate 3. Installieren Sie bei Framework-dependent-Anwendungen die aktualisierte Runtime und starten Sie die Anwendung neu. Self-contained-Anwendungen müssen neu erstellt und veröffentlicht werden: Ein Runtime-Update auf dem Host ersetzt nicht die in der Anwendung enthaltene Kopie. Erstellen Sie Container mit aktualisierten .NET-Images neu und stellen Sie sie erneut bereit.

Verwenden Sie für NativeAOT beim erneuten Veröffentlichen ebenfalls aktualisierte SDKs und Runtime-Pakete. Falls sich die Korrektur noch nicht bereitstellen lässt, deaktivieren Sie vorübergehend Brotli an den ermittelten Eingabepfaden, die nicht vertrauenswürdige Daten entgegennehmen. Prüfen Sie reguläre Anfragen und Integrationen: Das Deaktivieren der Komprimierung kann die Verarbeitung von Clients verändern, die komprimierte Inhalte senden.

Node.js und Systemabhängigkeiten prüfen

Das Node.js-Projekt meldete die Sicherheitslücke am 21. Oktober: Betroffen ist der in Node.js 22.x, 24.x und 26.x integrierte Brotli-Decoder. Das Node.js-Sicherheitsupdate nennt als korrigierte Versionen 22.23.4, 24.22.1 beziehungsweise 26.12.1. Aktualisieren Sie den verwendeten unterstützten Zweig und starten Sie den Dienst neu. Laut Projektbeschreibung tritt das Problem auf, wenn eine Anwendung mit node:zlib von Angreifern bereitgestellte Daten entpackt; die Speicherbeschädigung kann zu einem Absturz, zur Offenlegung von Speicherinhalten oder zur entfernten Ausführung von Code führen.

Prüfen Sie auch Abhängigkeiten, die unabhängig von der Systeminstallation von Node.js oder .NET bereitgestellt werden. Vergleichen Sie die Brotli-Versionen in Containern und Build-Artefakten und wiederholen Sie die Prüfung nach der Bereitstellung. Fixieren Sie in der CI das aktualisierte Basis-Image und beziehen Sie die Versionskontrolle anfälliger Bibliotheken in den regulären Build-Prozess ein.

Kurzer Maßnahmenplan

1. Erstellen Sie eine Liste der Anwendungen, SDKs, Runtimes, Container und NativeAOT-Builds, die Brotli verwenden.
2. Suchen Sie nach Stellen, an denen externe Daten automatisch oder direkt dekodiert werden.
3. Aktualisieren Sie .NET, Node.js und separat bereitgestellte Bibliotheken auf korrigierte Versionen; erstellen Sie eigenständige Anwendungen und Container neu.
4. Starten Sie die Prozesse neu und prüfen Sie die Versionen in der laufenden Umgebung, nicht nur in den Projektdateien.
5. Solange die Korrektur noch nicht bereitgestellt ist, schränken Sie die Verarbeitung nicht vertrauenswürdiger Brotli-Eingaben an den ermittelten anfälligen Stellen ein.

Die Priorität hängt von zwei Faktoren ab: ob eine anfällige Komponente vorhanden ist und ob ein speziell präparierter komprimierter Datenstrom an sie übergeben werden kann. Das Update behebt den Fehler; eine Übersicht der Eingabepfade hilft sicherzustellen, dass die Korrektur auch Prozesse, eigenständige Builds und Container erreicht.