BIND 9: cuatro CVE, una puede permitir ejecución de código

El 21 de octubre de 2026 el Canadian Centre for Cyber Security publicó el aviso AV26-1072 sobre cuatro vulnerabilidades de BIND 9, el servidor DNS de Internet Systems Consortium (ISC) muy extendido en Linux y Unix, tanto como resolver interno como servidor autoritativo. Al día siguiente el CERT.LV, el CERT nacional de Letonia, recogió la noticia añadiendo las puntuaciones de gravedad y las versiones corregidas, y heise Security la publicó con un titular que habla de un fallo que permite introducir código en el servidor de nombres.

La más grave es la CVE-2026-94300: según el CERT.LV, en determinadas condiciones puede permitir a un atacante ejecutar código arbitrario de forma remota. Las otras tres pueden detener el servicio DNS o agotar sus recursos. Ninguna de las fuentes informa, por ahora, de explotación activa.

Las cuatro vulnerabilidades

Los títulos de las CVE son los del aviso canadiense; las puntuaciones CVSS proceden del CERT.LV.

• CVE-2026-94300 – mensajes GSS-TSIG concurrentes corrompen la memoria. CVSS 8,1. Es la que, según el CERT.LV, puede llevar a la ejecución remota de código.
• CVE-2026-19630 – agotamiento amplificado de recursos en el procesamiento de los mensajes entrantes. CVSS 7,5.
• CVE-2026-96888 – named puede terminar de forma inesperada cuando se usa una zona de tipo redirect junto con la QNAME minimization en modo strict. CVSS 7,5.
• CVE-2026-97313 – algunas configuraciones RPZ (Response Policy Zone), con determinados patrones de consulta, pueden hacer que el proceso termine de forma inesperada. CVSS 7,5.

El CERT.LV califica una de las vulnerabilidades como «crítica» y las demás como de gravedad alta; sin embargo, la puntuación más alta que indica es 8,1, que en la escala CVSS corresponde a gravedad alta. Para las otras tres CVE, los efectos descritos son fallos de funcionamiento del servidor DNS, un consumo excesivo de CPU y memoria o la denegación de servicio.

Un poco de contexto para entender quién está expuesto. GSS-TSIG es la variante de TSIG basada en GSS-API y Kerberos: en BIND se usa sobre todo para las actualizaciones dinámicas autenticadas, típicas de los entornos integrados con Active Directory, y se activa con opciones como tkey-gssapi-keytab o tkey-gssapi-credential. Las zonas redirect sirven para dar respuestas personalizadas a las consultas de nombres inexistentes; las RPZ son el mecanismo con el que un resolver aplica listas de bloqueo, por ejemplo en un firewall DNS. Las fuentes disponibles no dicen si las CVE ligadas a estas funciones afectan también a los servidores que no las usan: compruébalo en el aviso de ISC de cada CVE.

Versiones afectadas y correcciones

Según el aviso canadiense, están afectadas:

• BIND 9: de la 9.11.0 a la 9.18.50 y de la 9.21.0 a la 9.21.26;
• BIND Supported Preview Edition: de la 9.11.3-S1 a la 9.18.50-S1 y de la 9.20.9-S1 a la 9.20.29-S1.

El CERT.LV cita también la rama 9.20 entre las afectadas e indica como versiones corregidas, que ISC pide instalar cuanto antes, la 9.20.30 y la 9.21.27. Las fuentes disponibles no indican una versión corregida para la rama 9.18 ni para las Supported Preview Edition, ni qué versiones afecta cada CVE: el aviso canadiense remite a la matriz de vulnerabilidades de BIND 9 publicada por ISC, que sigue siendo la referencia.

Impacto para las empresas europeas e italianas

BIND está presente en los resolvers internos de muchas empresas, en los servidores autoritativos de proveedores y hosting, en las distribuciones Linux y en dispositivos que lo incluyen. Si el DNS se detiene, se detienen de hecho el correo, las aplicaciones web, las VPN y los servicios internos, aunque los servidores de aplicaciones funcionen. Una corrupción de memoria explotable de forma remota es un riesgo de otro nivel: el servidor DNS ocupa a menudo una posición privilegiada en la red, con visibilidad sobre todas las resoluciones.

Para la NIS2, los proveedores de servicios DNS figuran expresamente entre las infraestructuras digitales; en Italia la directiva se ha transpuesto con el Decreto Legislativo 138/2024. Para las demás entidades, una interrupción del DNS que bloquee servicios esenciales puede convertirse en un incidente que hay que valorar para la notificación al CSIRT nacional, que en Italia es el CSIRT Italia de la ACN. En el sector sanitario, donde también los sistemas clínicos dependen de la resolución de nombres interna, la cuestión es la continuidad operativa.

Qué hacer ya

1. Haz el inventario de los sistemas que ejecutan named: resolvers internos, servidores autoritativos expuestos a Internet, dispositivos que incluyen BIND. Con named -v ves la versión instalada.
2. Actualiza a la versión corregida de tu rama: 9.20.30 o 9.21.27 según el CERT.LV. Para la rama 9.18 y las ediciones -S1, consulta el aviso de ISC. Si usas los paquetes de una distribución Linux, la referencia es el boletín de la distribución, que a menudo incorpora las correcciones sin cambiar el número de versión principal.
3. Da prioridad a los servidores que usan GSS-TSIG, RPZ o zonas redirect con QNAME minimization strict. Una comprobación rápida de la configuración: named-checkconf -p | grep -E 'tkey-gssapi|response-policy|qname-minimization|type redirect'.
4. Reduce la exposición: los resolvers recursivos deberían responder solo a los clientes internos (allow-recursion) y las actualizaciones dinámicas deberían llegar solo desde los sistemas autorizados. Son buenas prácticas generales, no soluciones temporales indicadas por las fuentes: para cualquier workaround, la referencia es ISC.
5. Detecta: vigila las paradas y los reinicios anómalos de named y los picos de CPU y memoria en los servidores DNS. En términos de MITRE ATT&CK, una explotación entraría en T1190 (Exploit Public-Facing Application) para la ejecución de código y en T1499.004 (Application or System Exploitation) para la denegación de servicio.

Cómo ayuda ARXDOME

ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete, para que encuentres rápidamente los servidores con versiones de BIND que hay que actualizar. ARX Expose y ARX Scout te dicen qué servicios DNS de tu empresa son accesibles desde Internet: el primero a partir de fuentes públicas, el segundo con una verificación autorizada de puertos y servicios. ARX Sentry recoge registros y eventos de los servidores Linux, para que una parada anómala de named no pase desapercibida.

Última actualización: 22 de octubre de 2026