La faille du serveur Web Kestrel permet des attaques de contrebande de requêtes, mais le risque réel dépend du code de l’application et de son déploiement.
Microsoft a corrigé une vulnérabilité critique dans ASP.NET Core qui a obtenu un score de gravité CVSS de 9,9, la note la plus élevée que l’entreprise ait jamais attribuée à une faille dans le cadre de développement Web.
La vulnérabilité, identifiée comme CVE-2025-55315, affecte le composant du serveur Web Kestrel intégré à ASP.NET Core et pourrait permettre à des attaquants authentifiés de contourner les fonctionnalités de sécurité via la contrebande de requêtes HTTP, a indiqué la société dans un avis de sécurité.
« Une interprétation incohérente des requêtes http (« contrebande de requêtes/réponses http ») dans ASP.NET Core permet à un attaquant autorisé de contourner une fonctionnalité de sécurité sur un réseau », indique l’avis.
La faille affecte toutes les versions d’ASP.NET Core actuellement prises en charge, y compris les versions 8, 9 et 10, ainsi que l’ancien ASP.NET Core 2.3 qui s’exécute sur le .NET Framework Windows uniquement.
Ce que les attaquants pourraient faire
La vulnérabilité se concentre sur les attaques de contrebande de requêtes, qui exploitent la façon dont les serveurs Web et les applications interprètent les requêtes HTTP. Un attaquant peut cacher une deuxième requête malveillante dans ce qui semble être une première requête légitime, permettant potentiellement d’effectuer des actions qui nécessiteraient normalement une authentification sans autorisation appropriée, ajoute l’avis.
Barry Dorrans, responsable du programme de sécurité de Microsoft pour ASP.NET Core, a déclaré dans l’avis GitHub que la requête introduite clandestinement pourrait effectuer diverses actions malveillantes.
« Un attaquant pourrait utiliser cette vulnérabilité pour se connecter en tant qu’utilisateur différent, contourner les contrôles de falsification de requêtes intersites ou effectuer des attaques par injection », a-t-il écrit.
Cependant, Dorrans a souligné que le risque réel dépend fortement de la manière dont les applications sont écrites et déployées. De mauvais résultats sont peu probables, « à moins que le code de votre application fasse quelque chose d’étrange et saute un certain nombre de vérifications qu’il devrait effectuer à chaque requête », a-t-il déclaré.
La confusion CVSS
Malgré l’évaluation prudente du risque réel par Dorrans, la note CVSS de 9,9 a semé une confusion considérable parmi les développeurs, beaucoup se demandant si la vulnérabilité justifie réellement un score de gravité aussi extrême.
Dorrans a abordé ce problème directement dans la discussion sur GitHub, expliquant que la méthodologie de notation de Microsoft prend en compte les pires scénarios.
« À lui seul, pour ASP.NET Core », a-t-il écrit, la note serait « loin d’être aussi élevée ». Mais Microsoft évalue les vulnérabilités en fonction du potentiel de « contournement d’une fonctionnalité de sécurité qui modifie la portée », ce qui signifie que l’attaque pourrait affecter des composants au-delà de celui initialement vulnérable.
Lorsque les développeurs ont demandé des détails sur les modèles de code d’application qui pourraient être vulnérables, Dorrans a proposé des réponses prudentes.
« Tout ce qui fait quelque chose avec une requête pourrait être problématique », a-t-il déclaré, ajoutant qu' »une application qui effectue une authentification et dispose de règles d’accès basées sur l’authentification peut être vulnérable ».
Il a cependant noté qu’il s’agissait d’observations personnelles plutôt que de directives officielles de Microsoft.
Qui a besoin de patcher ?
La vulnérabilité affecte un large éventail de versions d’ASP.NET Core. Toute application exécutant ASP.NET Core 10.0.0-rc.1.25451.107 ou version antérieure, ASP.NET Core 9.0.9 ou version antérieure, ASP.NET Core 8.0.20 ou version antérieure, ou ASP.NET Core 2.x avec Microsoft.AspNetCore.Server.Kestrel.Core version 2.3.0 ou version antérieure est sensible à la faille, selon l’avis.
Les organisations sont confrontées à différentes exigences en matière de correctifs en fonction de leur modèle de déploiement. Les applications utilisant des déploiements dépendants du framework s’appuient sur le runtime .NET installé sur le serveur, ce qui signifie que les administrateurs doivent mettre à jour le serveur lui-même. Ceux qui utilisent des déploiements autonomes, qui regroupent le runtime avec l’application, doivent reconstruire et redéployer chaque application concernée individuellement.
Microsoft a publié des versions corrigées pour toutes les versions prises en charge. Les développeurs doivent effectuer une mise à niveau vers .NET 8.0.21 Runtime ou .NET 8.0.318 SDK pour la version 8, .NET 9.0.10 Runtime ou .NET 9.0.111 SDK pour la version 9, ou .NET 10.0.0-rc.2.25476.107 Runtime pour la version préliminaire de la version 10, indique l’avis. Pour les anciennes applications ASP.NET Core 2.x, Microsoft a publié la version 2.3.6 du package Kestrel.Core via NuGet.
Certains sont peut-être déjà protégés
Toutefois, toutes les organisations n’auront pas besoin de prendre des mesures immédiates. Un facteur atténuant est que les applications protégées par des proxys inverses ou des passerelles API peuvent déjà disposer de défenses adéquates, a déclaré Dorrans.
« Si une passerelle ou un proxy supprime les requêtes clandestines, l’application est protégée », écrit-il. Cependant, les implémentations de Kestrel qui font directement face à Internet sans un tel filtrage intermédiaire restent vulnérables.
Microsoft a déclaré dans son guide de mise à jour officiel que la vulnérabilité n’est pas connue pour être exploitée à l’état sauvage.
Malgré cela, Dorrans conseille aux organisations d’évaluer soigneusement leurs risques spécifiques. « Vous seul pouvez évaluer les risques pour votre application », a-t-il écrit, tout en recommandant que « l’approche prudente consiste à appliquer les correctifs dès que possible ».
