SharePoint CVE-2026-45659 ya es un riesgo de ransomware

CVE-2026-45659 ha pasado de ser un problema de parches en SharePoint a convertirse en una amenaza de ransomware. Desde agosto de 2026, CISA clasifica este fallo como explotado activamente y vinculado a campañas conocidas de ransomware, por lo que cualquier servidor local de SharePoint afectado que haya estado expuesto antes de parchear requiere tanto remediación como una evaluación de compromiso.

La cronología de fechas lo deja claro. Microsoft publicó actualizaciones de seguridad en mayo de 2026. CISA añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas el 1 de julio, y la relación con el ransomware se hizo pública en agosto. Por tanto, los administradores deben analizar la ventana temporal entre la disponibilidad del parche y el momento exacto en que cada servidor quedó realmente protegido.

Mr.PlanB ya analizó la designación inicial de ransomware por parte de CISA cuando cambió su estado. La pregunta más útil ahora es qué debe hacer un equipo de infraestructura cuando una vulnerabilidad ha sido parcheada pero también convertida en arma de ataque, sobre todo si el servidor pasó semanas accesible desde internet.

¿Se está utilizando realmente CVE-2026-45659 en ataques de ransomware?

Sí. El programa de vulnerabilidades explotadas conocidas de CISA dejó atrás la posibilidad teórica de explotación al confirmar ataques reales en curso, y posteriormente la agencia catalogó el fallo como asociado a campañas de ransomware. Esta es una señal operativa mucho más determinante que una simple puntuación de gravedad, ya que sitúa la vulnerabilidad dentro del comportamiento real de los atacantes.

CVE-2026-45659 es una vulnerabilidad de deserialización en Microsoft SharePoint Server. Microsoft la describe como un fallo que permite a un atacante autenticado ejecutar código a través de la red. Conviene prestar atención al nivel de privilegios requerido: el atacante no necesita ser administrador de SharePoint desde el inicio, ya que un acceso inicial con pocos privilegios puede bastar para transformar la entrada a la aplicación en ejecución de código en el servidor.

La etiqueta de ransomware no implica que cada intento de explotación termine en cifrado de datos. CISA no ha señalado públicamente a un operador de ransomware específico para este CVE, y algunas publicaciones abiertas han incluido especulaciones que no deben considerarse atribuciones formales. La conclusión prudente es más acotada y sigue siendo grave: las operaciones de ransomware están aprovechando esta vulnerabilidad, por lo que los sistemas expuestos deben tratarse como objetivos reales de intrusión.

¿Qué servidores de SharePoint deben revisar primero los administradores?

Los despliegues locales afectados incluyen SharePoint Enterprise Server 2016, SharePoint Server 2019 y SharePoint Server Subscription Edition. Conviene comenzar inventariando cada instancia, incluidos servidores antiguos que aún responden en una dirección interna, réplicas para recuperación ante desastres, entornos de prueba y nodos orientados a internet que alguien consideró temporales en su momento.

Contar con una política de actualizaciones de Windows en marcha no garantiza que el parche específico de SharePoint esté instalado. Confirma que la actualización de seguridad correspondiente de SharePoint se instaló con éxito en cada servidor y registra la fecha de instalación. Una máquina parcheada en agosto exige una investigación muy diferente a una actualizada en mayo, porque la ventana de exposición no es la misma.

También es un buen momento para buscar rutas de publicación olvidadas. Proxies inversos, reglas de VPN, antiguas entradas de NAT, controladores de entrega de aplicaciones y reglas de cortafuegos en la nube pueden mantener accesible una instancia mucho después de que el equipo crea haberla aislado. La vulnerabilidad reside en la aplicación, pero el riesgo práctico depende en gran medida de quién podía alcanzarla y de qué credenciales o sesiones pudo haber obtenido un atacante.

¿Por qué sigue siendo peligrosa una ejecución remota de código autenticada en SharePoint?

Un fallo de ejecución remota de código autenticada es peligroso porque los entornos empresariales de SharePoint suelen acumular numerosas cuentas legítimas con pocos privilegios. Contratistas externos, usuarios de proyectos, cuentas de servicio, identidades migradas y accesos obsoletos amplían el abanico de credenciales susceptibles de abuso antes de activar la vulnerabilidad.

La autenticación también puede surgir como un segundo paso. Campañas de phishing, reutilización de contraseñas, registros de infostealers, robo de sesiones y endpoints comprometidos facilitan credenciales válidas, y una vez que el atacante dispone de una cuenta legítima, una falla del lado del servidor convierte ese acceso de identidad en una posición mucho más privilegiada.

SharePoint resulta especialmente delicado en este escenario porque opera muy cerca de documentos confidenciales, flujos de trabajo internos, permisos, sistemas de identidad y, a menudo, otra infraestructura de Microsoft. Un servidor de aplicaciones comprometido puede servir de punto de partida para el robo de credenciales, la persistencia, el movimiento lateral y la preparación para la exfiltración de datos. El ransomware es la consecuencia visible, pero el desafío más complejo de detectar es todo lo que un atacante puede ejecutar antes de que comience el cifrado.

Por esta razón, la gestión de vulnerabilidades y la recuperación ante ransomware deben trabajar de la mano. El equipo de seguridad puede cerrar el CVE mientras el equipo de recuperación aún debe responder si el entorno puede reconstruirse a partir de datos verdaderamente confiables.

¿Basta con aplicar el parche tras iniciarse la explotación activa?

Aplicar el parche es obligatorio, pero no puede deshacer lo ocurrido anteriormente. Si un servidor SharePoint vulnerable estuvo accesible durante un periodo de explotación confirmada, la actualización impide que la vulnerabilidad conocida vuelva a utilizarse, pero no demuestra en absoluto que el servidor estuviera limpio antes de recibir el parche.

Las directrices de CISA para SharePoint de julio advirtieron específicamente sobre atacantes que roban claves de máquina de IIS y emplean técnicas de deserialización para mantener la persistencia, por lo que un responsable de respuesta a incidentes no puede considerar que una actualización exitosa marca el fin del problema. Cuando la ventana de exposición coincide con la explotación activa, es indispensable revisar registros, telemetría de endpoints, eventos de autenticación, archivos nuevos, indicios de webshells, cambios en servicios, tareas programadas y conexiones salientes inusuales.

La misma lógica se aplica a credenciales y secretos. Si el servidor tenía acceso a cuentas de servicio, credenciales de bases de datos, certificados, claves API o sesiones administrativas, evalúa si estos secretos requieren rotación. El alcance exacto dependerá de las evidencias, pero es necesario plantear la pregunta de forma explícita en lugar de darla por resuelta.

Cuando un servidor de alto valor muestra indicios creíbles de compromiso, una reconstrucción limpia suele ser preferible a una incertidumbre prolongada. Esa decisión implica un coste operativo significativo, y esa es la razón exacta por la que las configuraciones probadas y la recuperación de contenidos deben existir antes de que estalle una emergencia.

¿Qué deben verificar ahora los equipos de backup?

Los equipos de copias de seguridad deben verificar que pueden restaurar el contenido de SharePoint y sus componentes auxiliares en un entorno limpio sin depender de las mismas identidades y rutas de administración que un atacante pudo haber comprometido. Un trabajo marcado como completado con éxito es un dato útil, pero solo una restauración real pone a prueba la recuperación.

Conviene empezar por la cadena de recuperación. Identifica las bases de datos de SharePoint, los datos de configuración, los certificados, las cuentas de servicio, las dependencias de DNS, los ajustes del balanceador de carga y cualquier servicio externo que requiera una reconstrucción. Después, define qué componentes provienen del backup y cuáles deben recrearse desde una configuración de confianza. Si el equipo no puede explicar esa secuencia en una jornada ordinaria, un incidente real de ransomware agravará enormemente esa carencia.

La lección general sobre recuperación ante ransomware radica en la independencia ante fallos. Las copias de recuperación no deben depender enteramente de las mismas credenciales, servicios de directorio, permisos de almacenamiento o redes de gestión que producción, y un atacante con privilegios de dominio no debería poder destruir automáticamente cada punto de restauración.

Para entornos Proxmox que albergan cargas de trabajo complementarias, la guía de Proxmox Backup Server resulta útil para estructurar copias de recuperación independientes, aunque el principio rige para cualquier plataforma: mantén copias aisladas, protege el plano de gestión, verifica la integridad y ejecuta restauraciones periódicas.

¿Qué haría hoy con un servidor SharePoint expuesto?

En primer lugar, confirmaría la versión exacta de SharePoint y su nivel de parches, documentando cuándo se aplicó la corrección para CVE-2026-45659. Si el servidor estuvo orientado a internet y continuó vulnerable durante julio o agosto de 2026, lo consideraría objeto de investigación en lugar de darlo por seguro solo porque ya cuenta con el parche.

A continuación, buscaría evidencias de compromiso siguiendo las directrices de Microsoft y CISA, revisaría la telemetría de identidad y endpoints y rotaría credenciales sensibles cuando la evidencia o la ruta de exposición lo justifiquen. Al mismo tiempo, prepararía una opción de recuperación limpia para que el equipo de respuesta no se vea obligado a elegir entre confiar en un servidor dudoso o improvisar una reconstrucción bajo presión.

En un servidor parcheado puntualmente en mayo sin una exposición significativa, la respuesta puede ser comedida. Para un servidor que permaneció expuesto mientras se confirmaba la explotación activa, el nivel de exigencia debe ser mucho más alto. Una vez que una vulnerabilidad forma parte de la actividad del ransomware, el estado del parche responde solo a una pregunta, y todavía necesitas pruebas de que el sistema que conservas es realmente el sistema que crees tener.