La vulnerabilidad bajo ataque activo

Esto no es un aviso teórico; la falla se está explotando ahora mismo. El 17 de julio de 2026 la Agencia de Ciberseguridad e Infraestructura de EE. UU. añadió CVE-2026-58644, una vulnerabilidad crítica de Microsoft SharePoint Server, a su catálogo de vulnerabilidades explotadas conocidas y ordenó a las agencias civiles federales parchearla antes del 19 de julio. El fallo es una deserialización de datos no confiables con una gravedad de 9,8 sobre 10, que permite a un atacante sin credenciales ejecutar código arbitrario en el servidor.

No está solo. Un grupo de fallas de SharePoint Server se está encadenando en la naturaleza para eludir la autenticación, lograr ejecución remota de código y realizar actividad posterior. SharePoint autoalojado tiene aquí un largo historial: desde finales de 2021 los reguladores han señalado cerca de una docena de sus vulnerabilidades como explotadas en ataques, y la mayoría se usaron luego en ransomware.

Por qué un parche solo no le salvará

Lo peligroso es lo que los atacantes se llevan al entrar. Durante la explotación roban las claves criptográficas de máquina del servidor, los secretos que SharePoint usa para firmar y validar los tokens que conceden acceso. Una vez que un atacante tiene esas claves, puede falsificar credenciales válidas a voluntad, y puede hacerlo contra un servidor que usted ya ha actualizado.

Esa es la trampa de este incidente. Aplicar el parche de Microsoft cierra el agujero por el que entró el intruso, pero no hace nada con las claves que ya copió. Un SharePoint Server parcheado y totalmente actualizado aún puede ser accedido de nuevo con claves robadas, por eso aquí la remediación no termina con parchear. Si no rota las claves de máquina, puede creerse seguro mientras la puerta sigue silenciosamente abierta.

Quién está realmente expuesto

Esto es un problema local, no de la nube. La vulnerabilidad afecta a SharePoint Server autoalojado, la versión que una organización ejecuta en su propia infraestructura. SharePoint Online de Microsoft 365, el servicio alojado, no es el objetivo de estas explotaciones concretas. Así que el riesgo se concentra justo en las instalaciones que muchas empresas medianas, organismos públicos, despachos de abogados y entidades financieras europeas mantienen en casa.

A menudo lo mantienen en casa por buenas razones: residencia de datos, normas sectoriales o la decisión de guardar documentos sensibles en infraestructura que controlan. Esa elección es legítima, pero también significa que el parcheo, la rotación de claves y la monitorización son enteramente su responsabilidad. La comodidad que un proveedor de nube habría gestionado en silencio es, en local, una tarea con su nombre y un reloj en marcha.

Qué significa bajo las normas de la UE

El plazo de EE. UU. no le obliga, pero la urgencia sí. El 19 de julio se aplica a las agencias federales estadounidenses; un operador europeo no tiene obligación legal hacia él. Trátelo en cambio como una señal pública de lo rápido que avanza esto, porque los mismos servidores y el mismo código de explotación no se detienen en una frontera. Autoridades nacionales como el BSI alemán y el NCSC británico emiten sus propios avisos sobre exactamente este tipo de falla activamente explotada.

Bajo NIS2 y, para entidades financieras, DORA, una intrusión exitosa aquí es un incidente notificable con plazos estrechos y responsabilidad a nivel de consejo. Un almacén de documentos lleno de contratos, datos personales y registros internos es justo el activo que estas normas existen para proteger. Ser lento en parchear una vulnerabilidad conocida y explotada es la clase de fallo que un regulador lee como negligencia, no como mala suerte.

Qué hacer ahora

Actúe por orden y asuma lo peor donde no pueda probar lo contrario. Aplique de inmediato las actualizaciones de SharePoint Server de Microsoft, luego rote las claves de máquina de IIS para que las claves robadas queden inútiles. Busque señales de compromiso: web shells inesperados, archivos desconocidos en los directorios del servidor, claves nuevas o alteradas y eventos de autenticación que no coincidan con sus usuarios. Reduzca la superficie de ataque retirando de la red abierta cualquier SharePoint expuesto a internet donde pueda.

Si su servidor estuvo accesible y sin parchear en algún momento desde la divulgación, trátelo como comprometido e investigue sobre esa base en lugar de confiar en que pasó desapercibido. El coste de suponer un compromiso que no tuvo son unas horas de revisión; el coste de suponer una seguridad que no tuvo es el propio incidente.