Am 6. Februar 2025 veröffentlichte Microsoft einen Security-Blog-Eintrag mit einer Zahl, die aufhorchen lässt: mehr als 3.000 öffentlich exponierte ASP.NET Machine Keys, mit denen Angreifer zwischen dem 11. und 19. Dezember 2024 gefälschte ViewState-Pakete in fremde IIS-Server einschleusten und darüber Code im Kontext des Worker-Prozesses w3wp.exe ausführten. Kein Zero-Day, kein exotischer Exploit. Nur ein kryptografischer Schlüssel, der eigentlich geheim sein sollte und es nicht war.
Ein Schlüssel aus der Doku ist kein Schlüssel mehr
Der Mechanismus dahinter ist unspektakulär, gerade deshalb gefährlich. ASP.NET verschlüsselt und signiert den sogenannten ViewState, den Zustand einer Webseite zwischen Formular-Postbacks, mit einem Machine Key aus der web.config. Wer diesen Key kennt, kann eigene ViewState-Pakete bauen und signieren, die der Server als legitim akzeptiert, samt eingeschleustem Code. Das Problem: Viele Entwickler übernehmen Beispiel-Keys direkt aus Tutorials, Stack-Overflow-Antworten oder Doku-Snippets, statt sich selbst zufällige Werte generieren zu lassen. Ein Key, der einmal öffentlich in einem Code-Repository oder einer Anleitung stand, bleibt öffentlich, egal wie viele Jahre seitdem vergangen sind. Die Angreifer, die Microsoft im Februar 2025 beschrieb, setzten anschließend das Post-Exploitation-Framework Godzilla ein, komplett mit Shellcode-Injection und persistenter Command-Execution.
Wie real dieses Muster ist, zeigte sich noch einmal im September 2025 an einem völlig anderen Fall: Bei einem verbreiteten .NET-basierten CMS wurde eine kritische ViewState-Deserialisierungslücke bekannt, CVSS 9,0, deren Ursache ein Beispiel-Key aus der eigenen Dokumentation von vor 2017 war, der in Produktivsystemen weiterlief. Die Angriffskette folgte demselben Schema wie beim Massenangriff: Sondierung eines exponierten ViewState-Formulars, Payload mit bekanntem Key, Remote Code Execution, danach Post-Exploitation-Tools zur Rechteausweitung und Aufklärung im Netzwerk. Es geht hier nicht um das Produkt selbst, das reagierte mit einem eigenen Advisory und Patches. Es geht um den Beleg, dass diese Angriffsklasse nicht theoretisch ist, sondern in freier Wildbahn ausgenutzt wird, sobald ein Machine Key öffentlich auffindbar ist.
Klartext für Geschäftsführer: Wenn Ihre Webseite oder Ihr Kundenportal auf ASP.NET läuft, lohnt sich eine einzige Frage an Ihre Entwicklung oder Ihren Dienstleister: Wurde der Machine Key jemals selbst generiert, oder stammt er noch aus einer Vorlage? Diese Frage kostet fünf Minuten und schließt eine der am aktivsten ausgenutzten Lücken der letzten anderthalb Jahre.
Zwei kritische Lücken direkt im Framework, nicht im Altbestand
Das Machine-Key-Problem ist ein Legacy-Thema, entstanden aus Copy-Paste-Gewohnheiten über Jahre. Wer daraus schließt, aktuelle .NET-Versionen seien automatisch sicherer, sollte zwei Fälle aus 2025 und 2026 kennen.
CVE-2025-55315 betrifft Kestrel, den Webserver, den praktisch jede ASP.NET-Core-Anwendung unter der Haube nutzt. CVSS 3.1: 9,9, laut NVD verursacht durch uneinheitliches Parsing von HTTP-Requests zwischen vorgeschalteten Proxys oder Load-Balancern und Kestrel selbst, eine klassische Request-Smuggling-Schwäche, mit der sich eine zweite, versteckte Anfrage in eine legitime einschmuggeln lässt und dadurch Sicherheitsprüfungen umgeht. Betroffen waren ASP.NET Core 2.3 vor Version 2.3.6, 8.0 vor 8.0.21 sowie 9.0 vor 9.0.10. Microsoft veröffentlichte den Patch am 14. Oktober 2025. Laut Presseberichten, unter anderem CSO Online, war es der höchste je an eine ASP.NET-Core-Lücke vergebene Schweregrad. Diese Einordnung stammt nicht aus dem MSRC-Blog selbst, aber der CVSS-Wert von 9,9 ist NVD-belegt und spricht für sich.
Ein halbes Jahr später, am 21. April 2026, folgte CVE-2026-40372: eine Regression in den Microsoft.AspNetCore.DataProtection-NuGet-Paketen, Versionen 10.0.0 bis 10.0.6, CVSS 9,1. Der managed authenticated encryptor berechnete die HMAC-Prüfsumme über die falschen Bytes der Nutzlast, teils wurde der berechnete Hash sogar verworfen. Damit ließen sich signierte Payloads fälschen, darunter Auth-Cookies. Microsoft wurde nach eigener Darstellung über Nutzerberichte aufmerksam, die nach dem Update auf .NET 10.0.6 von fehlgeschlagenen Entschlüsselungen berichteten. Der Fix folgte einen Tag später, am 22. April, mit Version 10.0.7.
Ein drittes, kleineres Beispiel rundet das Bild ab: CVE-2025-24070, CVSS 7,0, ein Logikfehler in RefreshSignInAsync, der bei unzureichend authentifiziertem User-Parameter dazu führen konnte, dass sich ein Angreifer faktisch als anderer Nutzer anmelden ließ. Betroffen waren ASP.NET Core 8.0 (bis 8.0.13) und 9.0 (bis 9.0.2). Ein Presseartikel von TuxCare behauptet zusätzlich, auch .NET 6 sei trotz fehlender offizieller Dokumentation betroffen. Diese Zusatzbehauptung lässt sich am offiziellen GitHub-Security-Advisory nicht direkt nachvollziehen, sie steht hier nur der Vollständigkeit halber und mit klarer Quellenangabe.
Klartext für Techniker: Alle drei Lücken wurden über Patches geschlossen, keine davon erfordert Architekturänderungen. Der eigentliche Risikofaktor ist die Zeit zwischen Advisory und Update-Einspielung. Bei CVE-2025-55315 lagen zwischen Bekanntwerden und breiter Ausnutzung in der Praxis wenige Wochen, das ist der Zeitraum, in dem Patch-Management über Kompromittierung entscheidet.
Der Klassiker, der einfach nicht sterben will
Neben den CVE-nummerierten Lücken gibt es eine strukturelle Schwäche, die seit weit über zehn Jahren dokumentiert ist und trotzdem regelmäßig in aktuellen Scans auftaucht: die IIS-Tilde-Enumeration. Windows-Dateisysteme generieren für lange Dateinamen automatisch kurze 8.3-Namen. IIS beantwortet speziell präparierte Tilde-Requests mit unterschiedlichen HTTP-Statuscodes, je nachdem, ob eine Datei oder ein Ordner mit passendem Kurznamen existiert. Aus diesem Unterschied lässt sich systematisch ableiten, welche Dateien und Verzeichnisse auf dem Server liegen, einschließlich Konfigurations- und Wartungsskripten, die eigentlich nicht auffindbar sein sollten. Kein CVE, keine Versionsnummer, keine Ausnutzung eines Bugs im eigentlichen Sinn, nur ein seit Jahren bekanntes Verhalten, das schlicht nie deaktiviert wurde. Genau das macht es interessant: Während CVE-Lücken irgendwann gepatcht sind, bleibt diese Schwäche so lange bestehen, bis sie jemand aktiv abschaltet.
Was tatsächlich zu tun ist
Vier Punkte lassen sich ohne größeren Aufwand prüfen, unabhängig davon, welches CMS oder Framework konkret im Einsatz ist.
Erstens, Machine-Key-Herkunft klären. Ein Key aus Doku, Tutorial oder Beispielprojekt gehört ersetzt, unabhängig vom Alter der Anwendung. Microsoft empfiehlt zusätzlich regelmäßige Rotation und Verschlüsselung der web.config-Sektionen, in denen der Key liegt.
Zweitens, Patch-Stand der ASP.NET-Core-Version gegen die aktuellen Advisories prüfen, nicht nur einmalig, sondern als wiederkehrenden Termin. CVE-2025-55315 und CVE-2026-40372 zeigen, dass selbst brandneue, gerade erst veröffentlichte Paketversionen kritische Lücken enthalten können.
Drittens, 8.3-Kurznamen-Generierung auf dem IIS-Server per fsutil deaktivieren, wo technisch möglich, alternativ Tilde- und Wildcard-Muster über IIS Request Filtering oder eine vorgeschaltete Web Application Firewall blockieren.
Viertens, und das lässt sich nicht outsourcen: eine Liste führen, welche .NET- und ASP.NET-Core-Version auf welchem System läuft. Ohne diese Übersicht bleibt jede der drei genannten CVE-Nummern eine abstrakte Meldung statt einer konkreten, prüfbaren Frage.
Wer diese vier Punkte nicht selbst beantworten kann, hat damit bereits die erste, wichtigste Erkenntnis dieses Artikels: eine offene Frage, die vor dem nächsten Deployment geklärt gehört, nicht danach.
Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 26.07.2026. Er ersetzt keine anwaltliche oder technische Prüfung des konkreten Sachverhalts und begründet keine Zusicherung von Rechtssicherheit oder IT-Sicherheit.