Microsoft hat Ende April 2026 außerplanmäßig einen Out-of-Band-Patch für ASP.NET Core veröffentlicht. Der Auslöser: CVE-2026-40372, eine kryptografische Lücke in der Data Protection-Bibliothek, die Angreifer ohne jede Authentifizierung in den Stand versetzt, gültige Authentifizierungs-Cookies zu fälschen. CVSS 9.1. Wer .NET-10-Workloads betreibt, hat keine Wartezeit mehr.

Was ist passiert?

Die Microsoft.AspNetCore.DataProtection-Bibliothek ist das stille Rückgrat moderner ASP.NET-Core-Anwendungen. Sie verschlüsselt und signiert alles, was zwischen Client und Server pendelt und vor Manipulation geschützt sein muss: Authentifizierungs-Cookies, Anti-Forgery-Tokens, Session-IDs, OAuth-State-Werte, Reset-Token, geschützte URL-Parameter. Entwickler nutzen sie meist gar nicht direkt – das ASP.NET-Identity-Framework, OpenIddict, Duende IdentityServer und unzählige Eigenentwicklungen rufen sie im Hintergrund auf.

Mit der Veröffentlichung von .NET 10 hat Microsoft die Data-Protection-Internals refaktoriert. Im Zuge dieser Refaktorierung schlich sich eine Regression in den managed authenticated encryptor ein: Der Code berechnet das HMAC-Validierungs-Tag über die falschen Bytes des Payloads – und verwirft den berechneten Hash in bestimmten Fällen vollständig. Im Klartext: Die Authentizitätsprüfung, die eigentlich verhindert, dass Angreifer einen Cookie verändern oder neu erfinden, läuft ins Leere.

Das Resultat: Wer einen ASP.NET-Core-10-Server mit aktiviertem Data Protection erreicht, kann selbst gebaute Cookies einreichen, die der Server als gültig akzeptiert. Identität, Rollen, Anspruch – alles fälschbar.

Die technischen Eckdaten

CVE-Nummer: CVE-2026-40372
CVSS-Score: 9.1 (Critical)
Betroffene Versionen: Microsoft.AspNetCore.DataProtection 10.0.0 bis einschließlich 10.0.6
Fix-Version: 10.0.7
Vektor: Netzwerkbasiert, ohne Authentifizierung, ohne Benutzerinteraktion
Impact: Vertraulichkeit hoch, Integrität hoch, Verfügbarkeit nicht betroffen
Plattformen: Linux, macOS, Windows – plattformunabhängig, sobald die NuGet-Pakete in der vulnerablen Version geladen werden

Warum gerade dieses Update keinen Aufschub duldet

Drei Punkte machen CVE-2026-40372 besonders gefährlich:

Erstens: Die Lücke ist trivial ausnutzbar. Anders als komplexe Speicherkorruptionen, die Angreifer mit Heap-Sprays und Bypass-Techniken ausnutzen müssen, reicht hier ein bestehendes Wissen über die Data-Protection-Cookie-Struktur und ein Stück Standard-Krypto. Es gibt keine Authentifizierungshürde: Wer den Endpoint erreicht, kann es versuchen.

Zweitens: Die Auswirkung ist Identitätsdiebstahl auf höchstem Niveau. Sobald ein Angreifer einen Auth-Cookie für einen Administrator fälschen kann, übernimmt er nicht nur die Sitzung, sondern oft das gesamte Backend, weil ASP.NET-Anwendungen Rollen und Claims aus dem Cookie ableiten. In einer Identity-Server-Konstellation, in der mehrere Anwendungen denselben Schlüsselring nutzen, multipliziert sich der Schaden.

Drittens: Der Patch allein reicht nicht. Microsoft empfiehlt ausdrücklich, nach dem Update auf 10.0.7 den kompletten Data-Protection-Schlüsselring zu rotieren. Hintergrund: Hat ein Angreifer in der Verwundbarkeitsphase Tokens fälschen oder die Anwendung dazu bringen können, legitime Tokens für eine gefälschte Identität auszustellen, bleiben diese Tokens auch nach dem Patch gültig – sie wurden ja regulär signiert.

Wie Sie sich schützen – Schritt für Schritt

1. Inventur in 30 Minuten

Listen Sie alle ASP.NET-Core-Workloads auf und prüfen Sie, welche Version der DataProtection-Pakete sie laden. Auf Linux-Containern hilft ein gezielter Suchlauf, etwa per dotnet list package --include-transitive innerhalb des Build-Containers. Ergänzend können Sie das Image mit grep -r "Microsoft.AspNetCore.DataProtection" /app durchsuchen, um auch transitive Verweise zu finden. In größeren Umgebungen lohnt sich ein Software-Bill-of-Materials-Scanner, der die NuGet-Versionen unternehmensweit abgleicht.

2. Patch auf 10.0.7

Aktualisieren Sie die NuGet-Referenz und bauen Sie alle betroffenen Anwendungen neu:

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7
dotnet restore --force-evaluate
dotnet build --configuration Release

