Triage CVSS isolée : 13 000 firewalls Palo Alto compromis

CVSS 6.5 + CVSS 7.0, ça donne quoi quand on les enchaîne ? Réponse en avril 2026 : root sur 13 000 firewalls Palo Alto exposés sur Internet, pendant que des équipes de sécurité triaient tranquillement leurs tickets P2 par ordre alphabétique. La compromission Lunar Peek n'est pas un échec technique — c'est l'échec d'une méthode. La triage par score CVSS isolé, doctrine dominante depuis dix ans dans la majorité des SOC et des équipes vulnerability management, vient de recevoir une gifle publique d'une ampleur rarissime. Ce n'est pas un cas isolé, c'est un signal. Et ce signal dit que si vous continuez à trier vos CVE par score décroissant en 2026, vous organisez votre propre compromission. Voici pourquoi, et ce qu'il faut mettre en place à la place.

Lunar Peek : autopsie d'une compromission à 13 000 firewalls

En novembre 2024, deux CVE sont publiées pour les firewalls Palo Alto Networks PAN-OS. CVE-2024-0012, un auth bypass sur l'interface de management web, scorée CVSS 9.3. CVE-2024-9474, une escalade de privilèges locaux, scorée CVSS 6.9. Prise isolément, CVE-2024-9474 passe sous le seuil de patch immédiat dans la plupart des organisations. Elle exige en effet un compte administrateur authentifié pour être exploitée — donc, logiquement, elle est considérée à risque modéré.

Sauf que CVE-2024-0012 élimine précisément ce prérequis. L'enchaînement est trivial : on bypass l'authentification avec la première CVE, puis on escalade en root avec la seconde. Résultat final : accès root complet sur le firewall, possibilité d'exfiltrer les configurations, d'installer un implant persistant, de modifier les règles de filtrage, ou de pivoter vers l'ensemble du périmètre interne que le firewall est censé protéger.

Le groupe Lunar Peek — identifié par Palo Alto Unit 42 comme un acteur à motivation d'espionnage — a exploité cette chaîne de manière automatisée. Les logs d'exploitation analysés a posteriori montrent des patterns de scan de masse suivis d'une exploitation en moins de deux minutes par cible. À la date du rapport d'incident, 13 000 interfaces de management Palo Alto exposées sur Internet avaient été compromises. Pas 13. Pas 130. 13 000.

La question que chaque RSSI devrait se poser : est-ce que mon équipe vulnerability management aurait priorisé CVE-2024-9474 en P1 sur la base d'un score CVSS 6.9 ? Dans neuf cas sur dix, la réponse honnête est non. Et c'est exactement le problème.

Pourquoi la grille classique craque structurellement en 2026

Trois facteurs se conjuguent pour rendre la triage isolée par CVSS structurellement obsolète. Et aucun de ces facteurs n'est conjoncturel — ils s'inscrivent dans des tendances de fond.

Facteur 1 : l'effondrement du délai disclosure-to-exploit. En 2020, le délai moyen entre la publication d'un CVE et son exploitation active était de 28 jours selon l'analyse Kenna Security / Cyentia Institute. En 2023, Log4Shell avait montré qu'il pouvait tomber sous 24 heures pour les vulnérabilités très exposées. En 2026, LMDeploy (CVE-2026-xxxxx) a été exploité 13 heures après publication de l'advisory. Marimo, 9h41. BlueHammer a été exploité avant même la disponibilité du patch.

Ces chiffres ne sont pas des anomalies. Ils sont la conséquence logique de deux évolutions : d'abord, les advisories publics sont de plus en plus détaillés techniquement (endpoint exact, condition de déclenchement, version vulnérable), ce qui facilite la rétro-ingénierie. Ensuite, les LLM permettent maintenant de transformer une description technique en preuve de concept fonctionnelle en quelques heures. L'attaquant qui construit un exploit en 2026 ne lit plus un PDF d'advisory — il pilote un assistant qui écrit le payload.

Facteur 2 : l'industrialisation du chaînage de vulnérabilités. Là où l'exploitation de chaînes CVE nécessitait autrefois une expertise manuelle significative, des frameworks publics intègrent désormais des templates de chaining. Metasploit, ProjectDiscovery Nuclei, et des outils privés vendus sur des forums spécialisés permettent d'enchaîner des vulnérabilités en quelques commandes. Une combinaison auth bypass + LFI + RCE peut devenir un one-liner accessible à n'importe quel script-kiddie avec une carte de crédit et un accès à un market d'accès initial.

