Cuando sale una prueba de concepto y a las horas hay atacantes usándola, la reacción de oficio es preguntarse si hacía falta publicarla. Nos parece la pregunta equivocada, y no por elegancia: los sensores de KEVintel datan el primer intento contra este fallo el 19 de julio, veinticuatro días antes de que el exploit existiera en GitHub. Lo que sí cambia el problema es otra fecha: el parche salió el 14 de julio, el mismo día en que SharePoint Server 2016 y 2019 dejaron de recibirlos.
No somos partidarios ni detractores de publicar código de explotación por principio. Administramos servidores de clientes, y desde esa silla lo que cuenta son los veintinueve días que van del parche del 14 de julio al exploit del 12 de agosto: qué se hizo con ellos. En este caso hay además una circunstancia que no se repite todos los meses, y es la que hace que este aviso merezca media hora de tu tarde.
Qué hace el fallo: una firma que nadie comprueba
CVE-2026-55040 está puntuado por Microsoft con un 9,1, con este vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Por red, sin complicaciones, sin credenciales previas, sin que nadie tenga que pinchar en nada. Confidencialidad e integridad altas; disponibilidad, ninguna. En cristiano: el servidor sigue en pie mientras alguien lee y escribe dentro haciéndose pasar por otro.
El análisis de Rapid7 describe cuatro piezas que fallan seguidas, y ninguna de ellas es un desbordamiento exótico. Son cuatro comprobaciones que existen y que dicen que sí:
- 1El código deja
RequireSignedTokens = false, así que se admite un token conalg: none: sin firma. - 2La cabecera
x5tdel token interior apunta al certificado del propio SharePoint, que se obtiene de un endpoint de metadatos sin autenticar. El servidor resuelve esa clave sin verificar nada. - 3La validación del emisor acepta ese certificado precisamente porque no está en la lista de servicios de confianza que se consulta.
- 4La comprobación final de la firma solo exige que no esté vacía. No que sea válida. Con poner cuatro letras, pasa.
Lo único que el atacante necesita aportar es a quién quiere suplantar: el SID de Windows o el UPN de la víctima, que muy a menudo es su dirección de correo. Con eso opera como ese usuario —o como administrador del sitio— contra las API autenticadas. El punto tres es el que más se parece a la vida real: la comprobación no falla por descuido, falla por estar mal orientada. Busca en una lista, no encuentra el certificado y en vez de rechazarlo, lo da por bueno.
La cronología, que es donde está el argumento
- 14 julMicrosoft y Rapid7 divulgan el fallo. Salen
KB5002891(2016),KB5002883(2019) yKB5002882(Subscription Edition). Ese mismo día termina el soporte extendido de 2016 y 2019. - 19 julLos sensores de KEVintel datan aquí el primer intento contra este fallo. Cinco días después del parche, sin exploit público de por medio. Es telemetría de una sola casa: cuatro sensores.
- 11-12 agoRapid7 publica el análisis técnico completo y la prueba de concepto en GitHub. El 12, los investigadores de Defused ven atacantes usándola contra sus señuelos de SharePoint.
- 14 agoKEVintel acumula 367 intentos desde 23 direcciones IP y ocho países, con confianza «confirmada». El CVE no está en el catálogo KEV de CISA, y la valoración de CISA del día 13 clasifica la explotación como «prueba de concepto», no como «activa».
El día que hay que mirar es el 19 de julio, con una advertencia por delante: viene de una sola fuente. Los sensores de KEVintel datan ahí el primer intento contra este fallo, y la cobertura del sector —que sitúa la explotación después de la prueba de concepto— no lo recoge. Son además pocos eventos: hasta el 11 de agosto, la propia ficha apenas contaba una decena. Y CISA, en su valoración del 13 de agosto, sigue clasificando la explotación como «prueba de concepto» y no como «activa». No lo damos por cerrado; lo damos por suficiente para ir a mirar los registros de julio, que es lo que cuesta media hora. Porque para llegar ahí no hace falta un actor estatal: basta con saber comparar el binario de antes del parche con el de después, que es una técnica de manual y no una hazaña.
El argumento de siempre, y por qué aquí no vale
El argumento contra publicar código de explotación tiene una versión fuerte, y conviene ponerla entera: a quien iba en serio no le hacía falta —ese llevaba semanas—, pero un repositorio con el exploit dentro convierte a cualquiera con una consola en atacante capaz. En este caso hay datos que lo respaldan: los intentos que registran los sensores se concentran justo después del 12 de agosto, y los señuelos de Defused vieron el código de Rapid7 usado tal cual, el mismo día. Publicar tiene un coste medible.
Aun así no nos convence, por una razón concreta: el argumento pide tiempo para parchear, y aquí ya no queda tiempo que pedir. La lógica de retrasar la publicación tiene sentido cuando existe un proceso de arreglo funcionando —el fabricante corrige, el cliente aplica, la ventana se cierra—. Para un SharePoint 2016 o 2019, ese proceso se cerró el 14 de julio y no hay ESU que comprar, como ya contamos cuando llegó la fecha. Ahí el retraso no compra parcheo: compra ignorancia. Cuatro semanas más de silencio no habrían arreglado un solo servidor; habrían mantenido a los que lo administran creyendo que un aviso de julio ya estaba resuelto.
Y hay que decir la parte que no nos favorece: tenemos interés. Vivimos de administrar infraestructura de clientes y de desplegar Microsoft 365, así que un aviso ruidoso nos beneficia. Léelo con eso puesto. Lo que no cambia con el interés de nadie es el calendario de soporte.
Un contraste que conviene tener delante
A día de hoy, CVE-2026-55040 no figura en el catálogo KEV de CISA. El fallo de los Cisco ASA del que escribimos esta misma mañana sí: entró el 11 de agosto con fecha límite el 14, y es una denegación de servicio que no filtra ni altera nada. Este permite hacerse pasar por el administrador de tu intranet. Sobre por qué una lista ajena llega siempre con su propia latencia ya escribimos con el aviso de vCenter; aquí basta con dejar los dos casos uno al lado del otro.
Qué miramos nosotros en un servidor así
- ✓La compilación exacta, no «lo actualizamos en julio». Corregidas:
16.0.5561.1001en 2016,16.0.10417.20175en 2019 y16.0.19725.20434en Subscription Edition. En la administración central o con(Get-SPFarm).BuildVersion. Un número por debajo y el resto de la lista sobra. - ✓Quién puede abrir una conexión. Shadowserver cuenta más de 8.500 servidores SharePoint alcanzables desde internet —todos los que ve, no los vulnerables—. Una extranet publicada «porque los comerciales entran desde fuera» es exactamente la población contra la que se lanzan estos intentos. Si puede vivir detrás de la VPN, hoy es el día.
- ✓Qué pasó entre el 14 y el 19 de julio. Si el parche se aplicó tarde —y en agosto, con medio equipo de vacaciones, se aplicó tarde en muchos sitios—, hubo una ventana con intentos reales por ahí fuera. Toca mirar los registros de IIS de esas fechas buscando peticiones a los endpoints de metadatos y de token, no solo confirmar que hoy estás al día.
- ✓Qué se llevaría alguien que entrara como administrador. En la intranet suelen convivir nóminas, contratos, presupuestos y la carpeta de dirección. La puntuación mide el fallo; el daño lo mide lo que hay guardado dentro, y esa lista la tiene cada empresa.
- ✓Qué versión es realmente. Subscription Edition sigue recibiendo actualizaciones y no está en esta conversación de fin de soporte, aunque comparta el CVE. Confundir las dos cosas lleva a las dos decisiones malas: dormirse en 2019 o migrar con prisas algo que no hacía falta.
Tres reflejos que salen caros
El primero es poner una regla en el WAF y dar el tema por cerrado. Sirve para esta cadena concreta y para el patrón que hoy se conoce; el servidor que hay detrás seguirá sin recibir arreglos el mes que viene, y para el siguiente fallo no habrá regla que copiar de nadie.
El segundo es anunciar la migración a Microsoft 365 «para este mes». Mover una intranet con años de permisos heredados, flujos y personalizaciones no es un fin de semana, y prometerlo es como se acaba con las dos cosas encendidas y ninguna mantenida. Reducir la exposición hoy y migrar con calendario son dos decisiones distintas, y solo una de ellas se puede hacer esta tarde.
El tercero es archivarlo como un fallo más del montón. En julio salieron 622 parches en un solo día y ese volumen invita a tratarlos por lotes. Este tiene una diferencia de fondo con los otros 621: no habrá un próximo martes que arregle lo que venga después.
Lo que cambió el 15 de julio
Un servidor fuera de soporte no es un servidor con un riesgo mayor: es un servidor con un riesgo que ya no baja. Hasta el 14 de julio, cada fallo que aparecía en tu SharePoint 2016 tenía por delante una fecha en la que se arreglaría. Desde el 15, no. Este CVE es el primero que lo demuestra con exploit público y con intentos sobre la mesa, y por eso vale la pena mirarlo hoy: enseña algo sobre los que vendrán detrás y ya no llevarán KB. Conviene saber hasta cuándo «estamos parcheados» va a seguir significando algo en esa máquina.
Con una salvedad honesta: Microsoft ha roto su propia regla al menos dos veces, con XP y Server 2003 en 2017 por WannaCry y otra vez en 2019 por BlueKeep, siempre ante fallos capaces de propagarse solos de máquina en máquina. Este no lo es. Planificar contando con esa excepción es planificar con la lotería.
Fuentes (consultadas el 14 de agosto de 2026): puntuación 9,1, vector CVSS, descripción oficial, versiones afectadas y compilaciones corregidas — registro de CVE-2026-55040 en el NVD, con la métrica asignada por Microsoft y con la valoración SSVC de CISA del 13 de agosto que clasifica la explotación como «prueba de concepto»; cadena técnica de las cuatro comprobaciones y fecha de divulgación conjunta del 14 de julio — análisis técnico de Rapid7; números de KB — KB5002891, KB5002883 y KB5002882 en el soporte de Microsoft; publicación de la prueba de concepto y observación de su uso el 12 de agosto por Defused — Security Affairs y BleepingComputer, que es también la fuente del recuento de más de 8.500 servidores expuestos atribuido a Shadowserver; primer intento observado el 19 de julio, 367 intentos acumulados, 23 direcciones IP, ocho países y confianza «confirmada» — ficha de KEVintel (telemetría de cuatro sensores privados: son intentos observados por ellos, no un censo del sector, y la cobertura del sector sitúa la explotación después de la prueba de concepto); ausencia del CVE en el catálogo de vulnerabilidades explotadas conocidas — KEV de CISA, comprobado sobre su fichero público el 14 de agosto; fin de soporte extendido de SharePoint Server 2016 y 2019 el 14 de julio de 2026 sin programa ESU — ciclo de vida de SharePoint Server 2016 y 2019 en Microsoft Learn. Foto: «Archive storage», Samuel Zeller, dominio público (CC0), vía Wikimedia Commons.
¿Qué hacemos con la intranet que ya no recibe parches?
En everyWAN desplegamos y securizamos el puesto de trabajo moderno sobre Microsoft 365, sin prometer que una migración es un fin de semana. Si tienes un SharePoint local encendido y ninguna fecha escrita, esa conversación es corta y merece la pena tenerla.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN