CISA mete una nueva SharePoint en la lista KEV y el mensaje real no va solo de parches

Otra entrada más en el catálogo KEV de CISA. Un titular de los que muchos equipos ven, archivan mentalmente bajo “ya lo revisaremos” y siguen con su día. Mala idea.

El 1 de julio de 2026, CISA añadió CVE-2026-45659, una vulnerabilidad de deserialización de datos no confiables en Microsoft SharePoint Server, a su Known Exploited Vulnerabilities Catalog tras constatar evidencia de explotación activa. Traducido a lenguaje menos burocrático: no estamos ante un fallo teórico, ni ante un PoC de laboratorio, ni ante una CVE que vive de su propio marketing. Hay atacantes usándola.

La agencia lo enmarca además en BOD 26-04, la directiva operativa vinculante para agencias federales civiles de EE. UU. que prioriza la remediación de vulnerabilidades en función del riesgo real y no del vicio corporativo de perseguir números de escáner. Esa es la parte interesante. La entrada de una sola CVE importa menos que el patrón: cuando CISA mete algo en KEV, está diciendo qué merece interrupción inmediata del calendario.

Si tu organización usa SharePoint Server on-premises, sobre todo si lo expone a Internet o lo mantiene accesible desde perímetros mal segmentados, la pregunta no es si vas a parchear. La pregunta es si vas tarde, si tu telemetría permite saber si te comprometieron antes del parche y si tu proceso de gestión de vulnerabilidades sigue atado a SLAs genéricos que no distinguen entre “alto CVSS” y “explotado en la calle”. Ahí está el quid.

Lo que ha anunciado CISA, sin adornos

La comunicación de CISA del 1 de julio de 2026 es breve, pero contiene tres hechos concretos que sí mueven la aguja.

Primero, añade CVE-2026-45659 al catálogo KEV. La descripción publicada identifica el producto afectado como Microsoft SharePoint Server y el tipo de fallo como deserialization of untrusted data. Esa categoría importa porque la deserialización insegura no suele quedarse en un comportamiento extraño o en una denegación de servicio menor; con frecuencia abre la puerta a ejecución de código o a toma de control del sistema dependiendo del contexto de explotación.

Segundo, CISA afirma que la inclusión se basa en evidencia de explotación activa. No ha publicado, al menos en esa alerta, detalles técnicos, TTPs del actor o indicadores de compromiso. Pero para entrar en KEV no basta con que el fallo sea feo sobre el papel. CISA exige, como mínimo, un CVE asignado, evidencia de explotación y mitigación clara. Lo recuerda incluso al invitar a enviar candidaturas al catálogo a través de su formulario de nominación.

Tercero, vincula la entrada con Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk. Esa referencia tampoco es de trámite. BOD 26-04 obliga a las agencias FCEB a priorizar la remediación rápida de vulnerabilidades de alto riesgo, específicamente las CVE listadas en KEV en activos expuestos públicamente que, tras la explotación, otorgan control total del activo. También fija una expectativa operativa básica que demasiadas empresas siguen sin cumplir con seriedad: comprobar si el sistema fue comprometido antes de aplicar el parche.

Ese último punto merece repetirse porque suele perderse entre tickets: parchear no equivale a limpiar. A veces equivale solo a cerrar la puerta después de que el intruso ya haya dejado una copia de la llave en el felpudo.

Por qué SharePoint vuelve a ser un problema serio

SharePoint no es solo un servidor más en el inventario. En muchas organizaciones es un concentrador de documentos, flujos internos, bibliotecas de conocimiento, integraciones con Active Directory, formularios, automatizaciones heredadas y, en demasiados casos, permisos inflados por años de “déjalo así que funciona”. Cuando una vulnerabilidad explotada afecta a SharePoint Server, el riesgo no se limita al propio host. Se extiende al contenido, a las cuentas de servicio, a los tokens, a la confianza que el resto del entorno deposita en esa plataforma y a menudo a la capacidad de pivotar lateralmente.

La deserialización insegura tiene además un historial regulatorio y defensivo particularmente ingrato. No porque sea una técnica nueva; más bien al contrario. Lleva años figurando entre los vectores clásicos para ejecutar payloads en aplicaciones empresariales complejas, especialmente en entornos Java y.NET con componentes heredados, bibliotecas de terceros o lógica de negocio difícil de desmontar. Que siga apareciendo en sistemas críticos en 2026 dice dos cosas: la deuda técnica no ha desaparecido y muchas organizaciones siguen confiando demasiado en el perímetro.

