El Exchange que dejaste encendido: 21.899 servidores sin parchear y el tuyo puede ser uno

El 31 de agosto de 2026, los escaneos diarios de la Shadowserver Foundation contaban 21.899 direcciones IP con un Exchange Server sin el parche de CVE-2026-62911, publicado veinte días antes. Es fácil suponer que son empresas que nunca se movieron a la nube. De los que nos encontramos nosotros, buena parte son justo lo contrario: organizaciones que ya migraron y que conservan un Exchange encendido porque alguien dijo, hace años, que hacía falta para gestionar los usuarios.

Ese servidor tiene una particularidad incómoda: no aparece en las reuniones. No hospeda buzones, no tiene usuarios quejándose, no genera tickets. Solo está ahí, publicado en internet, con la misma superficie de ataque que el día que se instaló. Y desde el 14 de octubre de 2025 tampoco recibe actualizaciones de seguridad, salvo que alguien pagara por ellas.

Qué es CVE-2026-62911 y qué no es

Microsoft lo publicó el 11 de agosto de 2026 y lo describe como una elevación de privilegios: un atacante capaz de capturar y reproducir material de autenticación puede reutilizarlo para obtener acceso elevado. La clasificación es CWE-294 —omisión de autenticación por captura y repetición— con una puntuación CVSS de 8.0. Afecta a Exchange Server 2016 CU23, a Exchange Server 2019 CU14 y CU15, y a Exchange Server Subscription Edition RTM.

Aquí hay que parar en algo que casi ninguna cobertura dice: las fuentes no cuentan lo mismo. El vector que publica Microsoft exige privilegios previos bajos e interacción de un usuario. La Oficina Federal de Seguridad alemana, en cambio, describe una prueba de concepto que permite tomar el control de sistemas desde internet sin autenticación previa, y los análisis de terceros van en esa línea. Uno de los dos matiza de más. Nosotros no vamos a resolver esa discrepancia desde fuera, pero tampoco la vamos a esconder: si estás decidiendo tu urgencia de parcheo con la puntuación de 8.0 y el vector de Microsoft, estás decidiendo con la lectura más benévola de las dos.

Lo que sí está confirmado por una autoridad nacional: el NCSC de los Países Bajos avisó de que hay un exploit funcional circulando. A partir de ahí, la ventana entre «esto es teórico» y «esto es un incidente» la marca el atacante, no tú.

El detalle que hace este fallo distinto

Si la lectura pública es correcta, el camino de entrada es el extremo que se usa para mover buzones entre tu Exchange y Exchange Online. Léelo otra vez: la puerta es la que abriste para migrar a la nube. Cuanto más ordenada fue tu migración —híbrido bien montado, endpoint de migración publicado, certificado en regla—, más probable es que esa puerta siga exactamente donde la dejaste, cuatro años después de que el último buzón cruzara.

Los números por país refuerzan la idea. Estados Unidos encabeza la lista con 6.200 servidores sin parchear y Alemania la sigue con 5.100. Pero el dato que de verdad explica el fenómeno lo publicó la autoridad alemana a finales de agosto, y es de una sequedad difícil de mejorar: solo tenían constancia de nueve servidores Exchange 2016 o 2019 en toda Alemania con los parches del programa de actualizaciones extendidas instalados. Nueve. La misma nota estimaba que alrededor del 85% de los Exchange locales alemanes que ven seguían siendo vulnerables; el denominador de ese porcentaje no está especificado, así que lo tomamos como orden de magnitud y no como censo.

«Es que lo necesito para gestionar los usuarios»

Esta frase fue verdad durante años, y tiene hasta nombre propio en la documentación de Microsoft: el problema del último servidor Exchange. Con sincronización de directorio, los atributos de correo de un usuario se editan en el Active Directory local y viajan a la nube; y los únicos comandos soportados para tocarlos son los del Exchange local. Ni ADUC, ni ADSI Edit, ni utilidades de terceros. Por eso miles de migraciones terminaron con la misma cantinela: «dejamos uno para gestión».

Dejó de ser obligatorio en abril de 2022. Desde la actualización acumulativa de Exchange 2019 de ese mes —CU12 en adelante— las herramientas de administración se pueden instalar solas, en cualquier máquina unida al dominio, y gestionar los destinatarios desde PowerShell sin ningún Exchange en marcha. Estas son las condiciones que pone Microsoft, y hay que cumplirlas todas:

Aquí conviene no quedarse en 2022, porque Microsoft ha movido la recomendación. En su artículo de mayo de 2026 sobre cómo retirar el último Exchange, califica esa vía de las herramientas de administración de «solución temporal»: te deja apagar el servidor, pero no desinstalarlo, y sobre todo deja la autoridad sobre los atributos anclada en tu Active Directory. El problema del último servidor sigue abierto, solo que con la luz apagada.

Apagarlo y quitarlo no son la misma decisión

La vía que Microsoft describe hoy para acabar el trabajo es transferir a la nube la autoridad sobre los atributos —marcando cada buzón sincronizado como gestionado en la nube, o pasando el objeto entero a la nube— y entonces sí desinstalar el servidor con Setup /m:Uninstall. Es la diferencia entre un servidor apagado que sigue estando en el Active Directory y una organización que ya no tiene Exchange local que mantener.

