Exchange: el parche está hace tres semanas y hay 21.899 servidores sin instalarlo

El 11 de agosto Microsoft publicó el parche. El 28 de agosto el código para atacar la falla ya estaba público y descargable. El 31 de agosto había 21.899 servidores de correo en el mundo todavía sin actualizar. Casi todos son de empresas que no saben que ese servidor sigue prendido.

La falla se llama CVE-2026-62911 y afecta a Exchange Server, el correo corporativo que corre en un servidor propio. No afecta a Exchange Online: si tu empresa está enteramente en Microsoft 365, este problema no es tuyo. El punto de la nota es que muchas empresas creen estar en el segundo grupo y están en el primero.

Qué pasó, en orden

La vulnerabilidad se demostró originalmente en Pwn2Own Berlín 2026, la competencia donde investigadores rompen software real a cambio de un premio. La reportó el equipo Zero Day Initiative de Trend Micro. Microsoft la corrigió en el martes de parches del 11 de agosto, el mismo paquete de más de 400 vulnerabilidades del que escribimos hace tres semanas.

Le pusieron puntaje 8.0 sobre 10 y la clasificaron como "elevación de privilegios". Esa etiqueta hizo que en muchas listas de tareas quedara en la fila de abajo, debajo de las que dicen "ejecución remota de código".

El 28 de agosto el Centro Nacional de Ciberseguridad de los Países Bajos avisó que el código para explotarla ya circulaba, y lo describió con una frase que conviene leer dos veces: de bajo esfuerzo y fácil de convertir en arma. Hoy ese código está publicado en GitHub y cualquiera puede bajarlo.

Al día siguiente, el 31 de agosto, la Shadowserver Foundation —que escanea internet entera todos los días y publica el conteo— marcó 21.899 direcciones IP únicas todavía vulnerables. Estados Unidos encabeza con unos 6.200 y Alemania sigue con unos 5.100. La agencia de seguridad alemana, el BSI, estimó que alrededor del 85% de los Exchange locales del país sigue sin parchear. Alemania no es un país con problemas de madurez informática, y ese es exactamente el dato que incomoda.

Por qué la etiqueta se queda corta

Microsoft dice "elevación de privilegios". La investigación publicada describe una cadena que termina en ejecución de código sin autenticarse, con permisos de SYSTEM sobre el servidor. Trend Micro discutió públicamente la valoración de Microsoft sobre qué tan fácil era explotarla.

Sin entrar en la interna, lo que un atacante consigue con esto está bastante claro: acceso a todas las casillas del servidor. Leer los correos, mandar correos como cualquier persona de la empresa y descargar los adjuntos. Sin la contraseña de nadie.

Pensemos qué significa eso en una pyme. Ahí adentro está la cadena de correos con el contador, las facturas de los proveedores con sus datos bancarios, los presupuestos que se están negociando y el historial completo de cómo se escribe cada persona. Es la materia prima exacta del fraude del cambio de CBU: el atacante no necesita improvisar un correo creíble, tiene meses de correos reales para copiar el tono, y además puede mandarlo desde la casilla verdadera.

El detalle técnico, en criollo

Exchange tiene un componente llamado MRSProxy que sirve para mover casillas de un servidor a otro. Es la pieza que se usa, por ejemplo, cuando una empresa migra correo a la nube. En muchas instalaciones ese componente quedó accesible desde internet.

El problema es que MRSProxy acepta un tipo de autenticación de Windows pero no verifica una comprobación llamada channel binding, que es la que ata la credencial al canal por el que viaja. Sin esa verificación, un atacante puede tomar la autenticación de la propia cuenta del servidor, reenviarla a ese punto de entrada y ser tratado como si fuera el servidor mismo.

Es el equivalente digital de agarrar una llave que alguien está usando en una puerta y usarla en otra puerta del mismo edificio, porque nadie está mirando de qué puerta vino.

Quién tiene esto y no lo sabe

Hay tres situaciones típicas y las tres son comunes acá.

• La empresa que nunca migró. Tiene su Exchange en el servidor de la oficina, funciona hace años y por eso nadie lo toca. La regla informal es "si anda, no lo toques", y con un servidor de correo expuesto a internet esa regla es cara.
• La que migró a Microsoft 365 y dejó el servidor prendido. Esta es la más frecuente y la más peligrosa. Cuando se hace una migración híbrida queda un Exchange local para administrar las casillas desde la consola de siempre. Después la migración termina, nadie lo apaga y el servidor sigue ahí, publicado, sin dueño y sin entrar en ningún plan de actualizaciones. Para la empresa "ya estamos en la nube". Para internet, ese servidor sigue contestando.
• La que tiene Exchange 2016 o 2019. Esas versiones dejaron de tener soporte el 14 de octubre de 2025. Microsoft igual publicó corrección para esta falla, pero la próxima puede no tenerla. La única versión local con soporte hoy es Exchange Server Subscription Edition.

Qué hacer esta semana

Esto no se resuelve con una herramienta nueva. Se resuelve con una tarde de trabajo y una decisión.

• Primero, averiguar si tenés un Exchange local. Suena obvio y no lo es: en muchas empresas la respuesta honesta es "habría que fijarse". Si hay un servidor con Exchange instalado, aunque no se use, cuenta.
• Verificar el número de compilación, no la versión. Tener el Cumulative Update correcto no alcanza: la actualización de seguridad de agosto es aparte. En PowerShell sobre el servidor: Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}. Las versiones ya corregidas son 15.1.2507.72 (Exchange 2016 CU23), 15.2.1544.44 (2019 CU14), 15.2.1748.49 (2019 CU15) y 15.2.2562.46 (Subscription Edition). Si el número es menor, el servidor es vulnerable.
• Instalar la actualización de agosto y reiniciar. Son los KB5121573 al KB5121576 según la versión. No hay mitigación alternativa: la mitigación de emergencia de Exchange no cubre este caso. El parche es el arreglo.
• Revisar qué está publicado a internet. Si el servidor no necesita estar accesible desde afuera, no debería estarlo. Un servidor de correo publicado a internet es una puerta que atiende a todo el mundo, las veinticuatro horas.
• Si el servidor quedó de una migración y ya no cumple ninguna función, apagarlo y darlo de baja como corresponde. El servidor más seguro es el que no existe.
• Si hay Exchange 2016 o 2019 en producción, poner fecha. Migrar a Microsoft 365 o a Subscription Edition es un proyecto de semanas, no de un día, y conviene decidirlo antes de que lo decida un incidente.

Y una tarea que va aparte del parche: si el servidor estuvo expuesto todo este tiempo, revisar los registros de acceso y las reglas de reenvío automático de las casillas. Una regla que manda copia de todo a una dirección de afuera es lo primero que deja un atacante que entró a un correo, y es invisible para el dueño de la casilla. Es el mismo chequeo que detallamos para las protecciones de Google Workspace que ya se pagan y están apagadas.

Lo que este caso muestra

El parche existía tres semanas antes de que el ataque fuera público. No hubo sorpresa, no hubo día cero, no hubo nada que no se pudiera prever. Hubo 21.899 servidores donde nadie miró.

Esa es la parte que se repite en casi todos los incidentes que nos tocó atender: el problema rara vez es que falte tecnología. Es que no hay nadie con la tarea asignada de revisar, y entonces la revisión no ocurre. Un servidor sin dueño es un servidor sin parches, y tarde o temprano alguien del otro lado lo encuentra antes que vos.