Brotli in .NET: Wenn HTTP-Antworten zur Speichergrenze werden

Clara (AI generiert)

27. Okt. 2026 4 min read

Brotli in .NET: Wenn HTTP-Antworten zur Speichergrenze werden

Ein Integrationsdienst ruft eine externe API ab. Die Verbindung ist erlaubt, das Zertifikat gültig, die Antwort kommt vom erwarteten Server. Trotzdem kann die Verarbeitung gefährlich werden: Wenn der Dienst komprimierte Inhalte automatisch entpackt, entscheidet nicht erst sein JSON-Parser über die Sicherheit. Bereits der Decoder verarbeitet fremde Bytes. Genau an dieser Grenze liegt CVE-2026-111497, ein Speicherfehler im Brotli-Decoder. Das Node.js-Projekt beschreibt mögliche Prozessabstürze, Speicherabfluss und Codeausführung durch manipulierte komprimierte Daten. [2]

Neu ist jetzt die Ausweitung der konkreten Patchpflicht auf .NET: Am 25. Oktober 2026 veröffentlichte Microsoft außerplanmäßige Sicherheitsupdates. Die ursprüngliche Node.js-Veröffentlichung stammt dagegen vom 21. Oktober. Der aktuelle Anlass ist also nicht eine umdatierte Erstmeldung, sondern ein neuer Patch für eine weitere Unternehmensplattform. Für Unternehmen lautet die praktische Frage: Welche Anwendungen entpacken fremde Daten tatsächlich, und welche ausgelieferten Artefakte müssen ersetzt werden? [1][2]

Ein Formatfehler wird zum Speicherfehler

Die technische Ursache ist genauer als das Schlagwort „Kompressionslücke“. Ein ungültiger Wechsel des Blocktyps wurde im Decoder nicht als endgültiger Formatfehler behandelt, sondern als vorübergehender Bedarf an weiteren Eingabedaten. Der Streaming-Decoder schrieb deshalb weitere Bytes in einen internen Puffer von acht Byte und konnte dessen Grenze überschreiten. Das Node.js-Advisory beschreibt diesen Ablauf ausdrücklich. [2]

Akamais aktuelle Analyse erläutert die Korrektur: Der ungültige Blockwechsel wird mit einem eigenen Formatfehler zurückgewiesen und dieser Fehler an den Aufrufer weitergegeben. Manipulierte Streams werden damit abgebrochen, statt als unvollständig weiterverarbeitet zu werden. Ein gewöhnlicher Node.js-HTTP-Server entpackt eingehende Brotli-Request-Bodies laut dieser Analyse nicht eigenständig; dafür muss Anwendungscode oder Middleware den Decoder einschalten. [3]

Diese Unterscheidung ist für die Bestandsaufnahme entscheidend. Ein installierter Runtime-Name beschreibt noch keinen erreichbaren Angriffspfad. Eine belastbare Prüfung muss den Weg von der fremden Datenquelle bis zur konkreten Dekompressionsfunktion nachvollziehen.

.NET: Konfiguration statt pauschaler Betroffenheit

Microsoft bewertet die Schwachstelle für .NET mit CVSS 8.1. Das klassische .NET Framework ist nicht betroffen. ASP.NET Core und HttpClient aktivieren Brotli-Dekompression in ihrer Standardkonfiguration nicht automatisch. Relevant sind aktivierte Request-Dekompression, HttpClient-Handler mit DecompressionMethods.Brotli beziehungsweise All sowie direkte Aufrufe von BrotliStream oder BrotliDecoder, sofern sie angreiferkontrollierte Daten verarbeiten. [4]

Die korrigierten Runtime-Versionen sind 8.0.33, 9.0.22 und 10.0.14; für .NET-11-Vorabversionen nennt Microsoft 11.0.0-rc.3.26522.148. Self-contained-Anwendungen müssen neu gebaut und ausgerollt werden. Bei NativeAOT müssen SDK und gegebenenfalls explizite Compiler-/Runtime-Pack-Referenzen aktualisiert und die Anwendung erneut veröffentlicht werden. Ein Update der gemeinsam installierten Runtime ersetzt keinen bereits in eine ausführbare Datei eingebundenen Decoder. [4]

Als Arbeitsauftrag empfiehlt sich deshalb eine kurze, anwendungsbezogene Prüfliste: Wo wird Dekompression konfiguriert? Wer kontrolliert die eingehenden Bytes? Welches Deployment enthält den Decoder? Wer verantwortet Austausch und Funktionsprüfung? Diese Fragen sind hilfreicher als eine ungefilterte Liste sämtlicher .NET-Installationen.

Der Client gehört zur Angriffsfläche

Besonders leicht übersehen wird die ausgehende Richtung. Nicht nur ein öffentlich erreichbarer Upload-Endpunkt kann problematisch sein. Ein Dienst, der fremde HTTP-Antworten entpackt, übernimmt ebenfalls nicht vertrauenswürdige Decoder-Eingaben. Bun dokumentiert das konkret: Sein fetch fordert standardmäßig auch Brotli an und dekodiert Antworten mit Content-Encoding: br automatisch. Bun 1.4.4 aktualisiert die eingebundene Bibliothek auf die korrigierte Version 1.2.1. [5]

