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. La triage par score isolé, méthode dominante depuis dix ans dans la majorité des SOC, vient de prendre une gifle publique. Et ce n'est pas un cas isolé.

Le piège du score individuel

Le réflexe est partout le même : un CVE arrive, on regarde le score CVSS, on classe en P1/P2/P3 selon les seuils internes — typiquement 9.0+ en urgence, 7.0–8.9 sous 30 jours, le reste dans le backlog. Cette logique est défendable sur le papier : elle permet d'industrialiser un flux qui dépasse 30 000 CVE par an. Sauf que dans la vraie vie, les attaquants ne se contentent pas de prendre la faille la plus haute. Ils combinent.

L'exemple Palo Alto Lunar Peek est devenu cas d'école : CVE-2024-0012 (auth bypass) chaînée à CVE-2024-9474 (privilege escalation). Prises séparément, la PE filtrait sous le seuil de patch immédiat de la plupart des organisations parce qu'elle exigeait un compte admin. Sauf que la première CVE éliminait précisément ce prérequis. Aucun des deux scores ne reflétait l'effet composé. Résultat : 13 000 interfaces compromises avec accès root.

Pourquoi la grille classique craque en 2026

Trois facteurs se conjuguent pour rendre la triage isolée structurellement obsolète. D'abord, le temps entre disclosure et exploitation s'effondre : LMDeploy a été exploitée 13 heures après publication de la CVE, Marimo en 10 heures, Defender BlueHammer dans la semaine. Le délai pendant lequel un score moyen reste tolérable n'existe plus.

Ensuite, les attaquants industrialisent le chaînage. Là où une exploitation manuelle nécessitait un opérateur formé, des frameworks publics intègrent désormais des templates de chaining. Une combinaison auth bypass + LFI + RCE devient un one-liner.

Enfin, les outils défensifs eux-mêmes sont devenus surface d'attaque. Microsoft Defender vient de cumuler trois zero-days en 48 heures, dont deux non patchés. CrowdStrike LogScale a connu sa CVE 9.x. La séparation conceptuelle entre l'agent qui protège et la chose à protéger ne tient plus.

Vers une triage par contexte d'exploitation

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

Concrètement : pour chaque CVE non triviale, l'analyste vulnérabilité doit se poser trois questions. Premièrement, cette faille combinée à quoi déjà exposé donne quoi ? Un info disclosure devient critique si une RCE pré-auth existe en aval. Deuxièmement, la pile applicative concernée embarque-t-elle d'autres CVE non patchées formant une chaîne plausible ? Un inventaire SBOM honnête répond à cette question, pas un score. Troisièmement, 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.

Conclusion

Le score CVSS reste un signal utile, mais c'est un signal — pas une décision. Le tri par score isolé a fait son temps. La triage de 2026 doit intégrer le contexte d'exposition, la combinabilité, et le rayon de propagation. 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.