Windows DNS, un 9,8 sin autenticar: lo que convierte un fallo en gusano no es el fallo, es tu red

Coge un portátil, siéntate en la wifi de invitados de tu oficina y lanza un nslookup contra la IP de tu controlador de dominio. Si te responde, el resto de este artículo va contigo, y ninguno de los 972 parches del martes arregla eso.

Microsoft publicó el 8 de septiembre la mayor tanda de parches de su historia, y no hay acuerdo sobre cuántos son. La Zero Day Initiative cuenta 972 CVE de Microsoft y 114 críticos; CrowdStrike da 972 y 113; Tenable titula con 964; buena parte de la prensa dice 973 o 974. Uno de los repasos explica el baile: «dependiendo de cómo cuenten los investigadores los fallos externos y los de Chromium, Microsoft corrigió entre 966 y 997 CVE en esta actualización». Ninguna de esas cifras te dice qué hacer el jueves por la mañana.

El fallo del que todo el mundo habla

CVE-2026-69730 es una ejecución remota de código en el servidor DNS de Windows, crítica, CVSS 9,8, un uso después de liberar según el desglose de Talos. Un atacante sin autenticar envía un paquete manipulado al servicio DNS y ejecuta código en la máquina, sin que nadie haga clic en nada. Dustin Childs, de la Zero Day Initiative, lo despachó como «el sucesor espiritual de SigRed», y añadió: «hace años que no vemos un gusano global, pero con un fallo de DNS haciendo de sucesor espiritual de SigRed, esa realidad podría cambiar rápido».

Conviene fijar el alcance antes de que cunda el pánico por el inventario: esto es el rol de servidor DNS, el que resuelve nombres para los demás, no el cliente DNS que lleva cualquier Windows. Según los repasos publicados, Microsoft lista Windows Server de 2012 a 2025 —Server Core incluido— más Windows 10 en las versiones 1607 y 1809, y Windows 11 no aparece. Ese detalle de las dos versiones cliente, que son las ramas LTSB y LTSC, no sabemos explicarlo del todo: si el rol solo existe en Server, no está claro por qué aparecen ahí. Damos la lista como de segunda mano —la ficha del MSRC se renderiza con JavaScript y no pudimos leerla— y recomendamos comprobarla en la ficha antes de fijar el alcance.

Y no es un fallo de DNS. Son varios. De los veinte que Childs marca como gusanables, tres son del servidor DNS: el 69730, el 69858 y el 72987. Talos lista además el 69813, el 69827 y el 77505, todos ejecución de código con CVSS 8,1. Quien vaya el jueves a parchear «el fallo de DNS» va a encontrarse media docena.

En tu red, «el servidor DNS» es el controlador de dominio

El análisis de CrowdStrike lo dice sin rodeos: «en la mayoría de entornos de Active Directory, el DNS corre en los propios controladores de dominio y no en infraestructura dedicada», de modo que «un exploit exitoso contra un servidor DNS integrado en AD puede entregar ejecución de código en un controlador de dominio». Y apuntan el historial: fallos parecidos del servicio DNS «han atraído históricamente atención rápida tanto de operadores de ransomware como de actores estatales, precisamente por este patrón de colocación».

En el inventario de una empresa de cincuenta personas eso significa que la máquina vulnerable es la misma que guarda las contraseñas de todo el mundo. También es la que nadie quiere reiniciar: se parchea la última precisamente porque es la que más duele si no vuelve.

Los veinte gusanables no son una lista. Son dos

Primero, la atribución, porque se está citando mal por ahí: «gusanable» no es una etiqueta de Microsoft. Es el recuento personal de Childs, y lo dice con esas palabras: «¿que dónde están los fallos gusanables?, preguntarás. Con toda franqueza, hay demasiados para destacar uno. Cuento veinte parches distintos que podrían clasificarse todos como gusanables». En cada uno, «un atacante remoto y sin autenticar podría conseguir ejecución de código arbitrario en los sistemas afectados sin interacción del usuario».

Esos veinte CVE se reparten en trece componentes: servidor DHCP, Active Directory Domain Services, RMCAST, Message Queuing, RRAS, NFS, servidor DNS, cliente SMB, IP Helper, Netlogon, Internet Connection Sharing, SSTP y Failover Cluster. Varios repasos publican una versión recortada de esta lista con un «y otros» al final, y ese «y otros» es justo donde está lo interesante, porque los trece componentes no se comportan igual. Se parten en dos grupos que piden trabajos distintos, y esta separación es lectura nuestra, no de las fuentes.