En el caso de SharePoint, hay un factor añadido: el producto sigue muy presente en despliegues on-premises por motivos de soberanía del dato, personalizaciones históricas, integraciones complejas o simple inercia corporativa. Y la inercia, como mecanismo de seguridad, no ha dado grandes resultados.

¿Significa esto que toda instancia de SharePoint Server está comprometida? No. ¿Significa que toda organización con SharePoint debe tratar esta CVE como una prioridad de máximos hasta descartar exposición y compromiso? Sí. Sin matices.

La verdadera noticia es BOD 26-04: menos culto al CVSS, más riesgo real

Lo más útil de esta alerta no es la línea sobre SharePoint, sino el marco que la rodea. BOD 26-04 marca una evolución práctica en la gestión de vulnerabilidades: pasar de un modelo obsesionado con listas infinitas de “critical/high/medium” a otro donde manda la combinación de exposición pública, evidencia de explotación y impacto real post-explotación.

Durante años, demasiados programas de vulnerabilidad han funcionado como una cadena de montaje burocrática. El escáner produce miles de hallazgos, el equipo clasifica por CVSS, el negocio pide excepciones, el parche se retrasa porque la ventana de cambio cae mal y todos fingen que el cuadro de mando representa seguridad. Luego aparece una KEV y desmonta la ficción en cinco minutos.

CISA lo está diciendo de forma cada vez menos sutil: no todas las vulnerabilidades merecen la misma urgencia, y algunas exigen respuesta inmediata precisamente porque ya están siendo explotadas. BOD 26-04, según resume la propia agencia, pide a las agencias federales:

• Priorizar la remediación rápida de CVEs listadas en KEV.
• Concentrarse en activos públicamente expuestos.
• Dar máxima prioridad a vulnerabilidades cuya explotación conceda control total del activo.
• Diferir la acción sobre vulnerabilidades de menor riesgo cuando esa priorización mejore el uso de recursos.
• Verificar si hubo compromiso previo al parche.

Esto tiene una consecuencia incómoda para muchas organizaciones privadas: si tu proceso sigue tratando una KEV explotada en Internet igual que un hallazgo interno con CVSS 8.1 sin exploit conocido, tu priorización está rota. Y no hace falta ser agencia federal para admitirlo.

Desde la óptica de gobierno corporativo, el cambio también importa. Un comité de riesgos entiende mejor “tenemos una vulnerabilidad explotada activamente en un servidor expuesto que puede dar control total del activo” que “hay 417 findings high pendientes”. Lo segundo suena a rutina. Lo primero suena a incidente en preparación, que es lo que probablemente es.

Qué implica realmente “evidencia de explotación activa”

Las alertas breves de CISA tienen una virtud y un defecto. La virtud: no pierden el tiempo. El defecto: no siempre detallan el contexto operativo que un CISO querría tener en el minuto uno. Cuando la agencia habla de “evidence of active exploitation”, conviene leer esa frase con disciplina.

No significa necesariamente que el exploit sea masivo o trivial para cualquier actor. Tampoco garantiza que exista ya explotación indiscriminada a gran escala. Pero sí significa algo suficiente para cambiar la prioridad: hay base fáctica para asumir que actores maliciosos ya están obteniendo acceso o ejecución mediante esa debilidad. Eso derriba tres excusas muy comunes.

La primera: “esperaremos al ciclo normal de parcheo”. No, si el activo es crítico o está expuesto.

La segunda: “nuestro WAF/EDR ya nos cubre”. Tal vez ayude. No sustituye a la remediación ni a la investigación post-explotación.

La tercera: “parcheamos y cerramos el ticket”. Eso solo tiene sentido si has verificado que no hubo explotación previa, persistencia, web shells, creación de cuentas, abuso de procesos de aplicación o movimientos laterales asociados.

En vulnerabilidades de aplicaciones servidoras, y SharePoint encaja de lleno aquí, el tiempo entre divulgación, weaponization y abuso oportunista suele comprimirse. A veces mucho. Los actores no necesitan una campaña sofisticada si encuentran un servicio expuesto, predecible y con credenciales o privilegios útiles alrededor.

La ironía habitual es esta: las organizaciones más maduras técnicamente suelen ser las que menos discuten la urgencia. Ya han aprendido que una KEV es una señal de respuesta. Quienes más debaten son a menudo quienes menos capacidad tienen para contener un compromiso una vez producido.

Parchear no basta: lo que tu equipo debe comprobar antes y después

