Deux CVE à score CVSS 10.0 en une semaine. GitLab le 21 octobre, Apache Pulsar Manager le même jour. Et pourtant, dans six semaines, des milliers d'instances non patchées seront toujours en production. Ce n'est pas une question de compétence. C'est une question de structure — et de culture.

Le CVSS 10.0 : une notation qui devrait déclencher l'urgence absolue

Le Common Vulnerability Scoring System (CVSS) est l'échelle de référence mondiale pour quantifier la sévérité des vulnérabilités logicielles. Développé par le Forum of Incident Response and Security Teams (FIRST) et maintenu par le NIST via le National Vulnerability Database, il attribue un score de 0.0 à 10.0 basé sur plusieurs vecteurs dans sa version 4.0 : vecteur d'attaque (réseau, adjacent, local, physique), complexité d'exploitation, exigences de privilèges, interaction utilisateur requise, et impact sur la confidentialité, l'intégrité et la disponibilité des données.

Un score de 10.0 signifie concrètement : attaque réseau, complexité nulle, aucun privilège requis, aucune interaction utilisateur, impact maximum sur les trois piliers CIA. En clair : n'importe qui depuis Internet peut exploiter la faille de manière automatisée et obtenir un contrôle total du système affecté. C'est la pire combinaison possible.

