Depuis le 10 novembre 2026, .NET 8 et .NET 9 ne reçoivent plus de correctifs de sécurité, le jour même où Microsoft publie .NET 11 : les équipes qui font tourner des applications sur ces deux versions doivent planifier une migration vers .NET 10 ou .NET 11.
- .NET 8 (LTS) et .NET 9 (STS) sont sortis du support le 10 novembre 2026.
- .NET 11 est disponible en version 11.0.0, avec le SDK 11.0.100 et C# 15.
- .NET 10 LTS et .NET 11 STS seront tous deux supportés jusqu’au 14 novembre 2028.
- La dernière salve de correctifs couvre 25 vulnérabilités, dont deux qui demandent une action en plus de la mise à jour du runtime.
Plan de l'article
Que s’est-il passé le 10 novembre ? #
Microsoft a publié sa mise à jour mensuelle de maintenance, annoncée sur le blog officiel .NET. Elle livre .NET 10.0.15, .NET 9.0.23 et .NET 8.0.34, ainsi que la toute première version stable de .NET 11.
À lire VS Code 1.145 : agents distants, revue croisée entre agents et automatisations cron
Pour .NET 8 et .NET 9, ces correctifs sont les derniers. La page de politique de support de Microsoft classe désormais les deux versions parmi les versions hors support, avec une fin de support fixée au 10 novembre 2026.
Concrètement, une faille découverte demain dans ASP.NET Core ou dans le runtime ne sera plus corrigée pour ces versions. Une application qui reste en 8.0.34 devient vulnérable à chaque nouveau bulletin.
Pourquoi .NET 8 et .NET 9 tombent-ils le même jour ? #
La politique de Microsoft distingue deux types de versions. Les versions paires sont LTS et reçoivent trois ans de support. Les versions impaires sont STS : elles sont supportées un an après la sortie de la version suivante, soit deux ans au total.
.NET 8, sorti le 14 novembre 2023, arrive donc au bout de ses trois ans. .NET 9, sorti le 12 novembre 2024, arrive au bout de ses deux ans. Les deux calendriers se rejoignent cette semaine, ce qui crée une vague de migrations simultanées.
À lire Discord abandonne Electron pour Rust : ce que la réécriture dit aux développeurs
Pour beaucoup d’équipes, la situation est plus délicate qu’une simple montée de version mineure. .NET 8 était le choix par défaut des projets lancés en 2024 justement parce qu’il était LTS, et une bonne partie du parc applicatif en entreprise repose encore dessus.
.NET 10 ou .NET 11 : quelle cible choisir ? #
C’est la vraie surprise du calendrier actuel. D’après la même page de support, .NET 10 LTS et .NET 11 STS expirent tous les deux le 14 novembre 2028. Le statut LTS ne donne donc, cette fois, aucun délai supplémentaire.
Le choix se fait alors sur d’autres critères. .NET 10 a un an de recul en production, ses bibliothèques tierces sont compatibles et ses régressions ont été corrigées par quinze mises à jour successives. .NET 11 apporte C# 15 et les dernières optimisations, mais il sort tout juste.
Une règle simple fonctionne pour la plupart des équipes : migrer les applications critiques vers .NET 10, et réserver .NET 11 aux nouveaux projets ou aux services dont toutes les dépendances sont déjà validées. Dans les deux cas, la prochaine échéance tombe au même moment.
À lire C++26 recalé au vote ISO : une première dans l’histoire du langage
Quels outils faut-il ?
La page de téléchargement de .NET 11 indique que le SDK 11.0.100 est inclus dans Visual Studio 2026 en version 18.12. Les équipes qui travaillent encore sur une version plus ancienne de l’IDE devront aussi la mettre à jour pour cibler .NET 11.
Que contient la dernière mise à jour de sécurité ? #
Le bulletin de novembre corrige 25 vulnérabilités. On y trouve des dénis de service et des élévations de privilèges dans ASP.NET Core, ainsi que plusieurs failles d’exécution de code à distance liées à Visual Studio.
Deux corrections ne s’appliquent pas toutes seules. La première, CVE-2026-118747, exige de mettre à jour séparément le paquet NuGet System.Formats.Cbor. Sur la branche .NET 9, la correction se trouve dans la version 9.0.24 du paquet, et non dans la 9.0.23.
La seconde, CVE-2026-118741, touche les modèles et le code généré par la génération automatique d’ASP.NET Core Identity. Mettre à jour le runtime ne répare pas le code déjà généré dans un projet : il faut le relire ou le régénérer.
À lire Node.js 27 alpha : une seule version majeure par an, et toutes deviennent LTS
Comment organiser la migration ? #
Première étape, installer tout de suite les versions 8.0.34 ou 9.0.23 si ce n’est pas déjà fait. Ce sont les dernières versions corrigées, et elles réduisent l’exposition pendant la migration.
Deuxième étape, faire l’inventaire. Il s’agit de repérer les projets qui ciblent encore net8.0 ou net9.0, les images Docker de base, les pipelines CI qui épinglent une version de SDK et les fichiers global.json.
Troisième étape, changer la cible des projets, mettre à jour les paquets Microsoft.* vers la même version majeure, puis lancer les tests. Les notes de compatibilité publiées par Microsoft pour chaque version listent les changements qui cassent la compilation ou le comportement.
Enfin, une dette de mise à jour coûte moins cher quand on la traite tôt. Les équipes qui migrent dès maintenant vers .NET 10 auront deux ans pour préparer le passage à .NET 12, attendu en LTS selon la règle des versions paires.
À lire Gemini 4 Carbon : Google réserve son modèle le plus puissant à la cyberdéfense
Questions fréquentes #
Une application .NET 8 cesse-t-elle de fonctionner après le 10 novembre 2026 ?
Non. Elle continue de tourner, mais elle ne reçoit plus aucun correctif de sécurité. Chaque nouvelle faille publiée par Microsoft la laisse exposée.
Faut-il préférer .NET 10 LTS à .NET 11 ?
Les deux versions sont supportées jusqu’au 14 novembre 2028. .NET 10 est plus éprouvé en production, tandis que .NET 11 apporte C# 15 et les dernières nouveautés.
Mettre à jour le runtime suffit-il à corriger toutes les failles de novembre ?
Non. CVE-2026-118747 demande aussi de mettre à jour le paquet System.Formats.Cbor, et CVE-2026-118741 impose de revoir le code généré par ASP.NET Core Identity.
