Vulnérabilité critique dans ASP.NET Core et comment protéger vos applications

Ces derniers temps, ASP.NET Core a été secoué par plusieurs failles de sécurité critiques. qui affectent directement l'authentification, la protection des données et le serveur web Kestrel lui-même. Si vous développez ou maintenez des applications .NET, il ne s'agit pas d'un simple détail technique : nous parlons de vulnérabilités avec scores CVSS très élevés (9,1 et même 9,9), pouvant ouvrir la porte à des élévations de privilèges, à l'usurpation d'identité et à la divulgation d'informations hautement sensibles.

Au-delà du brouhaha des bulletins de sécurité, il est essentiel de comprendre Qu'est-ce qui ne fonctionne pas exactement dans ASP.NET Core, et quels packages et versions sont concernés ?et comment une équipe de développement moderne travaillant avec les meilleures pratiques CI/CD et DevSecOps devrait réagir, par exemple : IDE et outils clés pour tester les applicationsNous allons analyser en détail les cas les plus graves (notamment CVE-2026-40372 et CVE-2025-55315), et passer en revue les Mesures d'atténuation recommandées par Microsoft Et tant qu'à faire, passons en revue le modèle de gestion des erreurs et des exceptions dans ASP.NET Core, car une faille de sécurité sans bonne observabilité revient à chercher une aiguille dans une botte de foin.

Vulnérabilité critique dans DataProtection : CVE-2026-40372

L'un des incidents les plus graves qui ait frappé l'écosystème est CVE-2026-40372, une vulnérabilité critique dans Microsoft.AspNetCore.DataProtection, corrigé par Microsoft avec une mise à jour hors cycle dans la version .NET 10.0.7. La gravité n'est pas mineure : CVSS 3.1 de 9,1 (Révision) et l'exploitation à distance sans authentification.

Cette vulnérabilité affecte Versions 10.0.0 à 10.0.6 du package NuGet Microsoft.AspNetCore.DataProtection et des dépendances associées, telles que Microsoft.AspNetCore.DataProtection.StackExchangeRedis. Le problème réside dans une faille très subtile mais dévastatrice de la logique cryptographique du chiffrement authentifié géré par ASP.NET Core.

Le composant vulnérable calcule l'étiquette de validation HMAC sur les octets incorrects de la charge utile Dans certains cas, le système rejette même le hachage généré. Cette validation défaillante compromet totalement le modèle de confiance attendu : un attaquant peut ainsi concevoir des charges utiles d'apparence légitime, contournant les contrôles d'authenticité du système de protection des données.

Les conséquences pratiques sont particulièrement graves.En effet, DataProtection ne sert pas uniquement à chiffrer des données arbitraires ; il est au cœur de nombreux mécanismes de sécurité d’ASP.NET Core : cookies d’authentification, jetons anti-falsification, TempData, état OIDC et autres éléments qui dépendent de ce trousseau de clés. Si ces objets peuvent être falsifiés ou déchiffrés, un attaquant dispose d’un accès direct à une élévation de privilèges.

Impact réel : cookies, jetons et usurpation d'identité

La faille dans DataProtection permet à un attaquant falsification de charges utiles qui passent les contrôles cryptographiques et, dans certains cas, même déchiffrer des données précédemment protégéesDans les environnements où les API de protection ASP.NET Core sont utilisées, cela se traduit par une gamme d'attaques très inquiétante.

Les données potentiellement exposées comprennent Cookies d'authentification, jetons anti-falsification, TempData, statut OIDC et autres jetons internesDans le pire des cas, un attaquant non authentifié pourrait fabriquer un cookie ou un jeton qui l'identifie comme un utilisateur disposant de privilèges élevés, tel qu'un administrateur d'application ou un administrateur de service interne.

