Exchange cae 24 horas después del parche de octubre, y la mitigación deshace el parche

Quinientos doce entre veintitrés con siete da veintiuna horas y media. Esa división es el tiempo que tu servidor de Exchange aguanta desde que instalas la actualización de Windows Server de octubre hasta que los buzones empiezan a desconectarse. Si parcheaste el martes por la tarde, el correo se paró el miércoles a media mañana, con la ventana de cambio cerrada, el acta firmada y nadie mirando ya hacia el parche.

Qué metieron las actualizaciones del 13 de octubre

Las actualizaciones de seguridad de Windows Server publicadas el 13 de octubre de 2026 —KB5126646 para Windows Server 2025, KB5126655 para 2022, KB5126651 para 2019 y KB5126868 para 2016— introducen un tope nuevo en el Endpoint Mapper, la pieza del subsistema RPC de Windows que resuelve qué puerto dinámico atiende a cada servicio. El tope es de 512 contextos de búsqueda guardados a la vez, y vive en RpcEpMap.dll.

La nota de Microsoft en el panel de estado de Windows lo cuenta como un límite de memoria: «la actualización de octubre de 2026 introdujo un límite por defecto en la cantidad de memoria que usa el Endpoint Mapper al gestionar llamadas de resolución de extremos. Para cargas de trabajo como Exchange Server, el límite por defecto de 512 llamadas simultáneas de resolución de extremos puede no ser suficiente con carga alta». Esa redacción es, en buena parte, la razón de que nadie ate el fallo al parche: «simultáneas» suena a algo que se libera solo cuando la carga baja, y lo que el tope cuenta son contextos guardados, que se acumulan y no se sueltan. De ahí las veintiuna horas. No es un pico de carga: es un depósito que se llena. Y la nota deja fuera por qué aparece ese tope. Quien lo ha puesto por escrito es Michel de Rooij, que localiza el cambio en RpcEpMap.dll y lo relaciona con CVE-2026-96300: un consumo descontrolado de recursos (CWE-770) en el propio servicio Endpoint Mapper de RPC, puntuado 5,9, que permite a cualquier equipo capaz de hablar con ese servicio agotarle la memoria y tumbarlo. Si esa lectura es correcta —y encaja con todo lo demás—, el tope de 512 es el arreglo de ese fallo. Microsoft no lo dice en la página de la actualización.

Por qué tarda un día en notarse

Denis Grebner lo midió en un servidor de correo en producción y publicó los números en Franky's Web: 135 contextos en 5,68 horas de servicio, 23,7 por hora. Con un tope de 512 y sin que nada los libere, el contador llega al techo a las 21,6 horas —y el servidor que midió se cayó a las 21 horas y 27 minutos—. Los casos documentados sitúan la caída entre las 20 y las 24 horas según la carga. A partir de ahí, el Endpoint Mapper deja de entregar extremos y las piezas de Exchange que hablan entre sí por RPC —que son casi todas— se quedan sin forma de encontrarse.

Veintiuna horas de retardo rompen el procedimiento de cambio entero. Una ventana de mantenimiento típica dura dos horas, tres si el equipo es generoso. Se instala, se reinicia, se comprueba que entra el correo web, que sale un mensaje de prueba y que las bases están montadas, y se cierra el acta. Todas esas comprobaciones pasan. Pasan porque en ese momento el servidor lleva veinte contextos de los 512 y no hay nada que ver.

Qué vas a ver cuando se llene

Los síntomas llegan por partes y ninguno dice «RPC». Lo que se está viendo:

• Usuarios que no pueden iniciar sesión en Outlook on the Web, y clientes Outlook que pierden la conexión con el buzón.
• Mensajes que se quedan en la bandeja de salida y colas que crecen sin entregar.
• Copias de base de datos de un DAG que dejan de replicar.
• En el registro de aplicación, Event ID 1006 de MSExchange Mailbox Replication con MapiExceptionMdbOffline: Unable to make connection to the server. (hr=0x80004005, ec=1142).
• El que apunta al sitio correcto: Event ID 4082 de MSExchangeRepl, donde el gestor de red de replicación falla con OpenCluster(...) failed with 0x6d9 y, al final de la traza, «There are no more endpoints available from the endpoint mapper».

Mientras todo esto ocurre, las bases de datos siguen apareciendo conectadas y montadas en el centro de administración de Exchange. Es decir, tu panel dice que el servicio está bien mientras los buzones están inaccesibles. Si tu monitorización comprueba el estado de montaje de las bases en lugar de hacer una conexión de cliente de verdad, no te vas a enterar por ahí: te vas a enterar por el teléfono.