Facteur 3 : les outils de sécurité eux-mêmes sont devenus des surfaces d'attaque prioritaires. Microsoft Defender a cumulé trois zero-days en 48 heures en avril 2026, dont deux sans patch disponible. CrowdStrike LogScale a eu sa CVE 9.x. Un agent EDR compromis sur un endpoint est pire qu'aucun EDR : il donne à l'attaquant des privilèges système et une visibilité complète sur l'activité de la machine. La séparation conceptuelle entre l'outil qui protège et la surface à protéger ne tient plus dès lors que les éditeurs de sécurité sont des cibles comme les autres.

Trois exemples réels de chaînes CVE exploitées en 2025-2026

Chaîne 1 — Ivanti Connect Secure (janvier 2025). CVE-2025-0282 (stack overflow pre-auth, CVSS 9.0) + CVE-2025-0283 (escalade de privilèges, CVSS 7.0). Prise isolément, la CVE 7.0 semblerait passer sous le seuil d'urgence de beaucoup d'équipes. Enchaînées, elles donnent un accès root complet sur les appliances VPN d'Ivanti. CISA a émis une directive d'urgence pour les agences fédérales américaines. Dans les heures suivant la publication des CVE, des milliers de scans de masse étaient déjà détectés dans les honeypots Shadowserver.

Chaîne 2 — Fortinet FortiOS (2024-2025). Multiple CVE enchaînées sur FortiOS : auth bypass (CVSS 9.8) → lecture de fichier arbitraire (CVSS 7.5) → écriture de configuration persistante (CVSS 6.5). La dernière CVE de la chaîne, à CVSS 6.5, est celle qui garantit la persistance après reboot — la pièce la plus précieuse pour un attaquant qui veut maintenir un accès long terme. Si on trie uniquement par score, cette CVE serait la dernière à être patchée. Elle est pourtant la plus critique du point de vue de l'impact opérationnel d'une compromission réussie.

Chaîne 3 — Microsoft SharePoint (avril 2026). CVE-2026-32201, un zero-day SharePoint scoré CVSS 6.5 (accès authentifié requis), exploité in-the-wild avant la disponibilité du patch. La raison du score modéré : l'authentification est requise. La raison de l'exploitation massive : les attaquants avaient accès à des credentials valides via des campagnes de phishing antérieures. Le score CVSS modélise la sévérité intrinsèque de la faille, pas son risque dans votre contexte d'exposition. Cette distinction est fondamentale et la plupart des outils de triage ne la font pas.

Vers une triage par chemin d'attaque : ce qui change concrètement pour les équipes

La sortie n'est ni une formule magique ni un nouveau scoring miracle. EPSS (Exploit Prediction Scoring System) aide à pondérer la probabilité d'exploitation, mais ne capture pas non plus le chaînage. Ce qui change concrètement les courbes de compromission, c'est la triage par chemin d'attaque plutôt que par CVE individuel.

Concrètement : pour chaque CVE significative, l'analyste vulnerability management doit se poser trois questions fondamentales.

Question 1 : Cette faille, combinée à quoi de déjà exposé, donne quoi ? Un information disclosure CVSS 5.0 devient critique si une RCE pre-auth existe en aval dans la même stack applicative. Un bypass d'authentification CVSS 7.5 devient catastrophique si une escalade de privilèges locaux non patchée coexiste sur le même équipement. Un inventaire SBOM précis et maintenu à jour permet de répondre à cette question. Un ticket dans le backlog, non.

Question 2 : La pile applicative concernée embarque-t-elle d'autres CVE non patchées formant une chaîne plausible ? Ce n'est pas une question théorique. C'est une requête sur votre base d'actifs. Pour chaque CVE publiée sur un équipement réseau exposé, l'outil de gestion des vulnérabilités doit automatiquement lister toutes les CVE non patchées sur ce même équipement et identifier les chaînes plausibles. C'est ce que font les outils de gestion des vulnérabilités contextuelles — Tenable One, Qualys TruRisk, Rapid7 InsightVM — mais seulement si vous les avez configurés pour ça.

