Pourquoi attendre la publication d'une CVE est déjà trop tard

La plupart des organisations ont une gestion de vulnérabilités se basant sur un processus simple : une nouvelle CVE est publiée, elle entre dans les outils de veille, on la compare à son inventaire, puis on décide s’il faut corriger.

Le problème tient dans le mot « nouvelle ».

Une vulnérabilité n’est pas nécessairement nouvelle lorsque sa fiche CVE apparaît. Elle peut déjà avoir été décrite par l’éditeur, corrigée dans une version, documentée avec une preuve de concept ou même exploitée dans des attaques réelles.

Le programme CVE le précise lui-même : CVE n’est pas une base de données de vulnérabilités. C’est avant tout un mécanisme d’identification commun qui permet à plusieurs personnes et outils de parler du même problème. Cette fonction est indispensable, mais elle ne garantit pas que la fiche CVE constitue le premier signal public.

Deux événements récents autour de Traefik et MikroTik illustrent deux façons très différentes de se retrouver en retard lorsque la veille commence uniquement à la publication d’une CVE.

Traefik : tout était public, sauf la CVE

Le 21 août 2026, l’équipe Traefik publie dans son propre dépôt GitHub l’avis de sécurité GHSA-5w68-77r2-r64c. Il décrit un contournement complet du middleware digestAuth, évalué à 9,3 avec CVSS v4.0.

La vulnérabilité est particulièrement directe. Lorsqu’un utilisateur inconnu tente de s’authentifier, Traefik transmet une chaîne vide à la bibliothèque d’authentification au lieu de refuser immédiatement cet utilisateur. Après avoir récupéré le challenge HTTP Digest dans une première requête, un attaquant peut donc calculer la réponse attendue et accéder à la route protégée avec un nom d’utilisateur arbitraire, sans mot de passe.

L’avis ne se contente pas d’un résumé. Il contient :

les versions affectées, jusqu’à la 2.11.54 et de la 3.0.0 à la 3.7.10
les versions corrigées, 2.11.55 et 3.7.11
l’explication de la cause technique
une reproduction complète en deux requêtes
les conséquences possibles sur les routes protégées, le tableau de bord, l’API et l’identité transmise au backend

Autrement dit, le 21 août, un administrateur disposait déjà de tout ce dont il avait besoin pour vérifier son exposition et corriger.

Pourtant, la fiche CVE-2026-85595 n’a été publiée que le 4 septembre 2026, soit quatorze jours plus tard.

Pendant ces deux semaines, un processus limité aux nouvelles CVE n’avait aucun identifiant à rapprocher de l’inventaire. Le correctif et la preuve de concept existaient, mais le signal se trouvait dans l’avis de sécurité du projet, pas encore dans le flux CVE.

Ce premier cas est le plus simple : la source officielle avait déjà publié une alerte complète, structurée et directement exploitable par une équipe défensive.

MikroTik : le patch lui-même devient le signal

Le cas MikroTik est différent, et plus délicat.

Le 3 septembre 2026, MikroTik publie le même jour RouterOS 7.23.4, 7.24.2 et 6.49.21. Les annonces comportent un avertissement inhabituel : il s’agit d’une mise à jour de sécurité importante, la mise à niveau est fortement recommandée, mais les détails ne sont pas encore communiqués afin de laisser du temps aux utilisateurs pour appliquer les correctifs.

À cet instant, il n’y a pas encore de description technique détaillée ni de CVE publique à intégrer dans un scanner. Il existe néanmoins un signal opérationnel fort : plusieurs branches maintenues reçoivent le même correctif de sécurité en même temps, avec une recommandation explicite de mise à jour.

Le 4 septembre, le chercheur Nick Pratley publie une analyse comparative des versions 7.23.3 et 7.23.4. En étudiant les différences entre les binaires, il identifie notamment :

une nouvelle validation des paramètres transmis au processus de connexion SSH
un durcissement de la vérification des signatures RSA
la correction d’un débordement de pile dans le composant mtget, déclenchable via un chemin TFTP trop long

Ses tests reproduisent plusieurs impacts, dont une élévation de privilèges après l’acceptation du nom d’utilisateur -2, ainsi qu’un contrôle du pointeur d’instruction dans mtget permettant de démontrer l’exécution d’un appel ROP.

Cette analyse apporte aussi une nuance importante. Elle ne démontre pas, à elle seule, une chaîne universelle permettant à n’importe quel attaquant d’obtenir un accès administrateur sans identifiants. Le chemin utilisant -2 nécessite d’abord que SSH accepte cette identité. Dans son laboratoire, le chercheur a dû utiliser un serveur RADIUS contrôlé pour atteindre cette étape. Une veille utile ne doit donc pas seulement détecter rapidement une publication. Elle doit également distinguer ce qui est démontré, ce qui dépend d’une précondition et ce qui reste affirmé par une autre source.

Le 5 septembre, CERT Polska publie six vulnérabilités RouterOS, dont CVE-2026-67276 et CVE-2026-86060. Le CERT indique que la combinaison de deux vulnérabilités, baptisée « MikroTrick », permet une prise de contrôle sans authentification lorsque SSH est accessible à distance. Il confirme également des attaques contre des équipements exposés sur Internet depuis au moins le 2 septembre, donc avant la publication détaillée des CVE.

