Aller au contenu
Le journal

Notes & retours d’expérience

Trop de failles à trier : comment une PME priorise ses correctifs

10 min de lecture

Une mise à jour Debian à 1 313 CVE, 948 exploits du noyau Linux produits par une IA, des correctifs plus souvent contournés : une petite équipe ne peut plus tout patcher. La grille en quatre questions de la CISA, le bon usage d'EPSS et du CERT-FR, et le plan de tri d'une PME.

Le 29 septembre, Debian a publié une seule mise à jour de son noyau Linux qui corrige 1 313 identifiants CVE. Le 4 novembre, OpenAI a décrit une campagne automatisée qui a produit 948 exploits fonctionnels contre le noyau, pour environ 1,2 million de dollars de crédits d'API. Le 6 octobre, IBM et Red Hat annonçaient plus de 400 failles inédites corrigées dans des bibliothèques Java, sans en publier la liste. Et pendant ce temps, PHP, WordPress, le noyau Linux et OpenSSH ont chacun eu leur faille critique en moins de trois semaines.

Pour une PME, la question n'est plus « faut-il patcher ? », mais « par quoi commencer, quand on ne peut pas tout faire cette semaine ? ». Cet article s'adresse à un confrère CTO ou responsable technique d'une petite équipe : la méthode de tri que j'applique, appuyée sur une grille publiée en juin par l'agence américaine de cybersécurité, et sur ce que j'ai vérifié cette semaine.

Le volume a changé d'échelle

Les chiffres de l'automne ne disent pas tous la même chose, mais ils vont dans le même sens.

  • Debian, DSA-6528-1. Une mise à jour du noyau de Debian 13 liste 1 313 CVE. Selon un décompte publié par l'analyste P. K. Sharma, c'est presque autant que les 17 avis noyau précédents de cette version réunis, et aucune de ces failles n'était inscrite au catalogue des vulnérabilités exploitées de la CISA au 4 octobre. Ce nombre compte des identifiants, pas un niveau de risque.
  • OpenAI, 948 élévations de privilèges. Dans un billet du 4 novembre, OpenAI explique que son pipeline a reproduit 1 724 vulnérabilités du noyau et produit 948 exploits permettant à un utilisateur local sans droits de devenir administrateur, pour 1 279 dollars par exploit en moyenne. La société note elle-même que le goulet d'étranglement n'est plus la découverte, mais le tri et la validation.
  • XBOW, une chaîne complète contre Chrome. La société XBOW affirme avoir construit en six jours, du 2 au 7 août, une chaîne d'exploits qui sort Chrome de ses bacs à sable sous Windows, avec un modèle d'OpenAI accessible à tous, pour environ 40 000 dollars de calcul. Google lui a versé 250 000 dollars. XBOW précise que l'expertise de ses chercheurs a compté, mais conclut : la barre est nettement plus basse.
  • Lightwell, 400 failles sans nom. IBM et Red Hat disent avoir corrigé plus de 400 failles inédites dans des bibliothèques Java, sans publier ni les bibliothèques ni les CVE, relève Help Net Security : impossible de les rapprocher de son inventaire.

Côté français, le CERT-FR en est à l'avis CERTFR-2026-AVI-1486, publié le 9 novembre, contre 15 alertes sur l'année. FIRST, qui publie le score EPSS, compte environ 61 000 CVE publiées sur les douze derniers mois. Aucune petite équipe ne lit tout cela. Il faut donc une règle de tri, écrite à l'avance.

Le correctif n'est plus la ligne d'arrivée

Deuxième changement : un correctif appliqué ne clôt plus forcément le sujet. La start-up de tests d'intrusion Terra Security a passé en revue les CVE et les avis de sécurité de GitHub. Selon elle, la part des correctifs suivis, dans les 90 jours, d'un nouvel avis signalant qu'ils étaient incomplets ou contournables est passée d'environ 0,2 % entre 2019 et 2025 à 2,3 % en 2026. Toujours selon Terra, les failles dont le correctif a été contourné sont environ quatre fois plus souvent inscrites au catalogue de la CISA que les autres failles des mêmes éditeurs. Ce sont les chiffres d'un éditeur, rapportés par The Register le 19 octobre, mais la conséquence est simple : sur une faille exploitée, surveillez les avis de suivi après avoir patché.

Le score CVSS ne suffit pas pour trier

Le réflexe le plus courant reste de trier par score CVSS : on corrige les « critiques », puis les « élevées ». Le cas de CVE-2026-98432 montre les limites de l'exercice. C'est une faille du noyau Linux dans le traitement des connexions TCP en IPv4, atteignable à distance sans authentification. L'équipe CVE du noyau la note 9,8 sur 10. Red Hat l'avait d'abord classée « modérée » à 5,9, avant de remonter à 9,8. Amazon Linux la note 8,1. Trois chiffres pour le même bogue, selon The Hacker News. Elle ne figurait pas au catalogue des vulnérabilités exploitées de la CISA dans sa version du 9 novembre, que j'ai consultée.

