El RCE de SharePoint entra en la lista de parcheo urgente de CISA: el boletín llegó semanas después del parche

Microsoft publicó el parche de CVE-2026-45659 en la actualización acumulativa de mayo, pero no publicó el boletín de seguridad hasta el 21 de mayo: semanas después de que el parche ya estuviera disponible. CISA ha confirmado desde entonces explotación activa y lo ha añadido a su catálogo de vulnerabilidades explotadas conocidas (KEV), dando a las agencias federales hasta el 4 de julio para parchear.

La vulnerabilidad tiene una puntuación CVSS de 8.8 y permite ejecución remota de código mediante deserialización insegura de datos no confiables: el tipo de fallo que, en un servidor SharePoint expuesto a internet, puede pasar de "hallazgo interesante" a "compromiso completo" en una sola petición.

La cronología, reconstruida

Puesta en orden, la secuencia queda así:

• Principios de mayo de 2026: Microsoft publica el parche en silencio, incluido dentro de la actualización acumulativa mensual habitual de SharePoint Server.
• 21 de mayo: se publica el boletín de seguridad de CVE-2026-45659, semanas después de que el parche ya estuviera disponible para descargar.
• Finales de junio: CISA confirma explotación activa y añade el fallo a su catálogo de vulnerabilidades explotadas conocidas (KEV).
• 4 de julio: fecha límite de remediación para las agencias civiles federales de EE. UU.

Merece la pena traducir qué significa entrar en el catálogo KEV para quien está fuera de la órbita federal estadounidense. Bajo la directiva BOD 22-01, las agencias civiles están legalmente obligadas a remediar cada entrada del catálogo antes de la fecha indicada, pero la influencia real del KEV es mucho más amplia: se ha convertido en la lista de referencia del sector de vulnerabilidades que se están usando contra objetivos reales ahora mismo, y muchos programas de parcheo privados priorizan según ella aunque nada les obligue.

La clase de fallo también importa. La deserialización insegura significa que el servidor toma datos suministrados por el atacante y los reconstruye en objetos vivos sin validarlos correctamente – lo que en la práctica suele entregar ejecución de código con los privilegios del propio servicio. Es una clase de bug con un largo historial en SharePoint y otras aplicaciones .NET, y una que los desarrolladores de exploits saben convertir en arma muy rápido en cuanto un parche les enseña dónde mirar.

Por qué importa el retraso en la divulgación

El desfase entre "parche disponible" y "boletín publicado" es la parte que merece atención. La mayoría de los programas de gestión de parches se organizan en torno a los boletines del fabricante como disparador de priorización – si el boletín todavía no ha salido, la actualización acumulativa que lo incluye suele tratarse como mantenimiento rutinario, no urgente. Ese es exactamente el hueco que aprovechan los atacantes que hacen ingeniería inversa de los parches.

¿Te afecta?

• Ejecutas SharePoint Server on-premise (no afecta a SharePoint Online / Microsoft 365).
• Aplicaste las actualizaciones del Patch Tuesday con tu cadencia habitual, sin confirmar específicamente que llegó la acumulativa de mayo.
• Expones SharePoint, directamente o a través de un proxy inverso, a usuarios fuera de una red estrictamente controlada.

Qué hacer ahora

No des por hecho que tu cadencia habitual de parcheo ya cubre este caso. Confirma explícitamente que tu granja de SharePoint Server está en la actualización acumulativa de mayo, no solo "actualizada" según tu panel de parches. Si no puedes confirmar el estado del parcheo con rapidez, trata cualquier SharePoint expuesto a internet como comprometido y valora restringir el acceso a nivel de red hasta que puedas.

Preguntas frecuentes