La mitigación de Microsoft, y la letra pequeña

Microsoft recomienda subir el tope desde un símbolo del sistema con privilegios y reiniciar:

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v EpmapSavedContextCap /t REG_DWORD /d 65536 /f

Son 65536, ciento veintiocho veces el tope original, y Microsoft añade que si el problema persiste se puede subir más. El fabricante no te está dando el número correcto, te está dando un número grande y la instrucción de agrandarlo. Nadie sabe cuál es tu número porque depende de tu carga, y eso incluye a quien escribió la nota.

Microsoft es explícita además en dos cosas, y conviene no fundirlas. Primera, el imperativo: «no desinstaléis las actualizaciones de Windows Server de octubre de 2026». Es decir, el parche que vas a querer quitar a las tres de la mañana es justo el que te piden que dejes puesto. Segunda, que la causa no está en las actualizaciones de Exchange: «los problemas reportados no están relacionados con la instalación de las actualizaciones de seguridad de octubre de 2026 para Exchange Server». En la página de la propia actualización añaden que Soporte de Microsoft puede facilitar una mitigación adicional a los equipos afectados, y que el caso sigue en investigación. Y hay un tercer punto que no está en la nota pero sí en lo que cuenta quien lo ha sufrido: reiniciar el servidor limpia los contextos y hace desaparecer el síntoma, durante otras veinte horas. Esa es la trampa que convierte un fallo en una leyenda de oficina —«va bien, lo reinicié el lunes»— y la razón de que gente haya pasado el fin de semana encima de sus servidores.

La contrapartida, dicha en voz alta

Si el tope de 512 es el arreglo de CVE-2026-96300, subirlo a 65536 es desandar casi todo ese arreglo. Es la consecuencia directa y conviene que esté escrita en el ticket, no sobreentendida. Dicho eso, nuestra recomendación es que apliques la mitigación. Un correo parado es una avería de hoy, medible en personas que no trabajan; el CVE es una denegación de servicio de 5,9 que requiere que alguien tenga línea abierta con tu Endpoint Mapper. No son riesgos del mismo tamaño en una tarde de miércoles.

Pero con dos condiciones que no son negociables. La primera: el puerto 135/TCP no debe estar publicado a internet. Si lo está, tu problema de hoy no es el valor de registro, es el puerto, y el CVE es la menor de las cosas que te pueden pasar por ahí. La segunda: ese EpmapSavedContextCap es ahora una dependencia no documentada de la disponibilidad de tu correo. No viaja en ningún parche, no sale en ningún inventario de software y desaparece el día que alguien reinstale ese servidor desde una plantilla. Ponle dueño, ponle fecha de revisión y apúntalo donde se apuntan las cosas que hay que deshacer.

Qué hacer esta semana

• Comprueba qué KB tiene instalada cada servidor Windows que aloje Exchange. Si es una de las cuatro de arriba, estás en el grupo.
• Busca Event ID 4082 y 1006 en el registro de aplicación de los últimos siete días, aunque nadie se haya quejado. Un servidor que se reinicia cada noche por otra razón puede llevar días rozando el techo sin cruzarlo.
• Aplica el valor de registro y reinicia. En un DAG, nodo a nodo.
• Registra el cambio como temporal, con la fecha en que hay que revisarlo y el motivo (CVE-2026-96300) escrito al lado. Un valor sin motivo escrito sobrevive años.
• Verifica desde fuera que 135/TCP no responde desde internet. Hoy, no de memoria.
• Cambia la comprobación de tu monitorización: que haga una conexión de cliente real al buzón, no que lea el estado de montaje de la base. Este fallo deja el panel en verde.
• Y apunta en el calendario revisar la nota del panel de estado de Windows: cuando salga el arreglo definitivo, hay que quitar el valor.

Dos horas de validación para un fallo de veintiuna

La validación duró dos horas. El fallo tardó veintiuna en nacer. Una ventana de cambio que acaba antes de que el fallo exista certifica que la instalación terminó, y eso es todo lo que certifica. Ese desfase seguirá ahí cuando este parche concreto sea un recuerdo.

Lo que sí funciona es poco glamuroso: un servidor primero y el resto después, con una separación mayor que el tiempo que tarda el fallo más lento que conoces. Si tienes un DAG, tienes el laboratorio puesto —actualiza un nodo, espera cuarenta y ocho horas, actualiza el siguiente—. Si solo tienes un servidor de correo, la separación la tienes que comprar en otro sitio: en los anillos de despliegue del resto del parque, donde el puesto de trabajo va por delante y te avisa. De eso hablamos hace poco a propósito de quién prueba los cambios antes que tú, y el razonamiento es el mismo aquí.

