async-http-client-check

Comprobador offline de los 21 avisos de seguridad a nivel de repositorio de org.asynchttpclient:async-http-client (AsyncHttpClient, "AHC"). Te indica a cuáles está realmente expuesto tu jar, señala los que Dependabot y OSV no pueden ver, y da una respuesta por línea: 3.0.13 (3.x) / 2.16.1 (2.x).

Un solo jar, cero dependencias en tiempo de ejecución, totalmente offline, Java 17+.

---

Por qué existe esto

1. Se publicaron 17 avisos el 2026-08-09 — la base de datos global tiene 4 de ellos

El 2026-08-09 los mantenedores de AsyncHttpClient publicaron 17 avisos de seguridad en el propio repositorio del proyecto (AsyncHttpClient/async-http-client → Security → Advisories).

Dependabot y OSV no leen esa página. Leen la base de datos global de avisos de GitHub. A fecha de 2026-09-19 esa base de datos contiene solo 4 de los 17 (CVE-2026-85716, CVE-2026-85717, CVE-2026-85720, CVE-2026-85721, todos añadidos el 2026-09-17). Los otros 13 devuelven 404 en GET /advisories/<GHSA>; dos de esos 13 incluso tienen IDs CVE (CVE-2026-85718, CVE-2026-85719).

Incluyendo los cuatro avisos más antiguos (CVE-2024-53990, CVE-2026-40490, CVE-2026-45300, CVE-2026-55688), el repositorio lista 21; la base de datos global tiene 8.

2. La versión que Dependabot te dice que instales está ella misma afectada por 5 de ellos

Calcula "la versión que lo soluciona todo" a partir de la base de datos global y la respuesta para 3.x es 3.0.12. OSV coincide: POST /v1/query para 3.0.12 devuelve cero vulnerabilidades.

Los avisos del repositorio dicen que 3.0.12 sigue dentro del rango de cinco:

Aviso	Gravedad	Qué	Requiere
GHSA-rqf5-2wxv-rjf4	alta	Un desafío Digest sin un nonce utilizable se responde con Authorization: Basic, es decir, la contraseña en base64	Un Realm Digest (autenticación de servidor o proxy)
GHSA-jmqq-x5g9-9p2w	alta	Cuando una petición se reenvía a un host diferente, la petición / credenciales del primer host van al segundo host	Reenvío a otro host (un ResponseFilter de failover o la ruta de reintento por IOException) y credenciales o un proxy
GHSA-vvp4-63h8-v5pm	media	Las conexiones NTLM / Negotiate se reutilizan entre principals	NTLM o Negotiate con credenciales por petición
GHSA-f9m8-cv68-674w	media	El Domain de la cookie no se comprueba contra la lista de sufijos públicos (Domain=co.uk)	Un CookieStore compartido entre orígenes
GHSA-qhv6-3pmh-95q4	baja	qop="auth-int" desactiva la autenticación mutua Digest (solo 3.0.12)	Autenticación Digest

Sé preciso con las dos de gravedad alta: filtran credenciales, pero solo si configuraste credenciales (un Realm, Digest/NTLM o un proxy) — y GHSA-jmqq además necesita un reenvío a un host diferente. Un cliente que hace GETs simples sin autenticar no está expuesto a ellas. Esta herramienta no sabe cómo usas el cliente; informa de lo que dice el rango de versiones y te deja la decisión a ti.

Los propios mantenedores lo dicen en el texto de CVE-2026-85721:

Ten en cuenta que 3.0.12 está ella misma afectada por un problema aparte, GHSA-rqf5-2wxv-rjf4 … Actualiza a 3.0.13 para incorporar ambas correcciones.

Así que en 3.x: Dependabot dice 3.0.12, y después de actualizar se muestra en verde. La respuesta real es 3.0.13. En 2.x la respuesta es 2.16.1 en cualquier caso — pero 13 de los avisos que hay detrás siguen siendo invisibles para tu escáner.

3. La bomba de descompresión no necesita configuración