Le scénario est aggravé car, si pendant la période de vulnérabilité, l'attaquant parvient à obtenir un niveau d'accès élevé, cela peut inciter l'application à émettre des actifs légitimes mais obtenus de manière malveillante : Clés API, jetons d'actualisation de session, liens de réinitialisation de mot de passe ou clés d'accès persistantesTous ces éléments resteraient valides même après la mise à niveau vers .NET 10.0.7, sauf si des mesures supplémentaires sont prises.

Autrement dit, même si vous appliquez le correctif, si vous ne réagissez pas correctement, Votre système pourrait encore être exposé à des jetons déjà émis dans des conditions compromises.C’est pourquoi Microsoft compare cette faille à des vulnérabilités historiques comme MS10-070, liées à des problèmes d’oracle de remplissage dans le chiffrement ASP.NET hérité.

Microsoft a découvert cette régression à la suite de Des clients signalent des échecs de déchiffrement après l'installation de .NET 10.0.6. Lors du Patch Tuesday d'avril, après enquête sur l'incident (initialement documenté dans le problème aspnetcore n° 66335), l'équipe a découvert qu'il ne s'agissait pas seulement d'un bug fonctionnel, mais d'une faille de sécurité importante nécessitant un correctif urgent hors cycle.

Conditions de fonctionnement et environnements affectés

Bien que cette défaillance soit critique, Tous les environnements ne sont pas exposés par défaut.Selon les informations officielles, pour exploiter la vulnérabilité CVE-2026-40372, plusieurs conditions spécifiques liées aux paquets et à l'environnement d'exécution doivent être remplies.

D'une part, l'application doit être utilisée les versions vulnérables du package Microsoft.AspNetCore.DataProtection (10.0.0 à 10.0.6) ou des bibliothèques qui la chargent à l'exécution. De plus, cette vulnérabilité a un impact plus important sur les systèmes d'exploitation autres que Windows, tels que Linux et macOSCela correspond parfaitement au déploiement typique d'ASP.NET Core dans les conteneurs, les orchestrateurs et les plateformes cloud.

Le vecteur d'attaque est normalement exécuté par le réseau, sans avoir besoin d'une authentification préalableCela accroît le danger pour les applications exposées à Internet. Un attaquant peut envoyer des charges utiles spécialement conçues comme s'il était un client ordinaire du système, sans avoir besoin d'identifiants valides.

En pratique, cela signifie que infrastructures basées sur des microservices, des conteneurs Docker et des plateformes PaaS Les systèmes qui utilisent DataProtection pour partager des clés ou l'état d'authentification entre instances sont des cibles prioritaires. Si le trousseau de clés n'a pas été mis à jour et renouvelé, une simple compromission peut entraîner un accès persistant et difficile à détecter.

Pour toutes les raisons évoquées ci-dessus, les équipes de sécurité des applications doivent Analysez en détail quels services chargent le package vulnérable et sur quels systèmes d'exploitation ils fonctionnent, au lieu de supposer que le problème ne concerne que des scénarios très spécifiques.

Actions urgentes : mise à niveau vers .NET 10.0.7 et rotation des clés

La principale recommandation de Microsoft est claire : Mettez immédiatement à jour le package Microsoft.AspNetCore.DataProtection vers la version 10.0.7. et recompilez les applications avec les environnements d'exécution et les SDK corrigés (par exemple, le SDK .NET 10.0.203 et ses environnements d'exécution associés).

Pour confirmer que l'environnement est correctement mis à jour, vous devez exécuter la commande suivante : Exécutez la commande dotnet –info et vérifiez que la version du runtime est bien 10.0.7. Il ne suffit pas d'installer l'environnement d'exécution sur le serveur ; il est essentiel reconstruire et redéployer les applications utiliser des images ou des packages de conteneurs mis à jour pour garantir que le code de production soit lié aux binaires corrigés.

