netty-resolver-dns-check

Comprobador estático sin conexión que inspecciona los jars de Java empaquetados en busca de versiones vulnerables de netty-resolver-dns y detecta si Spring WebClient realmente utiliza el resolutor DNS de Netty.

Y no está solo en el classpath. El HttpClient de Reactor Netty — el conector que Spring Boot elige para WebClient siempre que Reactor Netty esté presente — resuelve nombres de host con el propio DnsAddressResolverGroup de Netty, no con el resolver del JDK:

• HttpClientConfig.defaultAddressResolverGroup() → HttpResources.getOrCreateDefaultResolver()
• TcpResources.getOrCreateDefaultResolver() → NameResolverProvider.newNameResolverGroup(...)
• NameResolverProvider.newNameResolverGroup → new DnsNameResolverBuilder() → new DnsAddressResolverGroup(builder)

(Lo mismo en reactor-netty 1.1.x, 1.2.x, 1.3.x y main.) El orden de detección de conectores de Spring Boot es reactor > jetty > httpComponents > jdk, así que Reactor Netty gana siempre que esté ahí.

No nos detuvimos en leer el código fuente. En el experimento controlado de abajo, una app por defecto de Spring Boot 3.5.14 que hacía una petición WebClient envió una consulta DNS real a través del resolver de Netty (WRITE: UDP ... DefaultDnsQuestion(example.com.)).

Los avisos de CVE-2026-45674 y CVE-2026-47691 lo dicen claramente: "Cualquier aplicación que use el resolver DNS de Netty se ve afectada."

2. Qué versiones de Spring Boot incluyen un valor por defecto afectado

Los tres CVE comparten la misma corrección: 4.1.135.Final (línea 4.1) / 4.2.15.Final (línea 4.2). Leído de cada spring-boot-dependencies-<v>.pom (<netty.version>), 2026-09-11:

Las versiones corregidas están todas en Maven Central. Actualizar funciona; esta herramienta no afirma lo contrario.

3. Qué puede y qué no puede decirte el escaneo estático

Un número de versión es una línea de mvn dependency:tree. La pregunta más difícil es si el resolver está realmente en uso. Así que construimos cuatro fat jars reales de Spring Boot 3.5.14 y uno en 3.5.16, y medimos la verdad sobre el terreno — consultas DNS realmente enviadas por Netty — frente a lo que esta herramienta infiere solo del jar:

El resultado honesto: la herramienta dice de forma fiable "en uso" cuando no hay override, y encuentra rastros de override en tu código y configuración (3 de 3, sin falso positivo en A). No puede distinguir B (todo con override) de D (un cliente aún en el valor por defecto) — su evidencia en bytecode es idéntica. Así que un override nunca hace que diga "no afectado"; dice "comprobar manualmente", y te da la comprobación de un minuto de abajo.

La autocomprobación de un minuto

1. Inicia tu app con --logging.level.io.netty.resolver.dns=DEBUG
2. Haz que envíe una petición saliente a través de cada WebClient que tengas
3. Busca WRITE: UDP en el log — presente: el resolver de Netty está en uso; ausente: esa petición no lo usó

No juzgues por "¿se cargó DnsNameResolver?". La app B reemplazó el resolver y aun así cargó esa clase, porque el grupo de resolvers por defecto se construye de forma anticipada. Solo las líneas de consulta son prueba.

Uso

Lee lo que está realmente empaquetado (fat jar BOOT-INF/lib, war WEB-INF/lib, jars anidados), no pom.xml — la dependencia es transitiva, así que el pom te diría que no está ahí. La presencia se decide por la clase io/netty/resolver/dns/DnsNameResolver.class, no por manifiestos de versión. Los rastros de override se buscan solo en tus propias clases y en application*.properties/yml (los jars de bibliotecas referencian estas clases por sí mismos).

La salida está en chino; las líneas de veredicto y los ids de CVE son en lo que los scripts deben basarse.

Lo que no te dice

• Si un atacante puede alcanzarte. CVE-2026-47691, del aviso: un atacante que controle un servidor de nombres autoritativo para un subdominio puede envenenar la caché de dominios padre — así que tu app tiene que resolver un nombre que el atacante controle (por ejemplo, obtener URLs proporcionadas por el usuario). CVE-2026-45673 es medio (6.8) y necesita respuestas falsificadas para llegar a tu resolver. Gravedad según el aviso: dos altas (8.7), una media.
• Los overrides establecidos mediante variables de entorno, o dentro de un jar de biblioteca, son invisibles para un escaneo estático. La herramienta se inclina hacia "en uso" en esos casos.
• Las bibliotecas que usan el HttpClient de Reactor Netty directamente (por ejemplo una pasarela) no se analizan por separado — si Reactor Netty está presente, se asume la ruta por defecto.
• Las versiones fuera de las líneas 4.1 y 4.2 se reportan como "no se puede juzgar", no se adivinan.

De dónde vienen las reglas

API de avisos de GitHub, leída el 2026-09-11:

La tabla de Spring Boot está en BootTable.java; una prueba unitaria vuelve a derivar las tres afirmaciones de la sección 2 a partir de ella, así que la tabla y las afirmaciones no pueden divergir en silencio.

El experimento controlado

evidence/ contiene las cinco apps (A–E) y runtime.sh, que cuenta las líneas WRITE: UDP por app. tools/e2e_real_jars.py ejecuta esta herramienta contra los mismos cinco jars y verifica cada veredicto. Compilar las apps requiere Maven 3.6.3 o superior.

Códigos de salida

Licencia

Apache License 2.0