Achten Sie darauf, dass auch Container-Base-Images, die das .NET-10-SDK enthalten, frisch gezogen werden – ein altes Cache-Layer kann den Fix maskieren. Dokumentieren Sie das Patch-Datum pro Service, weil Sie es später für die forensische Auswertung brauchen.

3. Schlüsselring rotieren

Konfigurieren Sie eine neue Schlüsselgeneration und entfernen Sie alle Schlüssel, die in der Verwundbarkeitsphase aktiv waren. Wenn Sie den Schlüsselring in Azure Blob Storage, Redis oder einem File Share persistieren, lassen sich die alten Schlüssel dort gezielt löschen. Vergessen Sie nicht, den Anti-Forgery-Token-Cache und Session-Stores zu invalidieren – sonst bleiben gültige, aber kompromittierte Sitzungen aktiv.

4. Forensik

Prüfen Sie die Application-Logs auf ungewöhnliche Login-Muster aus dem Verwundbarkeitsfenster: Anmeldungen ohne vorhergehende Passwort-Validierung, plötzliche Rollen-Sprünge, Cookies mit ungewöhnlich langen Lebenszeiten, geographische Anomalien. Wer ein SIEM betreibt, sollte zumindest rückwirkend für die letzten 30 Tage einen Suchlauf über alle Auth-Events machen.

5. Nachgelagerte Systeme

Föderierte Identitäten und gespeicherte OAuth-Refresh-Tokens, die in der Verwundbarkeitsphase ausgestellt wurden, sind potentiell kompromittiert. Falls Ihre ASP.NET-Anwendung Token an Drittsysteme weitergegeben hat, müssen diese ebenfalls rotiert werden. Dasselbe gilt für Service-Account-Tokens, die über Data Protection geschützt sind.

Was bedeutet das für Ihr Unternehmen?

Wer im Bereich der Informationssicherheit auf .NET-Stacks setzt – und das tun in Deutschland viele Mittelstandsfirmen mit eigener Web- oder Backend-Software – sollte CVE-2026-40372 als Stufe-1-Vorfall behandeln. Die Kombination aus "Pre-Auth", "Identity Forgery" und "Patch+Rotate-Pflicht" ist exakt das Muster, vor dem das BSI in seinen Lageberichten regelmäßig warnt.

Besonders kritisch: Viele Softwareentwicklungsteams haben in den letzten Monaten auf .NET 10 migriert, weil Microsoft die LTS-Schiene beworben hat. Genau diese Früh-Umsteiger sind jetzt im Risiko. Wer noch auf .NET 8 läuft, hat aktuell mehr Glück als Verstand – sollte aber die Migration nicht aus Angst zurückstellen, sondern mit klarem Patch- und Rotations-Plan angehen.

Lehren über den Patch hinaus

CVE-2026-40372 ist mehr als ein Routine-Patch – die Lücke zeigt drei strukturelle Schwachstellen, die viele Unternehmen zum dauerhaften Risiko machen:

Krypto-Bibliotheken sind der schlimmste Ort für Regressionen. Wenn der Hash über die falschen Bytes berechnet wird, fällt das im Funktionstest nicht auf. Statisches Verhalten bleibt korrekt – die Anwendung läuft, Cookies werden gesetzt, Logins funktionieren. Erst der Angriff offenbart das Problem. Das spricht für aggressive Property-Based-Tests und Cross-Version-Vergleiche im Build-Pipeline-Stage jeder Krypto-relevanten Komponente.

Patch-Frequenz schlägt Patch-Vollständigkeit. Wer Out-of-Band-Patches innerhalb von 24 bis 72 Stunden nach Veröffentlichung ausrollen kann, ist im Vorteil. Das setzt voraus, dass Build-Pipelines, Container-Registries und Staging-Umgebungen so automatisiert sind, dass eine NuGet-Erhöhung kein Halbtages-Projekt ist. Hier zahlen sich Investitionen in strukturiertes Projektmanagement und CI/CD-Modernisierung direkt aus.

Schlüsselrotation ist eine Disziplin, keine Notfallübung. Organisationen, die ihre Data-Protection-Schlüssel nie geplant rotiert haben, stehen jetzt vor der Frage: Wo liegen die eigentlich? Wer rotiert? Wer invalidiert die laufenden Sessions? Wer informiert die Anwender über erzwungene Re-Logins? Das ist Material für ein Runbook, das in jedes Compliance-Konzept gehört.

Fazit

CVE-2026-40372 ist eine der gefährlichsten ASP.NET-Core-Lücken seit Jahren. Sie ist trivial ausnutzbar, betrifft die Identitätsschicht direkt und verlangt mehr als nur ein NuGet-Update: ohne Schlüsselrotation bleibt das Risiko bestehen. Microsoft hat schnell reagiert – die Frage ist, wie schnell Ihr Unternehmen reagieren kann.

Wenn Sie unsicher sind, ob Ihre .NET-Anwendungen betroffen sind oder ob die Schlüsselrotation in Ihrer Umgebung ohne Service-Unterbrechung gelingt, melden Sie sich bei uns. Das pleXtec-Team unterstützt sowohl beim akuten Patch-Management als auch bei langfristiger Härtung Ihrer Web-Plattformen. Hier geht es zum Kontaktformular.