CVE-2026-86419 touche MISP, la plateforme open source de partage de renseignement sur les menaces utilisée par une grande partie des CERT, CSIRT, SOC et communautés sectorielles de partage. Notée CVSS 9.1, elle affecte toutes les versions jusqu'à 2.5.45.
Ce qui rend cette CVE intéressante au-delà de sa gravité, c'est la qualité de sa description : l'équipe MISP a documenté non seulement la faille, mais chaque contournement que son ancienne défense laissait passer. Pour quiconque écrit du code qui effectue des requêtes sortantes vers des URL fournies par des utilisateurs, c'est une liste de contrôle rare.
La vulnérabilité
| Champ | Valeur |
|---|---|
| CVE | CVE-2026-86419 |
| CVSS 3.1 | 9.1 (CRITICAL) |
| Vecteur | AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H |
| Type | SSRF + transmission d'identifiants lors de redirections |
| Versions affectées | ≤ 2.5.45 |
| Publication NVD | 2026-09-07 |
Le PR:L indique qu'il faut un compte capable de configurer des flux ou une découverte TAXII. Le S:C (scope changed) traduit le fait que l'impact porte sur des systèmes au-delà de MISP : le réseau interne atteint par SSRF, et les partenaires dont les identifiants fuient.
Deux défauts distincts
1. Récupération des flux : les redirections suivies aveuglément
In feed processing, redirects were followed without validating the redirect scheme or destination. The original request headers were reused across redirect hops, meaning authentication headers or API credentials configured for a feed could be forwarded to a different host. Redirects could also target internal network resources, resulting in SSRF.
Deux problèmes dans une même phrase.
La fuite d'identifiants. Un flux MISP est souvent authentifié : clé API d'un partenaire, jeton d'une plateforme commerciale de renseignement. Si le serveur du flux répond par une redirection vers un autre hôte, MISP suivait la redirection en renvoyant les mêmes en-têtes, identifiants compris. Il suffit donc de contrôler — ou de compromettre — une URL de flux pour récupérer les identifiants que l'instance y présente.
La SSRF. Une redirection vers http://169.254.169.254/ ou vers un service interne faisait émettre la requête par MISP, depuis l'intérieur du réseau.
2. Découverte TAXII : une défense par liste incomplète
The TAXII discovery endpoint had a related incomplete SSRF defense. It used
gethostbyname()and compared the result against only a few literal addresses. This missed cases including IPv6 loopback (::1), numeric host encodings such as0x7f000001, and potentially multiple DNS records.
C'est la partie la plus instructive. Il y avait une protection — elle ne tenait pas, et la description énumère exactement pourquoi :
| Contournement | Pourquoi il passait |
|---|---|
::1 | gethostbyname() ne traite que l'IPv4 ; la boucle locale IPv6 échappait à la comparaison |
0x7f000001 | c'est 127.0.0.1 écrit en hexadécimal ; une comparaison de chaînes ne le reconnaît pas |
| Plusieurs enregistrements DNS | un nom qui résout vers une adresse publique et une adresse interne ; vérifier la première ne dit rien des autres |
Toutes ces erreurs ont la même racine : comparer à une liste d'adresses interdites écrites en clair plutôt que de classer l'adresse résolue par plage réseau.
Ce que dit le correctif — et pourquoi il faut le lire
La description détaille les changements :
The fix adds redirect validation, blocks internal destinations for cross-host redirects, strips configured feed credentials before following redirects to another host, and pins validated DNS results to prevent re-resolution after validation. [...] The fix moves TAXII discovery to the shared URL egress validator.
Chaque point correspond à une règle générale :
- Valider chaque saut de redirection, pas seulement l'URL initiale
- Retirer les identifiants dès que la redirection change d'hôte — c'est le comportement par défaut des navigateurs, pas celui de toutes les bibliothèques HTTP
- Épingler le résultat DNS validé : sans cela, un attaquant qui contrôle son DNS répond une adresse publique au moment de la vérification, puis une adresse interne au moment de la connexion (DNS rebinding)
- Un seul validateur partagé pour toutes les requêtes sortantes, au lieu d'une protection réimplémentée différemment à chaque endroit
Ce dernier point est celui qui empêche la prochaine faille. Le défaut TAXII existait précisément parce qu'un second chemin de requête sortante avait sa propre défense, moins bonne.
Pourquoi la cible est sensible
Une instance MISP n'est pas un serveur comme un autre :
- Elle détient les identifiants d'accès aux flux de partenaires et de fournisseurs commerciaux
- Elle est connectée à d'autres instances MISP de la communauté de partage, avec des clés de synchronisation
- Elle est souvent placée dans le réseau du SOC, avec un accès vers les outils de détection
- Elle contient du renseignement non public : indicateurs d'incidents en cours, informations partagées sous conditions (TLP)
Une fuite d'identifiants de flux n'expose donc pas seulement ton organisation : elle expose tes partenaires, qui t'ont confié un accès.
Versions et vérification
| Produit | Versions affectées |
|---|---|
| MISP | ≤ 2.5.45 |
NVD n'expose pas de numéro de version corrigée : passe à une version postérieure à 2.5.45 en suivant les notes de publication du projet MISP.
# Version de l'instance
cat /var/www/MISP/VERSION.json
Interface : Administration → Server Settings & Maintenance
Détection
- Journaux d'accès des flux : réponses de redirection (
301,302,307,308) depuis des serveurs de flux qui n'en renvoient pas habituellement - Requêtes sortantes du serveur MISP vers des adresses internes,
169.254.169.254ou des hôtes non déclarés comme sources de flux - Flux ou serveurs TAXII ajoutés récemment par des comptes qui n'ont pas vocation à le faire
- Utilisation anormale de tes clés de flux côté partenaires — à leur demander si tu soupçonnes une fuite
Mitigation
1. Mettre à jour au-delà de 2.5.45
C'est le seul correctif complet.
2. Restreindre qui peut configurer des flux
Le prérequis PR:L est ton levier : limite la création et la modification de flux et de connexions TAXII à un petit nombre d'administrateurs.
3. Filtrer les sorties réseau
Le serveur MISP devrait ne pouvoir joindre que les sources de flux déclarées et les instances de synchronisation. Un filtrage en sortie — pare-feu ou proxy — neutralise la SSRF indépendamment du code.
4. Si tu soupçonnes une fuite d'identifiants
Fais tourner toutes les clés de flux et de synchronisation, et préviens les partenaires concernés. C'est une obligation de confiance envers la communauté de partage autant qu'une mesure technique.
Pourquoi surveiller en continu vos outils de sécurité
Les plateformes de sécurité — MISP, SIEM, SOAR, outils de gestion des vulnérabilités — sont rarement traitées comme des surfaces d'attaque par les équipes qui les exploitent. Elles détiennent pourtant les identifiants les plus sensibles de l'organisation et, dans le cas de MISP, ceux de ses partenaires.
Avec cveo.tech, inventorie tes outils de sécurité avec leur version exacte, et reçois une alerte automatique dès qu'une CVE critique les concerne — y compris celles qui visent les outils censés te protéger.