Microsoft ASP.NET Core Zero-Day CVE-2026-40372 : CVSS 9.1, Patch disponible depuis le 22 avril

7 min de lecture · Mise à jour : 23.04.2026

Microsoft a publié le 22 avril 2026 une mise à jour hors cycle et, avec CVE-2026-40372, a confirmé un bug CVSS 9,1 dans ASP.NET Core. La faille permet à un attaquant non authentifié d’escalader ses privilèges jusqu’au niveau SYSTEM en falsifiant les cookies d’authentification. Le correctif dans DataProtection 10.0.7 est disponible. Le véritable risque ne réside pas dans la faille elle‑même, mais dans sa diffusion : des milliers d’applications d’entreprise s’exécutent sur des serveurs faits maison, dépourvus de mise à jour automatique. Les équipes de sécurité ont désormais besoin d’un plan propre de 72 heures.

Ce que la faille fait concrètement

Qu’est‑ce que CVE-2026-40372 ? CVE-2026-40372 est une faille d’escalade de privilèges dans la bibliothèque ASP.NET Core DataProtection, publiée le 22 avril 2026 avec un score CVSS de 9,1. Une régression dans les versions 10.0.0 à 10.0.6 affaiblit la vérification cryptographique des signatures. Un attaquant peut contourner la validation avec un HMAC tout zéro et ainsi falsifier les cookies d’authentification et les jetons anti‑forgery. Il peut ensuite obtenir des privilèges SYSTEM sur l’hôte ASP.NET Core. Microsoft a livré le correctif dans la version 10.0.7.

Le mécanisme est bien documenté. ASP.NET Core utilise DataProtection pour le chiffrement et la signature des cookies. Lorsque la validation de la signature accepte un HMAC tout zéro, il est possible de falsifier n’importe quel cookie. Cela ouvre la porte à un contournement d’authentification. Un attaquant peut alors prendre le contrôle de la session d’un administrateur et exécuter du code avec les privilèges SYSTEM via le pipeline ASP.NET Core. La chaîne d’escalade est courte, le préjudice dans les applications en production est considérable.

Le problème réside moins dans la faille elle‑même que dans sa diffusion. ASP.NET Core est présent dans des dizaines de milliers d’applications d’entreprise, tous secteurs confondus. Nombre de ces applications ont été migrées vers .NET 10 au cours des 24 derniers mois, sans que la configuration DataProtection ne soit vérifiée. Des images de conteneurs avec le runtime .NET 10 sont construites dans des pipelines CI et déployées sur des clusters Kubernetes, sans chemin de correctif automatisé. Qui ne dispose pas d’un mécanisme de suivi actif des mises à jour hors cycle de Microsoft passe facilement à côté de la faille.

Quelles catégories d’applications sont particulièrement critiques

Trois catégories d’applications méritent une attention particulière. La première est l’application classique de back‑end web sous .NET 10. Qui exploite une application web côté client dans un secteur réglementé, tel que la banque en ligne, les portails d’auto‑service client ou les parcours de demande d’assurance, dispose d’une surface d’attaque directement exposée. Le correctif doit être mis en production dans les 48 heures, avec une traçabilité d’audit documentée.

La deuxième catégorie regroupe les passerelles d’API internes et les services de niveau intermédiaire. Ces applications ne sont pas directement accessibles depuis Internet, mais dès qu’un attaquant obtient un point d’ancrage dans le réseau interne, la faille s’escalade rapidement. Qui ne met pas en œuvre une segmentation réseau stricte doit traiter les correctifs de la même façon que pour les applications exposées à Internet. Le point de vue conformité sur DORA et NIS2 explique pourquoi les applications internes dans les secteurs réglementés doivent être traitées de façon similaire.

La troisième catégorie concerne les anciennes applications ASP.NET Core qui ont été migrées vers .NET 10 au cours des 24 derniers mois, sans que la configuration DataProtection n’ait été vérifiée. Ces applications sont souvent en statut de maintenance et sont mises à jour moins fréquemment. C’est précisément pour cette raison qu’elles constituent une cible attrayante. Un inventaire des restes de migration doit être mené en parallèle du déploiement des correctifs.

Un plan de réaction de 72 heures pour les opérations de sécurité

Trois jours suffisent pour une réaction propre, lorsque l’ingénierie et la sécurité travaillent main dans la main. La logique en étapes suivante s’est avérée efficace dans plusieurs banques et assureurs de la région DACH.

Ce que la faille révèle sur les routines de correctifs Microsoft en 2026

Microsoft a publié, au cours des douze derniers mois, des mises à jour hors cycle (out‑of‑band) plus fréquemment qu’en 2024. Cela modifie les attentes opérationnelles vis‑à‑vis des opérations de sécurité. Qui ne suit que le cycle mensuel Patch Tuesday passe régulièrement à côté des mises à jour critiques hors cycle. Les bulletins du Microsoft Security Response Center devront, en 2026, être intégrés à une plage hebdomadaire, avec un chemin d’escalade pour les publications critiques.