CVE-2026-85721 (alta) es la que se aplica a la configuración por defecto: la descompresión automática de respuestas está activada por defecto, y la ruta HTTP/1.1 infla el cuerpo sin límite de tamaño total. Un servidor malicioso o comprometido — o cualquiera capaz de modificar la respuesta en tránsito — puede enviar un cuerpo gzip/deflate pequeño que agote el heap. Afectados: <= 3.0.11 y <= 2.16.0. Esta sí está en la base de datos global, así que Dependabot alerta sobre ella.

Los límites no están escritos de forma consistente

Los rangos mezclan >=, <=, <, un = 3.0.12 explícito y un 3.0.0 sin operador. El mismo 3.0.11 es seguro para CVE-2026-55688 (< 3.0.11) y afectado para GHSA-v9f2-7rw2-gr2x (<= 3.0.11). La tabla de reglas conserva cada operador exactamente como está escrito; una aserción en tools/gen_rules.py y una prueba unitaria fallan si el límite deja de comportarse así. Cualquier fragmento de rango que el analizador no reconozca es un error — nunca "no afectado".

Cuando el repositorio y la base de datos global contienen ambos un aviso pero no coinciden, la tabla de reglas toma la unión. Hoy es un caso: CVE-2024-53990 — el repositorio solo lista la versión 3.x 3.0.0, la base de datos global también lista 2.x >= 2.1.0, < 2.12.4. Confiar solo en un lado infravaloraría el riesgo.

Y no escanea pom.xml — a propósito

AHC suele ser una dependencia transitiva, incorporada por un SDK o una librería cliente. El artifactId puede que nunca aparezca en tu pom.xml. Esta herramienta lee META-INF/maven/org.asynchttpclient/async-http-client/pom.properties dentro de los jars que realmente se distribuyen — incluidos los jars anidados en un fat-jar de Spring Boot (BOOT-INF/lib) o un WAR (WEB-INF/lib). La coordenada heredada 1.x com.ning:async-http-client tiene el mismo artifactId; se lista pero no se evalúa.

Uso

java -jar async-http-client-check.jar target/                 # scan build output
java -jar async-http-client-check.jar myapp.jar               # fat-jar / war, nested jars included
java -jar async-http-client-check.jar --version-of 3.0.12     # judge a version directly

Cada coincidencia imprime el ID (CVE si lo hay, si no GHSA), la gravedad, el título, la versión corregida y Dependabot/全局库:未收录 ("no está en la base de datos global") cuando corresponde. La salida está en chino.

Códigos de salida

Código	Significado
0	No afectado por ninguno de los 21, y todos los archivos se leyeron realmente
1	Afectado
2	No se pudo evaluar — argumentos incorrectos, no se encontró ningún jar de AHC, versión no reconocida, o una versión preliminar que queda fuera de los rangos publicados
4	Algún archivo no se pudo leer — no es un zip, está truncado, o un fallo de E/S

"No pude leerlo" y "estás a salvo" deben ser dos frases diferentes. Un jar legítimamente vacío (un registro EOCD simple de 22 bytes) no es un fallo de lectura. Si un archivo está afectado y otro es ilegible, el código de salida sigue siendo 1.

Lo que no te dice

• Solo estos 21 avisos, solo async-http-client. Los CVE de Netty en los jars de Netty de los que depende AHC no están cubiertos.
• No se comprueba la alcanzabilidad. La mayoría de los avisos del 2026-08-09 necesitan autenticación, un proxy, WebSocket, cookies o descargas reanudables para importar. La gravedad se imprime tal como se publicó.
• La brecha de información es temporal. GitHub puede añadir los 13 que faltan a la base de datos global en cualquier momento. tools/recheck_before_publish.py comprueba si todavía existe.

Cómo se construye la tabla de reglas

src/main/java/dev/mikko/ahccheck/RuleTable.java está generado, nunca editado a mano:

python tools/gen_rules.py --dry   # run the assertions only
python tools/gen_rules.py         # regenerate the table