xiaoqimikko/spring-cvss-checkEscanea artefactos y código fuente de Java en busca de CVEs de Spring/Tomcat, compara las puntuaciones CVSS del proveedor frente a las de NVD, verifica las condiciones de explotabilidad y comprueba si existen versiones corregidas en Maven Central.
Cubre 15 avisos de seguridad oficiales de Spring / Tomcat (siete del 2026-08-20 · cinco del 2026-06-08 · uno del 2025-09-15 · dos de Tomcat del 2026-08-25).
De esos 15, en 8 casos los escáneres conectados a NVD reportan CRITICAL 9.1~9.8, mientras que la valoración oficial del fabricante es LOW / MEDIUM.
En los otros 7, ambas valoraciones coinciden por completo — la única diferencia: si el fabricante envió o no su propia puntuación CVSS para el registro del CVE.
Esta herramienta responde a cuatro preguntas:
| CVE | Componente | Oficial del fabricante | NVD | Quién puso la puntuación en NVD |
|---|
| CVE-2026-59313 | Spring Framework | LOW | 9.8 CRITICAL | CISA-ADP |
| CVE-2026-47890 | Spring Framework | LOW | 9.8 CRITICAL | CISA-ADP |
| CVE-2026-59283 | Spring Framework | MEDIUM | 9.1 CRITICAL | CISA-ADP |
| CVE-2026-47891 | Spring Framework | MEDIUM | 9.8 CRITICAL | CISA-ADP |
| CVE-2026-47884 | Spring Framework | MEDIUM | 9.8 CRITICAL | CISA-ADP |
| CVE-2026-47892 | Spring Framework | MEDIUM | 9.8 CRITICAL | CISA-ADP |
| CVE-2026-65637 | Apache Tomcat | Moderate | 9.8 CRITICAL | CISA-ADP |
| CVE-2026-65905 | Apache Tomcat | Low | 9.8 CRITICAL | CISA-ADP |
| CVE-2026-59270 | Spring Security | CRITICAL | 9.4 CRITICAL | Autoevaluación del fabricante ✅ Coincide |
El único caso en el que ambas coinciden es precisamente aquel en el que el fabricante envió su propio CVSS a NVD.
La causa no es que alguien oculte algo: cuando el fabricante no envía su puntuación, CISA-ADP la asigna automáticamente según el peor escenario, y la mayoría de las herramientas SCA toman ese valor de NVD.
No es un Bug, son dos sistemas de puntuación con criterios propios — pero tu proceso de respuesta ante incidentes se rige por el 9.8.
Probado en la práctica (con control positivo, se re-ejecuta cada vez que se genera la tabla de reglas):
spring-web 6.2.19 = 200 ← la versión anterior sí está en Central
spring-web 6.2.20 = 404 ← a la que el fabricante te pide subir, no existe
spring-security-core 6.5.11 = 200
spring-security-core 6.5.12 = 404
En la tabla de versiones de corrección oficial, estas versiones están marcadas como Enterprise Support Only — solo disponibles para clientes con soporte comercial.
Así que si realmente te afecta, tus opciones son:actualizar a una versión mayor, o comprar soporte comercial.
java -jar spring-cvss-check.jar <jar|war|directorio>... [--src <directorio de código fuente>]
# Lo más común: escanear el artefacto compilado para fijar la versión y el código fuente para las condiciones de activación
java -jar spring-cvss-check.jar target/ --src src/main
# También vale con un único fat jar / war
java -jar spring-cvss-check.jar app.war
Requiere JDK 17+. Cero dependencias en tiempo de ejecución, sin conexión a red.
Códigos de salida:0 la versión no está afectada · 2 la versión está afectada pero no se encontraron condiciones de activación · 3 las condiciones de activación también se cumplen.
== Versiones detectadas ==
Spring Framework 6.2.19 .../spring-core-6.2.19.jar
Spring Security 6.5.11 .../spring-security-core-6.5.11.jar
Apache Tomcat 9.0.37 .../tomcat-embed-core-9.0.37.jar
== La versión está afectada por 8 avisos ==
-- CVE-2026-47884 Spring Framework Improper Path Limitation in XsltView
Producto Spring Framework Afecta 6.2.0 - 6.2.19
[Diferencia] Oficial **MEDIUM** <-> NVD **CRITICAL 9.8**
Esa puntuación en NVD no la puso el fabricante, sino CISA-ADP.
Condición Solo si se usa XsltView, existe un mapeo "/**" que pase por el renderizado de vistas y el nombre de la vista no se especifica explícitamente
[Afectado] Se encontró en tu código/configuración:
src/main/java/demo/ReportView.java <- XsltView(línea 2)
[Sin actualización] El fabricante pide subir a 6.2.20 —— **esa versión no existe en Maven Central (404)**, marcada oficialmente como Enterprise Support Only
== Resumen ==
Tu escáner puede reportar 7 de estos 8 avisos como CRITICAL;
mientras que la valoración **oficial del fabricante** es: 3 LOW / 4 MEDIUM / 1 CRITICAL.
De estos 8, en 6 no se encontraron condiciones de activación en tu código fuente; en 2 sí se encontraron.
[!] De estos 8, la versión de corrección oficial de 7 **no existe en Maven Central**
La tabla anterior puede dar a entender que «NVD siempre puntúa mal». No es así. En el mismo lote de datos hay otros 7 avisos donde la valoración oficial y la de NVD coinciden por completo:
| CVE | Componente | Oficial del fabricante | NVD | Quién puso la puntuación en NVD |
|---|---|---|---|---|
| CVE-2026-59270 | Spring Security | CRITICAL | 9.4 CRITICAL | Autoevaluación del fabricante |
| CVE-2026-41843 | Spring Framework | MEDIUM | 5.9 MEDIUM | Autoevaluación del fabricante |
| CVE-2026-41844 | Spring Framework | MEDIUM | 4.2 MEDIUM | Autoevaluación del fabricante |
| CVE-2026-41846 | Spring Framework | MEDIUM | 5.9 MEDIUM | Autoevaluación del fabricante |
| CVE-2026-41853 | Spring Framework | MEDIUM | 5.3 MEDIUM | Autoevaluación del fabricante |
| CVE-2026-41848 | Spring Framework | LOW | 3.7 LOW | Autoevaluación del fabricante |
| CVE-2025-41249 | Spring Framework | HIGH | 7.5 HIGH | Autoevaluación del fabricante |
No hay contraejemplos en ninguna de las dos direcciones, y esta es la única conclusión causal que esta herramienta se atreve a afirmar:
[email protected] (enviada por el propio fabricante)CISA-ADP (el fabricante no envió nada y un tercero puntuó automáticamente según el peor escenario)El script de generación usa dos aserciones para vigilar cada una de estas direcciones (ASSERT4 / ASSERT7); si aparece cualquier contraejemplo, se niega a generar la tabla.
🔑 Por qué validar ambas direcciones: que «todas las coincidentes sean autoevaluación del fabricante» no descarta que «algunas de las divergentes también sean autoevaluación del fabricante». Si apareciera una entrada así, la causalidad tendría un contraejemplo, y validando solo una dirección la tabla se generaría igual y saldría toda en verde. Una aserción unidireccional no demuestra causalidad.
spring-core-5.3.39.jar, se detectarán 11 avisos, y para esos 11 la versión de corrección oficial
no existe en el Maven Central público (5.3.45 / 5.3.49 / 5.3.50, todas marcadas Enterprise Support Only).La tabla de reglas la genera tools/gen_rules.py a partir de cuatro fuentes primarias, sin transcripción manual:
| Fuente | Qué se obtiene | |
|---|---|---|
| A | spring.io/security/<cve> | Valoración oficial / rango afectado / versión de corrección (incluida la marca OSS ⟷ Enterprise) |
| B | tomcat.apache.org/security-{9,10,11}.html | Igual que arriba |
| C | NVD REST API | Valoración de NVD y fuente de la puntuación |
| D | repo1.maven.org(HEAD) | Si la versión a la que el fabricante pide actualizar existe realmente en Central |
Volver a ejecutarlo es volver a verificar:
python tools/gen_rules.py
El script contiene seis aserciones; si alguna falla, se niega a generar la tabla, y tres de ellas vigilan directamente las afirmaciones de esta herramienta:
ASSERT2 Número de avisos donde oficial⟷NVD no coinciden —— si llega a cero, la afirmación ha dejado de ser válida y se detiene al momentoASSERT3 La detección en Central incluye control positivo —— si el control falla, todos esos 404 quedan invalidadosASSERT4 En los avisos coincidentes, la fuente de la puntuación debe ser la autoevaluación del fabricante —— es la única evidencia de la «causa»Apache-2.0