Microsoft hat am Sonntag, dem 25. Oktober 2026, völlig überraschend neue Sicherheitsupdates für .NET rausgehauen. Mitten außerhalb des regulären Patchdays heißt das für Administratoren und Entwickler mal wieder: reagieren. Insgesamt geht es um vier Sicherheitslücken, darunter ein ziemlich übler Speicherfehler im weit verbreiteten Brotli-Decoder. Besonders unangenehm: Zwei der Schwachstellen waren eigentlich schon am Oktober-Patchday dran, wurden damals aber nicht richtig behoben.
Betroffen sind .NET 8, .NET 9 und .NET 10 sowie die Vorabversion .NET 11. Auch für PowerShell 7 hat Microsoft entsprechende Aktualisierungen veröffentlicht. Wir zeigen Dir, welche Versionen betroffen sind, wie Du Deine Installation überprüfst und welche Updates jetzt erforderlich sind.
Microsoft .NET Notfallupdate vom 25. Oktober 2026
Normalerweise veröffentlicht Microsoft seine Sicherheitsupdates am zweiten Dienstag eines Monats. Bei schwerwiegenden Problemen kann es allerdings notwendig sein, zusätzliche Updates außerhalb dieses festen Zeitplans bereitzustellen.
Genau das ist am 25. Oktober 2026 passiert. Microsoft hat neue Versionen seiner .NET-Laufzeitumgebung veröffentlicht und empfiehlt, betroffene Installationen möglichst zeitnah zu aktualisieren.
Die wichtigste Schwachstelle hat die Kennung CVE-2026-111497. Sie steckt im Brotli-Decoder, der komprimierte Daten verarbeitet. Ein speziell präparierter Datenstrom kann unter bestimmten Voraussetzungen den Speicher eines verwundbaren Prozesses beschädigen.
| Merkmal | Information |
|---|---|
| Veröffentlichung | 25. Oktober 2026 |
| Update-Typ | Außerplanmäßiges Sicherheitsupdate |
| Hauptschwachstelle | CVE-2026-111497 |
| CVSS-Wert | 8,1 nach CVSS 3.1 |
| Weitere Sicherheitslücken | Drei zusätzliche CVEs |
| Betroffene .NET Reihen | 8, 9, 10 und 11 RC |
| Weitere Microsoft-Produkte | Unter anderem PowerShell 7 |
| Status | Sicherheitsupdates verfügbar |
Wichtig ist, dass nicht jede Windows-Installation automatisch angreifbar ist. Entscheidend sind die eingesetzte .NET Version und die Funktionen, die eine Anwendung tatsächlich verwendet.
CVE-2026-111497: Was macht die Brotli-Sicherheitslücke gefährlich?
Brotli ist ein Verfahren zur Komprimierung von Daten. Es wird häufig verwendet, um Webseiten und andere Inhalte platzsparend über das Internet zu übertragen. Die empfangende Anwendung muss diese Daten anschließend wieder entpacken.
Genau bei dieser Verarbeitung liegt das Sicherheitsproblem. Speziell manipulierte komprimierte Daten können dazu führen, dass der Decoder außerhalb des vorgesehenen Speicherbereichs schreibt.
Microsoft nennt als mögliche Folgen die Offenlegung vertraulicher Informationen, Programmabstürze und eine Erweiterung von Berechtigungen. Je nach betroffener Software kann eine Speicherbeschädigung auch noch weitergehende Auswirkungen haben.
Der CVSS-Basiswert liegt bei 8,1 nach CVSS 3.1. Microsoft stuft die Schwachstelle damit als schwerwiegend ein.
Welche .NET Anwendungen sind gefährdet?
Ein Risiko besteht insbesondere bei Anwendungen, die fremde Brotli-Daten verarbeiten. Microsoft nennt unter anderem folgende Möglichkeiten:
- ASP.NET Core Anwendungen mit aktivierter Brotli-Dekomprimierung eingehender HTTP-Anfragen.
- Programme, die mit HttpClient automatisch Brotli-komprimierte Antworten entpacken.
- Anwendungen, die ausdrücklich BrotliStream oder andere Brotli-APIs aus System.IO.Compression verwenden.
- Eigenständige Anwendungen, die eine ältere verwundbare Laufzeitumgebung mitbringen.
ASP.NET Core und HttpClient aktivieren die entsprechenden automatischen Dekomprimierungsfunktionen nicht standardmäßig. Deshalb ist die tatsächliche Angriffsfläche kleiner, als es eine pauschale Warnung für sämtliche .NET Programme vermuten lässt.
Die Schwachstelle betrifft nicht ausschließlich Microsoft-Software. Bereits am 21. Oktober hat das Node.js-Projekt korrigierte Versionen veröffentlicht. Darüber haben wir im Beitrag Node.js Sicherheitsupdate Oktober 2026 ausführlich berichtet.
Vier Sicherheitslücken: Diese CVEs behebt Microsoft
Das Notfallupdate enthält insgesamt vier Sicherheitskorrekturen. Zwei davon wurden erst mit der aktuellen Veröffentlichung in .NET behandelt. Bei zwei weiteren Problemen musste Microsoft frühere Korrekturen nachbessern.
| CVE | Problem | CVSS 3.1 |
|---|---|---|
| CVE-2026-111497 | Speicherfehler im Brotli-Decoder | 8,1 |
| CVE-2026-114148 | Unsichere Dateibesitzrechte in bestimmten Linux-Archiven | 7,8 |
| CVE-2026-70197 | Speicherbeschädigung bei Windows-Netzwerkoperationen | 8,1 |
| CVE-2026-102870 | Codeausführung im Blazor WebAssembly Debugger | 8,8 |
Oktober-Updates hatten zwei Schwachstellen nicht vollständig geschlossen
Besonders bemerkenswert sind CVE-2026-70197 und CVE-2026-102870. Microsoft hatte beide Probleme bereits am 13. Oktober 2026 behandelt. Die damaligen Sicherheitsupdates reichten jedoch nicht aus, um die entsprechenden Schwachstellen vollständig zu beheben.
CVE-2026-70197 betrifft die Verarbeitung bestimmter Netzwerkoperationen unter Windows. Dabei kann die Wiederverwendung einer internen Socket-Struktur bei IPv4- und IPv6-Datagrammen zu einer Speicherbeschädigung führen.
CVE-2026-102870 betrifft dagegen Entwickler, die mit dem Blazor WebAssembly Debugger arbeiten. Unter bestimmten Voraussetzungen können manipulierte Werte dazu führen, dass beim Debuggen unerwünschter Programmcode auf dem Entwicklungsrechner ausgeführt wird.
Für diesen Blazor-Fehler reicht es nicht, nur eine neue .NET Runtime zu installieren. Betroffene Entwickler müssen auch die entsprechenden Blazor-Pakete aktualisieren.
Linux-Sicherheitslücke CVE-2026-114148
Eine weitere Korrektur betrifft Dateibesitzrechte in bestimmten Linux-Tarball-Distributionen. Durch fehlerhafte Besitzinformationen kann unter geeigneten Voraussetzungen eine lokale Rechteausweitung möglich sein.
Bei .NET 8 und 9 sind bestimmte ASP.NET Core Archive betroffen. Bei .NET 10 und 11 beschränkt sich das Problem auf spezielle aus dem Quellcode erstellte Archive. Gewöhnliche Windows-Installationspakete sind von dieser zusätzlichen Linux-Schwachstelle nicht betroffen.
Welche .NET Versionen müssen aktualisiert werden?
Microsoft hat für alle betroffenen unterstützten Versionsreihen passende Sicherheitsupdates veröffentlicht. Die nachfolgende Tabelle zeigt die ersten korrigierten Versionen.
| Produkt | Erste korrigierte Version | Status |
|---|---|---|
| .NET 8 | 8.0.33 | Verfügbar |
| .NET 9 | 9.0.22 | Verfügbar |
| .NET 10 | 10.0.14 | Verfügbar |
| .NET 11 | 11.0.0 RC3 | Vorabversion |
Für Entwickler stehen außerdem aktualisierte SDK-Versionen bereit. Dazu gehören 8.0.133 bzw. 8.0.427, 9.0.123 bzw. 9.0.320 sowie 10.0.114 bzw. 10.0.403.
Wer noch .NET 8 oder 9 verwendet, sollte außerdem den bevorstehenden Supportablauf im Blick haben. Beide Versionsreihen erreichen am 10. November 2026 ihr reguläres Supportende. Für Anwendungen, die längerfristig laufen sollen, ist deshalb eine Migration auf eine weiterhin unterstützte Version einzuplanen.
Ist das klassische .NET Framework ebenfalls betroffen?
Nein. Microsoft bestätigt ausdrücklich, dass das klassische .NET Framework von CVE-2026-111497 nicht betroffen ist.
Das ist eine wichtige Unterscheidung. .NET 8, 9 und 10 sind nicht mit dem älteren .NET Framework 3.5 oder 4.8.1 gleichzusetzen. Für diese klassischen Framework-Versionen sind die hier beschriebenen Notfallupdates nicht vorgesehen.
Wie sich das ältere Framework unter Windows installieren lässt, erklären wir beispielsweise in unserer Anleitung .NET Framework 3.5 unter Windows 11 installieren.
PowerShell 7 erhält ebenfalls neue Sicherheitsversionen
Neben .NET hat Microsoft am 25. Oktober 2026 auch neue PowerShell-Versionen veröffentlicht. Die Aktualisierungen übernehmen die korrigierten .NET Komponenten und sind deshalb für Administratoren besonders interessant.
| PowerShell-Reihe | Korrigierte Version |
|---|---|
| PowerShell 7.4 | 7.4.22 |
| PowerShell 7.5 | 7.5.13 |
| PowerShell 7.6 | 7.6.9 |
Wenn Du PowerShell 7 auf einem Windows-PC oder Server verwendest, kannst Du die installierte Version mit folgendem Befehl überprüfen:
pwsh -vEine Ausgabe mit Version 7.5.12 zeigt zum Beispiel, dass noch nicht die neue Version 7.5.13 installiert ist.
Wichtig ist außerdem: Windows PowerShell 5.1 und PowerShell 7 sind unterschiedliche Produkte. Die klassische Windows PowerShell setzt auf das .NET Framework. Die beschriebenen PowerShell-7-Aktualisierungen sind dafür nicht gedacht.
Weitere Möglichkeiten zur Versionskontrolle erklären wir unter Welche PowerShell Version ist installiert?.
Schritt für Schritt: Installierte .NET Version unter Windows 11 überprüfen
Bevor Du ein Sicherheitsupdate installierst, kannst Du feststellen, welche .NET Laufzeitumgebungen auf Deinem Computer vorhanden sind. Dafür genügt normalerweise die Windows-Eingabeaufforderung oder PowerShell.
Schritt 1: Windows Terminal öffnen
Über einen Rechtsklick auf das Startmenü kannst Du Windows Terminal öffnen. Alternativ lässt sich die Eingabeaufforderung über die Windows-Suche starten.
Welche Möglichkeiten es dafür gibt, zeigen wir in unserer Anleitung Windows 11 Eingabeaufforderung öffnen.
Schritt 2: Installierte Laufzeitumgebungen anzeigen
Mit folgendem Befehl kannst Du die vorhandenen .NET Runtimes auflisten:
dotnet --list-runtimesEine mögliche Ausgabe sieht folgendermaßen aus:
Microsoft.AspNetCore.App 10.0.13
Microsoft.NETCore.App 10.0.13Dieses Beispiel zeigt eine Installation mit dem Sicherheitsstand vom 13. Oktober. Für die jetzt veröffentlichten Korrekturen ist die entsprechende Version 10.0.14 erforderlich.
Eine vollständige Übersicht der SDK-Installation und ihrer Umgebung erhältst Du zusätzlich mit:
dotnet --infoFalls der Befehl nicht gefunden wird, ist die .NET-Kommandozeilenumgebung vielleicht nicht installiert oder ihr Installationspfad nicht erreichbar. Das heißt aber nicht automatisch, dass keine Anwendung ihre eigene .NET-Runtime mitbringt.
Schritt 3: Passendes Sicherheitsupdate installieren
Wenn eine ältere betroffene Version vorhanden ist, kannst Du das passende Update über die Microsoft-Downloadseite oder Deinen bisherigen Softwareverteilungsweg installieren.
Auf Windows Servern stehen entsprechende Updates laut Microsoft auch über WSUS und den Microsoft Update Catalog zur Verfügung. Welche Möglichkeiten es bei der zentralen Verteilung von Sicherheitsupdates gibt, behandeln wir im Beitrag Windows Server Updates Oktober 2026.
Nach der Installation kann ein Neustart der betroffenen Anwendung oder des Computers erforderlich sein, damit die korrigierten Komponenten verwendet werden.
Microsoft .NET Notfallupdates herunterladen
Die Sicherheitsversionen vom 25. Oktober 2026 stehen auf den offiziellen Microsoft-Downloadseiten bereit. Wähle die zu Deiner Anwendung passende Runtime, Desktop Runtime, ASP.NET Core Runtime oder das benötigte SDK aus.
.NET Notfallupdates herunterladen
Microsoft hat neue Sicherheitsversionen für .NET und PowerShell veröffentlicht. Wähle die passende Version und den offiziellen Downloadweg für Dein System.
.NET 8 LTS
Version 8.0.33Sicherheitsupdate für .NET 8 und ASP.NET Core 8. Verfügbare SDKs: 8.0.133 und 8.0.427. Desktop Runtime, Runtime und Hosting Bundle können passend ausgewählt werden.
↓ .NET 8 offiziell herunterladen Microsoft | 8.0.33.NET 9
Version 9.0.22Sicherheitsupdate für .NET 9 und ASP.NET Core 9. SDK-Versionen 9.0.123 und 9.0.320. Der reguläre Support endet am 10. November 2026.
↓ .NET 9 offiziell herunterladen Microsoft | 9.0.22.NET 10 LTS
Version 10.0.14Aktuelles Sicherheitsupdate für .NET 10. Die SDK-Versionen 10.0.114 und 10.0.403 enthalten die korrigierten Laufzeitkomponenten. Auch ASP.NET Core und Desktop Runtime sind verfügbar.
↓ .NET 10 offiziell herunterladen Microsoft | 10.0.14PowerShell 7
Neue SicherheitsversionenPowerShell 7.4.22, 7.5.13 und 7.6.9. Die Versionen übernehmen aktualisierte .NET Komponenten. Wähle die zu Deiner bisherigen Versionsreihe passende Veröffentlichung.
↓ PowerShell Updates herunterladen Microsoft PowerShell | GitHub Releases.NET 11 RC3
11.0.0-rc.3.26522.148Korrigierte Vorabversion von .NET 11 für Test- und Entwicklungsumgebungen. Wer bereits RC2 verwendet, sollte auf RC3 aktualisieren. Nicht für gewöhnliche Produktivinstallationen vorgesehen.
↓ .NET 11 RC3 herunterladen Microsoft | Release Candidateⓘ Wichtige Hinweise zur Installation
Die Download-Schaltflächen führen ausschließlich zu offiziellen Microsoft-Projektseiten. Dort stehen die passenden Installationspakete für Windows, Linux und macOS zur Verfügung.
Unter Windows solltest Du je nach Anwendung zwischen .NET Runtime, Desktop Runtime, ASP.NET Core Runtime, Hosting Bundle und SDK unterscheiden. Eine neuere Runtime einer anderen Hauptversionsreihe ersetzt nicht grundsätzlich die benötigte Version.
Microsoft bestätigt außerdem die Bereitstellung entsprechender .NET Updates über Microsoft Update für Windows-Clients sowie WSUS und Microsoft Update Catalog für Windows Server. Eine allgemeingültige KB-Nummer für alle Pakete wurde nicht bestätigt.
Bei Anwendungen mit eingebetteter Runtime und Docker-Containern kann ein neuer Build erforderlich sein. Nach der Installation sollten die verwendeten Versionen sowie die Anwendung selbst kontrolliert werden.
Bei einer bestehenden .NET Installation über Visual Studio sollte auch der Visual Studio Installer berücksichtigt werden. Nicht jede Anwendung lässt sich zuverlässig durch die Installation eines beliebigen neueren .NET SDKs aktualisieren.
Windows Server und Unternehmen: Was Administratoren beachten sollten
Bei größeren IT-Umgebungen reicht es oft nicht, nur die üblichen installierten Programme zu prüfen. .NET-Komponenten werden auch von Webanwendungen, Windows-Diensten, Entwicklungswerkzeugen und Containern verwendet.
ASP.NET Core und IIS
Wenn eine Webanwendung auf einem Windows Server mit IIS betrieben wird, kann das entsprechende ASP.NET Core Hosting Bundle erforderlich sein. Microsoft stellt dafür eigene Installationspakete bereit.
Nach der Aktualisierung sollte überprüft werden, ob die Anwendung wieder korrekt startet und tatsächlich die aktualisierte Runtime verwendet.
Wie Du betroffene Dienste kontrollieren kannst, erklären wir unter Windows Dienste starten und stoppen.
Eigenständige Anwendungen und Docker-Container
Besondere Aufmerksamkeit verdienen sogenannte Self-contained-Anwendungen. Sie bringen ihre eigene .NET-Runtime mit und sind deshalb nicht automatisch geschützt, wenn Du nur die gemeinsam installierte Runtime aktualisierst.
Solche Programme müssen mit der korrigierten Version neu erstellt und bereitgestellt werden. Ähnlich sieht es bei Docker-Containern aus: Hier müssen die verwendeten Images aktualisiert und die Container neu bereitgestellt werden.
Aus der Administratorpraxis: Anwendungen nach dem Update testen
Unsere Empfehlung ist, zunächst öffentlich erreichbare Webanwendungen und geschäftskritische Dienste zu betrachten. Anschließend lohnt sich eine Überprüfung vorhandener Entwicklungsumgebungen und Programme mit eingebetteter Runtime.
Vor der Installation sollten eine passende Datensicherung und möglichst ein kurzer Funktionstest eingeplant werden. Besonders bei produktiven Webservern empfiehlt sich eine kontrollierte Aktualisierung.
Wenn nach einem Update unerwartete Programmfehler auftreten, hilft die Windows-Ereignisanzeige bei der Untersuchung. Unsere Anleitung Ereignisanzeige mit PowerShell auslesen zeigt die entsprechenden Befehle.
Für schwer nachvollziehbare Datei- und Registry-Zugriffe kann zusätzlich der Microsoft Process Monitor hilfreich sein.
Gibt es einen Workaround für die Brotli-Sicherheitslücke?
Wenn eine sofortige Aktualisierung nicht möglich ist, können Entwickler vorübergehend prüfen, ob sich die Verarbeitung nicht vertrauenswürdiger Brotli-Daten abschalten lässt.
Bei ASP.NET Core betrifft das zum Beispiel ausdrücklich aktivierte Funktionen zur Dekomprimierung eingehender Anfragen. Bei HttpClient kann eine entsprechend konfigurierte automatische Brotli-Dekomprimierung relevant sein.
So eine Änderung sollte sorgfältig getestet werden, weil Anwendungen möglicherweise auf die komprimierten Daten angewiesen sind. Außerdem schützt sie nicht automatisch alle anderen Brotli-Verarbeitungspfade.
Der bevorzugte Schutz bleibt deshalb die Installation der korrigierten Softwareversion. Eine reine Anpassung der Windows-Firewall oder ein normales Windows Update ohne Prüfung der tatsächlich verwendeten Runtime reicht nicht in jedem Fall aus.
Werden die Sicherheitslücken bereits aktiv ausgenutzt?
Zum Stand vom 26. Oktober 2026 bestätigen die ausgewerteten Microsoft-Veröffentlichungen keine konkreten erfolgreichen Angriffe auf betroffene .NET Installationen.
Für die zugrunde liegende Brotli-Schwachstelle existieren allerdings bereits öffentliche technische Untersuchungen und Demonstrationen. Das erhöht den Handlungsdruck, ist aber nicht mit einer bestätigten erfolgreichen Ausnutzung sämtlicher betroffener Microsoft-Produkte gleichzusetzen.
Gerade öffentlich erreichbare Anwendungen, die komprimierte Daten aus nicht vertrauenswürdigen Quellen verarbeiten, sollten deshalb mit hoher Priorität überprüft werden.
FAQ: Häufige Fragen zu den .NET Notfallupdates
Microsoft musste neue Sicherheitslücken schließen und zwei Korrekturen des Oktober-Patchdays nachbessern. Die Updates betreffen .NET 8, 9, 10 und .NET 11 RC3.
Die ersten korrigierten Versionen sind .NET 8.0.33, 9.0.22, 10.0.14 und .NET 11 RC3. Auch neuere, entsprechend korrigierte Versionen können verwendet werden.
Die Schwachstelle betrifft bestimmte .NET Komponenten und Anwendungen, die verwundbare Brotli-Dekomprimierung verwenden. Nicht jeder Windows-11-Computer ist dadurch automatisch angreifbar.
Mit dem Befehl dotnet –list-runtimes kannst Du die gemeinsam installierten .NET Laufzeitumgebungen auflisten. Eigenständige Anwendungen mit eingebetteter Runtime müssen zusätzlich überprüft werden.
Nein. Windows PowerShell 5.1 verwendet das klassische .NET Framework. Die neuen PowerShell-7-Versionen betreffen die moderne, separat installierte PowerShell.
Fazit: Microsofts Notfallupdates sollten zeitnah installiert werden
Die außerplanmäßigen Sicherheitsupdates vom 25. Oktober 2026 zeigen, dass der Oktober-Patchday für .NET noch nicht abgeschlossen war. Neben der gefährlichen Brotli-Schwachstelle musste Microsoft zwei frühere Sicherheitskorrekturen nachbessern.
Mit .NET 8.0.33, 9.0.22, 10.0.14 und .NET 11 RC3 stehen bereits korrigierte Versionen bereit. Zusätzlich sollten Administratoren die installierten PowerShell-7-Versionen überprüfen.
Besonders wichtig ist die vollständige Kontrolle aller verwendeten Laufzeitumgebungen. Anwendungen mit integrierter Runtime und Docker-Container benötigen unter Umständen eigene Aktualisierungen. Weitere technische Informationen und den offiziellen Veröffentlichungsstand findest Du in der Microsoft-Ankündigung zu den .NET Notfallupdates vom 25. Oktober 2026.
Neueste Kommentare