Les correctifs ne suffisent pas : les applications intégrant la bibliothèque non sécurisée devront être reconstruites et les jetons et cookies concernés expireront.
Il est conseillé aux développeurs de vérifier leurs applications après que Microsoft a révélé que la mise à jour ASP.NET Core de la semaine dernière avait introduit par inadvertance une grave faille de sécurité dans la bibliothèque de protection des données du framework Web.
Microsoft décrit le problème comme une « régression », un jargon de codage pour une mise à jour qui casse quelque chose qui fonctionnait correctement auparavant.
Dans ce cas, ce qui a été introduit était une vulnérabilité critique classée CVSS 9.1, identifiée comme CVE-2026-40372, qui affecte la bibliothèque d’applications Core Data Protection d’ASP.NET distribuée via le gestionnaire de packages NuGet. Cela affecte Linux, macOS et d’autres systèmes d’exploitation non Windows, ainsi que les systèmes Windows sur lesquels le développeur a explicitement opté pour des algorithmes gérés via l’API.
Un bogue dans le package .NET 10.0.6, publié dans le cadre des mises à jour du Patch Tuesday du 14 avril, amène la bibliothèque à calculer la balise de validation pour le code d’authentification de message basé sur le hachage (HMAC) en utilisant un décalage incorrect.
Un calcul incorrect des hachages de sécurité entraîne la validation et la confiance des cookies et des jetons d’application alors qu’ils ne devraient pas l’être.
« Dans ces cas, la validation brisée pourrait permettre à un attaquant de forger des charges utiles qui réussissent les contrôles d’authenticité de DataProtection et de déchiffrer les charges utiles précédemment protégées dans les cookies d’authentification, les jetons anti-contrefaçon, TempData, l’état OIDC, etc », a déclaré l’avis GitHub de Microsoft.
Lorsqu’ils sont intégrés dans des applications, ces jetons à longue durée de vie confèrent le type de puissance sur laquelle les attaquants s’attaquent rapidement. « Si un attaquant a utilisé de fausses charges utiles pour s’authentifier en tant qu’utilisateur privilégié pendant la fenêtre vulnérable, il peut avoir incité l’application à émettre des jetons légitimement signés (actualisation de session, clé API, lien de réinitialisation de mot de passe, etc.) », note l’avis.
Cette vulnérabilité arrive seulement six mois après qu’ASP.NET ait subi l’une de ses pires failles jamais enregistrées, la CVE-2025-55315 classée CVSS 9,9 d’octobre dans le composant du serveur Web Kestrel. Mais de manière quelque peu alarmante, l’avis actuel compare le problème à MS10-070, un correctif d’urgence pour CVE-2010-3332, une tristement célèbre vulnérabilité Zero Day dans la façon dont Windows ASP.NET a géré les erreurs cryptographiques qui a provoqué une certaine panique en 2010.
Pas une simple mise à jour
Normalement, lorsque des failles sont découvertes, l’exercice consiste simplement à appliquer une mise à jour, une solution de contournement ou une atténuation. Dans ce cas, la mise à jour elle-même aurait déjà dû s’effectuer automatiquement pour les versions de serveur, amenant les environnements d’exécution à la version corrigée 10.0.7.
Cependant, pour les développeurs utilisant la populaire plateforme de conteneurs Docker, les choses sont plus compliquées. Pour ces projets, la bibliothèque de protection des données est également intégrée aux applications intégrées. Pour résoudre ce problème, il faut mettre à jour et reconstruire toutes les applications ASP.NET Core créées après la mise à jour du 14 avril.
De plus, ceux qui utilisent 10.0.x sur l’actif du framework cible ou du package NuGet défectueux, pour la compatibilité avec les anciens systèmes d’exploitation, notamment Windows, sont également concernés.
Détection des binaires concernés
Comment les développeurs sauront-ils si un binaire vulnérable a été chargé ? L’avis de sécurité de Microsoft propose les conseils suivants :
« Vérifiez les journaux d’application. Le symptôme le plus clair est la déconnexion des utilisateurs et des erreurs répétées dans vos journaux après la mise à niveau vers 10.0.6. Vérifiez votre fichier de projet. Recherchez une référence de package à la version 10.0.6 dans votre fichier .csproj (ou dans un package qui en dépend). Vous pouvez également exécuter le package dotnet list pour voir les versions de package résolues. «
En résumé, les développeurs doivent reconstruire les applications concernées pour appliquer la version corrigée, faire expirer tous les cookies et jetons d’authentification concernés pour supprimer les contrefaçons, et effectuer une rotation pour appliquer de nouveaux jetons ASP.NET Core Data Protection.
Bien qu’il n’y ait aucune preuve que le problème ait été exploité par des attaquants, une bonne hygiène de sécurité exige également de vérifier les échecs de connexion inattendus ou inhabituels, les erreurs ou les échecs d’authentification, a conseillé Microsoft.
