SharePoint vuelve a arder: CERT-EU alerta de fallos críticos ya explotados y el problema ya no es solo parchear

Si tienes un SharePoint on-premise expuesto a internet, la pregunta útil ya no es si debes parchear. Eso era el 14 de julio. La pregunta de agosto de 2026 es bastante menos cómoda: ¿te han entrado ya?

CERT-EU lo ha dicho sin rodeos en su aviso 2026-009, publicado el 22 de julio y actualizado el 23 de julio de 2026: hay vulnerabilidades críticas en Microsoft SharePoint Server, una de ellas ya explotada activamente, y el patrón no apunta a un fallo aislado, sino a una serie de debilidades graves que han ido apareciendo entre abril y julio. El aviso pone nombre y apellidos al problema: CVE-2026-50522, con CVSS 9.8, y otras cuatro CVE recientes que afectan a instancias on-premise.

La parte incómoda no está en la puntuación CVSS. Está en la secuencia. Microsoft publicó actualizaciones el 14 de julio de 2026. El 20 de julio, WatchTowr identificó código de prueba de concepto y observó explotación activa de CVE-2026-50522. En otras palabras: la ventana entre el parche y la explotación pública fue ridícula. Exactamente el tipo de margen que deja fuera a cualquier organización que siga gestionando SharePoint como si fuera un servidor interno sin prioridad de crisis.

Y aquí aparece la ironía regulatoria habitual: durante años muchas empresas trataron SharePoint como una herramienta de colaboración algo aburrida, casi doméstica, no como un activo de alto riesgo. Ahora resulta que ese servidor aburrido puede dar ejecución remota de código, elevación de privilegios y movimiento lateral si está donde no debe estar. La tecnología legacy siempre pide la factura con intereses.

Lo que CERT-EU ha confirmado, sin adornos

El aviso de CERT-EU identifica cinco vulnerabilidades relevantes en Microsoft SharePoint Server on-premise. No todas tienen el mismo perfil técnico, pero juntas dibujan un cuadro bastante feo:

• CVE-2026-50522: vulnerabilidad crítica de deserialización que permite remote code execution. CVSS 9.8. Microsoft indica que la explotación requeriría algún nivel de autenticación, pero CERT-EU recoge hallazgos recientes que cuestionan ese supuesto.
• CVE-2026-32201: fallo de validación de entrada que permite spoofing por un usuario no autorizado. CVSS 6.5. Corregido en abril de 2026.
• CVE-2026-45659: deserialización de datos no confiables con RCE remota autenticada. CVSS 8.8. Corregido en mayo de 2026.
• CVE-2026-56164: ausencia de autenticación para una función crítica que permite elevación de privilegios sin autenticación. CVSS 9.8. Corregido en julio de 2026.
• CVE-2026-58644: otra vulnerabilidad de deserialización con RCE sin autenticación. CVSS 9.8. Corregido en julio de 2026.

Los productos afectados citados expresamente para CVE-2026-50522 son SharePoint Server Subscription Edition, SharePoint Server 2019 y SharePoint Enterprise Server 2016. CERT-EU remite a los avisos de Microsoft para el detalle completo del resto de productos y versiones impactadas por las otras CVE.

Eso ya sería bastante grave por sí solo. Pero el dato que cambia el tono de la conversación es otro: CERT-EU recomienda no solo parchear de inmediato, sino rotar credenciales y realizar una evaluación de compromiso. Ese matiz importa mucho. Cuando un organismo de respuesta europeo te pide revisión de compromiso, no está sugiriendo higiene básica; está insinuando que el riesgo de intrusión previa es real.

No es “un parche más”: es una cadena de fallos con síntomas de problema sistémico

Hay dos maneras de leer este episodio. La superficial consiste en ver una nueva oleada de CVE en un producto corporativo clásico y asumir que la rutina de actualizaciones resolverá el incidente. La lectura útil es otra: cuando en cuatro meses aparecen múltiples vulnerabilidades graves en la misma plataforma, con mezcla de deserialización insegura, funciones críticas sin autenticación y explotación activa casi inmediata, lo que tienes delante no es un sobresalto puntual, sino un problema de superficie de ataque estructural.

Eso cambia la gestión.

Una organización madura no debería limitarse a preguntar si el parche de julio está instalado. Debería hacerse al menos cinco preguntas adicionales:

