CVE-2026-45475 en Microsoft Office: una RCE local que obliga a revisar parches, macros y privilegios antes de que llegue el siguiente correo

Microsoft ha publicado la vulnerabilidad CVE-2026-45475 en su Security Update Guide y la descripción oficial no pierde el tiempo: heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to execute code locally. Traducido a castellano llano: un fallo de corrupción de memoria en Office que puede acabar ejecutando código en el equipo de la víctima. La frase “localmente” puede sonar tranquilizadora. No debería. En el ecosistema Office, “local” a menudo significa “el usuario abrió un archivo, previsualizó un contenido o interactuó con un documento que parecía de trabajo”. Y ahí empieza el problema de verdad.

La entrada de Microsoft MSRC, por sí sola, dice menos de lo que cualquier CISO querría saber. No detalla de entrada cadena de explotación, vector exacto, ni si hubo explotación activa en el momento de la publicación. Eso no convierte el fallo en menor. Solo significa que toca hacer el trabajo que muchas organizaciones siguen intentando evitar: inventario preciso, priorización basada en exposición real, despliegue de parches con control del riesgo y revisión de mitigaciones compensatorias. Lo de siempre, sí. Pero esta vez con Office por medio, que es justo donde demasiadas compañías aún mezclan productividad, macros heredadas, complementos opacos y privilegios más generosos de la cuenta.

La noticia importa por tres motivos muy concretos. Primero, porque Office sigue siendo una superficie de ataque masiva en entornos corporativos, especialmente en Windows. Segundo, porque una vulnerabilidad de desbordamiento de búfer en el heap apunta a una categoría de fallo históricamente explotable para obtener ejecución de código si el atacante controla suficientemente la entrada. Tercero, porque el verbo “local” no reduce el impacto regulatorio si el resultado final es compromiso de endpoint, movimiento lateral, robo de credenciales o acceso a datos personales. Cuando eso ocurre, la conversación ya no es solo técnica: entra DORA para el sector financiero, NIS2 para operadores y entidades esenciales o importantes, y GDPR si hay afectación de datos personales. Bastante papeleo, sí, pero sobre todo bastantes obligaciones reales.

Qué ha dicho Microsoft, y qué no ha dicho

El hecho verificable es este: Microsoft ha registrado CVE-2026-45475 en MSRC como una vulnerabilidad de Remote Code Execution en Microsoft Office causada por un heap-based buffer overflow. La propia URL oficial de referencia es la ficha de la vulnerabilidad en el Microsoft Security Response Center. Esa ficha es la fuente primaria que cualquier equipo de seguridad debería usar para seguir cambios en severidad, productos afectados, actualizaciones y referencias de parche.

Lo interesante no es solo lo que aparece, sino lo que no aparece en el contenido bruto aprobado para esta pieza. No tenemos, por ahora, detalle público suficiente sobre:

• la aplicación concreta de Office afectada o si el alcance abarca varias,
• el vector inicial exacto,
• la interacción requerida del usuario,
• si existe explotación activa o proof of concept pública,
• ni el impacto de configuración, por ejemplo Protected View, Application Guard o políticas de macros.

Ese silencio no autoriza a dramatizar ni a dormirse. Autoriza a hacer una evaluación prudente. Un fallo de memoria en Office con RCE suele situarse en la franja de vulnerabilidades que merecen prioridad alta aunque aún no haya explotación confirmada, porque el software afectado está instalado de forma muy amplia, el usuario final es un objetivo natural y el vehículo de entrega más probable —documentos de apariencia legítima— encaja demasiado bien con campañas de phishing y spear phishing.

Aquí hay una ironía conocida: las empresas llevan años gastando millones en EDR, sandboxing y arquitecturas Zero Trust, y luego un archivo de Office sigue teniendo capacidad para arruinarles la semana. No porque la tecnología defensiva no sirva, sino porque la combinación de software omnipresente, confianza del usuario y deuda de configuración sigue siendo extraordinariamente eficaz para un atacante paciente.

Por qué un desbordamiento de búfer en Office sigue siendo una mala noticia en 2026

“Heap-based buffer overflow” no es jerga decorativa. Describe una corrupción de memoria en una zona dinámica del proceso. Si el atacante consigue manipular cómo se procesa un objeto, una estructura embebida o un contenido especialmente construido, puede provocar escritura o lectura fuera de límites y, con ello, alterar el flujo de ejecución. No siempre acaba en RCE fiable. A veces termina en cierre inesperado. Otras, en denegación de servicio. Pero cuando el proveedor lo clasifica como Remote Code Execution, la conclusión operativa es inequívoca: existe un escenario en el que la corrupción de memoria permite ejecutar código.

En Office, esto es especialmente sensible por cuatro razones.

La primera es la diversidad de formatos y motores de análisis. Documentos, plantillas, objetos embebidos, contenidos heredados, integraciones con otros componentes de Windows y visualización previa en ciertos flujos crean una superficie compleja. Cuanto más legado y compatibilidad arrastra una suite, más puntos delicados hay.

La segunda es que Office vive pegado al usuario. A diferencia de un servicio de backend, aquí el atacante puede diseñar el señuelo para que parezca útil, urgente o rutinario: una factura, una revisión de contrato, un cuadro de mandos, una presentación para comité. La barrera psicológica es menor. El atacante no necesita convencer a la víctima de instalar un binario exótico si ya puede ofrecerle algo que parece trabajo.

La tercera es el contexto de privilegios. Si el usuario trabaja sin privilegios administrativos, el daño inicial se contiene mejor. Si no, el panorama cambia. Y aunque no haya admin local, ejecutar código en el contexto de un usuario corporativo ya permite robo de tokens, acceso a documentos, uso de credenciales guardadas y preparación del siguiente salto.

La cuarta es la dificultad de erradicar por completo ciertas prácticas heredadas: macros toleradas por excepción, complementos COM internos sin revisión reciente, aperturas desde ubicaciones de red confiables, listas de exclusión mal justificadas, o equipos que se saltan el ritmo normal de parcheo porque “siempre rompen algo”. Luego se sorprenden cuando algo se rompe de verdad.

“Ejecución local” no significa impacto local

Conviene desmontar un malentendido frecuente. Cuando una ficha de vulnerabilidad habla de ejecución de código local, no está diciendo que el riesgo se quede encerrado en un solo equipo como un problema doméstico. Está describiendo, normalmente, el contexto de ejecución del exploit. El atacante necesita que el código se ejecute en el endpoint. ¿Cómo llega hasta ahí? A través de un archivo, un flujo de apertura, una descarga inducida o un contenido accesible por la víctima. Una vez dentro, la pregunta relevante no es si el proceso empezó en local, sino qué puede tocar después.

Si la máquina comprometida tiene acceso a repositorios compartidos, CRM, correo corporativo, VPN, herramientas de administración remota o aplicaciones financieras, el incidente deja de ser un “problema de escritorio”. Pasa a ser una puerta de entrada. A partir de ahí, el impacto se mide en credenciales reutilizadas, sesión secuestrada, exfiltración, despliegue de payloads secundarios y tiempos de contención.

Los equipos de riesgo operativo lo saben bien: muchas intrusiones serias no empiezan con una vulnerabilidad de perímetro de película, sino con un usuario, un documento y una cadena de decisiones apresuradas. Office encaja demasiado bien en ese patrón.

Lo que debería hacer ahora un equipo de seguridad, sin teatro y sin excusas

Si tu organización usa Microsoft 365 Apps, Office LTSC o combinaciones híbridas, la primera tarea no es enviar un correo grandilocuente a toda la empresa. Es más prosaica: saber exactamente qué tienes desplegado. Parece básico. Aún falla más de lo que debería.

La secuencia sensata arranca con un inventario de versiones afectadas y canales de actualización. Muchas organizaciones no parchean Office como un bloque homogéneo. Tienen canal actual, canal mensual empresarial, imágenes congeladas en VDI, instalaciones persistentes en portátiles de alta dirección, y restos de versiones perpetuas que siguen ahí porque un complemento de finanzas “solo funciona con eso”. Ese mapa define el riesgo real mucho más que cualquier titular sobre la CVE.

Después toca verificar la disponibilidad del parche o actualización correspondiente desde Microsoft y asociarla a los productos realmente desplegados. No basta con asumir que “M365 se actualiza solo”. En la práctica, abundan políticas de aplazamiento, equipos desconectados durante semanas, dispositivos fuera de gestión y unidades de negocio que bloquean cambios en cierre contable, campañas comerciales o ventanas de reporting. Justo cuando más urge actualizar, siempre aparece alguien diciendo que no es buen momento. Nunca lo es. Ese es el chiste.