Grupo uno: superficie irreducible. Servidor DNS (tres CVE), servidor DHCP (dos), Netlogon (uno) y Active Directory Domain Services (uno). Siete de los veinte. Estos son los servicios que un puesto unido al dominio tiene que poder alcanzar para funcionar: sin DNS no resuelve, sin Netlogon no inicia sesión, sin DHCP no tiene ni dirección. Aquí la segmentación no te salva del puesto de trabajo. Si cortas el 53 del controlador a los portátiles, dejas de tener dominio a la primera renovación de tickets. Lo único que se puede hacer con este grupo es parchear rápido y controlar qué otros segmentos llegan hasta ahí.

Grupo dos: roles que alguien instaló. RMCAST (tres CVE), Message Queuing (dos), Failover Cluster (dos), RRAS, NFS, Internet Connection Sharing y SSTP (uno cada uno). Once de los veinte, más de la mitad. Ninguno de estos viene activo de fábrica en un Windows Server recién instalado. El multicast fiable de RMCAST hace falta si alguien montó PGM; NFS existe para hablar con Unix o con un almacén de ESXi; RRAS es enrutamiento y VPN; SSTP es un túnel; Message Queuing es la lección de QueueJumper en 2023, cuando medio mundo descubrió que tenía MSMQ instalado por un producto de terceros que lo arrastró. Estos once CVE solo son gusanables donde alguien encendió el rol y se le olvidó.

Quedan dos que no entran en ninguno de los dos grupos, y decir que sí sería redondear a costa de la verdad. El cliente SMB se explota al revés: no es un servicio que el portátil alcance en el controlador, es código en el portátil, y quien ataca es el servidor malicioso que responde algo manipulado a una máquina que se conectó a él. E IP Helper tampoco encaja: iphlpsvc corre por defecto en todos los Windows y gestiona túneles IPv6 —Teredo, 6to4, ISATAP—, así que no es un rol opcional ni un servicio del controlador, es algo que ya tienes encendido en todas partes sin haberlo pedido.

La conclusión práctica del reparto es que las dos mitades se gestionan con herramientas distintas. La irreducible se gestiona con orden de parcheo y con quién llega desde dónde, porque no la puedes apagar. La otra se gestiona desinstalando, que es gratis y permanente: un rol que no está no aparece en la lista del año que viene. Y la pregunta que casi nadie sabe responder de memoria no es cuál de los 972 parches le toca, sino cuál de esos siete roles opcionales tiene encendido en cada servidor. Es la misma idea que contábamos en no son fallos viejos, son clases de fallo viejas, aplicada al inventario en vez de al código.

De ahí sale la respuesta a la frase que más veces hemos oído esta semana: «pero nosotros no tenemos el DNS publicado en internet». Correcto, y no te salva. Un gusano interno no entra por el cortafuegos perimetral. Entra en el portátil de alguien que abrió lo que no debía, y ese portátil tiene permiso, por diseño, para hablar con el puerto 53 del controlador de dominio. La superficie que cuenta aquí es la que ve la primera máquina que caiga.

Lo que no vamos a decirte: que viene un gusano

SigRed, la referencia que todo el mundo está usando, fue CVE-2020-1350: un 10,0 en el servidor DNS de Windows, julio de 2020, diecisiete años latente en el código, con una mitigación por registro para quien no pudiera parchear a tiempo —TcpReceivePacketSize a 0xFF00 bajo la clave de parámetros del servicio DNS, documentada en el KB4569509—. Aquel julio se dijo exactamente lo que se está diciendo esta semana. El gusano global no llegó.

A 9 de septiembre, cuando escribimos esto, CVE-2026-69730 no figura en el catálogo KEV de CISA y no hemos encontrado prueba de concepto pública. Lo que sí hay, y sería tramposo callarlo en el párrafo donde presumimos de prudencia, es que Microsoft lo clasifica como «más probable que se explote». Eso es una predicción, no una observación, pero es la predicción de quien ha visto el código. En el otro platillo, uno de los repasos del mes cuenta 58 fallos con esa misma etiqueta y añade que «no hemos visto un repunte correlativo de exploits activos, todavía». Tampoco hemos verificado si Microsoft publicó alguna mitigación alternativa para este caso; los repasos que leímos no la mencionan.