Une deuxième observation mérite votre attention. ASP.NET Core est une plateforme très répandue sur le marché DACH, notamment dans les secteurs financier, assurantiel et des services publics. La faille ne touche pas un composant de niche, mais une couche centrale. Si, en tant que responsable de la sécurité, vous ne connaissez pas l’étendue de la plateforme au sein de votre organisation, vous avez un angle mort lors de vagues comme celle‑ci. Un inventaire de plateforme fondamental, mis à jour une fois par an, s’avère rentable.

Troisièmement : la discipline SBOM constitue, en 2026, l’investissement opérationnel le plus important. Qui possède une liste complète et à jour des composants logiciels réagit en quelques heures à de tels incidents. Qui n’a pas de SBOM consacre les douze premières heures à la recherche plutôt qu’au correctif. Des fournisseurs tels qu’Anchore, Snyk et Sysdig proposent, en 2026, des outils matures qui automatisent la génération de SBOM et la corrélation des CVE. L’investissement porte ses fruits dès le premier incident critique.

Comment la réaction s’insère dans le panorama des correctifs du T2

CVE-2026-40372 s’inscrit dans une série. La mise à jour CISA‑KEV du 20 avril avec huit autres vulnérabilités, la réactivation de PaperCut et plusieurs correctifs mineurs ont occupé en permanence les opérations de sécurité en 2026. La séquence montre que la charge opérationnelle augmente. Les équipes qui pouvaient gérer deux CVE critiques par mois en 2024 en voient désormais quatre à six par semaine en 2026.

Sur le plan structurel, cela nécessite une autre architecture du personnel dans les opérations de sécurité. Ceux qui utilisent le modèle SOC à trois niveaux classique seront à la traîne en 2026. La visibilité de l’ingénierie de plateforme, les pipelines de correctifs automatisés et l’inventaire basé sur les SBOM doivent faire partie de l’équipement standard. Reporter cela crée une friction croissante qui deviendra visible au cours des prochains trimestres.

Pour les dirigeants, l’incident constitue un motif d’action concret. Une question sur l’état des correctifs à la prochaine réunion du conseil aiguise le sujet auprès du CISO et du CIO. Une seconde question sur la discipline SBOM constitue un bon test de maturité. Qui peut répondre concrètement aux deux questions en 30 secondes dispose d’une gouvernance de sécurité fonctionnelle. Qui fournit des réponses vagues a un besoin d’investissement identifiable.

Foire aux questions

Quelles versions d’ASP.NET Core sont concernées ?

DataProtection dans les versions 10.0.0 à 10.0.6. Le correctif en 10.0.7 est disponible depuis le 22 avril 2026. Les versions majeures antérieures ne sont pas directement concernées, mais devraient être vérifiées indépendamment de leur statut de cycle de vie.

Une rotation des cookies est‑elle toujours nécessaire ?

Pas forcément. Pour les applications à exposition courte et sans signe d’exploitation, le correctif suffit. Pour les applications exposées à Internet pendant une période plus longue, une rotation des cookies est judicieuse, car on ne peut exclure que des cookies aient déjà été compromis.

Comment savoir si mon application est vulnérable ?

En recherchant dans le SBOM le composant Microsoft.AspNetCore.DataProtection dans l’une des versions mentionnées. Les analyses d’images de conteneurs avec Trivy, Grype ou Snyk identifient les paquets affectés dans les couches d’image. Les équipes de développement peuvent généralement fournir un état des lieux en quelques heures.

Comment le CISA et le BSI réagissent-ils à l’incident ?

Le CISA a documenté l’incident rapidement, sans enregistrement formel KEV jusqu’au 23 avril. Le BSI a publié un avertissement préliminaire. Les deux organismes recommandent de corriger immédiatement. L’enregistrement formel KEV pourrait suivre dans les prochains jours, si une exploitation active est confirmée.

Quelles règles de détection sont pertinentes ?

Alertes SIEM pour des modèles inhabituels de renouvellement de cookies, des tentatives inhabituelles d’élévation de privilèges depuis le contexte du processus ASP.NET Core et des anomalies dans les journaux d’authentification. La chasse EDR sur les spawns de processus suspects provenant d’IIS ou de Kestrel complète la couche de détection.

À quelle fréquence Microsoft publie-t-il des correctifs hors cycle en 2026 ?

Plus fréquent qu’en 2024. Au cours des douze derniers mois, plusieurs correctifs critiques hors cycle ont été livrés. Un examen hebdomadaire de routine des bulletins du Microsoft Security Response Center constitue le bon rythme en 2026.

Plus du réseau MBF Media

Cloudmagazin : Google Cloud Location Finder Pre‑GA

MyBusinessFuture : Deloitte State of AI 2026

Digital Chiefs : IT‑Services comme activité orientée résultat