1. ¿Qué instancias on-premise siguen accesibles desde internet, directa o indirectamente?
2. ¿Qué cuentas de servicio, administradores de granja, cuentas de aplicación y secretos vinculados a SharePoint pueden haber quedado expuestos?
3. ¿Qué integraciones dependen de SharePoint para autenticación, workflows, búsqueda, almacenamiento documental o conectores con terceros?
4. ¿Qué nivel de telemetría conservamos para reconstruir actividad entre el 14 y el 20 de julio, y las semanas previas?
5. ¿Estamos tratando SharePoint como un activo crítico o como un rincón heredado que solo mira el equipo de sistemas cuando se cae?

La secuencia temporal lo complica todo. Si una vulnerabilidad pasa de parche a prueba de concepto y luego a explotación observada en apenas unos días, el ciclo clásico de gestión de vulnerabilidades —clasificar, planificar ventana, coordinar cambios, desplegar el mes que viene— sencillamente no sirve. Ese proceso valía para otro internet. No para este.

Además, la combinación de fallos autenticados y no autenticados invita a un escenario de encadenamiento. Un atacante no necesita que una CVE lo haga todo si puede usar una para acceso inicial, otra para privilegios y otra para ejecución persistente. CERT-EU no afirma una cadena concreta en su aviso, y sería irresponsable inventarla. Pero el patrón técnico sí justifica elevar la hipótesis operativa de compromiso complejo, no de incidente aislado.

La frase que más debería inquietar a los CISOs

Microsoft sostiene, según recoge CERT-EU, que la explotación de CVE-2026-50522 requiere algún nivel de autenticación. Sin embargo, hallazgos posteriores citados por CERT-EU sugieren que puede que no sea así. Esa discrepancia es mucho más que una discusión académica sobre precondiciones de explotación.

Si una organización clasificó el riesgo interno bajo el supuesto de “necesita autenticación”, es probable que haya priorizado por detrás de otros fallos supuestamente más urgentes. Si después resulta que la autenticación no era realmente una barrera efectiva, la matriz de priorización salta por los aires. Y esto pasa más de lo que al sector le gusta admitir: la severidad técnica publicada el día uno rara vez coincide del todo con la realidad ofensiva del día seis.

Traducido a operaciones: si tu proceso de priorización depende demasiado de la ficha inicial del proveedor y demasiado poco de inteligencia de explotación en los días siguientes, vas tarde casi por diseño.

WatchTowr observó explotación activa el 20 de julio. CISA, citada por CERT-EU, también urgió endurecimiento de SharePoint tras nuevas explotaciones el 14 de julio de 2026. No hablamos de ruido en redes sociales ni de FUD comercial. Hablamos de señales convergentes de actores distintos: fabricante, CERT europeo, investigadores y autoridad estadounidense. Cuando todas las alarmas suenan a la vez, discutir si la vulnerabilidad es “verdaderamente crítica” resulta casi entrañable. El atacante ya ha votado.

El error recurrente: creer que parchear cierra el incidente

Parchear es obligatorio. Parchear no basta.

De hecho, el propio texto de CERT-EU coloca tres acciones al mismo nivel: actualizar, rotar credenciales y realizar una evaluación de compromiso. Ese tríptico debería leerse como una secuencia lógica. Si el servidor ha estado expuesto y vulnerable, el parche elimina la puerta actual, pero no el posible acceso obtenido antes ni las credenciales ya capturadas.

Esta distinción es operativamente crítica. Un atacante que logró código remoto o privilegios elevados antes del parche puede haber hecho varias cosas que siguen activas después:

• Crear cuentas o backdoors en el servidor o en sistemas conectados.
• Robar credenciales de servicio, tokens, cookies, claves API o certificados.
• Modificar tareas programadas, jobs de SharePoint, componentes web o archivos de configuración.
• Establecer persistencia en IIS, PowerShell, servicios de Windows o mecanismos de administración remota.
• Pivotar hacia Active Directory, bases de datos SQL Server, sistemas de archivo o repositorios documentales.

SharePoint rara vez vive solo. Normalmente está conectado a identidad, correo, flujos documentales, DLP, motores de búsqueda, escáneres, herramientas de e-discovery y, en no pocas empresas, a procesos sensibles de negocio. Por eso una intrusión en SharePoint no es simplemente “un servidor comprometido”. Puede convertirse en una vía de acceso a información regulada, secretos contractuales, expedientes de RRHH, documentación legal, borradores de consejo o evidencias de auditoría. Un festival, pero del malo.