La spécification CVSS 4.0 le dit elle-même : le score de base décrit la gravité intrinsèque d'une faille, et c'est à l'utilisateur de l'enrichir avec les menaces et son propre environnement. FIRST ajoute un ordre de grandeur : un peu plus de 10 % des CVE publiées sur un an sont notées « critiques », et les notes « élevées » ou plus couvrent environ 48 % du total. Trier par CVSS, c'est se donner une liste aussi longue que celle qu'on cherchait à réduire.

Quatre questions plutôt qu'un score

Le 10 juin, la CISA a publié la directive BOD 26-04, Prioritizing Security Updates Based on Risk. Elle s'impose aux agences fédérales américaines, pas aux entreprises françaises. Mais elle a un mérite rare : elle remplace un score par quatre questions binaires, issues de la méthode SSVC du CERT/CC.

  1. L'actif est-il exposé ? Joignable sans compte depuis un réseau public.
  2. La faille est-elle au catalogue KEV ? Le catalogue des vulnérabilités dont la CISA a confirmé l'exploitation.
  3. L'exploitation est-elle automatisable ? Un attaquant peut-il enchaîner repérage, préparation, livraison et exploitation sans intervention humaine ?
  4. L'impact est-il total ? L'attaquant prend-il le contrôle complet de l'actif, ou récupère-t-il toutes ses données ?

Les réponses donnent un délai, en jours calendaires : trois jours avec recherche de compromission, trois jours, 14 jours, 60 jours, ou « à la prochaine mise à niveau ». Deux détails sont précieux pour une PME. Les réponses aux questions 2 à 4 sont publiées gratuitement par la CISA dans les fiches CVE, via son programme Vulnrichment, quand elles existent. Et le délai bouge avec les faits : retirer un serveur d'Internet l'allonge, une inscription au KEV le raccourcit.

Schéma : trier une faille en quatre questions selon la grille BOD 26-04 de la CISA, exposition à Internet, inscription au catalogue KEV, exploitation automatisable et contrôle total, et les délais qui en découlent, de trois jours avec recherche de compromission jusqu'à la prochaine mise à niveau

La grille de la CISA en une page. Les délais sont ceux imposés aux agences fédérales américaines ; pour une PME, c'est un étalon de départ.

Appliquée aux failles du moment, la grille donne des réponses nettes.

OpenSSH, « SSHole » (CVE-2026-123158). Sur les systèmes construits avec la bibliothèque musl et sans PAM, Alpine Linux en tête, un compte dont le mot de passe est verrouillé par « * » peut être ouvert avec un mot de passe de plus de 257 caractères, selon l'annonce publiée sur oss-security. La configuration est étroite. Pourtant, la faille est entrée au KEV le 9 novembre, avec une échéance au 12 novembre, et le CERT-FR en a fait une alerte. Les données Vulnrichment la décrivent comme exploitée, non automatisable, à impact total. Sur un serveur SSH ouvert sur Internet : trois jours et recherche de compromission. Sur un serveur joignable uniquement par VPN : 14 jours. La mesure de contournement, PasswordAuthentication no, s'applique en quelques minutes.

Noyau Linux, CVE-2026-98432. Hors KEV, exposée dès qu'un port TCP écoute, impact total si l'exécution de code se confirme. Pas de données Vulnrichment à ce jour. La grille donne 14 jours, ou trois si l'on considère l'exploitation automatisable. Selon The Hacker News, Anthropic affirme qu'un modèle interne a écrit un exploit donnant un accès administrateur à distance sur des serveurs qui exposent un service MPTCP, sans publier le code. Dans le doute, je retiens trois jours pour les serveurs exposés, redémarrage compris : un noyau installé mais pas chargé ne protège rien.

PHP php2shell et WordPress CVE-2026-119977. Les deux sont au KEV, depuis le 26 octobre et le 3 novembre, et touchent des sites exposés par définition. C'est la case du haut, ce que j'ai détaillé dans l'article sur php2shell et dans celui sur WordPress.

EPSS pour tout ce que le KEV ne couvre pas

Le KEV est court par construction : un peu moins de 300 entrées ajoutées depuis le 1er janvier 2026, d'après le fichier de la CISA. Pour le reste, FIRST publie chaque jour le score EPSS, la probabilité estimée qu'une CVE soit exploitée dans les 30 jours. Le guide d'utilisation donne des repères utiles : le taux de base d'exploitation tourne autour de 2 à 3 % ; un seuil de 50 % ne retiendrait presque rien ; un seuil autour de 4 %, soit environ le 90e percentile, représente à peu près le même volume que les « critiques » CVSS, mais choisi d'après des signaux d'exploitation.