Les correctifs étaient disponibles dans RouterOS 7.25beta3, 7.24.2, 7.23.4 et 6.49.21. CERT Polska recommandait aussi de rechercher un utilisateur privilégié inattendu nommé ops, des événements attribués à ssh:-2@<adresse> et l’indicateur flagged ajouté par RouterOS sur certains équipements compromis.

Ici, attendre la CVE ne signifiait pas seulement découvrir le problème après le correctif. Cela signifiait le découvrir après le début de l’exploitation observée.

Une CVE est un identifiant, pas un signal de nouveauté

Ces deux cas ne remettent pas en cause l’intérêt des CVE. Sans identifiant commun, il serait beaucoup plus difficile de corréler un avis éditeur, un bulletin CERT, une alerte d’un scanner, un exploit public et un équipement présent dans un inventaire.

Mais il faut utiliser la CVE pour ce qu’elle est : une couche de normalisation et de corrélation.

Elle n’est pas systématiquement :

le premier endroit où une vulnérabilité devient publique
le premier endroit où un correctif est annoncé
la meilleure source pour comprendre les prérequis réels
une confirmation de l’exploitation active
une réponse à la question « sommes-nous réellement exposés ? »

La chronologie peut prendre plusieurs formes :

avis éditeur, puis correctif, puis CVE
correctif silencieux, puis analyse du patch, puis CVE
CVE réservée mais détails encore absents
CVE publiée, puis avis enrichi plus tard avec une exploitation active ou de nouveaux périmètres affectés

Dans tous les cas, une collecte centrée sur un seul flux voit seulement une partie de l’histoire.

Ce qu’une veille de vulnérabilités doit surveiller

La réponse consiste à faire travailler plusieurs couches complémentaires.

1. Les sources amont

Il faut surveiller les canaux contrôlés par les éditeurs et les projets concernés :

PSIRT et pages d’avis de sécurité
flux RSS, Atom ou CSAF officiels
GitHub Security Advisories publiés dans les dépôts des mainteneurs
canaux de correctifs explicitement utilisés pour les alertes de sécurité

Ces sources peuvent fournir le premier signal, parfois avant tout identifiant CVE.

Une modification de page ou une nouvelle version ne constitue cependant pas automatiquement une alerte. Le canal doit être légitime, le contenu doit concerner la sécurité et la publication doit être ouverte puis qualifiée avant d’en tirer une conclusion.

2. Les flux CVE et les enrichissements

Les flux CVE restent nécessaires pour normaliser les informations, dédupliquer les signalements et relier les données issues de plusieurs acteurs.

Ils doivent être complétés par des sources telles que les bulletins CERT, les catalogues de vulnérabilités exploitées, les probabilités d’exploitation et la surveillance des preuves de concept publiques. Chaque source répond à une question différente. Une entrée dans un catalogue d’exploitation connue n’a pas la même valeur qu’un score théorique ou qu’un dépôt contenant simplement le nom d’une CVE.

3. La qualification humaine

Collecter plus de sources sans méthode produit surtout plus de bruit.

Chaque signal pertinent doit être qualifié :

quel produit et quel composant sont concernés
quelles versions sont affectées et corrigées
quel service doit être exposé
faut-il un compte, une configuration particulière ou une interaction
existe-t-il un correctif ou une mesure temporaire
la source confirme-t-elle une exploitation, ou ne se prononce-t-elle pas
la preuve de concept démontre-t-elle réellement l’impact annoncé

Le cas MikroTik montre précisément pourquoi cette étape est indispensable. Une publication indépendante peut révéler très tôt la nature d’un correctif tout en laissant une partie de la chaîne non démontrée. Le bulletin du CERT apporte ensuite une confirmation d’exploitation, mais ne publie pas nécessairement tous les détails techniques. Ces informations sont complémentaires, pas interchangeables.

4. Le contexte de l’organisation

Enfin, une vulnérabilité critique n’est actionnable que lorsqu’elle est rapprochée de l’environnement réel :

le produit est-il utilisé
la version déployée est-elle concernée
la fonctionnalité vulnérable est-elle activée
le service est-il accessible depuis Internet ou depuis une zone à risque
l’équipement donne-t-il accès à des actifs critiques

C’est ce contexte qui permet de transformer une publication de sécurité en décision de remédiation.

Comment nous abordons cette veille chez NevaSec

Notre veille ne commence pas et ne s’arrête pas à la liste des nouvelles CVE.

Nous séparons plusieurs workflows :

une surveillance des avis amont, pour détecter les publications nouvelles ou révisées des éditeurs et projets suivis
un triage des CVE, pour normaliser, dédupliquer et analyser les vulnérabilités qui correspondent aux technologies réellement présentes chez nos clients
une veille distincte sur l’exploitation active, les catalogues KEV et la maturité des preuves de concept
une qualification humaine des prérequis, de l’exposition et de la portée réelle de chaque signal

L’objectif n’est pas d’accumuler le plus grand nombre d’alertes. Il est de détecter suffisamment tôt les événements pertinents, puis de répondre à quatre questions simples : nos clients sont-ils concernés, exposés, quel est le risque maintenant et quelle action doit passer en premier ?

Cette logique alimente notre approche du Vulnerability Operations Center, un terme qui peut sembler être un nouveau buzzword à la mode mais qui va devenir essentiel pour traiter le flux de vulnérabilités grandissant.