Mark of the Web: siete formas de que el archivo que llega de fuera no lo parezca

El martes 13, en el paquete de actualizaciones de octubre, Microsoft corrigió CVE-2026-96951. La ficha oficial lo titula Windows Shell Security Feature Bypass Vulnerability y responde en su propio apartado de preguntas qué función de seguridad se salta: «An attacker who successfully exploited the vulnerability could evade Mark of the Web (MOTW) defenses». Puntuación 8.8, con un vector que marca explotación funcional y corrección oficial disponible. Y una línea que conviene leer entera: «Publicly Disclosed:No;Exploited:Yes;Latest Software Release:Exploitation Detected». No se sabía y ya se usaba.

La reacción normal a esto es parchear, y hay que parchearlo. Pero el fallo de esta semana es la parte menos interesante del asunto. Lo interesante es qué es exactamente eso que se saltaba, porque es el cimiento de la protección que tu gente llega a ver cuando abre un adjunto, y porque la documentación de la propia Microsoft enumera, sin esconderlas, siete situaciones perfectamente legítimas en las que ese cimiento no está.

Qué decide que Office no ejecute esa macro

Mark of the Web es un flujo de datos alternativo de NTFS llamado Zone.Identifier que Windows adjunta a los ficheros que llegan de sitios en los que no confía. Dentro va un número, el ZoneId: 0 es el propio equipo, 1 la intranet local, 2 los sitios de confianza, 3 internet y 4 los sitios restringidos. Se mira desde una consola, sin herramientas:

notepad informe-trimestral.xlsm:Zone.Identifier

[ZoneTransfer]
ZoneId=3

Ese 3 es la razón por la que Excel enseña la banda roja de riesgo de seguridad y no deja ejecutar la macro. El diagrama de decisión que publica Microsoft tiene siete pasos, y el primero es la frase que sostiene todo lo demás: «A user opens an Office file containing macros obtained from the internet. (…) The file has Mark of the Web (MOTW)». Si el fichero no la lleva, no hay paso dos. No es que el usuario pueda saltarse el aviso: es que el aviso no se plantea.

Cuatro vías por las que la marca no llega a ponerse

Las cuatro están en la misma página de documentación, en apartados distintos, y ninguna es un fallo. Son el comportamiento previsto.

• Abrir en la aplicación de escritorio. Si alguien está viendo el fichero en la web de OneDrive o en un sitio de SharePoint —incluido el de un canal de Teams— y pulsa Open in Desktop App, «the file won't have Mark of the Web». Es el camino que le enseñas a usar a todo el mundo porque es el cómodo.
• El cliente de sincronización de OneDrive. Cuando es él quien se descarga el fichero, tampoco se pone: «If a user has the OneDrive sync client running and the sync client downloads a file, then the file won't have Mark of the Web».
• Las carpetas conocidas. Escritorio, Documentos, Imágenes, Capturas y Álbum de cámara, cuando están sincronizadas con OneDrive, «don't have Mark of the Web». Es decir: la copia de seguridad de carpetas que activas por higiene también desactiva la marca donde la gente guarda las cosas.
• El sistema de ficheros. «Mark of the Web only applies to files saved on an NTFS file system, not files saved to FAT32 formatted devices». El pendrive de la feria, el disco de intercambio con la gestoría, la tarjeta de una cámara: si va en FAT32, no hay dónde escribir la etiqueta.

Tres más en las que la marca está y no decide nada