FIRST insiste aussi sur deux pièges. EPSS ne connaît pas votre environnement : un score élevé sur un logiciel que vous n'avez pas, ou qui n'est pas joignable, ne change rien. Et un score faible sur une faille inscrite au KEV n'est pas une contradiction : le KEV l'emporte. Au 9 novembre, SSHole et la faille WordPress avaient un score EPSS proche de 1 %, alors qu'elles sont toutes deux au KEV ; la faille php2shell CVE-2026-109618 était à 99,999 %.

Alerte ou avis : lire le CERT-FR

Pour une équipe française, le CERT-FR apporte un tri déjà fait. Ses alertes sont, selon sa propre définition, des documents « destinés à prévenir d'un danger immédiat ». Ses avis font « état de vulnérabilités et des moyens de s'en prémunir ». En 2026, cela fait une quinzaine d'alertes contre plus de 1 400 avis. Une alerte qui touche un logiciel que vous exploitez se traite comme une entrée du KEV. Un avis entre dans la file normale, et passe par la grille.

Ce que vendent les outils

Les grands fournisseurs ont compris que le tri devient le problème. AWS a rendu disponible le 22 octobre Continuum for code vulnerabilities, qui dit vérifier si une faille est atteignable dans votre environnement, la reproduire dans un bac à sable et la classer selon sa proximité avec vos systèmes critiques. Ce sont des promesses commerciales, à juger sur pièces. Mais les questions automatisées sont celles de la grille : le composant est-il déployé, joignable, et que touche-t-il ? Une PME peut y répondre sans outil, à condition d'avoir un inventaire.

Le plan d'action pour une PME

1. Savoir ce qui est exposé

  • Une liste des actifs joignables depuis Internet : domaines, adresses IP, services, avec pour chacun l'environnement (production ou test) et un responsable. C'est la première question de la grille, et la seule à laquelle personne d'autre ne répondra pour vous.
  • L'inventaire des composants : runtimes, CMS, bibliothèques, images Docker, comme dans la routine de mise à jour des runtimes. Si vous livrez un logiciel, un SBOM généré à chaque version, comme évoqué dans l'article sur la chaîne d'approvisionnement.

2. Brancher trois flux, pas trente

  • Le catalogue KEV, par courriel ou en récupérant son fichier JSON chaque jour, filtré sur vos éditeurs.
  • Les alertes du CERT-FR, et les avis pour les produits que vous exploitez.
  • Les annonces de vos éditeurs critiques : CMS, runtimes, pare-feu, VPN.

3. Écrire sa grille, avec des délais tenables

Voici celle que je propose, inspirée de la BOD 26-04. C'est une règle de travail, pas une norme.

  • KEV ou alerte CERT-FR, sur un actif exposé : sous 72 heures, avec recherche de traces.
  • Exposé et impact total, hors KEV : dans la semaine.
  • Le reste, trié par EPSS : dans le cycle mensuel, en commençant au-dessus d'environ 4 %.
  • Non exposé, non automatisable : à la prochaine mise à niveau planifiée.

4. Contourner quand le correctif tarde

Une mesure de contournement donne du temps, comme le prévoit la directive : couper l'authentification par mot de passe sur SSH, filtrer les options IPv4 comme le propose Red Hat pour CVE-2026-98432, retirer un service d'Internet. Notez-la, avec une date de retrait.

5. Vérifier, puis revenir

  • Contrôler la version qui tourne réellement, pas celle qui est installée : redémarrage du noyau, rechargement de PHP-FPM, reconstruction des images.
  • Pour une faille exploitée, surveiller les avis de suivi pendant les semaines qui suivent : c'est là que se concentrent les correctifs contournés, selon Terra.

6. Si vous éditez un logiciel : le CRA s'applique déjà

Depuis le 11 septembre 2026, le Cyber Resilience Act oblige les fabricants de produits comportant des éléments numériques à signaler les vulnérabilités activement exploitées via la plateforme unique de l'ENISA : une alerte précoce sous 24 heures, une notification sous 72 heures, un rapport final au plus tard 14 jours après la mise à disposition d'un correctif. Pour un éditeur, le tri n'est plus seulement une affaire interne : il faut savoir, en moins d'une journée, si une faille exploitée touche votre produit.

Une revue de trente minutes par semaine suffit ensuite : nouvelles entrées KEV et alertes qui vous concernent, délais tenus ou non, contournements à retirer.

Ce qu'il faut retenir

L'IA rend la découverte de failles bon marché ; elle ne rend pas leur correction plus rapide chez vous. Une petite équipe ne gagnera pas la course au volume. Elle peut en revanche décider, avant la prochaine vague, de ce qui passe en premier : exposé, exploité, automatisable, impact total. Le reste attend son tour, et c'est très bien ainsi.

Si vous voulez valider votre grille, trier une liste de failles qui vous dépasse ou cadrer l'urgence d'une alerte, c'est exactement le format de l'avis CTO en 30 minutes. Pour un site PHP ou WordPress à remettre d'aplomb, voir aussi la remise en route WordPress et PHP et, côté Node, la sécurisation et mise à niveau Node.js.

Sources

Retour au journalEn parler ensemble
Tout le journal