Si todavía estás en Exchange 2016 o 2019

El fallo les afecta igual —2016, 2019 y Subscription Edition están en la lista—, pero la salida no es la misma. El soporte de Exchange Server 2016 y 2019 terminó el 14 de octubre de 2025. La página de Microsoft lo enumera sin eufemismos: desde esa fecha no hay soporte técnico, ni correcciones de errores que afecten a la estabilidad y usabilidad del servidor, ni correcciones de seguridad, ni actualizaciones de zona horaria. La única versión on-premises soportada es Exchange Server SE.

Dicho de otra forma: esta semana aplicas el valor de registro y sales del paso, pero la próxima incidencia que necesite un arreglo del producto no va a tener arreglo. Es el mismo razonamiento que aplicamos en el Exchange que dejaste encendido, el servidor que sigue en el rack porque hace falta para gestionar los destinatarios: desde octubre de 2025, ese servidor no tiene a quién llamar.

Y no, irse a la nube no es la respuesta fácil

El 12 de octubre de 2026, ocho días antes de escribir esto, un cambio de configuración dejó el centro de administración de Exchange Online devolviendo errores internos a los administradores durante unas 5,4 horas, hasta que Microsoft revirtió el cambio. Nadie tocó un registro, nadie reinició nada y nadie pudo hacer nada mientras duró.

Lo que cambia al moverse a Microsoft 365 no es que desaparezcan las caídas: es qué tipo de fallo te toca y quién pasa el fin de semana con él. Pierdes el servidor que se te llena de contextos RPC y el valor de registro que nadie recuerda; ganas una dependencia que no puedes reiniciar: cuando se cae, tu única palanca es un número de incidencia. Cuando nos lo encontramos, el cambio suele tener sentido —desaparece un inventario de máquinas y desaparecen noches—, pero tiene sentido con los ojos abiertos y un plan para los días en que el panel está en rojo y tú no tienes mando. Eso último, que es lo que nadie incluye en la propuesta de migración, es lo que ponemos por escrito antes de mover el primer buzón.

Fuentes y método: la cita de Microsoft sobre el límite por defecto está en la propia página de la actualización, en el apartado de problemas conocidos de KB5126646 (Windows Server 2025, compilación 26100.33650, 13 de octubre de 2026), consultada el 20 de octubre de 2026; ahí mismo consta que Soporte de Microsoft puede facilitar una mitigación adicional. El imperativo literal sobre no desinstalar las actualizaciones de Windows Server y la frase sobre las actualizaciones de Exchange salen del aviso del equipo de Exchange en Tech Community del 16 de octubre de 2026 — techcommunity.microsoft.com. La lista de síntomas y el comando exacto proceden de la cobertura de BleepingComputer del 19 de octubre de 2026 — bleepingcomputer.com. Los números de KB por versión de Windows Server, la ventana de 20-24 horas y el detalle de que las bases siguen apareciendo montadas en el centro de administración proceden del artículo de Frank Zöchling en Franky's Web; la medición de 23,7 contextos por hora (135 contextos en 5,68 horas), la proyección de 21,6 horas y la caída real de 21 h 27 min son de Denis Grebner, publicadas en el hilo técnico de ese mismo artículo; ambos en frankysweb.de; los Event ID 1006 y 4082 y el código 0x6d9 proceden del análisis de Michel de Rooij — eightwone.com, que es también quien sitúa el tope en RpcEpMap.dll y lo relaciona con CVE-2026-96300; la nota pública de Microsoft que hemos leído no enlaza explícitamente ambas cosas. La descripción de CVE-2026-96300 (consumo descontrolado de recursos, CWE-770, 5,9) procede de su ficha pública. Las fechas y condiciones de fin de soporte de Exchange Server 2016 y 2019 son de la página oficial de Microsoft — learn.microsoft.com. La caída del centro de administración de Exchange Online del 12 de octubre de 2026 y su duración aproximada están recogidas por Petri — petri.com. Insistimos en que la proyección de 21,6 horas no es nuestra; lo nuestro es la lectura de ese número: es más largo que cualquier ventana de cambio que hayamos visto firmar. No tenemos telemetría propia de este incidente: todo lo anterior es lectura de documentación pública y de los informes de quienes sí lo han sufrido. Lo que sí es nuestro es el criterio: la recomendación de aplicar la mitigación, las dos condiciones que le ponemos y la lista de esta semana.