CISA incorporó CVE-2026-65660 de Microsoft SharePoint Server a su catálogo de vulnerabilidades explotadas el 25 de septiembre de 2026. La alerta del Centro Canadiense de Ciberseguridad publicada el día anterior describe una inyección de código que exige autenticación, aunque ciertas configuraciones que permiten acceso anónimo pueden abrir una ruta previa a la autenticación. Para organizaciones en España que todavía operan SharePoint Server local, el paso urgente es localizar instalaciones y versiones, aplicar actualizaciones oficiales y revisar evidencia de abuso. Ninguna de esas fuentes identifica víctimas españolas concretas.
De aviso técnico a explotación reconocida
El 24 de septiembre, el Centro Canadiense alertó sobre la vulnerabilidad y enumeró versiones corregidas. El 25, CISA la añadió a Known Exploited Vulnerabilities. El segundo hito aporta evidencia de explotación observada, pero no describe una campaña exclusivamente española ni publica una lista de organizaciones afectadas. Un equipo que ya había programado un cambio para más adelante debe reconsiderar la prioridad ante este dato nuevo.
La clasificación de KEV es una señal de urgencia y no un diagnóstico local. Se debe verificar si el producto instalado corresponde a SharePoint Server, si la compilación cae en el rango vulnerable, si el servicio es accesible y qué registros se conservan. SharePoint Online es un servicio distinto; una empresa puede usar Microsoft 365 y a la vez mantener granjas locales antiguas para archivos, intranet o integraciones. El inventario debe distinguirlas.
Qué implica la inyección de código
La vulnerabilidad puede permitir ejecutar código bajo condiciones descritas por Microsoft. El aviso canadiense señala que requiere una identidad autenticada, y que una configuración con acceso anónimo puede permitir una cadena previa a la autenticación. Esta diferencia importa: no basta con decir «requiere credenciales» si un sitio ha habilitado rutas anónimas; tampoco puede afirmarse que todos los servidores admiten acceso sin credenciales. La revisión debe mapear configuración y exposición reales.
El riesgo potencial incluye alteración del servicio, persistencia y acceso a información según privilegios de la cuenta de servicio y de la granja. Esos son escenarios para investigar, no consecuencias automáticamente observadas en cada instalación. Un fallo de ejecución de código no demuestra por sí solo que haya ocurrido una filtración. La comprobación exige correlacionar solicitudes, procesos, cambios en archivos y actividad de identidad durante la ventana vulnerable.
Versiones corregidas y legado
El aviso canadiense enumera como versiones corregidas SharePoint Server 2016 16.0.5565.1001, SharePoint Server 2019 16.0.10417.20198 y SharePoint Server Subscription Edition 16.0.19725.20522. Confirme la compilación en cada servidor y la guía actual del fabricante antes de instalar. Una granja puede incluir nodos con actualizaciones distintas; un panel que refleja un solo nodo no verifica el conjunto.
El mismo aviso recuerda que SharePoint Server 2016 y 2019 llegaron al final de su soporte general según el calendario de Microsoft. Una actualización concreta puede reducir el riesgo de esta CVE, pero no resuelve el riesgo de operar un producto fuera de ciclo. Si una migración no puede completarse de inmediato, documente propietario, controles compensatorios, fecha y plan de retirada. Mantener una excepción indefinida es una decisión de riesgo que debe conocer la dirección.
Dónde buscar la instalación real
Revise granjas de producción y contingencia, servidores de pruebas, intranets antiguas, portales extranet, instancias mantenidas por filiales y aplicaciones que dependan de SharePoint aunque el usuario final no reconozca el nombre. Para cada una registre versión, nodos, URL, exposición a internet, acceso anónimo, método de autenticación, cuentas de servicio, datos alojados y responsable. Los balanceadores, proxies y firewalls deben formar parte del mapa.
Una empresa española con varias sedes puede tener un portal que una unidad adquirida mantiene por su cuenta. La revisión no debe limitarse al inventario del equipo central. Pregunte también a proveedores que administran contenido, infraestructura o autenticación. Exija una lista de activos concretos y fechas, no una declaración general de que «Microsoft ya lo corrigió».
Medidas inmediatas y prueba del cambio
Preserve registros y configuraciones relevantes; después confirme versiones y disponibilidad de las actualizaciones oficiales. Prepare respaldo y prueba de restauración, aplique el parche en todos los nodos y verifique la compilación que realmente recibe tráfico. Pruebe autenticación, permisos, búsqueda, documentos, flujos e integraciones críticas. Una actualización de seguridad debe cerrar el defecto sin dejar la intranet inutilizable.
Mientras se programa el cambio, limite exposición innecesaria, especialmente de sitios anónimos y accesos externos, según la arquitectura y la orientación de Microsoft. Un bloqueo temporal puede reducir superficie, pero no debe confundirse con la corrección. Registre la hora de implantación para definir la ventana retrospectiva de investigación. Si un nodo queda fuera de parche, mantenga el incidente abierto hasta corregirlo o retirarlo.
Búsqueda de actividad sospechosa
Correlacione registros de IIS, SharePoint, Windows, autenticación, proxy y protección de endpoints. Busque solicitudes anómalas, procesos hijos inesperados, nuevos archivos ejecutables o scripts, cambios de permisos y cuentas con actividad incompatible con su función. La búsqueda debe tener un rango temporal que incluya el periodo vulnerable conocido por la empresa. Un indicador aislado puede deberse a administración legítima; una secuencia de acceso, ejecución y persistencia exige investigación.
Si hay señales, capture evidencia antes de reinstalar o limpiar. Determine si el código se ejecutó, con qué privilegios y qué datos o servicios pudo alcanzar. El Análisis Forense Digital puede apoyar una cronología y una evaluación de alcance. No anuncie compromiso o exfiltración solo porque la CVE aparece en KEV; tampoco declare ausencia de impacto si no se conservaron registros suficientes.
Decisiones para organizaciones de España
La novedad tiene relevancia para instalaciones españolas, pero las fuentes no permiten afirmar una campaña local. La dirección debería pedir cuatro respuestas: qué granjas existen, cuáles tenían compilaciones vulnerables, cuándo se corrigieron y qué evidencia se examinó. Una intranet con información de empleados, clientes o contratos requiere una evaluación del impacto potencial según su contenido y accesos reales.
Si se confirma acceso a datos personales, involucre a privacidad y asesoría para evaluar obligaciones aplicables sobre hechos y plazos concretos. La mera existencia de una CVE no demuestra una brecha notificable. Para reducir incertidumbre, un Análisis de Vulnerabilidades puede localizar instancias y versiones, mientras un ejercicio de Ethical Hacking autorizado valida límites de acceso tras corregir.
Qué solicitar al operador de la granja
El informe de cierre debe identificar cada servidor, versión antes y después, hora del cambio, pruebas, exposición externa y revisión de registros. Si el proveedor no tiene acceso a una fuente de logs, debe indicarlo explícitamente. Pregunte quién administra el directorio, el proxy, la protección de endpoints y los respaldos; la investigación se fragmenta cuando cada componente tiene un operador distinto.
Defina una persona que consolide evidencias y mantenga una línea de tiempo única. El contrato debe permitir compartir los datos mínimos para investigar sin demoras. Si se decide aislar un portal, el negocio necesita saber qué procesos se detienen y dónde se atenderán solicitudes durante la contingencia.
Después de la corrección urgente
Consolide un inventario de aplicaciones heredadas, determine cuáles se migrarán y cuáles se retirarán, y establezca fechas y responsables. Revise acceso anónimo, cuentas de servicio con privilegios amplios y retención de registros. Ensaye restauración de contenidos y configuración. Una migración a otro servicio exige revisar permisos, enlaces, integraciones y tratamiento de datos; no se completa al copiar documentos.
Defina además un proceso de alerta que distinga boletín inicial de evidencia posterior de explotación. El caso demuestra cómo cambia la prioridad en un día. Quien recibe avisos de Microsoft, de CISA y del proveedor de operación debe registrar decisiones, no solo reenviar correos. La trazabilidad permitirá comprobar si la siguiente actualización llegó a todos los propietarios.
Evidencias para declarar la exposición cerrada
El expediente debe enumerar todas las granjas identificadas, su versión previa y posterior, los nodos que recibieron actualización y la fecha en que dejaron de servir código vulnerable. Incluya resultado de comprobación del sitio público y de funciones internas. Si una granja depende de una extensión que impide actualizar, registre el bloqueo y el control temporal, junto con una decisión explícita del responsable del riesgo.
La búsqueda retrospectiva necesita un intervalo definido y fuentes concretas. Por ejemplo, si los registros web cubren treinta días pero los eventos de endpoint solo siete, el informe debe reflejar ambos límites. Revise cuentas y archivos con una línea base, y destaque anomalías que requieran investigación adicional. La ausencia de alertas en una herramienta no sustituye la correlación cuando no hay cobertura de todos los nodos.
Una prueba de restauración de un sitio representativo aporta evidencia de continuidad, pero no comprueba ausencia de intrusión. Mantenga separadas las conclusiones: defecto corregido, servicio funcional, investigación realizada y plan de retirada de versiones heredadas. Dirección puede aceptar una excepción de migración con fecha y controles, siempre que conozca la exposición residual y que el progreso se revise periódicamente.
Preguntas frecuentes
¿SharePoint Online está incluido?
El aviso citado trata de SharePoint Server. Verifique si su empresa mantiene también una granja local aunque use Microsoft 365.
¿Se necesita una cuenta para explotar el fallo?
El aviso describe autenticación como condición, pero señala una posible cadena previa a ella cuando se permite acceso anónimo. Compruebe la configuración específica.
¿Actualizar demuestra que no hubo intrusión?
No. Corrige la vulnerabilidad hacia adelante; la actividad durante la ventana anterior requiere revisión de registros y cambios.
Verifique granjas y evidencias
Fuentes y límites
La explotación está reconocida a escala general. Estas fuentes no identifican organizaciones españolas afectadas; la exposición y el impacto requieren verificación local.