Question 3 : Quel est le rayon de propagation post-exploitation ? Une faille dans un orchestrateur (SD-WAN Manager, Kubernetes, Terraform Enterprise) a une portée structurellement plus large qu'une faille équivalente en bout de chaîne sur un système isolé. Un firewall compromis, comme dans le cas Palo Alto, donne accès à tout ce qu'il est censé protéger. Un agent EDR compromis voit toute l'activité de la machine. Ces multiplicateurs de portée doivent être intégrés dans le score de priorité — ce qu'aucun CVSS ne fait nativement.

Ce qu'il faut changer dans votre processus de patch management

La transition d'une triage CVSS isolée vers une triage par chemin d'attaque ne se fait pas du jour au lendemain. Voici les étapes réalistes pour les équipes qui veulent commencer cette semaine.

Étape 1 — Câbler un flux KEV-first en complément du CVSS. Le catalogue KEV (Known Exploited Vulnerabilities) de la CISA est le seul référentiel qui filtre le bruit avec une exigence de preuve d'exploitation active. Tout CVE qui entre dans le catalogue KEV doit déclencher automatiquement un ticket P0 dans votre système de gestion des vulnérabilités, indépendamment du score CVSS. C'est le filet de sécurité minimal pour les failles réellement exploitées.

Étape 2 — Enrichir chaque CVE avec son contexte d'exposition. Avant de scorer une CVE, répondre systématiquement à : est-ce que l'équipement concerné est exposé sur Internet ? Directement ou via un rebond ? Quels actifs critiques protège-t-il ou héberge-t-il ? Quelles autres CVE non patchées coexistent sur le même équipement ? Ce contexte d'exposition transforme radicalement la priorité réelle d'une CVE.

Étape 3 — Mettre en place une revue hebdomadaire des chaînes CVE actives. Un analyste dédié examine chaque semaine les CVE récentes sur les équipements exposés et cherche explicitement des combinaisons plausibles. C'est un travail de 2 à 4 heures par semaine pour une organisation de taille moyenne, et c'est l'investissement qui aurait permis de détecter la chaîne Palo Alto avant l'exploitation.

Étape 4 — Sortir les interfaces d'administration des firewalls et appliances réseau d'Internet. La leçon la plus simple de l'incident Palo Alto : 13 000 interfaces de management exposées sur Internet. Une règle triviale élimine 90 % du risque : aucune interface d'administration d'équipement réseau ne doit être accessible depuis Internet sans VPN ou sans zero trust network access. Si vous avez des Palo Alto, des Fortinet ou des Ivanti avec leurs interfaces de management directement sur Internet aujourd'hui, corrigez ça avant même de lire la suite.

Conclusion

Le score CVSS reste un signal utile, mais c'est un signal — pas une décision. La triage par score isolé a fait son temps. La réalité de 2026 est celle de chaînes CVE automatisées, de délais d'exploitation inférieurs à 24 heures, et d'équipements réseau dont les interfaces d'administration ne devraient jamais être exposées sur Internet.

La triage de 2026 doit intégrer le contexte d'exposition, la combinabilité des vulnérabilités coexistantes, et le rayon de propagation post-exploitation. Sans ça, on continuera à voir des compromissions à grande échelle expliquées a posteriori par des chaînes que tout le monde aurait pu modéliser a priori. Et on continuera à se demander comment 13 000 firewalls ont pu être compromis via deux CVE « moyennes ».

Construire un scoring contextuel avec SSVC et KEV CISA

Au-delà du CVSS, plusieurs frameworks enrichissent l'analyse de vulnérabilités. Le SSVC (Stakeholder-Specific Vulnerability Categorization), développé par CISA et le CERT/CC, structure la décision autour de cinq variables : l'état d'exploitation réelle (aucune preuve, PoC public, exploitation active), l'automatisation possible (manuelle ou scriptée), la portée de l'impact (systèmes isolés ou infrastructure partagée), la valeur des actifs concernés, et la présence de mesures compensatoires actives.

L'intérêt du SSVC réside dans sa capacité à produire une recommandation d'action directe — déployer immédiatement, déployer sous 7 jours, planifier dans le cycle normal, ou surveiller sans action urgente — plutôt qu'un score chiffré qui laisse l'interprétation à l'équipe. Pour les vulnérabilités de type chaîne CVE comme celles observées sur Palo Alto, le SSVC déclenche systématiquement la catégorie "déployer immédiatement" dès lors qu'une exploitation active est confirmée, même si le CVSS de composants individuels reste modéré.