La recomendación de rotar credenciales merece especial atención. Muchas organizaciones rotan usuarios interactivos y olvidan las cuentas de servicio, que son precisamente las más útiles para moverse sin hacer ruido. Si SharePoint se integra con SQL Server, Active Directory, SMTP, archivado, conectores de terceros o automatizaciones, la rotación parcial deja agujeros. Y si la granja utiliza certificados o secretos compartidos en varios nodos, el trabajo se complica rápido.

Qué deberían revisar hoy las organizaciones afectadas

La respuesta inmediata no necesita una plantilla de consultoría con colorines. Necesita decisiones concretas en horas, no en semanas.

Primero, identificación de exposición. No basta con preguntar al equipo de infraestructura si “hay un SharePoint por ahí”. Hay que confirmar qué instancias siguen publicadas, a través de qué FQDN, balanceador, reverse proxy o VPN, con qué segmentación y con qué registros. En más de una empresa aparecen sorpresas: entornos de preproducción publicados, nodos antiguos todavía accesibles, granjas híbridas mal inventariadas o instancias heredadas por adquisiciones.

Segundo, estado de parche y versión. A estas alturas, seguir sin aplicar las actualizaciones de julio de 2026 es una negligencia operativa difícil de defender. Y conviene revisar también los fixes de abril y mayo para CVE-2026-32201 y CVE-2026-45659. Si una organización solo reacciona a la CVE con explotación activa, puede dejar detrás fallos previos que faciliten persistencia o spoofing.

Tercero, búsqueda de compromiso. Esto implica revisar logs de IIS, eventos de Windows, PowerShell, procesos anómalos, tareas programadas, cambios en archivos de aplicación, actividad de cuentas privilegiadas, conexiones salientes sospechosas y artefactos en memoria o disco. Si la retención de logs es corta o la telemetría es pobre, habrá que asumir un grado mayor de incertidumbre. Y esa incertidumbre, por sí sola, ya es un hallazgo de riesgo.

Cuarto, rotación ordenada de credenciales y secretos. La palabra clave es ordenada. Rotar sin mapa puede romper medio negocio. Pero no rotar por miedo al cambio es peor. Prioridad: cuentas de servicio de SharePoint, administradores de granja, cuentas asociadas a SQL Server, certificados usados por aplicaciones conectadas y cualquier secreto almacenado en scripts, tareas o vaults accesibles desde el servidor.

Quinto, revisar la arquitectura de exposición. CERT-EU lo plantea claramente: dada la cantidad de vulnerabilidades críticas recientes, las organizaciones deberían reconsiderar exponer Microsoft SharePoint Server directamente a internet. Ahí está el verdadero mensaje estratégico del aviso. No es solo “instala este parche”; es “deja de asumir que este producto debe estar públicamente accesible si puedes evitarlo”.

El ángulo regulatorio: DORA, NIS2 y GDPR convierten un fallo técnico en un asunto de gobierno

Esta historia no se queda en el CPD. En Europa, una exposición insegura de SharePoint puede activar obligaciones de gobierno, gestión de incidentes, cadena de suministro y protección de datos. No por magia jurídica, sino porque estas plataformas suelen procesar información crítica y conectarse a procesos esenciales.

Para entidades financieras sujetas a DORA, el asunto encaja de lleno en la gestión del riesgo de las TIC. El art. 6 exige un marco interno sólido y documentado para el riesgo TIC; el art. 8 aterriza la identificación y clasificación de funciones, activos, dependencias y vulnerabilidades; el art. 10 exige mecanismos de detección de actividades anómalas; y el art. 11 entra en la respuesta y recuperación. Si una entidad no sabe qué SharePoint expone, no tiene inventario fiable y tarda días en decidir si rota credenciales, el problema ya no es solo técnico: es una grieta en el marco de control exigido por DORA.

Hay más. Si el servidor afectado soporta procesos esenciales o importantes, la materialidad del incidente puede escalar rápidamente dentro del régimen de notificación de incidentes graves de DORA. Los detalles procedimentales dependen de los RTS e ITS aplicables en 2026, pero el principio es claro: la incapacidad de detectar, contener y valorar impacto con rapidez ya tiene consecuencias supervisoras.

