Microsoft ha confirmado la explotación activa de CVE-2026-42897, una vulnerabilidad de tipo cross-site scripting (XSS) en Outlook Web Access (OWA) de Exchange Server on-premises. Su puntuación es CVSS v3.1 de 8.1 y, según la propia evaluación de Microsoft, está catalogada como “Exploitation Detected”: hay ataques reales en curso. La parte incómoda es la condición de disparo: basta con que un usuario abra en OWA un correo manipulado para que se ejecute JavaScript en el contexto de su sesión.
El calendario explica por qué importa ahora. Microsoft divulgó el fallo el 14 de mayo de 2026 y publicó la actualización de seguridad permanente el 9 de junio, en el Patch Tuesday de junio (aviso del MSRC). CISA lo incorporó a su catálogo de vulnerabilidades explotadas conocidas (KEV) y fijó plazo de remediación para las agencias federales. Entre la divulgación y el parche hubo casi un mes de ventana, cubierto por una mitigación automática que conviene entender bien.
Qué es exactamente CVE-2026-42897
En el catálogo de Microsoft figura como vulnerabilidad de spoofing, pero su mecánica es un XSS: una neutralización indebida de la entrada durante la generación de la página web de OWA. Los detalles técnicos están recogidos en el registro de la NVD y en el análisis del propio equipo de Exchange.
El vector es un correo electrónico especialmente diseñado. Cuando la víctima lo abre en Outlook Web Access y se cumplen ciertas condiciones de interacción, el navegador ejecuta JavaScript arbitrario dentro de la sesión autenticada del usuario. El atacante no necesita privilegios previos ni credenciales: aprovecha la sesión legítima de quien abre el mensaje.
A partir de ahí, las consecuencias descritas públicamente incluyen robo de credenciales, secuestro de sesión, suplantación de correo y ejecución de acciones en nombre del usuario comprometido (BleepingComputer, SecurityWeek). Lo que sí exige es interacción del usuario; no es una ejecución totalmente automática sin abrir el correo.
Por qué Exchange on-premises sigue siendo un objetivo prioritario
La vulnerabilidad afecta a Exchange Server 2016, 2019 y Subscription Edition en todos sus niveles de actualización. Exchange Online (Microsoft 365) no está afectado. Esa frontera es importante: el problema vive en la infraestructura que cada organización administra por su cuenta, no en el servicio gestionado de Microsoft.
Muchas organizaciones operan en híbrido: migraron el correo a Microsoft 365 pero conservan uno o varios servidores Exchange on-premises para gestión, coexistencia o aplicaciones heredadas. Ese servidor suele mantener privilegios elevados sobre Active Directory, de modo que comprometerlo no es un incidente de buzón aislado, sino una posible cabeza de puente hacia el directorio.
Exchange con OWA publicado en Internet es, además, una superficie expuesta y muy escaneada. Iniciativas como el informe de servidores Exchange vulnerables de Shadowserver muestran a diario cuántos sistemas siguen sin parchear y localizables desde fuera.
Anatomía del ataque, sin receta
Conviene entender el mecanismo sin convertirlo en un manual. El correo manipulado transporta contenido que OWA no neutraliza correctamente al renderizarlo; al mostrarse en el navegador, ese contenido se interpreta como script y se ejecuta. No hay prueba de concepto pública ni indicadores a nivel de paquete publicados por Microsoft, así que la descripción se queda, deliberadamente, en el plano conceptual.
La clave defensiva está en dónde corre ese script: en la sesión de OWA ya autenticada. Eso le da capacidad para leer y escribir correo, crear reglas de buzón para reenvío u ocultación, y —en entornos híbridos— intentar pivotar hacia otros servicios. La frase “bajo ciertas condiciones” no es un adorno: el alcance real depende de la configuración de cada despliegue.
Sobre la autoría, la información pública es honesta en su límite: Microsoft observó explotación en el momento de la divulgación, pero no se ha vinculado públicamente a ningún grupo concreto ni se ha cuantificado el alcance de la campaña (Help Net Security). Decir más sería especular.
Por qué los controles habituales no bastan
El primer reflejo —“tengo MFA, estoy cubierto”— no aplica aquí. El factor múltiple protege el inicio de sesión, pero el abuso ocurre cuando la sesión de OWA ya está autenticada: el script se ejecuta dentro de ella. Reforzar la identidad sigue siendo necesario, pero no neutraliza este vector por sí solo.
El filtrado de correo tampoco garantiza el bloqueo: un mensaje diseñado para este fallo puede tener apariencia legítima. Y el EDR de endpoint tiene poca visibilidad sobre lo que sucede dentro de la sesión de navegador contra el servidor de correo. La defensa eficaz se desplaza hacia el propio Exchange: parche, mitigación y reducción de exposición.
Detección: qué se puede y qué no
Sé claro con el equipo: sin PoC público ni IoCs de Microsoft, no hay una firma mágica. La detección se apoya en superficie de exposición, verificación de mitigación y vigilancia de comportamiento. La documentación del equipo de Exchange describe cómo comprobar el estado de la mitigación.
- Inventariar los servidores Exchange on-premises y su exposición real de OWA a Internet, como parte de la gestión continua de la superficie de ataque.
- Verificar que la mitigación automática (EEMS) está aplicada, con el Exchange Health Checker o la guía “Viewing Applied Mitigations”.
- Vigilar la creación de reglas de buzón sospechosas, reenvíos automáticos y delegaciones recién añadidas.
- Revisar accesos a OWA anómalos: geolocalizaciones improbables, agentes de usuario raros, ráfagas de actividad fuera de horario.
- Correlacionar en el SIEM los registros de IIS/OWA con la telemetría de buzón para detectar abuso de sesión.
Mantener esa vigilancia de forma continua es justo el trabajo de un SOC gestionado, que correlaciona estos indicadores sin depender de que alguien mire los logs a mano.
Contención y defensa práctica
- Aplicar la actualización de seguridad de junio de 2026: Exchange Subscription Edition, 2019 (CU14/CU15) y 2016 (CU23). Para versiones heredadas, el parche llega por el programa de Extended Security Updates (ESU).
- Mantener el servicio de mitigación de emergencia (EEMS) habilitado —lo está por defecto— y confirmar que la mitigación M2.1.x está activa. Microsoft recomienda no desactivarla tras instalar el parche.
- Reducir la exposición de OWA: restringir el acceso desde Internet, publicarlo tras proxy inverso o acceso Zero Trust (ZTNA), y aplicar geofiltrado donde tenga sentido.
- Endurecer la identidad con MFA resistente a phishing (FIDO2/passkeys) y revisar reglas de buzón, reenvíos y delegaciones existentes en busca de cambios no autorizados.
- Revisar el papel del servidor on-premises en Active Directory, segmentar la red y aplicar mínimo privilegio para limitar el movimiento lateral si la sesión se ve comprometida.
- Plantear la retirada o migración del Exchange on-premises donde sea viable: cada zero-day recuerda que la superficie que no existe no se explota.
Priorizar este tipo de fallos —CVE en el catálogo KEV, con explotación confirmada— es exactamente el criterio de una gestión de vulnerabilidades que no se limita a pasar un escáner. Sobre cómo ordenar esa prioridad ayudan marcos como KEV, EPSS y SSVC.
Si aparece sospecha de compromiso —reglas de buzón extrañas, exfiltración, accesos imposibles—, conviene activar cuanto antes la respuesta a incidentes y preservar evidencias antes de tocar el servidor.
Implicaciones de cumplimiento: NIS2, DORA y ENS
Para una entidad sujeta a NIS2, un Exchange on-premises expuesto y sin parchear es un activo crítico con una vulnerabilidad explotada conocida. Eso activa obligaciones de gestión de vulnerabilidades y, ante un incidente con impacto, los plazos de notificación.
En el marco de DORA, la resiliencia operativa digital exige procesos de gestión de parches y control del riesgo tecnológico que cubran precisamente estos escenarios. Y bajo el Esquema Nacional de Seguridad, el control de actualizaciones y la gestión de la exposición forman parte de los mínimos según la categoría del sistema.
Hay un matiz práctico: documentar la fecha de aplicación del parche y el estado de la mitigación no es burocracia, es la evidencia que sostiene una auditoría y que demuestra diligencia si el incidente acaba revisándose.
Qué priorizar ahora
Sin planes a tres meses ni proyectos eternos: lo urgente es concreto. Confirmar qué servidores Exchange on-premises hay y cuáles publican OWA, aplicar la actualización de junio, verificar que la mitigación EEMS está activa y vigilar los buzones por reglas y reenvíos no autorizados. Con eso se cierra la exposición inmediata; la conversación de fondo —cuánto Exchange on-premises sigue teniendo sentido— viene después.
Para entornos donde la mayoría del correo ya vive en la nube, revisar la postura conjunta ayuda: lo cubrimos en seguridad de Microsoft 365, y en piezas relacionadas como el secuestro de cuentas en Microsoft 365 y el device code phishing.
Exchange on-premises es, para muchas organizaciones, deuda técnica con factura de seguridad. CVE-2026-42897 no es el primer recordatorio ni será el último: mientras OWA siga publicado y sin migrar, la pregunta no es si habrá otro fallo, sino si el servidor estará parcheado y vigilado cuando llegue.