Ces 14 entrées, voici ce que vous voyez selon les trois endroits où vous allez chercher :

Le seul endroit qui raconte toute l'histoire, c'est l'enregistrement original soumis par Apache en tant que CNA sur CVE.org — c'est-à-dire la couche que le moins de monde va fouiller. Ce que fait cet outil, c'est confronter les informations de cette couche à la version réellement installée sur votre machine.

🔴 Cet outil expose les différences entre les sources de données, pas le comportement d'un produit. « Votre scanner va-t-il remonter ces 10 entrées ? » dépend de la base qu'il lit et de la façon dont il fusionne — cela n'a pas été testé, donc rien n'est écrit ici.

L'autre moitié tout aussi importante : sur les 14, seulement 2 touchent la configuration par défaut

Ne signaler que par numéro de version reviendrait à présenter les 12 entrées « valables uniquement avec une configuration spécifique » comme « vous êtes touché » — c'est vous envoyer faire une tâche inutile.

C'est pourquoi, lorsqu'un répertoire d'installation est fourni, l'outil lit tous les XML sous conf/ (y compris conf/Catalina/<host>/), retire les blocs de commentaires, puis cherche les marqueurs de condition déclenchante. Retirer les commentaires n'est pas une option : dans le server.xml officiel, la recherche textuelle de UpgradeProtocol donne 1 occurrence, mais 0 après retrait des commentaires — le passage entier est commenté.

Sur une installation nue officielle 8.5.100, le résultat est :

Une fois HTTP/2, RewriteValve et CGIServlet activés dans la même configuration, les « confirmées par configuration » passent à 5.

Utilisation

Comment le numéro de version est reconnu sur un déploiement décompressé

Les jars sous lib/ ne portent aucun numéro de version dans leur nom de fichier (c'est catalina.jar, pas catalina-8.5.100.jar). Les outils qui ne se fient qu'au nom de fichier ne reconnaissent rien sur ce type de déploiement — or « rien détecté » ressemble exactement à « vous êtes en sécurité ».

Cet outil détermine la version dans cet ordre :

1. server.number dans catalina.jar!/org/apache/catalina/util/ServerInfo.properties — c'est ce que rapporte version.sh de Tomcat lui-même
2. Implementation-Version dans META-INF/MANIFEST.MF
3. Le nom de fichier (uniquement pour les formes embarquées type Spring Boot)

Quand les deux sources ne concordent pas (ServerInfo.properties peut être écrasé, souvent pour masquer la version), les deux sont rapportées, sans choisir à votre place.

Trois lignes rouges à ne pas franchir

Un : on peut confirmer qu'une chose est activée, pas qu'elle ne l'est pas. Quand le rapport dit « introuvable », cela signifie « introuvable dans les fichiers que j'ai examinés », pas « vous ne l'avez pas activé ». La configuration peut se trouver là où l'outil ne regarde pas : WEB-INF/web.xml dans un war, CATALINA_BASE externe, paramètres de démarrage. C'est pourquoi il n'existe pas de niveau « non affecté » — tout ce qui est introuvable tombe dans à confirmer manuellement.

Deux : même quand on trouve, ce n'est pas toujours exactement ça. Par exemple, dans le server.xml officiel par défaut, AprLifecycleListener est activé par défaut, mais il ne fait que tenter de charger la bibliothèque native — si la bibliothèque n'existe pas, le connecteur APR ne s'active pas. C'est donc un « marqueur faible » : une correspondance ne rapporte que « possible », pas « confirmé ».

Trois : il n'existe aucune version 8.5 vers laquelle migrer. first_patched_version des 14 entrées est null côté 8.5. Ce n'est pas « pas encore corrigé », c'est « ne sera plus corrigé pour 8.5 ». La seule issue est de changer de ligne (9.0 / 10.1 / 11.0). Cet outil répond « de quoi êtes-vous touché », il ne prétend pas répondre « vers quel 8.5 migrer ».

Encore une chose qui peut vous faire croire que « l'outil se trompe » : une même CVE a plusieurs évaluations

Prenons CVE-2025-55754, les quatre chiffres sont tous vrais :

Si vous ne regardez que NVD, vous croirez que c'est la plus grave ; si vous ne regardez qu'Apache, vous croirez pouvoir l'ignorer. Les deux ont raison — Apache évalue l'exploitabilité réelle en configuration par défaut, CVSS est un calcul mécanique à partir du vecteur, sans vérifier si vous avez activé la fonctionnalité.

C'est pourquoi cet outil imprime les quatre chiffres, et signale explicitement quand les deux côtés divergent.

Les deux vocabulaires ne sont pas équivalents, l'alignement ne se fait que sur l'étape officiellement prise en charge

Apache utilise low / moderate / important / critical, GitHub utilise low / medium / high / critical. La base d'alignement vient du texte original de security-impact.html officiel de Tomcat :

Important / High — A vulnerability rated as Important (or High) impact is one which could result in the compromise of data or availability of the server.

→ Important et High sont deux appellations d'un même niveau, c'est écrit ensemble par l'officiel. 🔴 En revanche, l'officiel ne dit pas que moderate et medium s'alignent, et l'outil ne le fait pas non plus à sa place — le Moderate de l'ASF définit des conditions d'exploitabilité comme « facteurs d'atténuation significatifs / n'affecte pas les configurations courantes / nécessite une authentification », tandis que le medium de GitHub est un intervalle de score CVSS ; les deux ne sont pas la même chose. Dans ce cas, le rapport indique « l'officiel ne dit pas que ces deux niveaux sont égaux » et vous présente les deux.

Selon ce critère, sur les 14 entrées, 5 sont jugées substantiellement différemment des deux côtés (le plus éloigné : CVE-2025-52520 : Apache low / GitHub high), 2 ne s'alignent pas, 7 sont identiques.

D'où viennent les données et comment les reproduire

La table de décision CveTable.java est générée, aucune ligne n'est recopiée à la main :

Avant publication / diffusion, une re-vérification indépendante est également exécutée — elle ne lit pas le sources.json ci-dessus, mais analyse le CveTable.java généré, puis interroge NVD par cpe :

Cette étape n'est pas une formalité : dès sa première exécution, elle a attrapé une vraie erreur. Le script de génération, pour juger « NVD contient-il 8.5 », ne reconnaissait que « borne inférieure commençant par 8.5 », or CVE-2025-24813 indique versionStartIncluding=None .. versionEndExcluding=9.0.99 — borne inférieure ouverte, elle couvre donc 8.5. La différence en était faussée d'une entrée supplémentaire. Une recherche entrée par entrée sur cveId ne l'aurait jamais détectée ; c'est en passant au critère « interroger 8.5.100 par cpe », du point de vue utilisateur, que l'erreur est apparue.

Construction

Nécessite JDK 17+. Zéro dépendance à l'exécution, JUnit uniquement pour les tests.

License

MIT — voir LICENSE