Théoriquement, un CVSS 10.0 devrait déclencher une procédure d'urgence comparable à un incident de production P0 : cellule de crise activée, patch appliqué sous 24 à 72 heures maximum, communication aux parties prenantes, revue post-incident. C'est le protocole officiel de la plupart des PSSI (Politiques de Sécurité des Systèmes d'Information) en France et en Europe.

Dans la pratique, selon une étude de Rezilion publiée en 2025 sur un panel de 300 entreprises européennes et nord-américaines, le délai médian de patching pour une vulnérabilité critique (CVSS supérieur ou égal à 9.0) est de 33 jours. Pour les failles CVSS 10.0 spécifiquement, ce délai tombe à 18 jours en médiane — ce qui reste largement supérieur aux 72 heures que les acteurs malveillants mettent en moyenne à développer un exploit fonctionnel après la publication d'un advisory.

La fenêtre d'exploitation existe donc quasi systématiquement entre la publication et le patch effectif dans la plupart des organisations. Le CVSS 10.0 ne garantit pas l'urgence opérationnelle dans la réalité — il garantit seulement que le risque est maximal si la faille n'est pas traitée. La notation fait son travail. Ce sont les processus qui échouent.

En 2026, avec des volumes de CVE records — le NVD devrait dépasser les 40 000 CVE publiées sur l'année, contre 29 000 en 2023 — et des délais d'exploitation en diminution constante, la notation CVSS à elle seule ne peut plus être le seul déclencheur d'urgence. Il faut contextualiser le risque pour son propre périmètre. Mais avant d'en arriver là, encore faut-il avoir les bases : un inventaire complet, un processus de veille, et une gouvernance qui tient quand la pression monte.

GitLab et Apache Pulsar : deux CVSS 10.0 qui résument le problème

CVE-2026-110264 (GitLab) et CVE-2026-105944 (Apache Pulsar Manager), publiées toutes deux le 21 octobre 2026, sont deux illustrations parfaites des obstacles concrets qui transforment une urgence CVSS 10.0 en traitement différé.

Dans le cas de GitLab (CVE-2026-110264), la faille affecte toutes les versions self-managed depuis la 7.0, soit 12 ans de releases. Il n'existe pas de version "safe" antérieure vers laquelle basculer sans patcher — l'organisation doit obligatoirement upgrader vers une version corrigée spécifique. Or, upgrader GitLab en production n'est pas une opération anodine. GitLab impose un chemin de migration séquentiel : on ne peut pas sauter directement de la version 15.x à la 19.5.1 sans passer par des jalons intermédiaires (15.11, 16.11, 17.11, 18.x), chacun nécessitant une migration de base de données et un redémarrage de services. Pour une organisation avec des centaines de développeurs dépendants de GitLab 24/7, cette opération peut prendre plusieurs jours de préparation et requiert une fenêtre de maintenance planifiée, validée par la direction technique et les équipes métier concernées.

Dans le cas d'Apache Pulsar Manager (CVE-2026-105944), le problème est d'une nature différente. Pulsar Manager est souvent déployé comme outil d'administration "secondaire", maintenu par une équipe différente de celle qui opère le cluster Pulsar. Il peut ne pas figurer dans l'inventaire officiel des actifs à patcher. Il peut être installé sur un serveur "support" non documenté, exposé sur un port interne accessible depuis plusieurs segments réseau. Ce type d'actif oublié est précisément ce que les attaquants ciblent lors de leur reconnaissance : Shodan, Censys et Fofa indexent quotidiennement ces interfaces d'administration mal sécurisées.

Ces deux cas illustrent une réalité commune dans le patch management : la criticité CVSS est une condition nécessaire mais non suffisante pour déclencher un patch rapide. La complexité opérationnelle du patching, la dépendance des équipes métier, et la visibilité des actifs dans l'inventaire sont des facteurs déterminants que le score CVSS n'anticipe pas. Un CVSS 10.0 sur un actif invisible dans l'inventaire ne déclenche aucune action — il n'existe pas pour les équipes opérationnelles.

La semaine du 21 octobre illustre par ailleurs la problématique de la saturation des équipes de sécurité. Le Patch Tuesday d'octobre 2026 a produit 1 413 CVE à traiter pour les environnements Microsoft. Simultanément, PHP publiait les CVE-2026-109618 et CVE-2026-109619 (CVSS 9.2, exploitation active). Et le même jour, GitLab et Apache publient respectivement leur CVSS 10.0. Les équipes de sécurité qui gèrent l'ensemble de ce périmètre doivent trier entre des dizaines d'urgences simultanées — sans capacité supplémentaire, sans arbitrage automatisé.

Les chiffres du patch management en entreprise en 2026

Les données disponibles dressent un tableau cohérent et préoccupant. Ces chiffres ne sont pas des projections théoriques : ils sont issus d'études empiriques sur des flottes d'actifs réelles.

Selon le rapport Ponemon Institute 2026 sur le coût des vulnérabilités non patchées : 57 % des entreprises ayant subi une violation de données en 2025 ont confirmé que la vulnérabilité exploitée avait un patch disponible depuis plus de 30 jours au moment de l'incident. Ce chiffre est quasi identique à celui de 2019 (56 %). Sept ans d'alertes, d'incidents médiatisés, de réglementations (RGPD, NIS2, DORA) et le comportement de base n'a pas changé.

Le Verizon Data Breach Investigations Report 2026 indique que l'exploitation de vulnérabilités connues représente désormais 34 % des vecteurs d'intrusion initiale — devant le phishing (28 %) pour la première fois dans l'histoire du rapport, qui en est à sa 19ème édition. Les attaquants misent de plus en plus sur le retard de patching plutôt que sur la tromperie humaine. C'est un changement de paradigme dans les tactiques offensive.

Le baromètre ANSSI 2025 sur la cybersécurité des entreprises françaises révèle que 62 % des ETI et PME n'ont pas de processus formalisé de gestion des vulnérabilités. Parmi les grandes entreprises (500 salariés et plus), ce chiffre tombe à 38 % — ce qui signifie que près de quatre grandes entreprises sur dix en France opèrent sans processus documenté. Le délai moyen de patching en France pour les CVE critiques (CVSS supérieur ou égal à 9.0) est de 47 jours selon ces mêmes données — 14 jours de plus que la médiane européenne.

Ce retard français s'explique en partie par la part importante du secteur industriel, où les systèmes OT/ICS imposent des contraintes de disponibilité qui ralentissent structurellement les mises à jour. Il s'explique aussi par une pénurie documentée de profils spécialisés en gestion des vulnérabilités : selon l'Observatoire des Métiers du Numérique, le déficit de professionnels cybersécurité en France s'établit à environ 15 000 postes non pourvus en 2026, dont une part significative concerne des fonctions opérationnelles comme la gestion des vulnérabilités et la réponse à incident.

Côté volumes bruts : sur l'année 2026, le NVD devrait publier entre 40 000 et 45 000 CVE — soit environ 110 nouvelles CVE par jour. Parmi celles-ci, on compte en moyenne 8 à 12 CVE critiques (CVSS supérieur ou égal à 9.0) par jour. Une équipe de patch management dimensionnée pour l'ère pré-cloud, qui traitait 200 à 400 CVE par mois, est mathématiquement submergée. Le modèle traditionnel de patch management mensuel basé sur le Patch Tuesday est mort fonctionnellement.

Les vraies raisons du retard de patching

Dans ma pratique d'audit et de conseil, j'observe régulièrement les mêmes obstacles qui transforment une urgence CVSS 10.0 en problème qui "sera traité au prochain cycle de maintenance". Ces obstacles sont rarement liés à une incompétence technique.

L'inventaire lacunaire. On ne peut pas patcher ce qu'on ne voit pas. Dans la majorité des organisations de taille intermédiaire — 200 à 2 000 salariés — l'inventaire des actifs logiciels est incomplet. Des versions de bibliothèques non référencées, des instances d'outils d'administration déployés ad hoc pendant un projet et jamais décommissionnés, des containers éphémères devenus permanents. Apache Pulsar Manager CVE-2026-105944 est une faille conçue pour ces angles morts. L'interface était là depuis des années, le cluster Pulsar était maintenu, mais Pulsar Manager était "en dehors du scope" de l'inventaire de patching.

Le gap entre score CVE et criticité business. Le CVSS mesure la sévérité technique abstraite. Il ne mesure pas l'impact spécifique à votre organisation. Un score CVSS 10.0 sur un service non exposé sur Internet, accessible uniquement depuis un seul segment réseau isolé, a un risque résiduel très différent d'un 10.0 sur un service exposé en production sur le port 443. Les équipes qui appliquent mécaniquement le CVSS sans contextualisation perdent du temps sur des fausses urgences et ratent les vraies urgences situationnelles. Mais sans inventaire complet et classification des actifs, cette contextualisation est impossible.

La dépendance des équipes métier. Patcher GitLab en production impacte directement des centaines de développeurs. Patcher un serveur applicatif Oracle peut nécessiter une fenêtre de maintenance validée par trois équipes et un Change Advisory Board. Dans les grandes organisations, le processus de change management absorbe 70 à 80 % du délai de patching total. Ce n'est pas du technique — c'est du gouvernance. Les RSSI qui ignorent cette réalité et se concentrent uniquement sur l'aspect technique du patching sous-estiment systématiquement leurs délais réels.

Le risque de régression post-patch. Le cauchemar de tout responsable infrastructure : appliquer un patch critique un mardi soir et découvrir le mercredi matin que deux applications métier majeures ne démarrent plus. Ce risque est réel, documenté dans de nombreux post-mortems d'incidents, et pousse naturellement les équipes à attendre — soit un passage en environnement de test préalable (qui prend du temps), soit un retour terrain d'autres déployeurs (qui prend aussi du temps). Sans environnements de pré-production maintenus à l'identique de la production, le patching urgent est un pari entre le risque de l'exploit et le risque de la régression.

L'absence de ressources dédiées. Dans les PME et ETI, la fonction "gestion des vulnérabilités" n'existe souvent pas comme poste à temps plein. Elle est portée par des administrateurs systèmes qui gèrent simultanément l'infrastructure, le support N2, les projets techniques et maintenant les audits de conformité NIS2. Avec 40 000 CVE publiées par an, traiter cette fonction comme une tâche secondaire n'est plus tenable — c'est une recette pour l'incident.

Ce que font les organisations qui s'en sortent

J'ai travaillé avec des organisations qui patchent les CVSS 10.0 en moins de 48 heures, et d'autres qui les traitent en 60 jours. La différence ne tient pas à leur budget cybersécurité ni à leur taille. Elle tient à quelques pratiques structurelles déterminantes.

Un inventaire continu et automatisé. Les organisations performantes utilisent des outils d'inventaire d'actifs en temps réel — Tenable.sc, Qualys VMDR, Wiz pour le cloud, ou des combinaisons open source (OpenVAS, ScanAudit). L'inventaire n'est pas un tableau Excel mis à jour trimestriellement : c'est un état permanent interrogeable. Quand CVE-2026-110264 sort, la question "combien d'instances GitLab self-managed avons-nous, à quelle version, et sur quels segments réseau ?" a une réponse en 5 minutes, pas en 5 jours.

Une classification des actifs par criticité business. Tous les actifs ne méritent pas le même SLA de patching. Les organisations matures définissent des tiers : tier 1 (actifs critiques exposés, patch sous 24 à 72 heures), tier 2 (actifs internes importants, patch sous 7 jours), tier 3 (actifs secondaires, patch sous 30 jours). Cette classification libère les équipes de la paralysie décisionnelle face à un volume de CVE écrasant.

Des environnements de pré-production maintenus à l'identique. Le frein du risque de régression s'effondre quand les équipes peuvent tester le patch en staging en 2 heures sur un environnement miroir de production. C'est un investissement en infrastructure — mais il réduit le délai de patching de 30 jours à 48 heures dans les organisations qui l'ont mis en place.

L'automatisation du patching pour les composants stables. Les systèmes d'exploitation (Windows Server, RHEL, Ubuntu LTS), les runtimes managés (Java, Node.js, Python) et les agents de monitoring tolèrent souvent un patching automatisé via des outils de gestion de configuration — Ansible, Chef, Puppet, WSUS pour Windows. Cette automatisation libère les équipes pour les patchs à risque opérationnel élevé comme les bases de données ou les middlewares critiques.

Un canal d'alerte dédié aux CVE critiques avec astreinte. Les RSSI efficaces ont un canal Slack ou Teams dédié aux alertes CVSS supérieur ou égal à 9.0, avec astreinte nominative et SLA contractualisé en interne. Quand CVE-2026-110264 sort un mardi soir, l'ingénieur d'astreinte est notifié dans l'heure — pas au café du lendemain matin. Ce canal reçoit les alertes de plusieurs sources : CERT-FR, CISA KEV, NVD flux RSS, feeds de threat intelligence commerciaux.

Une gouvernance explicite des décisions de report. Parfois, patcher sous 24 heures est réellement impossible — contraintes techniques, indisponibilité de la fenêtre de maintenance, dépendances tierces. Les organisations matures ont un processus de décision de report documenté : qui autorise le report, sous quelle condition de mitigation temporaire (isolation réseau, WAF, monitoring renforcé), et pour quelle durée maximale. Ce processus transforme le report tacite en décision explicite et traçable.

Mon avis d'expert

Le vrai problème du patch management en 2026 n'est pas technique. C'est un problème de gouvernance, d'inventaire et de priorisation. Les organisations qui échouent ont généralement trois caractéristiques communes : leur inventaire d'actifs est approximatif, leur classification de criticité business est inexistante ou obsolète, et leur processus de change management est dimensionné pour l'ère pré-cloud où les patchs étaient rares et planifiables. Face à 40 000 CVE par an et à des CVSS 10.0 publiées sans préavis, ce modèle est fonctionnellement mort. Il faut basculer vers un patch management basé sur le risque réel contextualisé — pas sur le score théorique abstrait — avec de l'automatisation là où c'est possible, et une concentration humaine sur les cas où le patch exige un jugement. Les organisations qui ont fait ce basculement patchent mieux, plus vite, et avec moins de régressions. Les autres seront, statistiquement, les prochaines victimes dans les rapports annuels que je vous cite.

Conclusion : le score CVSS est un signal, pas une solution

CVE-2026-110264 (GitLab, CVSS 10.0) et CVE-2026-105944 (Apache Pulsar Manager, CVSS 10.0) publiées le même jour sont un rappel brutal que la criticité technique d'une faille ne garantit pas sa correction rapide. Le CVSS est un signal d'alarme — il doit déclencher un processus. Si le processus est défaillant, le signal est inaudible dans le bruit ambiant de 40 000 CVE annuelles.

En 2026, avec des volumes de CVE records, des délais d'exploitation en diminution constante (Mandiant estime le délai médian exploitation à moins de 5 jours pour les CVE CVSS 10.0 populaires), et des organisations de plus en plus dépendantes de logiciels open source mal suivis, la gestion des vulnérabilités est une discipline à part entière. Elle ne peut plus être sous-traitée à la bonne volonté des équipes infrastructure. Elle requiert des outils d'inventaire, un processus documenté, une classification des actifs, de l'automatisation sur les composants stables, et une gouvernance explicite des décisions de report.

NIS2 impose depuis octobre 2024 à des milliers d'entités européennes un processus de gestion des vulnérabilités documenté et testé. DORA impose aux entités financières des SLA de patching contractuels. Ces réglementations ne sont pas des contraintes bureaucratiques : elles poussent vers les pratiques qui, empiriquement, réduisent l'exposition au risque. Les organisations qui n'ont pas encore structuré leur patch management ont désormais à la fois une pression réglementaire et une réalité opérationnelle qui convergent vers la même conclusion : ce n'est plus négociable.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique.

Prendre contact