La decisión de CISA de añadir CVE-2026-45659 al catálogo Known Exploited Vulnerabilities no significa que todos los clientes de Microsoft 365 deban entrar en pánico. Es una señal clara para un grupo concreto: organizaciones que todavía operan Microsoft SharePoint Server local, gestionado por ellas mismas.

Servidor local de colaboración tras un firewall con documentos, identidades y lista de parches

Microsoft corrigió el problema en las actualizaciones de mayo de 2026. CISA lo añadió a KEV el 1 de julio tras evidencia de explotación activa y fijó el 4 de julio como fecha límite para agencias federales cubiertas. Ese plazo ya pasó, pero la pregunta operativa sigue viva: ¿sabe la organización dónde están sus granjas SharePoint locales, si están en builds corregidos, si eran accesibles desde internet y si alguien las tocó antes del parche?

No es una historia de gusano anónimo pre-auth. Microsoft describe la vulnerabilidad como autenticada y de bajos privilegios. Eso reduce el ruido, no la prioridad. Las cuentas de bajo privilegio se roban mediante phishing, infostealers, contraseñas reutilizadas, contratistas y permisos heredados. Una RCE autenticada en SharePoint puede convertir un problema de identidad en un problema de servidor.

Qué ocurrió

CVE-2026-45659 es una vulnerabilidad de ejecución remota de código en Microsoft SharePoint Server causada por deserialización de datos no confiables. CVE.org la describe como CWE-502. El CVSS base de Microsoft es 8.8: vector de red, baja complejidad, bajos privilegios, sin interacción del usuario y alto impacto en confidencialidad, integridad y disponibilidad.

La lista afectada es local: SharePoint Server Subscription Edition, SharePoint Server 2019 y SharePoint Enterprise Server 2016 / SharePoint Server 2016. MSRC da builds corregidos y KBs: Subscription Edition 16.0.19725.20280 con KB5002863, SharePoint Server 2019 16.0.10417.20128 con KB5002870, y SharePoint Enterprise Server 2016 16.0.5552.1002 con KB5002868.

SharePoint Online no aparece como producto afectado en la guía de parcheo de clientes. La zona peligrosa es el punto medio: granjas híbridas o heredadas que sobreviven por workflows, archivos, sitios departamentales, cargas reguladas, web parts personalizados o migraciones incompletas.

El parche existía, pero el riesgo cambió

La cronología explica el caso. MSRC dice que el CVE fue corregido en actualizaciones de mayo, pero que se omitió por error de la lista May 2026 Security Updates; la revisión del 26 de mayo fue informativa para clientes que ya habían instalado esas actualizaciones.

Un equipo que instaló mayo puede estar cubierto. Otro pudo ver el elemento tarde, con exploitability menos probable, y moverlo a una ventana normal. La entrada en KEV cambia la prioridad porque aporta evidencia de explotación real.

No hace falta acusar a nadie. La inteligencia de vulnerabilidades cambia. La evaluación de un proveedor es una foto del momento; los atacantes prueban; los defensores observan. Un bug puede pasar de “importante” a “explotado” sin que cambie su descripción técnica.

Autenticado no significa cómodo

La palabra autenticado confunde. Para un directivo suena tranquilizadora. Para un equipo defensivo solo tranquiliza a medias. Microsoft dice que cualquier atacante autenticado puede disparar la vulnerabilidad, que no requiere privilegios de administrador y que permisos mínimos de Site Member pueden bastar.

Los permisos de SharePoint crecen con los años: proyectos, socios, departamentos, grupos heredados, cuentas de prueba, contratistas. Una cuenta robada puede leer poco; con una SharePoint farm vulnerable puede buscar ejecución de código, configuración, web shells o movimiento lateral.

Por eso la respuesta adecuada es scoping: productos afectados, builds, exposición, rutas VPN o partner, grupos Site Member amplios, incidentes recientes de identidad y anomalías en SharePoint.

Por qué SharePoint importa

SharePoint parece un portal viejo, pero suele contener documentos, approvals, workflows, aplicaciones internas, archivos y procesos de negocio. Está cerca de Active Directory, SQL Server, cuentas de servicio, integraciones Office, código personalizado y backups. No es siempre el domain controller, pero puede contener documentos que explican cómo se opera el dominio.

Las instalaciones locales son difíciles de parchear porque están personalizadas. Custom web parts, workflows frágiles y ventanas de mantenimiento reales explican la lentitud. Pero la explotación activa no espera a que el calendario sea cómodo.

BleepingComputer citó datos de Shadowserver con más de 10.000 servidores SharePoint expuestos a internet. No significa 10.000 vulnerables ni comprometidos; es una señal de exposición y explica por qué los atacantes siguen mirando esta superficie.

