Assurez la prise en charge de fin de vie (EOL) de .NET sans avoir à réécrire votre application ni à précipiter une mise à niveau
Le service « Endless Lifecycle Support » fournit des correctifs CVE après la fin de vie (EOL) pour
.NET 6, 8 et 10, couvrant le runtime .NET, le SDK, ASP.NET
Core Runtime et Desktop Runtime, ce qui vous permet de réduire les risques
sans interruption.
Parlez-nous
N'hésitez pas à nous poser vos questions concernant la couverture, les accords de niveau de service (SLA), les tarifs ou tout autre sujet.
Versions .NET prises en charge
Fin du support :
12 novembre 2024
Couverture assurée par ELS
Fin du support :
14 mai 2024
Couverture assurée par ELS
Fin du support :
10 novembre 2026
Couverture assurée par ELS
Fin du support :
novembre 2028
Couverture assurée par ELS
Correctifs de sécurité que nous avons fournis pour les versions .NET en fin de cycle de vie
CVE de gravité élevée et critique
Prise en charge des composants .NET que vous utilisez
Choisissez le composant qui correspond à la manière dont vos équipes développent, hébergent et exploitent les applications .NET.
SDK .NET
Développez, compilez, testez et publiez des applications à l'aide de l'interface de ligne de commande (CLI), des compilateurs et des outils de compilation ; comprend les environnements d'exécution ci-dessous.
Environnement d'exécution ASP.NET Core
Veillez à toujours héberger vos applications et services web sur un environnement d'exécution sécurisé.
Environnement d'exécution .NET
Exécutez des applications console, des services en arrière-plan et des API sans avoir recours à l'ensemble de la chaîne d'outils de développement.
.NET Desktop Runtime
Permettre aux applications WPF et Windows Forms de continuer à fonctionner sur leur infrastructure .NET existante.
Ce que vous offre ELS
Correction des vulnérabilités CVE pour les versions non prises en charge de .NET
À mesure que de nouvelles vulnérabilités .NET sont révélées, TuxCare mène des enquêtes, procède à des rétroportages, effectue des tests et publie des mises à jour pour les versions en fin de vie (EOL) prises en charge, vous aidant ainsi à rester protégé après la fin du support de Microsoft.
Le premier jour
ELS vous donne accès aux correctifs existants pour les vulnérabilités CVE connues affectant la version et les composants .NET couverts.
Conservez votre configuration. Renforcez votre sécurité.
ELS conserve la version .NET, le comportement des applications et les modèles de déploiement auxquels vos équipes sont déjà habituées. Pas de refactorisation, pas de passage forcé à une nouvelle version majeure.
ELS intervient dans
Windows Server 2012 à 2025, Windows Server Core, Nano Server, Windows 10 et 11, sur x64 et x86, installés à l'aide des mêmes programmes d'installation .exe et .msi que votre équipe utilise déjà.
Un soutien qui résiste à l'examen
de déploiement de correctifs couvert par un SLA: le SLA de déploiement de correctifs de TuxCare aide votre organisation à répondre aux exigences en matière de correction des vulnérabilités imposées par des référentiels et des réglementations tels que SOC 2, NIS2, PCI DSS, HIPAA, DORA et la CRA.
Garanties d'assistance pour les entreprises
ELS est conçu pour une utilisation en entreprise, avec des conditions d'assistance commerciale et des protections contractuelles adaptées aux organisations qui ont besoin de plus qu'une simple maintenance communautaire assurée dans la mesure du possible.
Intégrez ELS à votre infrastructure existante en quelques minutes , sans avoir à modifier votre code.
Compatible avec :
Windows 11
Windows 10Windows Server CoreWindows Server 2012–2025Nano ServerUne longueur d'avance en matière de sécurité .NET
Adoptez ELS et bénéficiez des correctifs déjà fournis pour votre version, ainsi que d'une surveillance continue des vulnérabilités et de l'application des correctifs à mesure que de nouveaux CVE .NET apparaissent.
| CVE | Composant | Sévérité | Publié | Résumé |
|---|---|---|---|---|
| 42899 | ASP.NET Core | Haut | Une condition de sortie de boucle inaccessible peut être déclenchée à distance, ce qui peut entraîner un déni de service. | |
| 32178 | System.Net.Mail | Haut | Le traitement des adresses e-mail accepte des caractères injectés, ce qui permet l'injection de commandes ou d'en-têtes SMTP. | |
| 26131 | .NET 10 (installation sous Linux) | Haut | Des droits d'accès incorrects sur les fichiers sous .NET 10 (Linux) peuvent permettre à un utilisateur local d'élever ses privilèges. | |
| 26127 | Environnement d'exécution .NET | Haut | Une lecture hors limites peut provoquer le plantage d'une application à distance sans authentification. | |
| 25667 | Kestrel (HTTP/3) | Haut | Un paquet QUIC spécialement conçu peut entraîner une utilisation excessive du processeur et provoquer un déni de service. | |
| 21218 | Environnement d'exécution .NET (COSE) | Haut | Une gestion incorrecte des exceptions permet à un attaquant de contourner la validation de la signature. | |
| 30399 | Environnement d'exécution .NET | Haut | Un chemin de recherche non fiable peut permettre à un attaquant de déclencher l'exécution involontaire de code. | |
| 26682 | ASP.NET Core (HTTP/3) | Haut | L'allocation illimitée de ressources HTTP/3 permet à un attaquant de provoquer un déni de service. | |
| 24070 | ASP.NET Core (Authentification) | Haut | Une faille dans la validation de la connexion permet à un pirate de se faire passer pour un autre utilisateur. | |
| 38229 | ASP.NET Core (HTTP/3) | Haut | Une condition de concurrence dans la gestion des flux HTTP/3 peut entraîner l'exécution de code à distance. | |
| 38168 | ASP.NET (HTTP.sys) | Haut | Les requêtes non authentifiées adressées aux applications hébergées par HTTP.sys peuvent entraîner un déni de service. | |
| 38081 | .NET / Programme d'installation de Visual Studio | Haut | Une faille liée à la manipulation de fichiers locaux lors de l'installation peut permettre une élévation de privilèges. | |
| 26190 | MsQuic (protocole QUIC) | Haut | Des connexions QUIC malveillantes peuvent entraîner une allocation excessive de mémoire, provoquant ainsi un déni de service. | |
| 0057 | .NET (validation X.509) | Critique | Une faille dans la logique de validation des certificats peut faire apparaître comme valide une chaîne de confiance non valide. | |
| 36049 | .NET (System.Net.WebRequest) | Critique | Les URI non fiables peuvent injecter des commandes FTP — une faille critique bien connue de .NET. | |
| 35391 | ASP.NET Core (SignalR) | Haut | SignalR, lorsqu'il utilise Redis comme backplane, peut entraîner des fuites d'informations entre les connexions des utilisateurs. | |
| 33135 | SDK .NET | Haut | Une faille survenant lors de la restauration de l'outil peut être exploitée pour obtenir des privilèges locaux supérieurs. | |
| 24464 | ASP.NET Core (FormPipeReader) | Haut | Des données de formulaire composées de plusieurs parties spécialement conçues peuvent provoquer un déni de service. | |
| 21986 | Kestrel (HTTP/2, HTTP/3) | Haut | Des requêtes HTTP/2 et HTTP/3 mal formées peuvent provoquer le plantage du serveur web Kestrel. |
Demandez conseil à un expert en correctifsCVE pour l'
.NET
N'hésitez pas à nous contacter pour discuter de la couverture ELS, de sa mise en œuvre, de la conformité ou des tarifs pour votre environnement .NET.
Comment cela fonctionne-t-il ?
Nous intégrons de nouveaux projets et mettons en place un suivi automatisé des CVE 24 heures sur 24, 7 jours sur 7, en surveillant les avis de sécurité de la NVD, des fournisseurs, de GitHub et d'autres sources.
Une fois les CVE détectés, nous rétroportons les correctifs en amont à l'aide d'une automatisation algorithmique assistée par l'IA, accompagnée d'une validation par un expert.
Les correctifs sont compilés dans un format binaire, testés de manière approfondie (intégrité, fonctionnalité et régression), signés et déployés dans les dépôts ELS.
Vos gestionnaires de paquets, outils de construction ou orchestrateurs vérifient la présence de mises à jour, puis les extraient et les installent automatiquement.
Comment les équipes utilisent ELS
Fermer la fenêtre d'exposition aux vulnérabilités CVE
⚠️ Le problème :
Les API, services Web et systèmes de bureau essentiels à l'activité sont liés à la fin de vie (EOL) de .NET 6. Les outils de scan signalent chaque déploiement, Microsoft ne publie plus de correctifs, et chaque nouvelle vulnérabilité CVE creuse davantage l'écart entre la divulgation et l'exploitation.
🔄 Le tour :
ELS reprend la mise à jour des correctifs pris en charge par le SLA pour les versions .NET couvertes : des versions signées et testées en régression du runtime, du SDK et d’ASP.NET Core, installées via des programmes d’installation standard sans modification du code. Ce service s’appuie sur un suivi des CVE 24 h/24, 7 j/7.
Clôturer une constatation d'audit en cours
⚠️ Le problème :
L'audit interne, la norme SOC 2 et un questionnaire client soulignent tous que .NET est en fin de vie (EOL), et Microsoft ne publiera jamais de correctif à ce sujet ; il n'y a donc pas de date de mise en conformité à communiquer aux auditeurs ou au conseil d'administration.
🔄 Le tour :
ELS fournit un environnement d'exécution identifié et pris en charge par le fournisseur dans le cadre d'un accord de niveau de service (SLA) contractuel, avec des documents CSAF VEX inclus dans chaque version. Les incidents sont clôturés par des mesures correctives documentées, conformes aux normes PCI DSS, HIPAA, SOC 2, DORA, NIS2 et CRA.
Migrer selon vos propres conditions, sans vous laisser dicter le rythme par la date de fin de vie (EOL)
⚠️ Le problème :
Chaque nouvelle version de .NET ne bénéficie que de trois ans de support (LTS) ou de deux ans (STS, comme la version 7), et passer de la version 6 à la 7, puis à la 8 et enfin à la 10 implique des changements rompant la compatibilité, des mises à jour des dépendances et des tests de régression sur des centaines de projets.
🔄 Le tour :
ELS s'intègre à l'ensemble de votre infrastructure (sur site ou sur AWS, Azure et GCP) sans aucune modification du code. Vous disposez ainsi d'une marge de manœuvre de plusieurs années pour planifier vos mises à niveau en fonction des priorités de votre entreprise, au lieu de considérer une date de fin de vie comme une échéance urgente.
Pourquoi TuxCare ?
420,000+
Mises à jour fournies
Par l'équipe qui prolonge les cycles de vie des logiciels libres
TuxCare assure la protection des composants essentiels bien après la fin du support en amont, du noyau Linux aux environnements d'exécution de langages tels que Node.js. Un seul partenaire, une couverture complète de la pile technologique.
14,000+
Vulnérabilités corrigées
Partenaire platine fondateur de la Fondation AlmaLinux OS et membre de l'Open Source Security Foundation (OpenSSF).
TuxCare investit dans l'écosystème open source qu'elle sécurise, de Node.js à Linux, et bien au-delà.
En savoir plus →
70,000+
Sélection de forfaits
2,700+
Clients professionnels
Informations connexes
Fin de vie de .NET 6 : quelles conséquences pour votre entreprise en 2026 ?
Principaux enseignements .NET 7 n'est plus pris en charge - migrer vers une version prise en charge...
Fin de vie de .NET 8 : dates clés, risques et mesures à prendre dès maintenant
Principaux enseignements .NET 6 a atteint sa fin de vie le 12 novembre 2024, laissant les systèmes...
Alerte de sécurité critique concernant .NET : la vulnérabilité CVE-2025-24070 affecte .NET 6 malgré...
Notre équipe de recherche en sécurité a constaté que la vulnérabilité récemment révélée...
Sécurisez vos versions .NET en fin de vie
Discutez avec notre équipe des solutions permettant de sécuriser les environnements d'exécution et les composants .NET qui ne sont plus pris en charge, sans modification du code, sans migration précipitée ni retard indéfini dans le traitement des vulnérabilités CVE.
Une question ?
Foire aux questions
La documentation mentionne actuellement .NET 6, .NET 8 et .NET 10. La prise en charge de .NET 6 a déjà pris fin ; la prise en charge de .NET 8 et .NET 10 assure la continuité à mesure que ces versions atteignent leur date officielle de fin de prise en charge. D'autres versions et architectures sont disponibles sur demande — veuillez contacter [email protected].
Non. ELS fournit des versions corrigées de la même version de .NET que celle sur laquelle votre application fonctionne actuellement, installables à l'aide des programmes d'installation standard au format .exe et .msi. Votre code, vos fichiers de projet et votre processus de déploiement restent inchangés. Comme pour toute mise à jour du runtime, il est recommandé de procéder à des tests spécifiques à l'application avant le déploiement en production.
Le SDK .NET, le runtime .NET, le runtime ASP.NET Core et le runtime .NET Desktop (WPF et Windows Forms). Installez le composant adapté à votre charge de travail, ou le SDK pour disposer de l'ensemble des composants.
Éditions prises en charge de Windows 10, Windows 11, Windows Server, Windows Server Core et Nano Server, sur x64 (et x86 pour certaines versions de Windows Server). Les environnements pris en charge varient selon la version de .NET ; d'autres systèmes d'exploitation et architectures peuvent être disponibles sur demande.
La mise à disposition des correctifs est couverte par le contrat de niveau de service (SLA) de TuxCare, qui garantit le respect des délais de correction prévus par les normes SOC 2, NIS2, PCI DSS, HIPAA, DORA et CRA.
Oui, les différentes versions de .NET peuvent généralement coexister, ce qui permet aux équipes d'effectuer la transition en douceur. Utilisez les commandes `dotnet --list-sdks` et `dotnet --info` pour recenser les versions installées et vérifier les déploiements avant de supprimer les anciens composants.
ELS vous propose un processus documenté et soutenu par le fournisseur pour corriger les vulnérabilités des logiciels en fin de vie : une prestation couverte par un SLA, des conditions de support commercial et une SBOM fournie avec chaque version. Cela permet de transformer une exception d'audit non prise en charge en une couverture gérée et justifiée, même si chaque organisation détermine elle-même comment ce service s'adapte à ses obligations réglementaires spécifiques.
L'ELS ne remplace pas la modernisation. Il élimine la pression liée aux délais. Vous bénéficiez d'une marge de manœuvre supplémentaire, ce qui vous permet de planifier les migrations en fonction des priorités métier, des exigences de test et des capacités techniques, plutôt qu'en fonction d'une date de fin de vie (EOL).