Concrètement, intégrez dans votre processus de triage une vérification quotidienne du KEV (Known Exploited Vulnerabilities Catalog) de la CISA, actualisé en temps réel. Une vulnérabilité inscrite au KEV bénéficie d'une remontée automatique en priorité critique, quelle que soit sa note CVSS. Ce simple ajout au workflow réduirait de 70 % les délais de réponse aux vulnérabilités activement exploitées selon les retours d'expérience des SOC ayant adopté cette pratique. À ce jour, le KEV contient plus de 1 200 entrées couvrant aussi bien des équipements réseau que des systèmes d'exploitation, des applications web et des logiciels métier.

Le calcul du score contextualisé peut être automatisé en combinant les données CVSS de la NVD, le statut KEV de la CISA, et les informations EPSS (Exploit Prediction Scoring System) qui estiment la probabilité statistique qu'une vulnérabilité soit exploitée dans les 30 jours. Un score composite intégrant ces trois sources produit une priorisation significativement plus pertinente que le CVSS seul, avec une corrélation aux incidents réels trois fois supérieure selon les études comparatives publiées par Cyentia Institute.

Intégrer la threat intelligence dans le triage des vulnérabilités

La threat intelligence transforme le triage réactif en anticipation proactive. En corrélant les vulnérabilités de votre inventaire avec les TTPs (Tactiques, Techniques, Procédures) des groupes d'attaquants ciblant votre secteur, vous hiérarchisez différemment : une CVE de score 6.5 exploitée par un groupe APT actif dans votre industrie prime sur une CVE de score 9.0 sans exploitation répertoriée ni acteur menaçant identifié.

Les flux OSINT spécialisés (Vulncheck, GreyNoise, Shodan CVE Monitor) fournissent une vision en temps réel de l'exploitation en cours, distinguant les scans opportunistes des tentatives d'exploitation ciblées. Leur intégration dans le SIEM ou la plateforme de gestion des vulnérabilités automatise la remontée de criticité des CVE en cours d'exploitation active dans la wild. GreyNoise en particulier permet de savoir si une vulnérabilité donnée est activement scannée dans l'internet public, ce qui constitue un signal précoce d'exploitation imminente.

Sur le plan organisationnel, formalisez un processus de triage d'urgence pour les vulnérabilités zero-day ou exploitées activement : alerte immédiate au RSSI, évaluation de l'exposition dans les deux heures, décision de remédiation ou d'isolement dans les quatre heures, et rapport de situation au management en fin de journée. Ce processus doit être documenté, connu de l'équipe, et testé régulièrement via des exercices tabletop. L'incident Palo Alto a montré que la fenêtre d'exploitation peut se compter en heures : l'organisation qui réagit en jours subit des dommages disproportionnés.

Mesurer l'efficacité de votre programme de gestion des vulnérabilités

Un programme de gestion des vulnérabilités sans métriques est un programme sans direction. Les KPIs fondamentaux à suivre sont le temps moyen de remédiation (MTTR) par criticité — moins de 24h pour le critique, 7 jours pour le haut, 30 jours pour le moyen — et le taux de couverture de l'inventaire (pourcentage d'actifs inclus dans le périmètre de scan). Un taux de couverture inférieur à 95 % signifie que des angles morts persistent, potentiellement sur les actifs les plus sensibles.

Le suivi de la dette vulnérabilité — nombre de vulnérabilités critiques et hautes non remédiées depuis plus de 30 jours — constitue un indicateur de risque opérationnel directement présentable au COMEX. Son évolution à la baisse démontre l'efficacité du programme et justifie les investissements consentis. À l'inverse, une dette croissante doit déclencher une analyse des causes racines : manque de ressources, processus de change management trop lent, conflits de priorités avec les équipes métier.

Intégrez également le tracking du Mean Time to Exploit (MTTE) — délai entre la publication d'une CVE et sa première exploitation dans la wild — comme benchmark externe pour calibrer vos SLA internes. En 2025-2026, ce délai moyen est tombé sous 5 jours pour les vulnérabilités critiques affectant des équipements exposés sur internet, ce qui impose des processus de remédiation ultra-réactifs pour les actifs de la zone périmétrique.