El 1 de julio de 2026, CISA incorporó CVE-2026-45659 a su catálogo de vulnerabilidades explotadas activamente (KEV) y fijó a las agencias federales estadounidenses un plazo de tres días para parchear. Microsoft la corrigió con las actualizaciones de mayo, aunque el CVE fue incorporado posteriormente al Security Update Guide como cambio informativo, y mantenía una valoración de explotación menos probable.
El fallo, con puntuación CVSS 8.8, permite ejecutar código en el servidor a cualquier usuario autenticado con permisos mínimos de miembro del sitio. Y no es un ejercicio teórico: La explotación activa ya está confirmada por CISA, aunque por ahora las fuentes públicas no atribuyen CVE-2026-45659 a un actor concreto ni confirman su uso directo para desplegar ransomware. El precedente relevante es Storm-2603, que en 2025 sí explotó la cadena ToolShell en SharePoint on-premise para desplegar Warlock.
Qué es CVE-2026-45659 y por qué preocupa ahora
CVE-2026-45659 es una vulnerabilidad de deserialización de datos no confiables en SharePoint Server. Microsoft la corrigió el 12 de mayo de 2026 en las actualizaciones KB5002863, KB5002868 y KB5002870, y afecta a SharePoint Server Subscription Edition, SharePoint Server 2019 y SharePoint Enterprise Server 2016.
El mecanismo, explicado a nivel conceptual, es el habitual en esta clase de fallos: la aplicación reconstruye objetos a partir de datos que llegan de fuera sin validar suficientemente su contenido. Cuando esos datos se procesan, el servidor termina ejecutando lógica que el atacante controla. La condición que lo hace peligroso no es la complejidad, sino la accesibilidad: según Help Net Security la complejidad de ataque es baja y basta con una cuenta con permisos de miembro del sitio, un nivel de acceso muy común en despliegues internos con miles de usuarios.
Ese matiz importa. Muchos responsables descartaron el aviso de mayo porque exigía autenticación, y lo leyeron como una barrera. En SharePoint, donde el acceso de «miembro» se reparte con generosidad y las credenciales robadas circulan por foros y volcados, la autenticación previa es un obstáculo menor para un actor con recursos.
El precedente ToolShell: por qué SharePoint local sigue siendo un objetivo
Para entender la urgencia hay que mirar atrás. En julio de 2025, la cadena conocida como ToolShell (CVE-2025-49704, CVE-2025-49706 y los bypass CVE-2025-53770 y CVE-2025-53771) desató una campaña masiva contra SharePoint on-premise. Microsoft documentó la explotación activa por tres grupos vinculados a China: Linen Typhoon, Violet Typhoon y el propio Storm-2603, este último centrado en ransomware.
El alcance fue considerable. Unit 42 de Palo Alto Networks siguió la evolución de la campaña y los recuentos públicos hablaron de decenas de servidores comprometidos en las primeras oleadas, escalando después conforme se publicaban pruebas de concepto. Storm-2603 combinó el acceso inicial con secuestro del orden de búsqueda de DLL para desplegar Warlock, según el análisis de The Hacker News sobre el grupo.
La lección de 2025 es la que se repite en 2026: SharePoint on-premise concentra datos sensibles, está profundamente integrado con identidad corporativa y, cuando está expuesto a Internet, ofrece una superficie que los operadores de ransomware conocen bien. CVE-2026-45659 no inaugura un problema nuevo; reactiva uno que nunca se cerró del todo.
Por qué el parche no basta por sí solo
Aplicar la actualización de mayo es imprescindible, pero insuficiente si el servidor pudo estar expuesto antes de parchear. La experiencia de ToolShell dejó claro que estos atacantes roban material criptográfico del servidor —claves de máquina ASP.NET— para mantener acceso persistente incluso después de que se aplique el parche. Un servidor parcheado pero previamente comprometido sigue siendo un servidor comprometido.
Por eso la respuesta correcta no es solo «parchear y olvidar». Como explicamos en nuestra guía sobre cómo priorizar vulnerabilidades explotables con KEV, EPSS y SSVC, la inclusión de un CVE en el catálogo KEV de CISA es la señal más clara de que la explotación ya está ocurriendo y de que la ventana de reacción se mide en días, no en semanas.
Detección: qué buscar en la telemetría
Sin entrar en cómo se construye el ataque, sí conviene saber qué rastro deja para orientar la caza de amenazas. Los indicadores observados en la familia ToolShell y reutilizados por Storm-2603 dan un buen punto de partida:
- Procesos hijo anómalos de w3wp.exe (el worker de IIS que sirve SharePoint) lanzando intérpretes de comandos o utilidades de sistema. Un servidor web que de pronto invoca cmd.exe o PowerShell es una señal fuerte.
- Escritura de archivos .aspx en directorios de LAYOUTS o rutas web servidas por SharePoint. En campañas previas se observaron web shells con nombres como spinstall0.aspx; el nombre cambia, el patrón de un .aspx nuevo no legítimo no.
- Acceso o exfiltración de claves de máquina ASP.NET (machineKey) y su reutilización para forjar tokens válidos.
- Secuestro del orden de búsqueda de DLL: binarios legítimos cargando DLL con nombres esperados desde rutas inusuales, técnica que Storm-2603 usó para desplegar el cifrador.
- Peticiones a endpoints de SharePoint como ToolPane o similares con cargas serializadas voluminosas o mal formadas, correlacionadas con picos de CPU en el proceso worker.
Estas señales alimentan reglas de detección en el EDR y en el SIEM. Un equipo que opere un SOC gestionado con caza de amenazas continua puede convertir estos indicadores en consultas persistentes en lugar de esperar a que salte una alerta genérica.
Defensa práctica
Más allá del parche, un servidor SharePoint local expuesto exige un conjunto de controles concretos:
- Aplicar las actualizaciones de mayo de 2026 (KB5002863/68/70) en todas las ediciones afectadas, sin excepción y priorizando los servidores accesibles desde Internet.
- Rotar las claves de máquina ASP.NET después de parchear, asumiendo que el material criptográfico pudo quedar expuesto. Es el paso que más equipos omiten y el que neutraliza la persistencia.
- Retirar SharePoint on-premise de la exposición directa a Internet siempre que sea viable, situándolo tras una pasarela con autenticación reforzada o VPN.
- Activar y verificar AMSI (Antimalware Scan Interface) en modo completo para SharePoint, que en la campaña de 2025 bloqueó parte de la explotación cuando estaba correctamente configurado.
- Revisar y reducir la asignación de permisos de miembro del sitio: cuantas menos cuentas autenticadas puedan interactuar con componentes vulnerables, menor es la superficie.
- Cazar retrospectivamente indicios de compromiso previos al parche, no solo vigilar de cara al futuro.
Si la revisión retrospectiva encuentra rastro de intrusión, el escenario deja de ser de gestión de vulnerabilidades y pasa a ser de respuesta a incidentes. La diferencia es sustancial: un servidor comprometido con acceso persistente y posible despliegue de ransomware requiere contención, análisis forense y erradicación, no un simple parche.
Implicaciones de cumplimiento
Para las entidades sujetas a NIS2, una vulnerabilidad explotada activamente en un sistema que sostiene procesos de negocio entra de lleno en las obligaciones de gestión de riesgos y de notificación de incidentes. Un compromiso de SharePoint con despliegue de ransomware es, casi por definición, un incidente significativo con plazos de notificación estrictos.
La trazabilidad importa tanto como la corrección. Documentar cuándo se aplicó el parche, cuándo se rotaron las claves y qué evidencia descarta un compromiso previo es lo que convierte una respuesta técnica en una respuesta defendible ante un supervisor. Nuestro equipo de cumplimiento NIS2 y el servicio MSSP trabajan precisamente esa unión entre operación y evidencia.
Lo esencial
CVE-2026-45659 no es un fallo espectacular por su complejidad, sino por su contexto: SharePoint local, autenticación de bajo umbral, un actor de ransomware ya activo y un catálogo de amenazas explotadas que confirma la urgencia. Microsoft lo consideró improbable; la realidad lo desmintió en semanas. La conclusión operativa es sencilla y poco cómoda: parchear ya, rotar claves, cazar hacia atrás y asumir que un servidor SharePoint expuesto es un objetivo, no una posibilidad.