Mientras el despliegue se completa, hay medidas compensatorias que sí tienen sentido si están bien ejecutadas:

• reforzar el bloqueo de archivos procedentes de Internet con Mark of the Web y Protected View;
• revisar políticas de macros y eliminar excepciones amplias basadas en confianza implícita;
• restringir privilegios locales en puestos donde todavía existan administradores por comodidad;
• activar o verificar reglas de reducción de superficie de ataque en Microsoft Defender, especialmente las orientadas a bloquear comportamientos anómalos de Office;
• monitorizar procesos hijo de aplicaciones Office, actividad inusual de cmd, powershell, wscript o binarios LOLBins lanzados desde Office;
• elevar la sensibilidad del SOC para documentos sospechosos en correo, colaboración y almacenamiento compartido.

No todas las medidas sirven igual en todas las empresas. Algunas romperán flujos legítimos. Pero si no sabes qué se rompería, eso ya es una señal de que el control sobre el parque Office era más imaginario que real.

El detalle que separa a una organización preparada de una que improvisa

En vulnerabilidades de Office, la velocidad importa, pero la trazabilidad importa casi tanto. No porque quede bonito para auditoría, sino porque cuando un incidente escale necesitarás demostrar tres cosas: qué sistemas estaban afectados, cuándo se aplicó la corrección y qué exposición hubo entre la publicación y el cierre del parcheo.

Eso implica registrar, al menos, fecha de publicación en MSRC, fecha interna de clasificación, anillo de despliegue, porcentaje de cobertura por oleadas y excepciones aprobadas con responsable identificado. Si esto suena administrativo, recuerda que DORA no premia el heroísmo improvisado; premia la capacidad de gobernar, detectar, responder y aprender de forma repetible.

En el sector financiero europeo, DORA exige un marco de gestión del riesgo TIC robusto. El art. 6 establece principios generales del marco de gestión del riesgo relacionado con las TIC. El art. 8 entra en identificación, clasificación y documentación de funciones, activos TIC y dependencias. Y el art. 10 trata detección de actividades anómalas. Una RCE en Office no se menciona por su nombre, claro, pero cae de lleno dentro del tipo de exposición que debe poder identificarse, priorizarse y monitorizarse. Si la entidad no puede decir qué endpoints usan la versión vulnerable ni cómo se protege el correo y la ejecución de documentos, tiene un problema de control, no solo de parcheo.

La misma lógica aplica a NIS2. El art. 21 obliga a medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información, incluyendo gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de criptografía y autenticación cuando proceda. Una vulnerabilidad de Office explotable mediante documento malicioso encaja de lleno en gestión de riesgos, higiene técnica y respuesta a incidentes. Y si la explotación derivase en incidente significativo, el art. 23 introduce el régimen de notificación con alerta temprana en 24 horas, notificación de incidente en 72 horas e informe final en un mes, con arreglo a la transposición nacional aplicable.

Si además hay datos personales comprometidos, entra GDPR art. 33: notificación a la autoridad de control en un plazo de 72 horas desde que el responsable tenga constancia de la violación de seguridad, salvo que sea improbable que constituya un riesgo para los derechos y libertades de las personas físicas. Y si el riesgo es alto, art. 34 obliga a comunicarlo a los interesados. Es decir, un documento de Office abierto por un empleado puede terminar en una conversación con el DPO, el regulador sectorial y, si la cosa sale mal, con clientes enfadados. La cadena es bastante más corta de lo que muchos comités creen.

Para banca, seguros y fintech: esto no es solo un ticket de IT

Las entidades financieras europeas llevan meses —o años— afinando su narrativa de resiliencia por DORA. Luego llega una vulnerabilidad en Office y pone a prueba si esa resiliencia era operativa o decorativa. Porque el fallo no ataca el core bancario, ni la pasarela de pagos, ni el proveedor cloud crítico de forma directa. Ataca el puesto de trabajo, el correo, el flujo documental. Justo la capa que demasiadas veces se considera “higiene básica” y por eso acaba infrafinanciada, mal medida o delegada en exceso.

Para una entidad financiera española o europea, hay cuatro frentes especialmente sensibles.

Primero, front-office y back-office. Equipos de banca corporativa, riesgos, legal, suscripción, siniestros o compras abren y reciben documentos constantemente. Cuanto más documental sea la función, mayor es la exposición. No se trata solo del volumen, sino de la presión operativa para abrir archivos rápido.