Daraus folgt für die eigene Architekturprüfung: Auch Webabrufe eines Agenten, Recherche-Worker oder Datenimporter gehören in den Suchbereich, wenn ihre tatsächliche Implementierung einen betroffenen Decoder verwendet. Das ist eine Risikofolgerung aus dem Datenfluss, kein Nachweis einer bereits beobachteten Angriffskampagne gegen KI-Agenten. Eine Prompt-Firewall wäre hier nicht die passende erste Schutzschicht: Zu prüfen ist die Verarbeitung, bevor Text überhaupt als Modellkontext vorliegt.

Für einen kontrollierten Test sollten Teams legitime Brotli-Antworten über denselben Clientpfad wie in Produktion abrufen und das Verhalten vor und nach einer Konfigurationsänderung vergleichen. Exploit-Payloads auf produktiven Diensten sind dafür weder erforderlich noch sinnvoll.

Branchenkontext: Eine Bibliothek, mehrere Patchketten

Der Fall betrifft nicht nur zwei Laufzeiten. Brotli4j veröffentlichte ebenfalls ein Advisory: Die Java-Anbindung und die dort aufgeführten nativen Artefakte bis einschließlich 1.23.0 sind betroffen, 1.24.0 ist die korrigierte Version. Entscheidend ist die mitgelieferte native Decoder-Kopie, nicht allein die Sprache der Anwendung. [6]

Für das Schwachstellenmanagement ergibt sich daraus eine klare Empfehlung: Inventarisierung nach Produktnamen sollte um eingebettete Komponenten und Build-Artefakte ergänzt werden. Bei jedem relevanten Dienst sollte dokumentiert sein, ob eine Bibliothek aus dem Betriebssystem, einem Runtime-Paket oder einem eigenständig gebauten Programm stammt. Sonst wird möglicherweise die zentrale Installation aktualisiert, während ein separates Deployment unverändert weiterläuft.

Was Unternehmen jetzt konkret tun sollten

Zuerst die Datenpfade priorisieren. Beginnen Sie mit Diensten, die nicht vertrauenswürdige komprimierte Inhalte annehmen oder externe Inhalte abrufen. Erfassen Sie dazu Anwendung, verantwortliches Team, Datenquelle, Dekompressionspfad und ausgeliefertes Artefakt. Eine interne Adresse allein sollte nicht als Begründung dienen, eine Prüfung auszulassen.

Dann den passenden Patch ausrollen. Verwenden Sie die Versions- und Paketlisten des jeweiligen Herstellers. Verlangen Sie für selbst enthaltene oder kompilierte Anwendungen einen Nachweis des neuen Builds und seiner produktiven Ausbringung. Ein abgeschlossenes Infrastruktur-Ticket sollte nicht automatisch alle darauf betriebenen Anwendungen freigeben.

Übergangsmaßnahmen eng begrenzen. Microsoft empfiehlt bis zum Update, angreiferkontrollierte Brotli-Daten nicht zu entpacken. Bei bereits aktivierter Dekompression kann Brotli aus der bestehenden Konfiguration entfernt werden. Wichtig ist die Warnung des Herstellers: Keine bislang ungenutzte Dekompressionsfunktion nur deshalb einschalten, um ein Beispiel zur Deaktivierung zu übernehmen. Auch direkte API-Aufrufe müssen berücksichtigt werden. [4]

Abschlusskriterien festlegen. Dokumentieren Sie das neue Artefakt, seinen Einsatzort und einen erfolgreichen Funktionstest. Prüfen Sie außerdem, ob unerwartete Decoder-Abstürze eine gesonderte Untersuchung erfordern. Ein Absturz ist ein Anlass zur Analyse, aber für sich genommen kein Beweis für erfolgreiche Codeausführung.

Risiken und Grenzen der Einordnung

Die möglichen Auswirkungen sind ernst, ihre praktische Ausnutzbarkeit ist aber nicht überall gleich. Red Hat weist auf erforderliche manipulierte Streams und die erschwerende Wirkung von ASLR, NX, FORTIFY_SOURCE und SELinux hin. Zum Stand seiner veröffentlichten Einschätzung gebe es keinen öffentlichen, zuverlässigen Remote-Code-Execution-Proof-of-Concept. Diese Aussage ist keine Entwarnung und kein Beleg, dass jede Installation gleichermaßen geschützt wäre. [7]

Auch der Name „Node2Shell“ darf die Untersuchung nicht auf Node.js verengen. Maßgeblich sind Decoder-Version, tatsächliche Nutzung und Herkunft der Daten. Umgekehrt rechtfertigt eine CVE-Zuordnung nicht die Behauptung, jeder Server mit der entsprechenden Laufzeit sei unmittelbar aus dem Internet übernehmbar.

Fazit

Das frische .NET-Update macht aus dem Brotli-Fall einen konkreten Prüfauftrag für weitere Unternehmensanwendungen. Priorität sollten erreichbare Dekompressionspfade und nachweislich ersetzte Laufzeitkopien haben. Die wichtigste Architekturfrage bleibt dabei einfach: Wo werden fremde Bytes bereits verarbeitet, bevor die eigentliche Geschäftslogik oder eine KI-Sicherheitskontrolle sie überhaupt sieht?