La referencia de CISA a verificar compromiso previo al parche es probablemente la parte más infravalorada del aviso. Tiene lógica técnica y, en 2026, también lógica de auditoría y de reporte.

Si un atacante explotó CVE-2026-45659 antes de que aplicases la corrección, el parche puede dejar intactos artefactos de persistencia, cambios de configuración, cuentas creadas, tareas programadas, servicios anómalos o incluso acceso indirecto vía otros sistemas comprometidos durante el pivot. El parche elimina el vector; no borra la intrusión.

Para un entorno con SharePoint Server, la respuesta seria no empieza y termina en WSUS, SCCM, Intune o el método que uses para desplegar actualizaciones. Exige al menos cinco líneas de comprobación:

1. Confirmar exposición y alcance real

No basta con saber que “tenemos SharePoint”. Hay que identificar versiones, instancias, si son accesibles desde Internet, si están publicadas a través de reverse proxy, qué granjas están afectadas y qué cuentas de servicio usan. Aquí muchas CMDB se revelan como lo que son: literatura fantástica.

2. Revisar logs de acceso y aplicación en la ventana previa al parche

Busca patrones anómalos en IIS, en logs de SharePoint y en el sistema operativo anfitrión. Sin IoCs públicos detallados, la caza debe orientarse a comportamientos: requests inusuales, errores repetidos, serializaciones inesperadas, cargas anómalas, procesos hijos no habituales, invocaciones sospechosas de PowerShell, uso anómalo de w3wp.exe o del proceso de la aplicación como lanzadera de comandos.

3. Validar integridad y persistencia

Comprueba web roots, binarios, assemblies, tareas programadas, servicios, claves de registro relevantes, cambios en GPO locales y archivos recientemente modificados. Los atacantes no siempre dejan una web shell cutre con nombre de chiste. A veces dejan algo bastante más discreto.

4. Revisar identidad y privilegios

Audita las cuentas de servicio asociadas, cambios de pertenencia a grupos privilegiados, creación de cuentas locales o de dominio, concesión de permisos en buzones, accesos a repositorios documentales y uso anómalo de credenciales. En entornos Windows empresariales, el verdadero daño rara vez se limita al servidor inicial.

5. Decidir si basta con erradicar o si hay que reconstruir

Si encuentras evidencia razonable de ejecución remota con privilegios altos, la opción prudente puede ser reconstruir el servidor o la granja desde base confiable en lugar de “limpiar” sobre la marcha. Aquí no hay glamour. Hay disciplina forense y tolerancia al riesgo.

Todo esto tiene además una derivada legal y contractual. Si durante esa revisión detectas exfiltración o acceso no autorizado a datos personales, entran en juego obligaciones de notificación como GDPR art. 33 para notificar violaciones de seguridad a la autoridad de control sin dilación indebida y, de ser posible, en un plazo máximo de 72 horas desde que el responsable tenga constancia. Si el riesgo para los interesados es alto, GDPR art. 34 puede exigir comunicación a los afectados. El parche, de nuevo, no cierra ese frente.

Lo que esta alerta le dice a cualquier programa de vulnerabilidades maduro

Una CVE en KEV debería activar algo más que un ticket de infraestructura. Debería poner a prueba si tu programa de gestión de vulnerabilidades está diseñado para el mundo real o para quedar bien en comité.

Un programa maduro en 2026 distingue, como mínimo, entre cuatro cosas que demasiadas veces se mezclan:

• Severidad técnica: CVSS y características del fallo.
• Explotabilidad práctica: si hay exploit conocido, acceso requerido, complejidad real.
• Exposición del activo: Internet-facing, VPN, red interna segmentada, entorno aislado.
• Impacto de negocio: datos accesibles, privilegios, dependencia operativa, capacidad de pivot.

KEV no reemplaza ese análisis, pero le da una señal extraordinariamente valiosa: esta vulnerabilidad ya ha superado el umbral del interés teórico. Y eso debería reflejarse en SLA, ventanas de cambio y escalado ejecutivo.

Si todavía gestionas remediación con una política tipo “critical en 15 días, high en 30, medium en 90” aplicada de forma plana, tienes un problema de diseño. No porque esos plazos no sirvan nunca, sino porque ignoran el atributo que más importa cuando un ataque es posible hoy: la explotación observada.

El modelo más útil combina un feed de KEV con inventario de exposición, criticidad del activo y controles compensatorios verificables. Verificables, insisto. Decir “tenemos segmentación” sin demostrar que el servidor no puede moverse lateralmente hacia sistemas sensibles es una tradición corporativa muy arraigada y muy poco tranquilizadora.

