Catorce CVE en BIND: el aviso que no va de caídas sino de respuestas falsas

El CERT-In indio publicó el 21 de septiembre el aviso CIVN-2026-0467, que cubre catorce vulnerabilidades en ISC BIND con severidad alta. Lo llamativo no es el número redondo, sino lo que el propio documento pone como consecuencia posible: suplantación de respuestas, envenenamiento de caché e inserción no autorizada de datos en una zona DNS. Integridad, no disponibilidad.

La mayoría de avisos de DNS se leen como un problema de caídas. Este no.

Qué falla y cómo se explota

El aviso reparte las causas entre use-after-free, un error de truncamiento numérico, consumo excesivo de recursos dentro de un bucle, falta de liberación de memoria después de su vida útil, una aserción alcanzable, aceptación de datos no confiables junto a datos confiables, desreferencia de puntero nulo, error de validación de origen, consumo asimétrico de recursos (amplificación), verificación insuficiente de autenticidad de los datos y complejidad algorítmica ineficiente.

Tres de esas clases caen justo sobre la frontera de la integridad. Un error de validación de origen permite que el servidor acepte datos cuyo origen no se estableció bien. La verificación insuficiente de autenticidad hace que una respuesta se dé por buena sin pruebas suficientes. Y aceptar datos no confiables junto a datos confiables deja que el contenido del atacante viaje pegado a lo que el servidor ya se cree.

Para explotarlo hay que enviar consultas DNS, respuestas DNS, registros DNSSEC, datos de transferencia de zona, peticiones TKEY, registros SVCB/HTTPS o peticiones DNS-over-HTTPS construidos a propósito. En las clases de integridad la condición que de verdad importa es que el atacante consiga poner una respuesta o un registro falsos delante de un servidor que actúe sobre ellos. Es exactamente lo que necesita el envenenamiento de caché.

Versiones afectadas

Las releases afectadas son BIND 9.11.0 a 9.18.50, BIND 9.20.0 a 9.20.27 y BIND 9.21.0 a 9.21.25, además de BIND Supported Preview Edition 9.11.3-S1 a 9.18.50-S1 y 9.20.9-S1 a 9.20.27-S1.

El aviso no mapea cada CVE a cada versión, así que toca confirmar contra qué build corrige cada fallo en el índice de avisos de ISC. El CERT-In tampoco afirma que ninguno de los catorce se esté explotando ni publica los requisitos de ataque CVE a CVE.

Una búsqueda en ZoomEye con app="ISC BIND" devolvía 19.364.144 activos. Es una cifra de hosts alcanzables en internet con esa huella, y no dice cuántos son resolvers recursivos con caché envenenable, que es la población que importa aquí. La cifra es de ZoomEye, no del CERT-In.

Qué hacer

Aplicar las actualizaciones que referencia el aviso CIVN-2026-0467. En paralelo, apretar la frontera de confianza: activar y verificar la validación DNSSEC donde el despliegue la soporte, limitar la recursión a clientes conocidos para que un atacante fuera de camino no llegue fácil al resolver, exigir TSIG y autorización explícita de pares en las transferencias de zona, y desactivar dynamic update salvo que de verdad se use.

Añadir monitorización de cambios inesperados en respuestas en caché y en datos autoritativos que cambian fuera de una ventana de cambio. Las fallas de integridad no se anuncian solas: una entrada envenenada vive lo que viva el TTL y redirige tráfico en silencio, sin generar una alerta ni un crash que llame la atención. Ese es el problema real, y por eso este aviso se lee distinto a los demás.