Merece la pena mirar además qué se está explotando de verdad este mes, porque no es el 9,8. Son CVE-2026-81963, en la pila de Windows Update, y CVE-2026-85880, en la llamada a procedimiento local avanzado (ALPC): dos elevaciones de privilegios con CVSS 7,8 que requieren acceso local y sirven para subir a SYSTEM después de haber entrado. Del primero apunta Satnam Narang, de Tenable, que es el primero de siete fallos de elevación en la pila de Windows Update desde 2022 que se explota como día cero; el segundo lo reportaron investigadores externos, entre ellos Proofpoint. El número que asusta y el número que alguien está usando contra alguien rara vez coinciden, y de eso iba el titular no basta para decidir.

Entonces, ¿por qué mover ficha con el de DNS? No por el gusano, sino por la frase corta: ejecución de código sin autenticar en un controlador de dominio.

Qué haríamos esta semana, en orden

1. Comprobar quién llega al 53, desde donde no debería. Veinte minutos, y es lo que da los disgustos. Coge un portátil en la wifi de invitados, otro en el rango de la VPN y algo en la VLAN de impresoras o cámaras si la tienes. Hay que probar los dos transportes, porque no son intercambiables: Test-NetConnection <IP-del-DC> -Port 53 comprueba TCP, que es el camino de la clase de fallo de SigRed —de ahí que su mitigación fuera limitar el tamaño de paquete TCP—, mientras que las consultas normales van por UDP, y eso se prueba con Resolve-DnsName -Server <IP-del-DC> ejemplo.com o un nslookup apuntando al controlador. Un cortafuegos puede dejar pasar UDP y bloquear TCP, así que quedarse solo con el primer comando te devuelve un negativo que no significa nada. Si la wifi de invitados resuelve contra tu controlador de dominio, ya tienes el hallazgo del día.

2. Saber qué máquinas tienen el rol, no cuáles crees que lo tienen. Get-WindowsFeature DNS en cada servidor, o directamente sobre todos a la vez con un Invoke-Command alimentado por Get-ADComputer -Filter {OperatingSystem -like "*Server*"}. Y ya que pasas por todos, saca en la misma vuelta los siete roles del grupo dos: NFS, RRAS, SSTP, Message Queuing, Failover Cluster, ICS y el multicast de RMCAST. Casi siempre aparecen los controladores de dominio y, con una frecuencia que sorprende, un servidor miembro que alguien montó para una prueba en 2019 y que sigue resolviendo.

3. Segmentar lo que sí se puede segmentar. A los puestos de trabajo no les vas a cortar el DNS, el Netlogon ni el SMB del controlador; esa parte de la superficie es irreducible mientras uses Active Directory. Lo que sobra por completo es el resto: invitados, impresoras, cámaras, domótica, el pool de la VPN de proveedores. Ninguno necesita hablar con el controlador de dominio y son justo los segmentos con más máquinas que nadie parchea. Quitar esos orígenes no arregla el CVE. Reduce el número de sitios desde los que se puede lanzar.

4. Parchear los controladores primero, y con criterio. Esto no es heterodoxo: es lo que Microsoft ha recomendado siempre que un fallo afecta al controlador, y lo que casi nadie hace. En Active Directory no existe «el secundario» —desde Windows 2000 todos los controladores son iguales y lo que hay son roles FSMO—, así que la secuencia útil es: mira dónde están con netdom query fsmo, empieza por un controlador que no tenga ninguno, verifica con repadmin /replsummary que la replicación sigue limpia y que el servicio DNS responde, y deja el emulador de PDC para el final.

Y una advertencia que tiene que ir junto a ese consejo, porque si no lo estaríamos empujando a un problema peor que el CVE: en un controlador de dominio, restaurar la instantánea de la máquina virtual no es un plan de vuelta atrás. Revertir un controlador provoca un USN rollback que deja la replicación rota de forma silenciosa, salvo que el hipervisor soporte VM-GenerationID y se den las condiciones para que funcione. El rollback de un controlador es desinstalar la actualización, o promocionar otro y degradar el afectado. Con esto no se improvisa a las once de la noche.

El miedo a parchear el controlador no es irracional, por cierto: los parches rompen cosas, y lo contamos con nombre y apellidos cuando un parche de agosto rompió la impresión en aplicaciones WPF. Ese miedo es el mecanismo que produce las medianas de las que hablábamos en la IA encuentra el día cero y tú tardas 43 días. La respuesta no es dejar de parchear, es tener escrito el procedimiento de vuelta atrás y quién lo ejecuta fuera de horario.

5. Mirar qué más carga esa misma máquina. En muchas pymes el controlador de dominio lleva DNS y DHCP, que son dos de los trece componentes de la lista en la misma máquina. Y si tus «dos controladores» son dos máquinas virtuales en el mismo anfitrión, no tienes dos: tienes uno con dos nombres. Ninguna de las dos cosas se arregla esta semana, pero conviene anotarlas hoy para cuando toque decidir dónde va el próximo servidor.

