Queste 14 voci, nei tre posti in cui andresti a cercarle, appaiono così:

L'unico posto che racconta l'intera storia è il record originale che Apache, in qualità di CNA, ha inviato a CVE.org — cioè il livello che meno persone vanno a spulciare. Questo strumento fa proprio questo: prende le informazioni da quel livello e le confronta con la versione realmente installata sulla tua macchina.

🔴 Questo strumento descrive le differenze tra le fonti dati, non il comportamento di un prodotto. «Il tuo scanner segnalerà o no queste 10 voci» dipende da quale database legge e da come le unisce — non è stato testato, quindi qui non verrà scritto.

L'altra metà, altrettanto importante: di queste 14, solo 2 colpiscono con la configurazione predefinita

Segnalare solo in base al numero di versione equivale a dire «sei vulnerabile» anche per le 12 voci che richiedono una configurazione specifica — ti farebbe fare qualcosa di non necessario.

Per questo, quando gli passi la directory di installazione, lo strumento legge tutti gli XML in conf/ (incluso conf/Catalina/<host>/), rimuove i blocchi di commento e poi cerca i marcatori delle condizioni di attivazione. Rimuovere i commenti non è opzionale: nel server.xml ufficiale, la ricerca testuale di UpgradeProtocol trova 1 occorrenza, ma dopo aver tolto i commenti è 0 — l'intero blocco è commentato.

Su una installazione pulita della 8.5.100 ufficiale, l'output è questo:

Attivando nella stessa configurazione HTTP/2, RewriteValve e CGIServlet, le «confermate dalla configurazione» diventano 5.

Utilizzo

Come viene riconosciuta la versione nelle installazioni decompresse

I jar in lib/ non hanno alcun numero di versione nel nome file (è catalina.jar, non catalina-8.5.100.jar). Gli strumenti che ricavano la versione solo dal nome file, su questo tipo di installazioni non riconoscono nulla — e «non ha trovato nulla» sembra identico a «sei al sicuro».

Questo strumento ricava la versione in quest'ordine:

1. server.number da catalina.jar!/org/apache/catalina/util/ServerInfo.properties — è quello che riporta lo version.sh di Tomcat stesso
2. Implementation-Version da META-INF/MANIFEST.MF
3. Il nome file (solo per forme come quelle embedded di Spring Boot)

Se le due fonti non coincidono (ServerInfo.properties può essere sovrascritto, spesso per nascondere la versione), vengono riportate entrambe, senza scegliere al posto tuo.

Tre limiti che non vengono superati

Uno: posso confermare che è attivo, non che non lo sia. Se il report dice «non trovato», significa non trovato nei file che ho esaminato, non «non è attivo». La configurazione può trovarsi in posti che questo strumento non vede: WEB-INF/web.xml dentro i war, CATALINA_BASE esterno, parametri di avvio. Per questo non esiste la fascia «non vulnerabile» — se non trovo nulla, finisce comunque in da verifica manuale.

Due: anche se lo trovo, non è detto che sia proprio quello. Per esempio, nel server.xml predefinito ufficiale, AprLifecycleListener è già abilitato di default, ma si limita a tentare di caricare la libreria nativa — se la libreria non c'è, il connettore APR non si attiva. Quindi è un «marcatore debole»: se lo trovo, segnalo solo «possibile», non «confermato».

Tre: non esiste una versione 8.5 a cui aggiornare. Il first_patched_version di tutte e 14 le voci è null lato 8.5. Non è «non ancora corretto», è «non verrà più corretto per la 8.5». L'unica via d'uscita è cambiare linea (9.0 / 10.1 / 11.0). Questo strumento risponde a «a cosa sei vulnerabile», non finge di saper rispondere a «a quale 8.5 aggiornare».

Un'altra cosa che può farti pensare che «lo strumento sbagli»: la stessa CVE ha più valutazioni

Prendiamo CVE-2025-55754: tutti e quattro i numeri sono veri:

Se guardi solo NVD, penseresti che sia la più grave; se guardi solo Apache, penseresti che puoi ignorarla. Nessuno dei due ha torto — Apache valuta la sfruttabilità reale con la configurazione predefinita, CVSS è un calcolo meccanico basato sul vettore, che non guarda se hai attivato o no quella funzionalità.

Per questo lo strumento stampa tutti e quattro i numeri e, quando le due parti discordano, lo dice esplicitamente.

Le due tassonomie non sono la stessa cosa: l'allineamento copre solo il passo supportato ufficialmente

Apache usa low / moderate / important / critical, GitHub usa low / medium / high / critical. La base dell'allineamento viene dal testo ufficiale di security-impact.html di 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 e High sono due nomi per lo stesso livello, scritti insieme dagli stessi sviluppatori. 🔴 Invece per moderate e medium l'ufficialità non dichiara un allineamento, e questo strumento non lo fa al posto loro — il Moderate di ASF definisce condizioni di sfruttabilità come «fattori di mitigazione significativi / non tocca le configurazioni comuni / richiede autenticazione», mentre il medium di GitHub è un intervallo di punteggio CVSS: non sono la stessa cosa. In questo caso il report dice «l'ufficialità non dichiara questi due livelli uguali» e ti mostra entrambi.

Con questo criterio, delle 14 voci 5 hanno valutazioni sostanzialmente diverse tra le due parti (il caso più estremo è CVE-2025-52520: Apache low / GitHub high), 2 non sono allineabili, 7 coincidono.

Da dove vengono i dati e come riprodurli

La tabella di valutazione CveTable.java è generata, nessuna riga scritta a mano:

Prima di pubblicare/rilasciare viene eseguita anche una verifica con criterio indipendente — non legge il sources.json di cui sopra, ma analizza il CveTable.java generato e poi interroga di nuovo NVD tramite cpe:

Questo passaggio non è una formalità: al primo run ha trovato un errore vero. Lo script di generazione, per decidere se «NVD ha la 8.5», riconosceva solo gli intervalli con limite inferiore che inizia per 8.5, mentre CVE-2025-24813 riporta versionStartIncluding=None .. versionEndExcluding=9.0.99 — limite inferiore aperto, quindi copre la 8.5. La differenza contava quindi una voce in più. Controllare voce per voce il cveId non lo avrebbe mai scoperto; è emerso solo adottando il punto di vista dell'utente, cioè «cerca 8.5.100 tramite cpe».

Build

Richiede JDK 17+. Zero dipendenze a runtime, JUnit solo in fase di test.

License

MIT — vedi LICENSE