Y aquí va el aviso que Microsoft escribe con mayúsculas y que se mezcla constantemente: si estás gestionando destinatarios con las herramientas de administración, NO desinstales. El desinstalador borra los contenedores de configuración y los grupos de seguridad de Exchange en el Active Directory, que son justo de lo que dependen esas herramientas para funcionar. En ese escenario el servidor se apaga, se limpia con el script que viene incluido y se formatea, pero nunca se pasa por el desinstalador. Las dos rutas son legítimas; mezclarlas es lo que rompe cosas. Un aviso de propina que está en la documentación y que casi nadie ve venir: si ya ejecutaste la limpieza y solo apagaste el servidor, para desinstalarlo hay que volver a encenderlo, y hacerlo como administrador de dominio, porque el grupo que te daba permiso ya no existe.

Si eliges la vía de las herramientas, dos detalles operativos que se agradecen antes y no después. El primero: en cuanto apagues el servidor, los comandos de creación y modificación tardarán unos 40 segundos en responder, porque el inicializador del registro de auditoría intenta conectarse a una máquina que ya no está; la demora desaparece al ejecutar el script de limpieza de Active Directory que viene con las herramientas. El segundo, más serio: al apagar el último Exchange, el RBAC deja de funcionar. Quien gestionaba destinatarios por pertenecer a un grupo de Exchange se queda sin permisos, y hay que darle acceso con el script que crea el grupo de seguridad correspondiente. Si esto te pilla un lunes por la mañana, no es un incidente de seguridad: es un incidente de recursos humanos.

Cuándo NO hay que apagarlo

Este post no va de apagar servidores por deporte. Va de que cada servidor encendido tenga una razón por escrito. Hay casos en los que la respuesta correcta es dejarlo donde está y tratarlo como lo que es: un sistema en producción, con su ventana de parches y su dueño.

Y si te quedas, hay que decir la parte del calendario que aprieta. Exchange Server 2016 y 2019 dejaron de tener soporte el 14 de octubre de 2025. Las actualizaciones extendidas de seguridad solo llegan a quien está inscrito y acaban el 31 de octubre de 2026. Es decir: quedan menos de dos meses de red de seguridad, y después cada nuevo fallo se queda sin parche para siempre. La salida soportada es Exchange Server Subscription Edition, que a efectos de instalación es una actualización acumulativa más desde 2019 CU14 o CU15 —comparte código con CU15—, pero eso hay que planificarlo ahora, no el 30 de octubre.

Qué haríamos esta semana

Nada de esto es un proyecto de tres meses. Es media mañana de inventario y una decisión.

Es el mismo mecanismo del que hablábamos al analizar la retirada de EWS y por qué la fecha que te afectaba no era la que salía en el titular, y el que aparece cada vez que una caída de Microsoft 365 revela que seis servicios distintos eran en realidad una sola dependencia. El fallo casi nunca está en la tecnología. Está en que nadie tenía escrito qué dependía de qué.

Migrar no termina cuando cruza el último buzón

En los proyectos de Microsoft 365 que hacemos, la parte que más se subestima no es mover el correo: es desmontar lo que se montó para moverlo. El endpoint de migración, la relación de federación, el certificado, el conector de envío, el servidor. Todo eso se crea con prisa porque hay una fecha de corte, y se queda para siempre porque nadie tiene prisa por quitarlo.

Por eso, cuando entramos en un parque a hacer mantenimiento o a revisar la seguridad, una de las primeras preguntas es la más aburrida: qué hay encendido que ya no hace falta. No es una pregunta de ahorro. Es que la superficie de ataque de una empresa no la definen los sistemas que usa, sino los que tiene. Detrás de esas 21.899 direcciones IP hay muchas organizaciones que ni siquiera saben que están en la lista. Ese es exactamente el problema: no es que hayan decidido correr el riesgo, es que nadie se lo ha planteado.

Fuentes: recuento de 21.899 direcciones IP expuestas a 31 de agosto de 2026 y desglose por país (6.200 en Estados Unidos, 5.100 en Alemania), escaneos diarios de la Shadowserver Foundation recogidos por Help Net Security y BleepingComputer; aviso de exploit funcional en circulación, NCSC-NL; los nueve servidores con parches ESU instalados y la estimación del 85% de servidores locales vulnerables en Alemania, publicación del BSI de finales de agosto de 2026 recogida por heise —el denominador del porcentaje no está especificado en la fuente—; descripción, CVSS 8.0, clasificación CWE-294 y versiones afectadas, aviso de Microsoft del 11 de agosto de 2026 y bases de datos de vulnerabilidades públicas. La hipótesis sobre el extremo de migración y la protección extendida de la autenticación procede de análisis técnicos publicados por terceros; no la hemos verificado nosotros y así la presentamos. Procedimiento de las herramientas de administración, aviso de no desinstalar, demora de 40 segundos y pérdida de RBAC, y la ruta de transferencia de autoridad con desinstalación posterior (artículo actualizado en mayo de 2026): documentación oficial de Microsoft Learn. Fin del soporte extendido de Exchange 2016 y 2019 (14 de octubre de 2025) y final de las actualizaciones extendidas de seguridad (31 de octubre de 2026): anuncios de Microsoft.