• Ubicaciones de confianza. Guardar un fichero de internet en una de ellas «ignores the check for Mark of the Web and opens with VBA macros enabled». La propia Microsoft recomienda administrarlas «carefully» y usarlas «sparingly»; lo que uno se encuentra al sacar la lista son ubicaciones que nadie sabe justificar, puestas años atrás para desatascar una incidencia concreta.
• La zona de origen. La marca se añade «only from the Internet or Restricted sites zones», y con ZoneId=2 las macros no se bloquean. Añadir un servidor de ficheros a sitios de confianza para resolver una incidencia tiene un efecto que la documentación avisa en voz alta: «you're also giving the entire site elevated permissions for scenarios not related to Office».
• El propio usuario. La casilla Desbloquear en las propiedades del fichero, o un Unblock-File en PowerShell, borra el ZoneId. Y hay una herencia silenciosa: si alguien pulsó «Habilitar contenido» en ese documento antes del cambio de 2022, pasó a ser un Trusted Document y las macros «will continue to run» pese al bloqueo nuevo.

Ninguna de las siete es un ataque. Son decisiones de producto y de administración, tomadas por buenas razones, que en conjunto describen algo incómodo: la protección que de verdad separa a tu gente de una macro hostil no depende de una política que hayas escrito, sino de por qué puerta entró el fichero.

Y el octavo, que esta semana costó un parche urgente

El CVE del martes añade a esa lista un camino que no es legítimo. Según la ficha de Microsoft es una inyección de comandos en Windows Shell que un atacante usa enviando «a specially crafted file» por correo o mensajería, y el aviso insiste en que hace falta que alguien lo abra. Afecta a 31 productos: treinta ediciones de Windows, de Windows 10 1607 a Windows 11 26H2 y de Server 2012 R2 a Server 2025, más Outlook.com, que es el único de la lista sin KB porque no se parchea en tu casa. Para los otros treinta hacen falta nueve paquetes distintos según la rama. Si tu inventario tiene cuatro versiones de Windows conviviendo, ahí tienes cuatro validaciones, no una.

No es el primero de este año en el mismo componente. En febrero fue CVE-2026-21510, y en abril llegó CVE-2026-32202 porque el parche de febrero se había quedado a medias: el equipo de investigación de Akamai documentó que la corrección cerró la ejecución de código pero dejó abierta la etapa anterior, la extracción del icono, de modo que la máquina seguía autenticándose contra el servidor del atacante. Tres entradas del mismo componente en el catálogo de vulnerabilidades explotadas de CISA en ocho meses, y una de ellas hija de un arreglo incompleto.

El plazo ya no cabe en una ventana de mantenimiento

Las tres entradas llevan fecha límite, y la progresión se lee sola. A la de febrero CISA le dio hasta el 3 de marzo: 21 días. A la de abril, hasta el 12 de mayo: 14. A la del martes, hasta el 16 de octubre: tres. Descargamos el catálogo entero (versión 2026.10.13, 1.741 entradas) y contamos los plazos de las 257 altas de este año: 132 son de tres días, 78 de catorce, 44 de veintiuno y tres llevan plazos atípicos. La mitad de las altas del año ya se despacha en 72 horas.

Conviene decir de dónde sale el estrechamiento, porque no es que los fallos sean peores cada vez: CISA cambió el marco a mitad de camino. La directiva BOD 26-04, publicada el 10 de junio, reparte las correcciones en ventanas de tres, catorce o treinta días, o las aplaza al siguiente ciclo de actualización, y la de tres sale del cruce de cuatro condiciones: activo expuesto públicamente, fallo presente en el catálogo, explotación automatizable y control completo del sistema. Los plazos de febrero y abril se fijaron antes de que la directiva existiera. Después: de las 124 altas posteriores al 10 de junio, 101 llevan tres días y 23 llevan catorce, y el tramo de treinta días no ha aparecido ni una sola vez. Antes de esa fecha eran 31 de 133.

Y conviene decir a quién obliga eso: a las agencias federales civiles de Estados Unidos, con sus exclusiones. A una pyme de Manresa no la obliga nadie. Lo que mide ese plazo no es una multa, es el tiempo que el organismo que lo publica cree que tardas en tener el problema dentro. De la aritmética de esos plazos contra el calendario laboral ya escribimos en agosto —tres días para parchear y el tercero cae en sábado—; lo que ha cambiado desde entonces no es la aritmética, es que la ventana corta ya es la norma y no el caso excepcional.

