Top 25 des Failles CWE 2025

Résumé Exécutif

Le Top 25 CWE 2025 du MITRE met en avant les failles logicielles les plus répandues et critiques, identifiées à partir de 39 080 vulnérabilités CVE publiées entre mi‑2024 et mi‑2025. Ces faiblesses sont souvent simples à exploiter et sous-tendent de nombreuses vulnérabilités graves permettant des compromissions complètes de systèmes, du vol de données ou des perturbations de service.

Les résultats 2025 montrent la persistence de failles classiques d’injection web (XSS en tête du classement pour la deuxième année consécutive) ainsi qu’une montée des problèmes d’accès et d’autorisation. Notamment, des failles d’absence de contrôles d’autorisation gagnent du terrain, tout comme plusieurs variantes de corruptions de mémoire qui font leur entrée cette année dans le Top 25.

À l’inverse, certaines failles historiques très abstraites (p.ex. privilèges mal gérés, débordements entiers) reculent ou sortent du classement, reflet d’une meilleure précision des analyses de causes racines. Cette liste sert de guide prioritaire aux RSSI, équipes SOC et CERT pour orienter les efforts de réduction de surface d’attaque : corriger en priorité ces failles répandues et former les développeurs à les éviter renforce significativement la sécurité logicielle.

Analyse Détaillée des 25 Principales Faiblesses CWE en 2025

  1. CWE-79 – Cross-Site Scripting (XSS) :
    Faiblesse la plus courante en 2025 (rang #1, inchangé par rapport à 2024), le XSS provient d’une neutralisation insuffisante de données saisies dans une page web. Une application web vulnérable ne filtre pas correctement les entrées de l’utilisateur avant de les inclure dans du contenu HTML, permettant à un attaquant d’y injecter du script malveillant exécuté dans le navigateur des autres utilisateurs.
    Impact : vol de sessions, détournement de comptes administrateur, exécution de code côté client, etc.. Cette faille affiche le score CWE le plus élevé (60,38) et 7 CVE exploités publiquement (KEV) lui sont associés, soulignant sa gravité.
    Contexte technique : très répandue dans les applications web (prévalence « Often » côté Web) avec une probabilité d’exploitation jugée élevée par le MITRE.
    Mitigation : utiliser des frameworks de gabarits sécurisés ou des bibliothèques d’encodage pour échapper les caractères spéciaux dans les sorties web; valider systématiquement les entrées et privilégier une stratégie de “liste blanche” des formats attendus.
  2. CWE-89 – Injection SQL :
    En 2025, l’injection SQL occupe le rang #2 (en hausse de +1), avec un score de 28,72. Cette faille survient lorsque l’application construit dynamiquement une requête SQL en y insérant des données externes sans neutraliser les caractères spéciaux. L’attaquant peut altérer la syntaxe SQL, par exemple en fermant prématurément une requête et en enchaînant une commande arbitraire, ce qui permet de lire, modifier ou détruire les données en base, voire d’exécuter des commandes système via la base de données.
    Incidence : 4 CVE de ce type figurent dans la liste KEV 2024-2025, et la faiblesse reste hautement exploitable (“Likelihood: High” d’après le MITRE) dans les scénarios d’applications web classiques.
    Recommandations : recourir à des requêtes paramétrées ou des procédures stockées plutôt que de concaténer des chaînes SQL; utiliser des ORM ou frameworks fournissant une abstraction de persistance sécurisée qui empêchent ces injections.
  3. CWE-352 – Cross-Site Request Forgery (CSRF) :
    En 3e position (↑1), le CSRF se manifeste lorsqu’une application web ne vérifie pas suffisamment qu’une requête HTTP provient bien de l’utilisateur légitime. Un attaquant peut inciter la victime authentifiée à déclencher, à son insu, une action sur le site vulnérable (par ex. via une image ou un lien piégé).
    Conséquences : réalisation d’actions non souhaitées sous l’identité de la victime (transactions, modifications de données), compromission potentielle complète si la victime est administrateur.
    Données : Score CWE 13,64 et aucun CVE exploité associé en 2025, mais son importance demeure, d’autant que la protection repose sur le bon implémentation de tokens anti-CSRF.
    Mesures préventives : intégrer des jetons imprévisibles (“nonce”) dans les formulaires et vérifier leur validité côté serveur; s’assurer également qu’aucune faille XSS n’est présente, car un script malveillant pourrait sinon contourner les défenses CSRF.
  4. CWE-862 – Autorisation Manquante :
    Classée #4 (↑5), cette faiblesse traduit l’absence de contrôle d’autorisation pour certaines actions ou ressources critiques. L’application n’effectue pas de vérification des droits lorsqu’un acteur tente d’accéder à une ressource sensible ou d’exécuter une fonction, permettant à des utilisateurs non habilités de réaliser des opérations normalement réservées.
    Évolution : c’est l’une des plus fortes progressions de l’année, passant du rang #9 à #4, reflétant une prise de conscience des problèmes d’accès non restreint.
    Impact : accès ou modification de données sensibles, élévation horizontale de privilège, contournement de restrictions de sécurité (lecture/écriture non autorisée). Elle ne compte aucun CVE dans KEV (2024-25) mais son score reste élevé (13,28).
    Bonnes pratiques : appliquer le principe du moindre privilège et une gestion rigoureuse des rôles / permissions (RBAC) dès la conception; valider systématiquement côté serveur que l’utilisateur courant est autorisé pour chaque opération sensible (et non se fier aux seuls contrôles côté client ou à l’interface).
  5. CWE-787 – Écriture Hors Limites (Out-of-Bounds Write) :
    Après avoir été #1 en 2024, cette faille rétrograde #5 en 2025 (↓3), malgré un score incidence-sévérité de 12,68. Il s’agit d’une écriture de données en dehors des limites d’un tampon mémoire prévu, typiquement due à un débordement de buffer.
    Environnement typique : code en C/C++ manipulant des tableaux ou pointeurs sans vérification adéquate des indices ou de la taille.
    Conséquences : corruption de mémoire entraînant un plantage (DoS) ou, pire, écrasement de structures de contrôle (pointeurs de retour, etc.) permettant une exécution arbitraire de code malveillant avec les droits du programme. La faille est associée à 12 CVE exploités activement en 2024-25 (le plus haut total de la liste), soulignant l’attrait des attaquants pour ces vulnérabilités de corruption mémoire.
    Atténuation : utiliser des langages gérés ou des bibliothèques sûres offrant des contrôles automatiques des limites (p.ex. fonctions Safe C String); activer les protections compilateur (canaries, fortification) pour détecter les débordements à l’exécution.
  6. CWE-22 – Path Traversal :
    En 6e position (↓1), cette faiblesse de chemin d’accès se produit lorsque l’application utilise une entrée externe pour construire un chemin de fichier sans neutraliser les séquences spéciales (comme ../) permettant de sortir du répertoire autorisé. Un attaquant peut ainsi naviguer vers des fichiers sensibles en dehors de l’arborescence prévue (lecture de /etc/passwd, accès à des configurations, etc.).
    Impact : exposition ou modification non autorisée de fichiers critiques, contournement de mécanismes d’authentification ou plantage du système en altérant des fichiers système. Son score est de 8,99 et 10 CVE exploités y correspondent, ce qui en fait une menace concrète.
    Mesures : valider strictement les entrées de type chemin (n’autoriser que les caractères et formats attendus) et normaliser le chemin avant utilisation; idéalement, restreindre les accès fichiers à des répertoires prédéfinis et utiliser des API de résolution sécurisées évitant la simple concaténation de chemins.
  7. CWE-416 – Use-After-Free (Utilisation de Mémoire après Libération) :
    Cette faille mémoire atteint le rang #7 (↑1) avec un score de 8,47. Elle se produit quand le programme réutilise une zone de mémoire après l’avoir libérée. Cela crée un pointeur “dangling” pouvant pointer vers des données imprévues ou déjà réallouées à autre chose.
    Conséquences : en lisant/écrivant via ce pointeur invalide, le comportement est indéfini – souvent un crash, mais possiblement une corruption de mémoire exploitable pour exécuter du code arbitraire si un attaquant parvient à contrôler la nouvelle allocation (techniques d’exploitation heap). Très courant en C/C++, le use-after-free figure dans 14 CVE de la liste KEV de l’année.
    Contre-mesures : adopter des langages à gestion automatique de mémoire (Java, Rust…) pour éliminer ce risque; sinon, définir à NULL les pointeurs après free() et implémenter des vérifications robustes (mais cela reste défensif et non exhaustif). Des outils d’analyse dynamique (ASan) aident aussi à détecter ces erreurs à l’exécution.
  8. CWE-125 – Lecture Hors Limites (Out-of-Bounds Read) :
    En 8e position (↓2), la lecture hors limites survient quand le logiciel lit des données en dehors des limites d’un tampon (avant le début ou après la fin). Souvent dû à une mauvaise gestion des indices ou décalages, ce bug expose potentiellement en mémoire des informations sensibles (données d’autres variables, clés cryptographiques) et peut provoquer un crash si une zone invalide est lue.
    Exploitation : un attaquant pourrait ainsi contourner des ASLR/DEP en lisant des pointeurs ou déclencher un déni de service. Cette faiblesse a un score de 7,88 (plus modéré) et correspond à 3 CVE exploités connus.
    Prévention : valider soigneusement tous les calculs de taille et d’index avant lecture, éviter de se fier à un caractère sentinelle de fin de données. L’utilisation de structures de données sûres ou de langages effectuant la vérification des limites (Java, Python…) est fortement recommandée.
  9. CWE-78 – Injection de Commandes OS :
    Classée #9 (↓2), cette faille critique apparaît lorsque l’application compose une commande système en y incluant des données externes sans neutraliser les métacaractères du shell. L’attaquant peut injecter des délimiteurs de commande (&, ;, |…) pour exécuter des instructions système arbitraires avec les privilèges de l’application cible.
    Dangers : accès au système de fichiers, exécution de malware, élévation de privilèges, etc. (toutes les conséquences d’une compromission d’OS). Son score (7,85) et surtout les 20 CVE du KEV correspondants en font l’une des faiblesses les plus exploitées en pratique.
    Atténuation : ne pas construire de chaînes de commande shell directement depuis des entrées utilisateur. Privilégier des API ou appels système paramétrés (par ex. utiliser execvp avec une liste d’arguments plutôt qu’system() en concaténant une chaîne). Sinon, imposer une validation drastique des caractères autorisés dans les paramètres ou recourir à des whitelists de commandes.
  10. CWE-94 – Injection de Code :
    Cette faiblesse, en 10e position (↑1), recouvre les cas où le produit génère ou injection du code source ou bytecode de façon dynamique à partir de données influençables par un utilisateur, sans contrôle adéquat. Cela peut cibler par exemple les fonctions d’évaluation de code à la volée (eval() en Python/JS, Runtime.exec() en Java, etc.) ou la génération de fichiers de script sur disque.
    Impacts : très similaires à l’injection de commande, pouvant aboutir à de l’exécution de code arbitraire dans le contexte de l’application vulnérable. Le score CWE est de 7,57, avec 7 CVE connus exploités sur la période.
    Exemple : la compromission d’une fonction de template non sécurisée permettant d’insérer du code serveur. Contre-mesures : éviter autant que possible la génération dynamique de code – préférez des approches statiques ou précompilées. Si nécessaire, restreindre fortement ce code via un bac à sable (sandbox), et valider les entrées utilisées pour le construire (p.ex. filtrer tout caractère de contrôle de flux ou mot-clé dangereux).
  11. CWE-120 – Débordement de Tampon Classique :
    Nouveau venu au rang #11 en 2025 (n’apparaissait pas en 2024), ce CWE historique désigne la copie de données dans un tampon sans vérifier la taille de l’entrée par rapport à la capacité du tampon de sortie. Il s’agit du cas canonique de débordement de buffer (par ex. utilisation de strcpy en C sans contrôle de longueur).
    Conséquences : écrasement de la pile ou du tas menant à une exécution de code arbitraire ou un crash, selon l’exploitation par l’attaquant.
    Contexte : Ce CWE est plus spécifique que CWE-787, et son entrée dans le Top 25 cette année est due à l’abandon de la normalisation des données vers des parents abstraits (il était auparavant englobé par CWE-119). Aucun CVE du KEV n’y est rattaché pour 2025, reflétant possiblement une moindre médiatisation que d’autres débordements, mais son score reste significatif (6,96).
    Parades : adopter des fonctions sécurisées (p.ex. strncpy ou mieux, strlcpy/memcpy avec taille) ou des structures limitant la copie; activer les protections d’exécution (canaries, ASLR); et bien sûr, vérifier systématiquement les longueurs avant toute opération de copie en mémoire.
  12. CWE-434 – Téléversement de Fichier Dangereux Non Restreint :
    Cette faille (rang #12, ↓2) consiste à accepter le téléversement d’un fichier sans en restreindre le type ou le nom, dans un contexte où ce fichier sera ensuite traité automatiquement par le système. Un attaquant peut par exemple uploader un script (.php, .jsp…) dans un répertoire web accessible et l’exécuter à distance, conduisant à une prise de contrôle du serveur.
    Incidence : 4 CVE exploités correspondent à ce scénario en 2024-25, et le score est de 6,87.
    Mesures : implémenter une liste blanche stricte des types de fichiers autorisés (extensions et en-têtes MIME) et rejeter ou renommer tout fichier non conforme. Il est recommandé d’enregistrer les fichiers uploadés hors des dossiers web publics et d’utiliser des noms de fichiers internes aléatoires. De plus, désactiver l’exécution des scripts dans les répertoires de dépôt de fichiers peut empêcher l’exploitation même en cas d’upload réussi.
  13. CWE-476 – Déréférencement de Pointeur NULL :
    Cette faiblesse (rang #13, ↑8 places) survient lorsqu’un programme déréférence un pointeur alors qu’il vaut NULL (non initialisé ou déjà libéré), provoquant typiquement un crash immédiat de l’application. Bien que souvent perçu comme un simple bug provoquant un DoS, Le MITRE le liste parmi les 25 car il peut avoir des conséquences plus graves si exploité dans de rares contextes kernel ou pilotes (où NULL peut référencer une zone mémoire réelle accessible en ring 0).
    Tendance : son large bond dans le classement (de #21 à #13) peut indiquer une meilleure identification dans les CVE ou l’impact de la fin de normalisation (certaines occurrences n’étant plus converties en erreurs plus abstraites). Aucun CVE KEV ne lui est associé en 2025.
    Bonnes pratiques : vérifier systématiquement les retours de fonctions susceptibles de renvoyer NULL avant utilisation; initialiser les pointeurs et gérer les conditions d’erreur de manière centralisée. L’utilisation de langages sûrs (qui lèvent des exceptions plutôt que des crashs en cas de null dereference) élimine ce problème.
  14. CWE-121 – Dépassement de Tampon sur la Pile :
    Autre nouveau dans le Top 25 (#14). Ce CWE est une variante spécifique du débordement de buffer, concernant les variables locales stockées sur la pile (stack). Un débordement de pile bien exploité permet d’écraser le pointeur d’instruction de retour d’une fonction et donc de rediriger le flot d’exécution (technique classique d’exploit).
    Remarque : cette faiblesse était auparavant agrégée sous des entrées plus générales, son apparition distincte reflète l’utilisation des données brutes (raw data) sans normalisation dans l’analyse 2025. Score : 5,75 avec 4 CVE dans le KEV.
    Mesures d’atténuation : similaires aux autres débordements (C/C++) : utiliser des fonctions avec contrôle de limites, activer la protection de la pile (canary) et la randomisation de l’espace d’adressage, et tester la robustesse des fonctions récursives ou manipulant de gros tableaux locaux.
  15. CWE-502 – Désérialisation de Données Non Fiables :
    En 15e position (↑1), cette faiblesse concerne les applications qui désérialisent des objets ou données fournis par un acteur externe sans validation suffisante de leur intégrité ou de leur provenance. De nombreux langages (Java, PHP, Python…) permettent de sérialiser/désérialiser des objets complexes; si un attaquant fournit un flux manipulé, il peut instancier des objets inattendus ou malveillants en mémoire. Impacts : exécution de code (via des gadgets de désérialisation connus), modification de données internes, DoS (objet produisant une boucle infinie, surcharge CPU/mémoire). Avec un score de 5,23, elle totalise 11 CVE exploités activement – typiquement des vulnérabilités dans des applications Java non sécurisées ou des bibliothèques de serialisation en PHP. Contremesures : éviter la désérialisation d’entrées non sûres. Utiliser des signatures ou HMAC pour vérifier que les données n’ont pas été altérées si on doit absolument les désérialiser; limiter les classes désérialisables via des whitelists et désactiver les mécanismes d’auto-invocation d’objets durant la désérialisation.
  16. CWE-122 – Dépassement de Tampon sur le Tas (Heap) :
    Classé #16, ce CWE est l’analogue de CWE-121 pour la mémoire dynamique (tas). Un heap overflow signifie qu’un buffer alloué par malloc/&c a été débordé, corrompant potentiellement les structures de gestion du tas ou des données adjacentes.
    Exploitation : plus complexe que sur la pile mais tout aussi puissante – un attaquant peut altérer des pointeurs de fonction stockés dans le tas pour détourner l’exécution, ou provoquer un crash. Ce CWE (score 5,21) n’était pas comptabilisé tel quel auparavant (couvert par la CWE-787), il apparaît suite à l’ajustement de méthodologie 2025.
    Prévention : idem pour la CWE-787/120 – utiliser des langages avec contrôle de limites ou des allocateurs sécurisés, tester les allocations et copier en mémoire de façon sûre. Des mécanismes comme ASLR et les allocateurs de mémoire durcis (glibc mprotect, etc.) compliquent l’exploitation, mais la meilleure approche reste d’éliminer les débordements à la source (vérifications manuelles, analyse statique/dynamique).
  17. CWE-863 – Autorisation Incorrecte :
    Au 17e rang (↑1), cette CWE se distingue de la CWE-862 (Manquante) en ce que le contrôle d’autorisation existe mais est mal implémenté. L’application tente une vérification de droits qui, à cause d’une erreur, ne fonctionne pas correctement, laissant passer des accès non autorisés. Par exemple, l’application vérifie bien le rôle de l’utilisateur pour une ressource donnée, mais pas le bon attribut (ex: contrôle d’un rôle admin au lieu de vérifier qu’il s’agit du bon utilisateur propriétaire de la donnée – autorisation horizontale cassée).
    Conséquences : très proches de la CWE-862 – exposition ou altération de données d’autrui, escalade de privilèges horizontale ou verticale si la faille porte sur une vérification d’admin insuffisante. Ce CWE, de nature assez générale, marque 4,14 de score avec 4 CVE exploités correspondants.
    Mesures : multiplier les points de contrôle – ne pas supposer qu’une vérification précédente suffit, revalider les autorisations à chaque étape critique. Le MITRE recommande notamment de diviser clairement les zones anonymes/usuelles/admin de l’application et d’appliquer des contrôles adaptés sur chacune, tout en évitant de dupliquer la logique d’autorisation dans de multiples endroits au risque d’incohérences.
  18. CWE-20 – Validation d’Entrée Impropre :
    Longtemps omniprésente, cette faiblesse très large tombe au 18e rang en 2025 (↓6), en partie car beaucoup de cas sont désormais classés sous des CWE plus précis. Elle recouvre tout scénario où l’application n’impose pas le format ou les propriétés attendues d’une donnée d’entrée avant de la traiter. C’est souvent la cause première de nombreuses autres failles (injections, débordements, XSS… sont toutes des formes de mauvaise validation).
    Impact : dépend du contexte cela peut conduire à des injections de code, à des dépassements mémoire, à des divulgations de données ou plantages.
    Tendance : son recul (score 4,09, 2 CVE KEV) reflète qu’on catégorise mieux les problèmes spécifiques plutôt que d’utiliser ce fourre-tout.
    Bonne pratique générale : “Tout ce qui est externe est dangereux par défaut.” Il faut définir des critères stricts d’acceptation (taille max, type, format, caractères autorisés, cohérence…) pour chaque paramètre d’entrée. Les entrées ne respectant pas ces règles doivent être rejetées ou corrigées, et surtout ne jamais se fier à la validation côté client uniquement.
  19. CWE-284 – Contrôle d’Accès Impropre :
    Apparaissant pour la première fois au rang #19, cette CWE très général était jusque-là “pillé” (Pillar) et non listé tel quel dans le Top 25. Il indique que le produit n’impose pas les restrictions d’accès attendues à une ressource. Il englobe des problèmes d’autorisations mal configurées (droits trop larges, fichier sensible accessible en lecture/écriture à tous, etc.) ou de mécanismes d’enforcement défaillants.
    Exemple : un fichier de configuration contenant des secrets laissé accessible en mode anonyme, ou une API qui permet à n’importe quel utilisateur authentifié d’accéder à des données d’un autre rôle faute de check.
    Conséquences : Elles sont variables cela peut mener à n’importe quelle faille de sécurité selon la ressource affectée (exfiltration de données, abus de fonctionnalités, exécution de code).
    Conseils : dès la conception, séparer nettement les domaines (utilisateur normal, admin, etc.) et appliquer les contrôles d’accès correspondants pour chaque ressource. Veiller aussi à la bonne configuration des permissions par défaut (pas de “chmod 777” intempestif par exemple) et au durcissement des conteneurs ou espaces où tourne l’application pour limiter l’impact d’une éventuelle faille d’accès.
  20. CWE-200 – Exposition de Données Sensibles à un Acteur Non Autorisé :
    Au 20e rang (↓3), cette faiblesse recouvre les cas où une information sensible se retrouve accessible à quelqu’un qui ne devrait pas y avoir accès. Cela peut provenir d’une fuite directe (p.ex. une API renvoie des données confidentielles en clair à un utilisateur non authentifié) ou indirecte (messages d’erreur trop verbeux révélant des chemins ou des comptes, page de backup laissée accessible, etc.).
    Impact : perte de confidentialité (données personnelles, clés, infos système) avec éventuellement des conséquences légales ou stratégiques majeures.
    Exemples : fuite de logs système, de dumps mémoire ou d’en-têtes contenant des sessions. Son score est modeste (4,01, une seule CVE exploitée connue), car souvent ces cas accompagnent d’autres failles plus concrètes.
    Mesures : appliquer une politique de confidentialité stricte, ne jamais exposer plus d’information que nécessaire. Nettoyer les données sensibles des réponses (masquer les numéros de version, les stack traces), configurer correctement les ACL sur les fichiers et bases de données, et chiffrer les informations sensibles en stockage et en transit pour atténuer l’impact d’une éventuelle fuite.
  21. CWE-306 – Absence d’Authentification pour Fonction Critique :
    En 21e position (↑4), cette faiblesse décrit le fait qu’une fonctionnalité sensible n’est pas protégée par un mécanisme d’authentification. Par exemple, une application expose une API critique (arrêt du service, accès à des données critiques) sans exiger de login, ou un port d’administration n’est pas restreint.
    Conséquence : un attaquant non authentifié peut appeler directement la fonction en question et potentiellement compromettre tout le système, obtenir des privilèges ou causer un déni de service. Cette faille compte 11 CVE exploités (souvent dans des logiciels où une URL cachée admin était accessible publiquement).
    Correctifs : il est impératif de restreindre l’accès aux fonctionnalités critiques aux seuls utilisateurs authentifiés et autorisés. Organiser l’architecture logicielle en zones (anonyme, utilisateur, admin) et imposer une authentification robuste sur les transitions vers les zones à privilèges. Éviter les solutions d’auth “maison” non éprouvées et utiliser les frameworks sécurisés du langage pour gérer les sessions et les droits, afin de ne pas oublier une route ou une action critique non protégée.
  22. CWE-918 – Server-Side Request Forgery (SSRF) :
    En légère baisse (#22, ↓3), le SSRF se produit lorsqu’un serveur web accepte une URL fournie par l’utilisateur et la récupère sans s’assurer qu’elle cible une ressource légitime. L’attaquant abuse d’une fonctionnalité du serveur (par ex. conversion d’URL en aperçu) pour lui faire appeler des adresses internes ou arbitraires.
    Risques : contournement du pare-feu, le serveur agit comme proxy vers l’infrastructure interne (exfiltrer des données du réseau local, scanner des ports internes). Des variantes permettent aussi d’atteindre des fichiers locaux via des schémas file:// ou d’utiliser d’autres protocoles (gopher, ftp) pour des attaques complexes. Le score est de 3,36 (faible) et aucune CVE présente dans la KEV n’est listé, mais cette faille est en réalité très surveillée dans les applications cloud et web modernes.
    Contre-mesures : restreindre drastiquement les adresses et ports accessibles par le serveur : idéalement, n’autoriser que des URL externes validées (allow list) et empêcher l’accès aux adresses locales (127.0.0.1, metadata cloud) dans les requêtes sortantes. Mettre en place des délais et quotas sur ces appels pour limiter les abus.
  23. CWE-77 – Injection de Commande (générique) :
    Cette CWE (rang #23, ↓10, score 3,15) est proche de CWE-78 mais plus général, englobant l’injection de commandes dans des contextes non-OS (p. ex. injection dans un interpréteur propriétaire, un langage de commandes interne). La vulnérabilité est que l’application insère une entrée externe dans une commande ou requête interne sans neutraliser des éléments spéciaux. Par exemple, une appliance réseau avec une interface web acceptant une commande de configuration pourrait être trompée si les entrées ne sont pas nettoyées.
    Impacts : en fonction du contexte de la commande, souvent une exécution non autorisée d’actions ou de code avec compromission du système cible. La forte baisse de cette CWE dans le classement 2025 s’explique : de nombreux CVE auparavant mappés sur CWE-77 sont à présent soit associées à CWE-78 (OS) soit à des variantes plus spécifiques, d’où un recul de 10 places. Il n’en demeure pas moins qu’il existe 2 CVE exploitées en 2024-25 liées à des injections de commandes génériques.
    Parades : analogues à la CWE-78, canaliser au maximum les actions via des API sûres, échapper les métacaractères shell ou spécifiques de l’interpréteur ciblé, et valider le format des arguments attendus (ex: si une commande attend un nom de fichier, refuser tout autre caractère que lettres/chiffres/point).
  24. CWE-639 – Contournement d’Autorisation par Clé Contrôlée par l’Utilisateur :
    Au 24e rang (↑6), ce CWE décrit un cas particulier d’autorisation insuffisante : le système utilise un identifiant fourni par le client pour accéder à une ressource, sans vérifier que cette ressource lui appartient. C’est le classique IDOR (Insecure Direct Object Reference) : par exemple, un URL du type /profil?user=1234 qui renvoie les infos de l’utilisateur #1234, sans contrôle additionnel, permettra à un attaquant authentifié de changer l’ID pour accéder aux données d’autres utilisateurs.
    Conséquences : violation de confidentialité et d’intégrité horizontale – un utilisateur lambda peut voir ou modifier les données d’un autre utilisateur de même niveau. Voire, si un identifiant de rôle ou de statut est deviné, élévation verticale (p.ex. passer role=admin).
    Impact réel : bien que fréquent en tests d’intrusion, une seule CVE présente dans le KEV 2024-2025 y correspond (score 2,62), possiblement parce que beaucoup de rapports IDOR sont corrigés hors CVE dans les applications web.
    Contremesures : ne jamais faire confiance aux identifiants transmis par le client pour appliquer les permissions. Le serveur doit systématiquement vérifier que l’utilisateur authentifié courant a les droits sur l’objet référencé (par ex. si l’ID user 1234 ne correspond pas à sa session, renvoyer une erreur). Utiliser des clés non prévisibles (UUID) peut compliquer les attaques, mais pas remplacer un contrôle d’accès strict.
  25. CWE-770 – Allocation de Ressources Sans Limites ni Throttling :
    Dernière du Top 25 (score 2,54, ↑1). Cette faiblesse se produit lorsqu’une application permet à un acteur de consommer des ressources sans aucune limite ou quota. Par exemple, une API qui ne limite pas le nombre de requêtes qu’un même utilisateur peut faire, ou un système de génération de fichiers qui n’a pas de taille maximale.
    Conséquences : un attaquant peut facilement provoquer un déni de service en épuisant la ressource (CPU, mémoire, descripteurs de fichiers, connexions…). Ce CWE était au-delà du rang 25 l’an dernier (il apparaît à peine maintenant), ce qui indique un focus grandissant sur les vulnérabilités de type DoS applicatif dans les analyses.
    Bonnes pratiques : toujours implémenter des limitations dunombre maximum de requêtes par minute (limitation de débit), de la taille maximale des données traitées, du nombre de fichiers qu’un utilisateur peut créer, etc.. En cas de dépassement, refuser ou retarder les demandes supplémentaires (throttling). Par ailleurs, surveiller l’utilisation des ressources en production permet de repérer des abus et d’y répondre (bannir temporairement une IP qui fait trop de requêtes, …).

Les Grandes Tendances du Classement 2025

Montées notables :
L’édition 2025 révèle la progression marquée des faiblesses liées à l’authentification et l’autorisation. Missing Authorization (CWE-862) gagne 5 places (#4) et Incorrect Authorization (CWE-863) entre dans le top20, ce qui souligne l’attention accrue portée aux problèmes de contrôle d’accès horizontal et vertical.

De plus, plusieurs failles jusqu’alors classées sous des entrées abstraites font leur entrée explicite : c’est le cas des débordements de tampon classiques sur la pile ou le tas (CWE-120, 121, 122) et de Improper Access Control (CWE-284), introduits suite à l’abandon de la normalisation vers la vue simplifiée (View-1003). Leur présence directe dans le Top 25 permet de mieux cerner les causes racines concrètes exploitées dans les CVE.

Au niveau des baisses et sorties :
À l’inverse, on observe le recul des failles très générales ou “dérivées”. Par exemple, Improper Input Validation (CWE-20) perd 6 places (#18) et plusieurs CWE abstraits sortent du Top 25 : Integer Overflow (CWE-190), Missing Authentication (CWE-287), Hard-coded Credentials (CWE-798) etc., qui figuraient en 2024, sont relégués au-delà du rang 30 en 2025. Cette évolution s’explique en partie par les corrections de mapping : au lieu de regrouper les CVE sous un parent générique, le MITRE les attribue désormais aux catégories filles plus spécifiques quand cela est possible. Par exemple, de nombreux CVE autrefois comptés dans CWE-119 (Bufferoverflow générique) se répartissent maintenant entre CWE-120/121/122, faisant mécaniquement chuter CWE-119 du #20 à #39.

Cette tendance reflète une amélioration des pratiques de tri des CVE par les CNAs : moins de regroupements hâtifs et plus de précision dans le choix du CWE comme en témoigne la diminution des mappings vers des CWE “Découragés” au profit de CWE de niveau Base/Variante.

Failles les plus dangereuses :
Le sommet du classement reste dominé par les vulnérabilités web d’injection et de session. Le Cross-Site Scripting, SQL Injection et CSRF forment à nouveau le trio de tête (totalisant à eux seuls plus de 25% du score cumulé du Top 25). Ils apparaissent dans de nombreuses CVE Zero-Day exploitées activement et constituent des vecteurs d’attaque privilégiés pour les compromissions initiales d’applications en ligne.

Parallèlement, les erreurs de gestion mémoire en C/C++ (débordements, use-after-free) restent très présentes 6 de ces CWE figurent dans le Top 25 et continuent d’être exploitées par les attaquants pour l’escalade locale ou l’exécution de code, en particulier sur les logiciels systèmes ou embarqués. L’édition 2025 démontre ainsi qu’en dépit de l’essor des langages mémoire-sécurisés, les logiciels en C/C++ hérités ou performants représentent toujours un terrain fertile pour les exploits.

En résumé, ce Top 25 CWE 2025 valide l’importance de l’hygiène de base en développement sécurisé : protéger rigoureusement les interfaces web contre les injections et les abus de session, et appliquer des contrôles d’accès robustes, tout en éliminant les bogues mémoire dans le code bas-niveau. Les évolutions du classement reflètent plus de précision dans l’analyse des faiblesses, ce qui aide les équipes de sécurité à mieux prioriser les mesures de mitigation sur les points faibles les plus critiques de leurs applications.

Enjoy !

Références

[1] MITRE CWE Top 25 – Most Dangerous Software Weaknesses (2025 Edition) : https://cwe.mitre.org/top25/
[2] MITRE CWE Top 25 Archive – 2025 CWE Top 25 List : https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html
[3] MITRE CWE Top 25 Archive – 2025 Key Insights : https://cwe.mitre.org/top25/archive/2025/2025_key_insights.html
[4] MITRE CWE Top 25 Archive – 2025 Methodology : https://cwe.mitre.org/top25/archive/2025/2025_methodology.html