Toutefois, comme indiqué précédemment, l'application du correctif ne résoudra pas, à elle seule, les dommages déjà survenus. Microsoft le déconseille fortement. Faites tourner le porte-clés DataProtection dans les environnements exposés, afin d'invalider tout jeton, cookie ou identifiant généré de manière malveillante pendant la période de vulnérabilité.

En plus de la mise à jour et de la rotation des clés, il est prudent forcer la fermeture des sessions actives (la révocation des cookies de connexion, des jetons d'accès, etc.) exige une réauthentification et active un audit détaillé des journaux examiner les activités suspectes, notamment les accès administratifs atypiques, la création de clés API, les réinitialisations de mots de passe et les opérations privilégiées.

Du point de vue DevSecOps, cet incident souligne l'importance d'intégrer scanners de dépendances Dans la chaîne CI/CD, DataProtection permet de recevoir des alertes automatiques en cas de vulnérabilités critiques dans les packages tiers. Comme pour toute bibliothèque cryptographique, une modification, même minime, du comportement de DataProtection peut compromettre l'ensemble du modèle de sécurité si elle n'est pas rigoureusement validée.

Autre vulnérabilité critique : usurpation d’identité lors de la consultation de requêtes HTTP dans Kestrel (CVE-2025-55315)

Outre la vulnérabilité de DataProtection, une autre a été signalée. faille de sécurité extrêmement grave dans ASP.NET CoreCette fois-ci, l'attention s'est portée sur le serveur web Kestrel. Identifié comme CVE-2025-55315Elle a été classée comme une erreur d'usurpation de requête HTTP avec un score de gravité de 9,9 sur 10.

Le cœur du problème est que Un attaquant peut injecter une seconde requête HTTP malveillante au sein d'une requête apparemment légitime.Il s'agit d'une caractéristique des attaques par manipulation de requêtes ou de trames HTTP. Cette technique permet de contourner les contrôles de sécurité des proxys, des équilibreurs de charge ou du serveur lui-même, et d'amener le système à traiter des données qu'il n'aurait jamais dû accepter.

Selon l'avertissement de Microsoft, l'impact potentiel implique accès à des informations sensibles, vol d'identifiants, modification non autorisée de fichiers et même la possibilité de provoquer des pannes de serveur affectant la disponibilité. En ciblant directement la couche transport HTTP, l'éventail des attaques est très large, allant du contournement de l'authentification au détournement du trafic vers des routes internes.

La vulnérabilité affecte spécifiquement Microsoft.AspNetCore.Server.Kestrel.Core Cette vulnérabilité affecte certaines versions d'ASP.NET Core et est considérée comme l'une des failles de sécurité les plus graves que la plateforme ait connues ces dernières années. Elle constitue une faille exploitable par des attaquants non authentifiés, ce qui accroît considérablement la surface d'attaque.

Barry Dorrans, responsable technique de la sécurité chez .NET, a expliqué que Un score aussi élevé reflète le pire scénario possible.Étant donné que l'impact réel dépend largement de la manière dont chaque application est construite, l'évaluation repose sur le postulat d'un contournement des mécanismes de sécurité avec des modifications de périmètre, ce qui constitue le type de défaillance considéré comme inacceptable dans les environnements d'entreprise.

Versions et correctifs concernés pour Kestrel et ASP.NET Core

Pour corriger la vulnérabilité CVE-2025-55315, Microsoft a publié Mises à jour de sécurité spécifiques aux différentes branches de .NET et d'ASP.NET Core, englobant à la fois les versions plus anciennes et plus récentes, y compris ASP.NET Core 2.3, 8.0 et 9.0.

Dans les environnements où il est utilisé .NET 8 ou supérieurLa mesure d'atténuation recommandée consiste à appliquer tous les correctifs disponibles par le biais de Microsoft Update Il convient ensuite de vérifier que les environnements d'exécution et les paquets sont bien dans leur version corrigée. Il est particulièrement important de s'assurer que les applications sont recompilées avec ces versions et que les images de production ne contiennent plus de binaires vulnérables.

Dans le cas des projets qui sont encore en cours de réalisation .NET 2.3Microsoft indique que c'est essentiel Mettez à jour la référence au package Microsoft.AspNet.Server.Kestrel.Core vers la version 2.3.6.Recompilez la solution et redéployez les applications. Sinon, Kestrel continuera de traiter les requêtes avec la logique défectueuse qui permet l'usurpation d'identité lors de requêtes HTTP.

Les déploiements qui utilisent applications autonomes ou applications empaquetées dans un seul fichier Ils ont également l'obligation de compiler à partir des sources avec les environnements d'exécution corrigés ; sinon, le fichier exécutable contiendra toujours le code vulnérable. Il est facile d'oublier ce détail si l'on se fie uniquement à la mise à jour du système hôte.

Parallèlement aux mises à jour du framework lui-même, Microsoft a publié Correctifs pour Microsoft.AspNetCore.Server.Kestrel.Core et autres composants associésL'objectif est de renforcer la robustesse de l'analyse et du traitement des requêtes HTTP. En bref, il ne s'agit pas d'une solution unique et isolée, mais plutôt d'une amélioration coordonnée à plusieurs niveaux de la pile ASP.NET Core.

Mises à jour critiques supplémentaires dans ASP.NET Core et risque global

Au-delà de ces cas particuliers, Microsoft a publié Correctifs critiques pour d'autres vulnérabilités dans ASP.NET Core Ces vulnérabilités peuvent entraîner l'exécution de code à distance (RCE), l'élévation de privilèges et des attaques par déni de service (DoS). La combinaison de ces failles démontre clairement que le framework, aussi mature soit-il, n'est pas à l'abri de régressions dangereuses.

Ces défaillances affectent composants clés du runtime ASP.NET CoreCela inclut le traitement des requêtes HTTP, les intergiciels d'authentification et d'autorisation, ainsi que les API liées à la sérialisation et à la désérialisation des données. Dans de nombreux cas, les attaquants peuvent exploiter ces failles. entrées malformées ou charges utiles manipulées déclencher des comportements inattendus.

Les versions concernées correspondent généralement à versions antérieures aux correctifs de sécurité publiés en avril 2026Par conséquent, un audit de version est indispensable dans tous les environnements de production qui continuent d'utiliser d'anciennes versions. De nos jours, laisser des serveurs obsolètes est synonyme de catastrophe.

D'un point de vue commercial, le fait de ne pas appliquer ces correctifs peut avoir des conséquences très graves : perte de confidentialité des données, intégrité compromise, indisponibilité des services essentiels et un impact sur la réputation dont il faut des années pour se remettre. Les organisations qui utilisent ASP.NET Core pour leurs applications critiques doivent considérer la gestion des correctifs comme un processus continu, et non comme une tâche ponctuelle.

La recommandation générale de Microsoft est de Appliquez les correctifs dès leur disponibilité et vérifiez les paramètres de sécurité des environnements.Renforcer la surveillance des activités suspectes et revoir les processus de développement sécurisés afin de minimiser le risque d'introduire des vulnérabilités dans le code de l'application lui-même.

Gestion des erreurs et des exceptions dans ASP.NET Core : un élément clé du puzzle

Quand on parle de sécurité, on pense souvent uniquement aux correctifs et à la cryptographie, mais Un bon système de gestion des erreurs est essentiel dans ASP.NET Core. Ce cadre permet de détecter, d'analyser et d'atténuer les incidents. Il offre plusieurs mécanismes pour gérer les exceptions, renvoyer les codes d'état appropriés et exposer des réponses standard, telles que ProblemDetails, dans les API.

Dans les environnements de développement, ASP.NET Core active par défaut Page d'exception pour les développeurs Cette page s'affiche lorsque certaines conditions sont remplies (généralement en environnement de développement). Elle est déclenchée par le middleware DeveloperExceptionPageMiddleware, placé au début du pipeline HTTP. intercepter les exceptions non gérées, synchrones et asynchroneset afficher des informations détaillées.

La page des exceptions pour les développeurs peut inclure traces de pile, paramètres de chaîne de requête, cookies, en-têtes HTTP et métadonnées de point de terminaisonC'est un outil magnifique pendant le développement, mais, logiquement, Il ne devrait pas être activé en production.car exposer les détails internes facilite la tâche des attaquants.

En environnement de production, la pratique recommandée consiste à configurer un page d'erreur personnalisée utilisant UseExceptionHandlerCe middleware intercepte les exceptions non gérées, les consigne et réexécute la requête via un pipeline alternatif, pointant généralement vers une route telle que /Error.

Lors de la réinstallation de la tuyauterie, il est important de garder à l'esprit que Les intergiciels peuvent être invoqués à nouveau avec le même contexte HTTP.Il est donc conseillé de nettoyer les états internes, de mettre en cache les résultats ou de réutiliser les données déjà lues (par exemple, le corps de la requête) afin d'éviter des erreurs supplémentaires. De plus, les services concernés restent inchangés lors de la réexécution.

Accès aux exceptions et contrôle centralisé avec IExceptionHandler

Pour obtenir des informations détaillées sur l'exception qui a déclenché la page d'erreur, ASP.NET Core expose la fonctionnalité Fonction IExceptionHandlerPath. Via HttpContext.Features.Get Il est possible de récupérer à la fois le chemin de la requête d'origine et l'objet Exception lui-même.

Un schéma courant dans Razor Pages consiste en Stockez l'identifiant de la requête et un message d'erreur convivial dans le modèle de page.L'utilisation de IExceptionHandlerPathFeature vous permet de personnaliser le message en fonction du type d'exception (par exemple, FileNotFoundException) ou du chemin d'accès ayant provoqué l'erreur. Vous pouvez ainsi afficher des messages d'erreur plus explicites à l'utilisateur sans masquer les détails internes.

En plus de l'approche par page ou par contrôleur, ASP.NET Core offre l'interface Gestionnaire d'exceptions en tant que mécanisme centralisé de gestion des exceptions. Les implémentations de cette interface sont enregistrées auprès de AddExceptionHandler. et elles sont exécutées dans l'ordre, renvoyant vrai lorsqu'elles ont géré l'exception et faux lorsqu'elles préfèrent déléguer le comportement par défaut.

Ce système facilite, par exemple, Enregistrer les erreurs dans un système externe, appliquer une logique conditionnelle en fonction du type d'exception. ou modifier la réponse HTTP globale sans avoir à intervenir individuellement sur chaque contrôleur. À partir de .NET 10, le middleware de gestion des exceptions permet également de configurer SuppressDiagnosticsCallback afin de déterminer quand masquer les métriques et les journaux en cas d'exceptions déjà gérées.

Une autre option très flexible consiste à utiliser un lambda dans UseExceptionHandlerCela implique d'accéder directement au contexte, de définir le code d'état et le type de contenu, puis de rédiger manuellement la réponse. Vous pouvez même utiliser IProblemDetailsService au sein de cette fonction Lambda pour renvoyer une réponse ProblemDetails standard décrivant clairement le problème.

Pages de codes d'état et réponses ProblemDetails

Par défaut, une application ASP.NET Core Il n'affiche pas les pages compatibles avec les codes d'état HTTP tels que 404.Elle renvoie simplement le code et un corps vide. Pour enrichir cette expérience et faciliter le débogage, vous pouvez activer le middleware de gestion des codes d'état à l'aide de l'option UseStatusCodePages.

UseStatusCodePages prend en charge plusieurs modes : Texte brut avec un message générique, fonctions lambda pour personnaliser entièrement la réponse ou des variantes qui redirigent ou réexécutent le pipeline vers un point de terminaison alternatif, telles que UseStatusCodePagesWithRedirects et UseStatusCodePagesWithReExecute.

Avec UseStatusCodePagesWithRedirects, le middleware Elle renvoie un code 302 Found et redirige le client vers une URL qui offre généralement une vue plus conviviale., renvoyant généralement un code 200 OK. Cette approche est judicieuse lorsque vous souhaitez que la barre d'adresse reflète le chemin d'erreur final et que vous ne souhaitez pas conserver le code d'état initial.

En revanche, UseStatusCodePagesWithReExecute Le code d'état initial ne change pas.Au lieu de cela, la requête est réexécutée sur une route différente afin de générer le corps de la réponse. L'URL d'origine est conservée dans la barre d'adresse du navigateur, et le point d'erreur peut récupérer la route et l'interroger d'origine via l'interface IStatusCodeReExecuteFeature, ce qui est très utile pour la journalisation et le débogage.

Dans le domaine des API, ASP.NET Core a adopté la norme Détails du problème comme format standard pour les réponses d'erreurEn enregistrant AddProblemDetails dans le conteneur de services, le middleware peut générer automatiquement des réponses JSON avec des champs tels que type, title, status et traceId lorsque des erreurs client ou serveur surviennent sans corps.

Ce comportement peut être personnalisé par Options des détails du problème.Personnaliser les détails du problèmeCela implique l'ajout d'extensions telles qu'un identifiant de nœud (par exemple, le nom de la machine) ou d'autres métadonnées facilitant le traçage des problèmes dans les environnements distribués. Il est également possible d'implémenter un IProblemDetailsWriter personnalisé qui détermine les états à gérer et la manière de sérialiser les détails.

Leçons pour le DevSecOps et les meilleures pratiques d'amélioration continue

La cascade de vulnérabilités dans ASP.NET Core et son écosystème .NET présente plusieurs leçons clés pour toute équipe de développement sérieuse : Les dépendances envers des tiers constituent un vecteur critique ; une cryptographie mal implémentée compromet l'ensemble du modèle de confiance. et les mécanismes d'authentification sont devenus une cible privilégiée des attaquants.

Du point de vue DevSecOps, cela devient essentiel intégrer l'analyse de dépendance Dans les pipelines CI/CD, effectuez des tests de sécurité continus et assurez une visibilité complète sur tous les composants tiers intégrés au projet. Les outils d'analyse de la composition logicielle (SCA) et les scanners de vulnérabilités ne doivent plus être optionnels, mais faire partie intégrante du flux de travail d'intégration standard.

Il est également vital de renforcer Audits des journaux et surveillance des événements de sécuritéCela est particulièrement vrai en ce qui concerne l'authentification, l'émission de jetons, la création de sessions, les modifications d'autorisations et les opérations d'administration. Sans une journalisation et des alertes adéquates, une vulnérabilité comme CVE-2026-40372 ou CVE-2025-55315 peut être exploitée silencieusement pendant des mois.

Malgré sa complexité et le nombre de bogues récents, ASP.NET Core reste un framework robuste à condition d'être correctement mis à jour et configuré de manière sécurisée. La combinaison de Application rapide des correctifs, rotation des clés de chiffrement lorsque nécessaire, bonnes pratiques de gestion des erreurs et approche proactive de la sécurité Cela fait toute la différence entre une plateforme robuste et une cible facile pour les attaquants.

Cet ensemble de vulnérabilités et de mécanismes d'atténuation nous rappelle que La sécurité dans ASP.NET Core ne se résume pas à l'application ponctuelle de correctifs.mais plutôt d'adopter une discipline continue : surveiller les versions des packages et de l'environnement d'exécution, gérer les erreurs et les exceptions, examiner les réponses HTTP et les détails des problèmes que nous exposons, et soutenir tout cela par des processus DevSecOps matures qui nous permettent de réagir rapidement chaque fois qu'une nouvelle défaillance critique apparaît dans l'écosystème .NET.