La política que lo haría obligatorio no está en todos los planes

Hay una forma de no depender del comportamiento por defecto: activar la política «Block macros from running in Office files from the Internet», que Microsoft recomienda como parte de su línea base de seguridad para Microsoft 365 Apps for enterprise. Con ella puesta, dice la documentación, «your organization won't be affected by this default change». Y mucho más abajo, en otra sección y en otro recuadro, la letra pequeña que la acota: «You can only use policies if you're using Microsoft 365 Apps for enterprise. Policies aren't available for Microsoft 365 Apps for business».

Esto no significa que el Business Premium de una pyme de veinte personas quede desprotegido: el bloqueo por defecto le aplica igual. Significa que no puede fijarlo, que depende de que el comportamiento por defecto siga siendo ese y de que nadie toque el Centro de confianza en su equipo. La diferencia entre una protección y una configuración por defecto es quién puede cambiarla sin que te enteres. Es el mismo razonamiento que seguimos con las versiones perpetuas de Office, donde lo que caduca no es el programa sino la prueba —Office 2021 no deja de funcionar, deja de probarse—.

La tabla que responde esto en tu casa

Lo anterior es lo que dice la documentación. Lo que pasa en tu empresa se averigua con el mismo fichero entrando por todas las puertas y un notepad fichero:Zone.Identifier detrás de cada una. Es media hora y sale una tabla de tres columnas:

Faltan dos cosas que no caben en la tabla y se responden igual de rápido. Una: qué plan de Office tienes contratado de verdad, porque de ahí depende si la política existe o no. Y dos: cuántos días pasan desde que publicas una actualización hasta que el 95% de los equipos ha reiniciado de verdad. Si esa segunda respuesta es «el sábado que viene», ya sabes que el plazo de tres días no es para ti, y lo que te queda entretanto es detección en el puesto.

Lo que queda apuntado

La banda amarilla de Office lleva veinte años educando a la gente para que desconfíe de lo que viene de fuera, y ha funcionado razonablemente bien. El problema de educar a alguien con una señal es que el día que la señal no aparece, lo que has enseñado es a confiar. Un adjunto que llega por la vía cómoda, sin marca, no pide permiso para nada, y el usuario que hizo bien su trabajo durante años no tiene forma de notar la diferencia.

Fuentes (consultadas el 14-10-2026): el título oficial de CVE-2026-96951, la puntuación 8.8, el vector, la línea «Publicly Disclosed:No;Exploited:Yes», las dos respuestas del FAQ, los 31 productos afectados y los nueve paquetes de actualización salen del fichero CVRF de octubre de 2026 que publica el MSRC. Las fechas de alta y los plazos de las tres entradas de Windows Shell, el recuento de las 257 añadidas en 2026 y el corte del 10 de junio son nuestros, hechos sobre el catálogo KEV en su versión 2026.10.13 (1.741 entradas): cualquiera puede descargar el JSON y rehacerlos. El reparto de ventanas y las cuatro condiciones del tramo de tres días son de la directiva BOD 26-04; el alcance federal, del aviso del 13 de octubre. El flujo de siete pasos, el comando de Zone.Identifier, la tabla de zonas, las cuatro vías sin marca, las ubicaciones de confianza, los documentos de confianza y la frase sobre los planes son de «Macros from the internet are blocked by default in Office». El análisis del parche incompleto de febrero es de Akamai. Un matiz de conteo, por si comparas titulares: el CVRF de octubre trae 1.760 identificadores, pero 341 son de Mariner, el Linux de Azure, que la mayoría de recuentos públicos deja fuera; de ahí que se lean cifras distintas según la casa. No hemos reproducido el fallo ni tenemos telemetría propia sobre su explotación: lo que es nuestro es el recuento del catálogo, la lectura de las siete vías juntas y la tabla de puertas de entrada.