Para operadores esenciales e importantes bajo NIS2, el encaje es igual de evidente. El art. 21 obliga a adoptar medidas técnicas, operativas y organizativas apropiadas, incluyendo gestión de incidentes, seguridad de la cadena de suministro, políticas de análisis de vulnerabilidades, higiene básica y formación. Una plataforma on-premise públicamente expuesta con una cadena reciente de CVE críticas es justo el tipo de activo que un regulador esperaría ver inventariado, segmentado, monitorizado y parcheado con prioridad. Y si el incidente alcanza el umbral aplicable, el régimen de notificación de NIS2 art. 23 entra en juego: alerta temprana en 24 horas, notificación en 72 horas y, más tarde, informe final. El calendario no perdona a quien necesita una semana para averiguar si sigue usando SharePoint 2016.

Si hay datos personales comprometidos, aparece GDPR. El art. 32 exige medidas de seguridad apropiadas; el art. 33 obliga a notificar brechas a la autoridad de control en 72 horas cuando proceda; el art. 34 puede exigir comunicación a los interesados si el riesgo es alto. SharePoint almacena con frecuencia datos de empleados, clientes, proveedores y documentación sensible. Si una explotación ha permitido acceso no autorizado, la evaluación no puede quedarse en “hemos aplicado el parche”. Tendrás que acreditar qué datos estaban allí, quién pudo acceder, durante cuánto tiempo, y qué medidas tomaste para mitigar el riesgo residual. Sin logs, buena suerte.

Implicaciones para entidades financieras españolas

En banca, seguros, pagos y mercado de valores en España, este episodio tiene un filo adicional. No solo por DORA y GDPR, sino por la expectativa creciente de trazabilidad, evidencias y gobierno efectivo ante supervisores.

Si una entidad española mantiene SharePoint on-premise para gestión documental, expedientes, flujos internos o intercambio con terceros, estas son las preguntas que probablemente acabarán apareciendo en una revisión interna, auditoría o conversación con segunda línea:

• ¿El inventario de activos TIC identificaba la exposición externa de las instancias afectadas?
• ¿Existía un criterio formal para elevar a prioridad máxima una CVE con explotación activa y CVSS 9.8?
• ¿Qué plazo real transcurrió entre la publicación del parche el 14 de julio y su despliegue en producción?
• ¿Qué controles compensatorios existían durante esa ventana: WAF, segmentación, restricción de acceso, MFA, geoblocking, reverse proxy endurecido?
• ¿La entidad conservaba telemetría suficiente para evaluar compromiso y alcance?
• ¿Se activaron comités de crisis, notificación interna a compliance/DPO y valoración de impacto en procesos críticos?

El punto delicado es este: muchas entidades creen que su madurez regulatoria es alta porque tienen políticas, matrices y comités. Pero cuando aparece una explotación rápida sobre una plataforma heredada, lo que importa no es el PDF de gobierno. Importa si alguien sabía qué estaba expuesto, si el parche salió en horas, si hubo hunting y si se documentó la decisión de rotar o no rotar secretos. El supervisor no compra powerpoints cuando el log de IIS cuenta otra historia.

También hay una derivada de terceros. Muchas organizaciones externalizan la gestión de SharePoint o de su infraestructura subyacente. Eso no desplaza la responsabilidad última. Bajo DORA, la gestión del riesgo de terceros TIC no elimina la obligación de supervisión por parte de la entidad financiera; bajo NIS2, la cadena de suministro también entra en la ecuación; y bajo GDPR, el responsable del tratamiento no se lava las manos porque el encargado administre el servidor. Si el MSP o integrador tardó en aplicar el parche, tendrás que explicar cómo lo gobernabas tú.

Lo que esta crisis dice sobre el on-premise en 2026

Hay una lección de fondo que va más allá de SharePoint. En 2026, seguir operando plataformas corporativas on-premise expuestas a internet exige una disciplina casi quirúrgica. Inventario exacto, telemetría buena, hardening real, capacidad de parcheo urgente, control de secretos y hunting post-explotación. Si falta una de esas piezas, el modelo entero se vuelve frágil.

No se trata de repetir el mantra fácil de “todo a la nube”. Ese debate serio depende del caso de uso, del dato, de la soberanía, de la integración y del coste. Pero sí conviene decir algo incómodo: muchas organizaciones mantienen on-premise no por decisión estratégica, sino por inercia histórica. Y la inercia histórica suele ser una forma elegante de decir que nadie quiere pagar la migración ni tocar procesos viejos. Hasta que llega una serie de CVE 9.8 y entonces el coste aparece, solo que peor.

