CVE-2026-40372 : SYSTEM via cookies forgés ASP.NET Core (CVSS 9.1)

Les faits

CVE-2026-40372 est une vulnérabilité de sécurité critique affectant le composant ASP.NET Core Data Protection, la couche cryptographique fondamentale de .NET 10 utilisée pour protéger des données sensibles comme les cookies d'authentification, les tokens anti-forgery CSRF, les liens de réinitialisation de mot de passe et toute donnée nécessitant une confidentialité et une intégrité garanties. La faille a reçu un score CVSS v3.1 de 9.1 (Critical), avec le vecteur AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, indiquant qu'elle est exploitable à distance, sans authentification et sans interaction de l'utilisateur, bien qu'avec une complexité d'attaque élevée (AC:H).

La root cause de la vulnérabilité a été identifiée dans la méthode CalculateAndValidateMac du composant d'encryptage authentifié managé (managed authenticated encryptor). Lors de certaines conditions d'exécution, l'implémentation calcule son tag de validation HMAC sur les mauvais octets du payload et, dans ces cas, rejette le hash calculé plutôt que de l'utiliser pour la validation. Ce comportement incorrect crée une régression cryptographique exploitable via une attaque par oracle de padding (padding oracle attack), documentée par Microsoft et par Duende Software dans leurs advisories respectifs.

Une attaque par oracle de padding exploite les différences de comportement d'un système face à des données chiffrées malformées pour progressivement déduire la clé cryptographique ou forger des données chiffrées valides. Dans le contexte de CVE-2026-40372, un attaquant peut envoyer des requêtes répétées à l'application en variant subtilement le contenu des cookies, observer les réponses du serveur pour déduire si les données sont valides ou non, et progressivement construire un payload chiffré arbitraire que le serveur acceptera comme légitime. Ce processus nécessite un nombre significatif de requêtes mais est entièrement automatisable avec des outils existants.

Une fois capable de forger des payloads Data Protection valides, l'attaquant peut créer des cookies d'authentification se faisant passer pour n'importe quel utilisateur, y compris des administrateurs ou des comptes de service système. Si l'application cible accorde des privilèges SYSTEM à certains comptes — ce qui est courant dans les applications d'entreprise et les services Windows tournant sous ASP.NET — l'attaquant obtient les privilèges les plus élevés du système d'exploitation, permettant une compromission totale du serveur.

L'aspect le plus insidieux de cette vulnérabilité tient dans la persistance de la compromission après le patching. Microsoft a explicitement averti dans son advisory CVE-2026-40372 que si un attaquant a exploité la faille pour s'authentifier comme un utilisateur privilégié avant l'application du correctif, l'application aura pu émettre des tokens légitimement signés (jetons de session, clés API, liens de réinitialisation de mot de passe) à cet attaquant. Ces tokens restent valides même après la mise à jour vers la version 10.0.7, car ils ont été signés par le key ring Data Protection non compromis. La seule façon d'invalider ces tokens potentiellement forgés est d'effectuer une rotation complète du key ring Data Protection, ce qui invalide également toutes les sessions légitimes en cours.

Microsoft a publié un patch d'urgence (Emergency Security Update) pour corriger cette faille, hors du cycle habituel du Patch Tuesday. Le package NuGet Microsoft.AspNetCore.DataProtection version 10.0.7 corrige le bug dans CalculateAndValidateMac. Le correctif nécessite une reconstruction complète de l'application (rebuild complet du projet) et un redéploiement en production. Une simple mise à jour du package sans rebuild et redéploiement n'est pas suffisante pour les applications compilées en mode Release, car les bibliothèques sont liées statiquement dans le binaire final.