Cuándo esto no va contigo

Si tienes quince portátiles, ningún servidor Windows, la identidad en Microsoft 365 y el DNS lo da el router del operador, nada de este artículo va contigo. No hay rol de servidor DNS, no hay controlador de dominio, y la lista de los veinte no describe tu red porque tu red no obliga a nada de eso. Actualiza los Windows como cualquier mes y dedica la tarde a otra cosa.

Si en cambio tienes dominio, servidores de ficheros, impresoras en la misma VLAN que la gente y una wifi de invitados que nadie ha vuelto a mirar desde que se puso, el trabajo de este mes no es leerte las 972 fichas. Es una tarde de inventario y una tarde de reglas. En redes y comunicaciones eso es literalmente lo que hacemos: mirar quién puede hablar con quién y quitar de en medio lo que no tiene por qué estar. Y sigue valiendo el mes que no sale ningún 9,8.

Nota de fuentes

Del repaso The September 2026 Security Update Review de la Zero Day Initiative, firmado por Dustin Childs, salen: el recuento de 972 CVE de Microsoft y 114 críticos; la cita literal sobre los veinte parches gusanables y la frase sobre el atacante remoto sin autenticar; la relación completa de esos veinte CVE con su componente, de la que sale el reparto en trece componentes que usamos en el artículo (DHCP 69510 y 72979; Active Directory DS 69524; RMCAST 69530, 78449 y 78450; Message Queuing 69579 y 83997; RRAS 69590; NFS ONCRPC XDR 69595; servidor DNS 69730, 69858 y 72987; cliente SMB 72936; IP Helper 72981; Netlogon 72982; ICS 72983; SSTP 73009; Failover Cluster 73010 y 78444); y la descripción de CVE-2026-69730 con su CVSS 9,8 y la referencia a SigRed. La agrupación de esos trece componentes en «superficie irreducible» y «roles que alguien instaló», y la lectura de que la primera se gestiona parcheando y la segunda desinstalando, son NUESTRAS y no de ninguna de las fuentes citadas. Varios repasos publican una versión abreviada de la lista de componentes terminada en «y otros»; nosotros dimos esa versión corta por completa en un primer borrador y el fact-check interno lo corrigió. De la cobertura de Help Net Security salen las citas de Childs sobre el sucesor espiritual de SigRed y el gusano global, la atribución a Satnam Narang (Tenable) de que CVE-2026-81963 es el primero de siete fallos de elevación en la pila de Windows Update desde 2022 explotado como día cero, y la participación de investigadores de Proofpoint en el reporte de CVE-2026-85880; no hemos verificado la lista completa de créditos de ese CVE, por eso decimos «entre ellos». Del análisis de CrowdStrike salen el recuento alternativo de 972 y 113 críticos y las tres frases sobre la colocación del DNS en los controladores de dominio. Del resumen de Security Affairs sale la frase sobre el rango de 966 a 997 CVE según cómo se cuenten los fallos externos y de Chromium, el recuento de 58 fallos etiquetados por Microsoft como «más probable que se exploten» y la observación de que no se ha visto un repunte correlativo de explotación activa. Del desglose de Cisco Talos salen la clasificación de CVE-2026-69730 como «más probable que se explote», que es un uso después de liberar, y los otros CVE del servidor DNS con CVSS 8,1 (69813, 69827, 69858, 72987 y 77505). La lista de versiones afectadas procede de los recopilatorios públicos y NO está verificada en la ficha del MSRC, que se renderiza con JavaScript y no pudimos leer; la anomalía de que aparezcan Windows 10 1607 y 1809 la dejamos declarada como algo que no sabemos explicar. Los datos de SigRed (CVE-2020-1350, CVSS 10,0, julio de 2020, diecisiete años en el código, TcpReceivePacketSize a 0xFF00, KB4569509) proceden de la documentación de Microsoft y de los análisis publicados entonces; QueueJumper es CVE-2023-21554. Que a 9 de septiembre de 2026 CVE-2026-69730 no figura en el catálogo KEV de CISA y que no encontramos prueba de concepto pública es una comprobación nuestra en esa fecha, no una garantía. El aviso sobre el USN rollback al revertir instantáneas de un controlador de dominio y el comportamiento de VM-GenerationID son de la documentación de Active Directory de Microsoft. Las citas en castellano y catalán son traducción nuestra del original inglés. Los comandos son los estándar de Windows Server y no sustituyen a la comprobación en tu entorno. La fotografía de portada es de dominio público.