También conviene romper otro autoengaño frecuente. Algunos equipos defienden que un producto maduro es más seguro porque “ya está muy probado”. A veces. Otras veces significa que arrastra deuda técnica, compatibilidades heredadas, integraciones imposibles y superficies difíciles de endurecer. La madurez no inmuniza frente a errores de deserialización ni frente a funciones críticas sin autenticación. Si acaso, hace más dolorosa la remediación porque el producto está incrustado en medio negocio.

Qué decisiones estratégicas deberían salir de aquí

La respuesta táctica es parchear, rotar, buscar compromiso y reducir exposición. La estratégica va bastante más allá.

La primera decisión es clasificar SharePoint y plataformas equivalentes como activos de alta criticidad operativa cuando soporten contenido o procesos relevantes. Eso debe reflejarse en priorización de vulnerabilidades, requisitos de logging, pruebas de restauración, gestión de acceso privilegiado y revisión de arquitectura. Si internamente sigue etiquetado como “herramienta colaborativa”, seguirá perdiendo recursos frente a otros sistemas que suenan más nobles.

La segunda es reducir la dependencia de exposición directa a internet. No siempre será posible eliminarla por completo, pero sí suele ser viable interponer controles: acceso a través de VPN o ZTNA, reverse proxies endurecidos, segmentación estricta, restricciones por identidad y postura, y publicación solo de lo estrictamente necesario. CERT-EU no pide esto por capricho. Lo pide porque la frecuencia reciente de fallos críticos sugiere que el riesgo base de publicación es demasiado alto.

La tercera es cambiar el modelo de priorización de parches en activos expuestos. Para productos con historial reciente de RCE y explotación activa, la ventana aceptable no debería medirse en ciclos mensuales. Debería medirse en horas o, como mucho, pocos días, con procedimientos de emergencia preaprobados. Si cada parche crítico exige una negociación burocrática de cuatro capas, el problema no es técnico: es de gobierno.

La cuarta es conectar vulnerabilidad, detección y cumplimiento. En demasiadas empresas, VM, SOC, infraestructura, GRC y privacidad trabajan como departamentos vecinos que se saludan en el ascensor. Este caso demuestra por qué eso ya no sirve. Una CVE explotada en SharePoint puede requerir al mismo tiempo parcheo urgente, hunting, evaluación de brecha de datos, valoración DORA/NIS2 y revisión contractual con terceros. Si esos flujos no están ensayados, se pierde tiempo donde más duele.

Indicadores que merecen seguimiento en las próximas semanas

Este episodio no termina con el aviso de CERT-EU. Hay varios indicadores que los equipos de seguridad y compliance deberían vigilar durante agosto:

• Si Microsoft revisa de nuevo las condiciones de explotación de CVE-2026-50522, especialmente el requisito de autenticación.
• Si aparecen guías de detección adicionales, reglas Sigma, YARA o indicadores de compromiso más sólidos por parte de CERTs, CISA o investigadores.
• Si se observan campañas oportunistas de escaneo masivo dirigidas a instancias de SharePoint publicadas.
• Si nuevas CVE relacionadas sugieren que todavía quedan superficies similares sin corregir.
• Si autoridades sectoriales europeas elevan expectativas concretas de notificación o de evidencias de remediación para entidades reguladas.

El historial reciente aconseja prudencia. Cuando un producto entra en una fase de escrutinio ofensivo intenso, suelen emerger más hallazgos. No siempre porque el software se haya vuelto peor de repente, sino porque más ojos están buscando en el mismo sitio con un incentivo clarísimo.

La conclusión incómoda: el parche arregla el software; no arregla la complacencia

La alerta de CERT-EU sobre SharePoint importa por las CVE concretas, por supuesto. CVE-2026-50522, CVE-2026-56164 y CVE-2026-58644, todas con CVSS 9.8, ya bastan para disparar la prioridad máxima. Pero la lección de verdad es otra: las organizaciones siguen subestimando el riesgo de sus plataformas corporativas heredadas expuestas a internet.

Eso es lo que debería cambiar esta semana.

Si tu SharePoint on-premise sigue publicado, parchea ya. Luego asume que el parche no demuestra ausencia de compromiso. Revisa logs, rota credenciales, analiza integraciones y decide si ese servicio necesita seguir visible desde internet. Si eres una entidad regulada, documenta cada paso: fechas, responsables, alcance, evidencias y criterio de materialidad. Porque cuando llegue la pregunta —del consejo, del auditor, del supervisor o del DPO— nadie va a quedar impresionado por un “aplicamos la actualización en cuanto pudimos”.

En 2026, “en cuanto pudimos” ya no es una estrategia. Es una confesión.