KEV convierte el ticket en revisión de incidente

Un ticket normal pregunta si el update está instalado. Una vulnerabilidad explotada añade preguntas: ¿el sistema era accesible antes del parche?, ¿hubo intentos?, ¿hay que revisar forense antes de cerrar?

CISA menciona forensics triage y evaluación de exposición. Instalar el parche es necesario, pero puede no bastar si el servidor estuvo expuesto sin corregir. Un enfoque equilibrado separa casos: una granja interna ya parcheada y sin logs raros necesita verificación; una granja expuesta y vulnerable necesita parche o aislamiento más revisión; una con actividad sospechosa requiere incident response.

Qué comprobar

Empiece por inventario: granjas SharePoint, sistemas de migración, DR, test, portales de socios, servidores departamentales y reverse proxies. Compare edición y build con MSRC.

Reduzca exposición: si no puede parchear de inmediato, restrinja acceso público, use rutas de red confiables, cierre entradas innecesarias y no confíe ciegamente en WAF o proxy. Si el servicio no se necesita, apáguelo hasta actualizar.

Revise logs IIS y SharePoint antes del parche: solicitudes autenticadas inusuales, uploads o scripts inesperados, cuentas nuevas, cambios de site collections, comportamiento extraño del worker process, PowerShell, scheduled tasks y conexiones salientes raras. Revise también identidad: cuentas sospechosas, grupos Site Member amplios, contratistas antiguos y service accounts con acceso interactivo.

Qué no hacer

No trate SharePoint Online como si necesitara este parche local: no aparece en la lista afectada. No use “autenticado” como excusa para esperar si la granja está expuesta. No ejecute PoCs aleatorios ni cite repositorios GitHub de baja señal como prueba. CISA confirma explotación; no hace falta amplificar material dudoso. Tampoco atribuya ransomware: CISA marca ese uso como desconocido para este CVE.

Cinco preguntas útiles

¿Existe inventario completo de SharePoint Server? ¿Todos los sistemas afectados están en builds corregidos o con las actualizaciones de mayo? ¿Alguno estuvo expuesto a internet o a acceso remoto amplio? ¿Se revisaron logs y cambios de cuentas en la ventana de exposición? ¿Se sabe qué usuarios de bajo privilegio pueden autenticarse?

CVE-2026-45659 es seria porque une colaboración heredada, identidad y parches lentos. No significa que todo SharePoint esté perdido. Significa que los viejos servidores de colaboración no pueden ser invisibles.

Cómo priorizar sin histeria

La prioridad no se decide solo por CVSS. Un servidor SharePoint interno, ya actualizado y accesible solo desde redes controladas, no tiene la misma urgencia que una granja expuesta a internet con usuarios externos y permisos acumulados durante años. Pero KEV cambia la conversación: cuando CISA dice que hay explotación activa, el equipo debe confirmar el estado, no asumirlo.

El orden práctico es exposición, versión, identidad y señales. Exposición: quién puede llegar al servidor. Versión: si el build está corregido. Identidad: qué cuentas de bajo privilegio pueden autenticarse. Señales: si los logs muestran actividad inusual antes del parche. Ese orden evita tanto el pánico como la complacencia.

Para MSP y equipos pequeños, el riesgo más común es el inventario incompleto. Un cliente puede decir que “ya migró a la nube”, pero conservar una granja vieja para archivos, flujos o un departamento que nunca terminó la transición. En esos casos, la pregunta no es si la nube está segura, sino si el servidor olvidado sigue aceptando logins.

La lección más amplia

CVE-2026-45659 resume una realidad de 2026: la gestión de vulnerabilidades ya no es una hoja ordenada por puntuación. Las decisiones reales combinan evidencia de explotación, alcance del activo, exposición, importancia de negocio y probabilidad de credenciales robadas. SharePoint concentra todos esos factores porque es viejo, útil, conectado a identidad y a menudo personalizado.

Un buen cierre del incidente no es solo “KB instalado”. Es un registro de inventario actualizado, builds verificados, exposición reducida, logs revisados, cuentas sospechosas tratadas y permisos demasiado amplios recortados. Esa documentación será útil la próxima vez que una vulnerabilidad cambie de estado semanas después de su parche.

La conclusión tranquila es esta: si no ejecuta SharePoint Server local, no convierta la noticia en ansiedad inútil. Si lo ejecuta, no lo trate como un portal aburrido. Trátelo como infraestructura crítica que merece el mismo rigor que un servidor de identidad, una VPN o una plataforma de documentos sensibles.