Lundi matin, en dépouillant les publications du week-end, un de nos analystes tombe sur une CVE fraîchement publiée concernant WAPT Server. Réflexe habituel : vérifier lesquels de nos clients sont concernés. Trois le sont. Deuxième réflexe : regarder depuis quand.
C’est là que la journée a changé de nature. Le correctif de l’éditeur était disponible depuis le 9 juin 2026. La CVE, elle, a été publiée le 3 août. Entre les deux, cinquante-cinq jours pendant lesquels nos tableaux de bord de veille, alimentés par les flux publics, affichaient un vert parfaitement rassurant et parfaitement faux.
Nos trois clients étaient à jour — non pas grâce à notre veille, mais parce que leur cycle de mise à jour applicative avait fait le travail tout seul. Autrement dit : nous avons eu de la chance. C’est le genre de constat qui mérite un article plutôt qu’un rapport interne discret.
Ce que dit exactement l’avis
La publication qui a déclenché tout cela est titrée sans ambiguïté chez nos confrères d’IT-Connect : « WAPT Server (CVE-2026-33591) : une faille permet de contourner l’authentification ». Reprenons les éléments techniques, parce qu’ils comptent pour évaluer votre exposition réelle.
Le produit. WAPT est une solution de déploiement et de gestion de parc logiciel éditée par Tranquil IT, société française. Elle est très présente dans les administrations, les collectivités et les entreprises de taille intermédiaire françaises — un point qui rend cette CVE nettement plus pertinente ici qu’un avis générique sur un produit américain.
Le défaut. Un attaquant distant non authentifié peut envoyer un paquet spécialement construit afin de contourner une restriction de sécurité et de récupérer un jeton de session valide pour le compte visé. Il n’y a pas de prérequis d’accès : c’est le scénario le plus favorable qui soit pour un attaquant.
Le périmètre. Versions 2.6.0.16767 à 2.6.1.17787, éditions Enterprise et Discovery.
La notation. 7,5 en CVSS v3.1, 10,0 en CVSS v4.0. Cet écart n’est pas anodin et mérite qu’on s’y arrête — j’y reviens plus bas, parce qu’il illustre un piège de priorisation que beaucoup d’équipes n’ont pas encore intégré.
Le correctif. Version 2.6.1.17813, publiée le 9 juin 2026.
Chronologie de l’angle mort
Notre avis d’expert n°1 : piloter ses correctifs par flux CVE est une erreur de conception
La plupart des organisations que nous auditons ont construit leur gestion des vulnérabilités autour d’un déclencheur unique : la publication d’un avis. Un flux entre, un ticket sort, une équipe patche. C’est propre, mesurable, et cela produit d’excellents indicateurs.
C’est aussi structurellement incomplet, et ce cas le démontre mieux que n’importe quel argumentaire. Pendant 55 jours, la vulnérabilité existait, le correctif existait, et le flux ne disait rien. Aucun indicateur n’était au rouge. Une organisation exemplaire au sens de ses propres métriques était exposée.
La raison est simple et parfaitement légitime : l’attribution d’un identifiant CVE suit un processus indépendant du calendrier de correction de l’éditeur. Un éditeur peut corriger dans une version de maintenance, documenter sobrement, et l’identifiant n’arriver que des semaines plus tard. Ce n’est pas une faute, c’est le fonctionnement normal de l’écosystème. L’erreur est de notre côté : avoir supposé que le flux CVE était exhaustif et temps réel.
Le correctif organisationnel tient en une phrase : les notes de version de vos éditeurs critiques doivent être une source de veille au même titre que les flux CVE. Pas un complément, une source de premier rang.
Notre avis d’expert n°2 : l’écart 7,5 / 10,0 entre CVSS v3.1 et v4.0 va casser vos règles de priorisation
Cette vulnérabilité est notée 7,5 en v3.1 et 10,0 en v4.0. Le même défaut, deux référentiels, un écart de deux points et demi qui fait basculer la faille d’« élevée » à « critique ».
Or la quasi-totalité des politiques de correction que nous lisons en audit contiennent une règle du type « CVSS ≥ 9 : correction sous 48 heures, CVSS entre 7 et 9 : sous 30 jours ». Selon le référentiel que consomme votre outil, cette même CVE déclenche une astreinte de nuit ou un ticket de fin de mois.
Ce n’est pas une subtilité de spécialiste. La v4.0 a été conçue précisément pour mieux refléter l’impact réel, notamment sur les systèmes dont la compromission entraîne des effets en cascade — ce qui est exactement le cas d’une console de déploiement logiciel. Si votre politique interne ne précise pas quelle version de CVSS fait foi, elle est ambiguë sur son point le plus critique.
Ce que nous avons imposé depuis chez nos clients : la règle de priorisation retient la note la plus élevée disponible, tous référentiels confondus, et le référentiel utilisé est journalisé dans le ticket. Cela coûte une ligne de configuration et supprime une classe entière de mauvaises décisions.
Notre avis d’expert n°3 : une console de déploiement n’est pas un serveur applicatif comme un autre
Un serveur de déploiement logiciel dispose par construction d’un pouvoir d’exécution de code sur l’intégralité du parc qu’il administre. C’est sa fonction. Compromettre cette console ne donne pas accès à une machine : cela donne accès à toutes, avec les privilèges d’installation, et par un canal que vos outils de détection considèrent comme légitime.
C’est pourquoi je classe cette CVE au-dessus de ce que sa note v3.1 suggère, indépendamment du débat sur les référentiels. Les outils d’administration de parc — déploiement, sauvegarde, supervision, gestion des accès à distance — méritent un régime de traitement distinct : délai de correction raccourci, exposition réseau minimale, et surveillance renforcée des authentifications.
La question à se poser aujourd’hui n’est donc pas seulement « ai-je patché WAPT ». C’est « quels autres outils de ma chaîne d’administration ont ce niveau de pouvoir, et est-ce que je les traite en conséquence ». Dans la majorité des audits que nous menons, la réponse est non : ces serveurs sont gérés comme des serveurs applicatifs ordinaires, parfois même exposés pour faciliter le télétravail des équipes d’exploitation.