La faille a été divulguée et documentée en détail par Duende Software, l'éditeur d'IdentityServer, qui a publié un guide de mise à jour complet le 22 avril 2026 (Update Guidance for CVE-2026-40372 - ASP.NET Data Protection). L'advisory officiel Microsoft est référencé sur GitHub sous les issues dotnet/announcements #395 et dotnet/aspnetcore #66410. Des ressources de détection ont été publiées par SOCPrime et Tenable, permettant aux équipes SOC d'identifier des tentatives d'exploitation via des règles SIEM adaptées au monitoring du volume anormal de requêtes sur les endpoints d'authentification.

Le contexte d'impact de cette vulnérabilité est étendu à l'échelle mondiale. ASP.NET Core est l'un des frameworks web les plus utilisés en entreprise pour les applications d'entreprise, les portails clients, les API REST et les services SaaS. Toute application développée avec .NET 10 — la version LTS (Long Term Support) adoptée massivement depuis sa sortie en novembre 2024 — utilisant l'authentification par cookie (ASP.NET Core Identity, applications Blazor Server avec authentification, applications MVC et Razor Pages) est potentiellement affectée si elle n'a pas encore été mise à jour vers 10.0.7.

Impact et exposition

La surface d'exposition de CVE-2026-40372 est massive dans les environnements d'entreprise modernes. .NET 10 représente une version LTS adoptée massivement dans les environnements de production depuis fin 2024. Toute organisation ayant migré vers .NET 10 entre sa sortie et la publication du correctif version 10.0.7 est potentiellement exposée, couvrant des milliers d'applications d'entreprise à travers le monde, dont de nombreuses applications critiques exposées sur Internet.

Les applications les plus à risque sont celles qui exposent des endpoints d'authentification sur Internet (portails clients, extranets, API publiques) et qui fonctionnent avec des comptes disposant de privilèges élevés. Dans un contexte cloud Azure, une exploitation réussie sur une application App Service ou dans un container Azure Container Apps peut potentiellement permettre une élévation de privilèges vers des ressources partagées. Les applications multi-tenant sont particulièrement concernées car une compromission de token permettrait de traverser les frontières de tenant dans les implémentations insuffisamment cloisonnées.

La complexité d'attaque élevée (AC:H) signifie que l'exploitation n'est pas immédiate et requiert un effort technique significatif, plusieurs milliers à millions de requêtes pour un padding oracle classique. Cependant, ce n'est pas une protection à long terme pour les applications exposées sur Internet : un attaquant motivé et disposant de ressources peut mener cette attaque sur plusieurs heures ou jours sans déclencher d'alertes si le monitoring du volume de requêtes n'est pas correctement configuré dans le WAF ou le SIEM.

La rotation du key ring, bien que nécessaire et recommandée par Microsoft, a un impact opérationnel non-négligeable : toutes les sessions utilisateurs actuellement actives seront invalidées, et tous les liens de réinitialisation de mot de passe en cours deviendront inutilisables. Les équipes DevOps et de production doivent planifier cette opération en coordination avec les équipes métier et les utilisateurs finaux, idéalement pendant une fenêtre de maintenance, pour minimiser l'impact sur la continuité de service.

Recommandations immédiates

• Mettre à jour le package NuGet Microsoft.AspNetCore.DataProtection vers la version 10.0.7 (advisory : Microsoft Security Advisory CVE-2026-40372)
• Reconstruire (rebuild complet) l'application entière et redéployer en production — la mise à jour du package seule sans rebuild ne suffit pas pour les applications compilées
• Effectuer impérativement une rotation du key ring ASP.NET Core Data Protection après déploiement pour invalider tout token potentiellement forgé avant le correctif
• Analyser les journaux d'authentification pour identifier des connexions anormales (comptes avec privilèges élevés depuis des IP inhabituelles) durant la fenêtre de vulnérabilité (.NET 10.0.0 à 10.0.6)
• Si une exploitation est suspectée : révoquer toutes les sessions actives, réinitialiser les mots de passe des comptes administrateurs, auditer les tokens API émis pendant la période de risque
• Mettre en place une surveillance du volume de requêtes sur les endpoints d'authentification pour détecter des tentatives de padding oracle (pics de requêtes avec variations légères de cookies chiffrés)