La lectura europea: KEV no es norma de la UE, pero ignorarlo sería bastante torpe

Conviene no mezclar jurisdicciones. BOD 26-04 se aplica a agencias federales civiles de EE. UU., no a bancos españoles, aseguradoras francesas o proveedores cloud europeos. Pero quedarse en ese formalismo sería perder el punto.

En Europa, varios marcos regulatorios y de supervisión empujan exactamente hacia la misma lógica operativa, aunque no mencionen KEV por nombre.

NIS2, en art. 21, exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar riesgos de seguridad de las redes y sistemas de información. Entre ellas están la gestión de incidentes, la continuidad, la seguridad de la cadena de suministro, las políticas de análisis de riesgos y, de forma práctica, la capacidad de tratar vulnerabilidades con criterio. No dice “consulta KEV cada mañana”, pero si una organización ignora una CVE explotada activamente en un activo expuesto, le costará argumentar que su gestión del riesgo era proporcionada.

DORA va por la misma autopista. El art. 8 obliga a las entidades financieras a contar con un marco sólido, integral y bien documentado de gestión del riesgo de las TIC. El art. 10 entra en detección y el art. 11 en respuesta y recuperación. Además, la lógica de identificación continua de fuentes de riesgo, protección de activos TIC y gestión de vulnerabilidades no permite un enfoque meramente decorativo. Si un tercero crítico, una plataforma colaborativa o un sistema documental vinculado a procesos esenciales queda expuesto por un fallo conocido y explotado, el supervisor no va a entusiasmarse con la defensa de “estaba en cola de parcheo”.

En paralelo, GDPR sigue pesando cuando los datos personales alojados o accesibles desde SharePoint entran en la ecuación. Y en sectores fuertemente regulados, desde salud a servicios financieros, la combinación de seguridad, disponibilidad, trazabilidad y deber de diligencia convierte una KEV en una cuestión de gobernanza, no solo de hardening.

Dicho de otro modo: KEV no te obliga por sí sola en Europa, pero ignorar una KEV puede dejarte mal ante casi cualquier auditor, supervisor o investigador forense serio.

Qué deberían hacer ahora CISOs, equipos de infraestructura y compliance

La respuesta útil a esta alerta depende de si usas SharePoint Server y de cómo lo usas. Pero hay una secuencia clara de decisiones que no conviene diluir en burocracia.

Lo primero es inventariar con precisión. No mañana. Hoy. Necesitas saber si tienes SharePoint Server afectado, qué versiones, dónde está desplegado, si está accesible externamente y qué dependencia de negocio arrastra. Si tu inventario no permite responder esto en horas, no tienes un problema de SharePoint; tienes un problema de visibilidad.

Lo segundo es aplicar la mitigación o parche disponible con prioridad máxima en activos expuestos o críticos. CISA ha recordado que KEV requiere remediación rápida. Las organizaciones privadas harían bien en copiar esa disciplina, no por obediencia transatlántica sino por puro interés propio.

Lo tercero es investigar indicios de explotación previa. Aquí compliance debería prestar atención, porque la decisión de abrir o no una investigación más profunda tiene impacto en posible notificación regulatoria, retención de evidencias, contratación de forense externo, comunicación a clientes y activación de pólizas de ciberseguro.

Lo cuarto es revisar si tu política de gestión de vulnerabilidades incorpora fuentes de inteligencia accionable. Si KEV, EPSS, advisories de fabricante y exposición real no influyen de forma estructurada en la priorización, tu proceso necesita cirugía, no maquillaje.

Lo quinto es llevar el asunto al nivel de riesgo correcto. Un servidor de colaboración comprometido puede convertirse en puerta de entrada a documentos sensibles, credenciales, movimientos laterales y alteración de contenidos. Eso no es un tema “solo de sistemas”.

Para equipos de compliance y auditoría interna, hay tres preguntas especialmente buenas:

• ¿Existe un criterio documentado para elevar KEV a prioridad superior frente a otras vulnerabilidades de igual o mayor CVSS?
• ¿Se exige evidencia de revisión post-parche para descartar compromiso previo?
• ¿Puede la organización demostrar tiempos reales de identificación, decisión, remediación y validación?

Si la respuesta a alguna es no, esta alerta vale como test de madurez bastante más honesto que muchos ejercicios de control semestral.

Una vulnerabilidad en SharePoint puede acabar siendo un incidente de identidad