Segundo, terceros y outsourcers. Bajo DORA art. 28 y siguientes, la gestión del riesgo de terceros TIC no desaparece porque el software vulnerable esté en el endpoint propio. Si el procesamiento documental, el soporte de escritorios, el correo gestionado o parte del SOC está externalizado, la entidad necesita asegurarse de que los proveedores reaccionan con la misma urgencia. El agujero puede estar en Office; el retraso, en el contrato o en el SLA.

Tercero, teletrabajo y dispositivos móviles. Los portátiles fuera de la red corporativa y los equipos que actualizan con menor disciplina elevan la ventana de exposición. Si la organización depende de VPN para ciertas políticas o carece de gestión moderna de endpoints, el despliegue de la corrección se ralentiza justo donde más falta hace.

Cuarto, pruebas y evidencias. Un auditor interno, un supervisor o una segunda línea madura no va a conformarse con “hemos enviado el parche”. Va a pedir evidencia de cobertura, excepciones, validación de controles compensatorios y lecciones aprendidas. Si no existe esa disciplina, DORA deja de ser una sigla elegante y pasa a ser una incomodidad muy tangible.

Qué señales debería buscar ya el SOC

Incluso sin detalle público completo sobre la cadena de explotación, hay patrones que justifican una vigilancia reforzada. La lógica es simple: si Office es el proceso inicial, cualquier desviación hacia ejecución de comandos, scripts, cargas laterales o actividad de red anómala merece lupa.

Los casos más obvios incluyen lanzamientos de procesos hijo desde Word, Excel, PowerPoint o componentes asociados hacia cmd.exe, powershell.exe, wscript.exe, cscript.exe, rundll32.exe, mshta.exe o regsvr32.exe. También conviene revisar conexiones salientes inusuales inmediatamente después de la apertura de documentos, escritura de ejecutables o DLL en rutas de usuario, creación de tareas programadas, modificaciones de claves de persistencia y accesos anómalos a repositorios compartidos.

Si el entorno usa Microsoft Defender for Endpoint, merece la pena revisar reglas ASR relacionadas con Office. Si usa otro EDR, lo importante no es la marca sino el caso de uso: identificar explotación inicial, secuencia de hijo-proceso-red, y posible descarga de payload de segunda fase. Demasiadas organizaciones detectan la intrusión cuando ya ven el beaconing. A esas alturas, el documento inicial solo es arqueología forense.

El correo sigue siendo el canal probable, pero no el único. Plataformas de colaboración, compartición de archivos y mensajería empresarial también pueden entregar documentos maliciosos. Si tu política de seguridad sigue tratando el correo como “frontera principal” y lo demás como simple productividad, va con retraso.

El viejo problema de las macros, y por qué no conviene mezclarlo todo

Cuando aparece una vulnerabilidad en Office, media organización pregunta automáticamente por macros. La pregunta no es absurda, pero tampoco siempre es la correcta. Un fallo de corrupción de memoria y un abuso de macros son cosas distintas. El primero explota un error en el software; el segundo aprovecha funcionalidad legítima para ejecutar lógica maliciosa. Ambos pueden convivir en campañas reales, pero las mitigaciones no son idénticas.

Eso sí, operativamente se cruzan. Una empresa con macros permisivas, complementos heredados y usuarios con capacidad de omitir advertencias suele tener menos defensas frente a ambas clases de ataque. Por eso esta CVE debería servir también para revisar gobernanza de Office en sentido amplio: políticas de documentos confiables, control de complementos, firma de macros donde sigan siendo imprescindibles, aislamiento de flujos críticos y retirada de excepciones que nadie revisa desde hace años.

Aquí conviene ser honestos: muchas compañías no conservan ciertas excepciones porque sean necesarias, sino porque nadie quiere ser el responsable del proceso que deja de funcionar el viernes por la tarde. Es comprensible. También es exactamente así como se perpetúa la deuda de seguridad.

Parchear Office no es igual que parchear un servidor, y ahí está la trampa

Un servidor crítico suele tener propietario claro, ventana de mantenimiento, monitorización centralizada y procedimientos formales. Un parque de Office, no siempre. El software está repartido entre miles de dispositivos, versiones distintas, portátiles que no se conectan durante días, VDI, equipos de terceros, laboratorios y usuarios que posponen reinicios porque están “en algo urgente”. El resultado: la organización cree que tiene un 95% de cobertura cuando en realidad el 5% pendiente concentra perfiles de alto riesgo y equipos poco visibles.