Hay un error de modelado que se repite demasiado: pensar en SharePoint como repositorio documental y no como pieza del plano de identidad y confianza corporativa. En la práctica, SharePoint Server suele convivir con Active Directory, cuentas de servicio privilegiadas, integraciones con Exchange, autenticación federada o conectores hacia otros sistemas. Eso multiplica el valor del objetivo para un atacante.

Si la explotación permite ejecución en el servidor, el siguiente movimiento no suele ser “leer un PDF y marcharse”. Lo habitual es explorar credenciales, configurar persistencia, acceder a secretos, extraer información de configuración, inspeccionar tokens y buscar relaciones de confianza aprovechables. En entornos donde los permisos se han acumulado durante años, un servicio de colaboración comprometido puede transformarse muy rápido en un problema de identidad empresarial.

Por eso la investigación posterior debe incluir, cuando el contexto lo justifique, revisión de autenticaciones anómalas, uso inusual de cuentas de servicio, conexiones LDAP o Kerberos fuera de patrón y accesos a recursos que SharePoint normalmente no debería tocar. El compromiso de la aplicación es solo el acto uno.

La lección incómoda para Microsoft shops: el on-prem heredado sigue cobrando peaje

No hace falta convertir cada CVE en un manifiesto “todo a la nube”, pero tampoco conviene fingir que el riesgo operativo es igual en todas las arquitecturas. Las instalaciones on-premises de plataformas empresariales complejas suelen arrastrar personalizaciones antiguas, dependencias poco documentadas, ciclos de parcheo lentos y ventanas de cambio dictadas por negocio, no por la amenaza. Cada nuevo fallo explotado hace visible ese peaje.

Eso no significa que migrar resuelva mágicamente el problema. Los servicios SaaS también tienen incidentes y la compartición de responsabilidades sigue siendo eso: compartida, no abolida. Pero sí obliga a una conversación incómoda y útil: si mantienes SharePoint Server on-prem en 2026, puedes justificar operativamente el coste de parchearlo, monitorizarlo y responder con rapidez cuando aparece una KEV?

Si la respuesta es “más o menos”, ya tienes una respuesta de negocio. Y no es buena.

Qué no dice CISA, pero conviene asumir hasta tener más detalles

La alerta de 1 de julio no publica indicadores de compromiso, alcance de campaña ni perfiles de actor. Eso deja un espacio que muchas organizaciones llenan con optimismo. Error clásico.

Hasta que haya más detalle de fabricante, comunidad defensiva o investigadores, conviene asumir cuatro posibilidades operativas:

• Que existan intentos de explotación oportunistas dirigidos a instancias accesibles en Internet.
• Que la explotación pueda automatizarse con rapidez si no lo está ya.
• Que haya actividad de post-explotación orientada a persistencia y robo de credenciales.
• Que la telemetría nativa del entorno no sea suficiente si no estaba bien configurada antes.

Ese último punto es especialmente ingrato. Muchas investigaciones fallan no porque el atacante sea brillante, sino porque los logs adecuados no se retenían, no estaban centralizados o no permitían suficiente granularidad temporal. El día que necesitas reconstruir la cadena de hechos, descubres que el servidor hablaba, pero nadie escuchaba.

La pregunta de fondo: tu organización gestiona vulnerabilidades o gestiona listas

Esta es la cuestión que deja la entrada de CVE-2026-45659 en KEV. No si conoces el catálogo. No si tienes un escáner de primer nivel. No si produces dashboards impecables. La pregunta es si tu organización sabe distinguir entre inventario de debilidades y riesgo explotable con impacto inminente.

La diferencia parece semántica hasta que un servidor expuesto cae. Entonces deja de serlo.

Un enfoque basado en riesgo de verdad hace tres cosas muy concretas. Identifica activos expuestos con precisión. Cruza vulnerabilidades con inteligencia de explotación real. Y obliga a verificar compromiso previo cuando la amenaza lo justifica. Justo lo que CISA ha vuelto a subrayar con esta alerta y con BOD 26-04.

No hay mucha épica en esto. Hay menos de la que venderán algunos proveedores esta semana. Pero sí hay una lección práctica muy seria: una KEV no es una noticia de consumo interno; es una señal de prioridad ejecutiva. Y una vulnerabilidad de deserialización en SharePoint, con explotación activa, no merece cola. Merece atención inmediata, validación técnica y una conversación honesta sobre si tus procesos están preparados para distinguir lo urgente de lo simplemente pendiente.

Si usas SharePoint Server y todavía estás debatiendo si esto entra en la próxima ventana de cambio, la respuesta probablemente ya la ha dado CISA por ti.