Por eso la gestión de esta CVE debería separar tres grupos:

• equipos plenamente gestionados y con telemetría fiable, donde el parcheo debe ser inmediato;
• equipos parcialmente gestionados o con conectividad irregular, que exigen seguimiento específico;
• activos residuales o heredados, donde quizá no haya parche simple y toque decidir entre aislamiento, sustitución o retirada.

La tercera categoría suele ser la más incómoda y la más reveladora. Cada vez que aparece una vulnerabilidad seria, aflora software que la organización creía ya extinguido. Nunca lo estaba del todo.

Qué deberían preguntar hoy mismo el CISO, el CIO y Compliance

El CISO debería pedir una respuesta muy concreta: alcance por producto y versión, exposición por unidad de negocio, hipótesis de explotación probable, cobertura de EDR y correo, y plazo realista de remediación. No un “estamos en ello”. Datos.

El CIO debería exigir visibilidad sobre canales de actualización, dependencias que puedan bloquear el despliegue y criterios para excepciones. Si alguien pide retrasar el parche, que deje por escrito qué proceso se vería afectado, durante cuánto tiempo y con qué mitigación compensatoria. La opacidad operativa sale carísima en incidentes.

Compliance y segunda línea deberían preguntar si existe criterio formal de severidad, si la vulnerabilidad se vincula al registro de riesgos y si hay umbrales de escalado definidos en caso de explotación o indicadores de compromiso. No para burocratizar el parcheo, sino para evitar el clásico escenario en que seguridad técnica corre, legal se entera tarde y la organización improvisa notificaciones regulatorias con el reloj ya corriendo.

Lo que esta CVE dice sobre la madurez real de una organización

Las vulnerabilidades en productos ubicuos funcionan como una radiografía incómoda. No muestran solo si tienes un parche pendiente. Muestran si conoces tus activos, si segmentas el riesgo, si puedes desplegar cambios sin caos, si tus controles compensatorios existen de verdad y si la comunicación entre seguridad, IT, legal y negocio funciona cuando toca.

CVE-2026-45475 no será la última RCE en software de usuario, y probablemente tampoco la más mediática del año. Pero sí puede ser una prueba útil de madurez. Si tu empresa tarda varios días en averiguar dónde está Office, quién lo actualiza y qué usuarios quedan fuera de cobertura, el problema no es Microsoft. Microsoft ha hecho su parte al publicar y corregir. La parte incómoda te corresponde a ti.

También conviene recordar algo que a menudo se pierde entre CVEs y dashboards: las vulnerabilidades de cliente tienen una dimensión humana más marcada. Aquí no solo importa el parche. Importa cómo se comunica sin generar fatiga, cómo se refuerza la vigilancia sin paralizar al usuario, y cómo se evita que la próxima campaña de phishing use precisamente el ruido del parche como señuelo. Sí, eso también pasa. Los atacantes leen las noticias igual que tú.

Perspectiva: menos fetichismo por la CVSS, más foco en la exposición real

Cuando se publique o consolide la puntuación CVSS y más detalle técnico, muchos equipos correrán a meter la cifra en una hoja de priorización. Útil, hasta cierto punto. Pero una vulnerabilidad en Office con posibilidad de RCE tiene que evaluarse, sobre todo, por su exposición funcional: cuántos usuarios abren documentos externos, qué controles de aislamiento existen, qué privilegios tienen, qué visibilidad ofrece el EDR y cuánto tarda la organización en cerrar la brecha.

Un 8,8 en un activo invisible puede ser menos urgente que un 7,8 en Office desplegado en 20.000 endpoints con procesos documentales intensivos. La puntuación ayuda; el contexto decide.

Con DORA y NIS2 ya asentándose en la práctica supervisora europea, las excusas sobre “vulnerabilidades inevitables” pesan cada vez menos. Lo inevitable es que sigan apareciendo. Lo exigible es la capacidad de gestionarlas con disciplina. Ahí se distingue la resiliencia operativa real del PowerPoint con tipografía cara.

La conclusión, por tanto, no necesita dramatismo. CVE-2026-45475 exige parcheo rápido, telemetría útil y revisión de controles alrededor de Office. Si además sirve para retirar excepciones absurdas, reducir privilegios y ordenar el parque de productividad, mejor todavía. Las buenas crisis hacen limpieza. Las malas, auditorías.