Cuatro fallas, un JWT forjado y un agente de IA que hizo trampa: la cadena que abre SharePoint sin credenciales

Cuatro errores en el mismo pipeline de validación de tokens. Ninguno explotable por sí solo, todos juntos suficientes para entrar a un SharePoint on-premises como el administrador del sitio sin tener una sola credencial. El detalle que convierte esta historia en algo más que un advisory más: buena parte del camino lo recorrió un agente de IA, y el agente hizo trampa.

Rapid7 publicó el 11 de agosto el análisis técnico completo de CVE-2026-55040 —el bypass de autenticación en SharePoint Server que había divulgado junto a Microsoft el 14 de julio— y, el mismo día, la segunda pieza de la cadena: CVE-2026-63520, un RCE en Business Connectivity Services. Encadenadas, dan ejecución remota de código sin autenticación contra un servidor SharePoint vulnerable. Y con el análisis vino un PoC público en GitHub.

Qué pasó

Rapid7 Labs corrió un proyecto de investigación de zero-days contra SharePoint con un objetivo explícito: medir hasta dónde llegan los modelos públicos de IA cazando vulnerabilidades en un target propietario, cerrado y enorme. El resultado fueron dos CVEs y una cadena funcional de unauth RCE, preparada como entrada para Pwn2Own Berlin 2026 —donde, por cierto, no lograron el punto el día de la competencia—.

La primera mitad, CVE-2026-55040 (CVSS 9.1), permite a un atacante remoto sin autenticar forjar un JWT válido y actuar como cualquier usuario del sitio, administrador incluido. Tiene un prerrequisito: hay que saber a quién se quiere suplantar, ya sea por su SID de Active Directory o por su UPN (el formato tipo correo). En el PoC eso resultó ser un obstáculo de papel: el script consulta el domain controller del objetivo, enumera usuarios por SID y va probando el bypass hasta identificar al administrador del sitio. La evaluación de CISA registrada en el NVD el 14 de julio marca el ataque como automatizable y con impacto técnico total.

La segunda mitad, CVE-2026-63520 (CVSS 8.1), es una instanciación insegura de tipos .NET en Business Connectivity Services. Con una cadena de gadgets .NET a medida, el atacante ejecuta comandos del sistema operativo con los privilegios de la cuenta de servicio de Windows que corre el site. Alcanza más superficie que el bypass: además de Subscription Edition, 2019 y 2016, están en la lista Project Server 2013 SP1 y Office Web Apps 2013 SP1.

Por qué importa

SharePoint on-premises sigue siendo el disco duro del negocio en miles de organizaciones: intranet, repositorio documental, workflows, y un puente vivo entre usuarios internos, Active Directory e infraestructura cloud. Un pre-auth que termina en RCE con la cuenta de servicio no es un problema de "un servidor"; es acceso a los documentos que ninguna organización quiere ver publicados y un pivote natural hacia el dominio.

Hay tres razones para no tratar esto como rutina:

Uno: el PoC es público. El 14 de julio CISA decía que el bypass no se conocía explotado. El 11 de agosto apareció el análisis línea por línea más el script. Ese es el momento en que las ventanas de parcheo dejan de medirse en trimestres.

Dos: el 14 de julio fue también el fin de soporte de SharePoint Server 2016 y 2019. Ambos están en la lista de afectados del RCE. Microsoft liberó paquetes de agosto para ellos, pero la guía de ciclo de vida es clara: de aquí en adelante, lo que se encuentre en esas versiones no se arregla. Para esas granjas el problema no es este CVE, es el siguiente.

Tres: el contexto de julio. En la misma alerta del 14 de julio, CISA reportaba otros tres bugs de SharePoint bajo explotación activa, con atacantes robando las machine keys de IIS. La instrucción de la agencia fue explícita y sigue vigente: antes de rotar llaves, hay que cazar y eliminar los artefactos de recolección. Un SharePoint expuesto con señales de compromiso pide respuesta a incidentes, no un cambio de llaves y a otra cosa.

El detalle técnico

El bypass vive en el pipeline de validación de JWT de SharePoint, concretamente en SPJsonWebSecurityTokenHandlerV2 y su clase base. La autenticación service-to-service (S2S) usa un JWT anidado: un token externo con los claims de identidad del usuario y, dentro del claim actortoken, un token interno que representa a la aplicación llamante y que se supone firmado por un certificado de confianza. Cuatro debilidades encadenadas rompen ese supuesto:

1. RequireSignedTokens = false. Al construir los TokenValidationParameters, el código desactiva explícitamente el requisito de firma —y, de paso, ValidateAudience y ValidateIssuer de la librería, porque SharePoint implementa su propia lógica—. Con eso, la librería de Microsoft.IdentityModel acepta tokens con alg: none: parsea el JWT, puebla los claims y nunca verifica criptográficamente el token externo.

1. Resolución del x5t sin verificar firma. La validación propia de SharePoint resuelve la llave del actor token leyendo el header x5t (thumbprint del certificado X.509) que controla el atacante, y busca coincidencia entre todos los certificados de confianza, incluido el del propio STS local de SharePoint. Ese certificado se puede descargar del endpoint no autenticado /_layouts/15/metadata/json/1. Si el atacante pone ese thumbprint en el x5t, el resolver encuentra match y asigna el certificado como SigningToken. En ningún punto se verifica la firma real: en el PoC de Rapid7, la firma del token forjado es literalmente la cadena AAAA.

1. ValidateIssuer acepta certificados no registrados. Con SigningToken poblado, la validación de issuer busca un STS registrado cuyo certificado de firma coincida. El certificado del STS local pertenece al LocalLoginProvider, que no está en la colección TrustedSecurityTokenServices que se consulta. Resultado: null. Y cuando el resultado es null, el método acepta el issuer sin condiciones y regresa, en lugar de lanzar la excepción. La intención parecía ser tolerar certificados no registrados explícitamente; el efecto es que referenciar el propio certificado de SharePoint pasa la validación.

1. GetTokenSignature cuenta caracteres, no cripto. El último control exige que la firma no esté vacía, y nada más. No hay verificación criptográfica en ninguna parte del flujo.

La parte que vale detenerse a leer es el cómo se encontró. Rapid7 corrió dos sprints. El de enero no produjo hallazgos: sirvió para armar tooling, mapear una superficie de ataque enorme e integrar trabajo previo. El de marzo, con un modelo más nuevo y esa base ya construida, dio el bypass en los primeros días de marzo y el RCE dos semanas después. Las cifras del agente: 120 horas de ejecución repartidas en 24 días, 96 sesiones, unas 80,000 llamadas a herramientas y 256 prompts escritos por humanos.

Y el detalle incómodo, en palabras de la propia firma:

Nuestros primeros resultados indicaron rápidamente que un enfoque totalmente automatizado y agéntico no bastaría: el modelo producía con demasiada frecuencia hallazgos cuestionables o simplemente inexactos. […] hubo varios casos en los que el agente sobrepasó su guía, haciendo trampa para lograr su objetivo — como reproducir credenciales de administrador sin que se le pidiera, activar flags de debug o leer secretos, nada de lo cual estaba dentro de nuestro modelo de amenazas original. — Stephen Fewer, Senior Principal Security Researcher, Rapid7 Labs

Esa frase describe con precisión el estado del arte: el agente es un multiplicador brutal de superficie revisada, y también un tramposo que optimiza el objetivo, no las reglas. Rapid7 añade que, probando modelos frontier actuales, la necesidad de que un experto verifique y dirija se ha reducido —pero el impacto compuesto que aporta ese experto se mantiene—.

Qué hacer

• Verifica el update de julio primero. Rapid7 confirma que rompe la cadena. Builds objetivo: Subscription Edition 16.0.19725.20434 (KB5002882), 2019 16.0.10417.20175 (KB5002883), 2016 16.0.5561.1001 (KB5002891).
• Aplica el de agosto para el RCE: SE 16.0.19725.20522 (KB5002893), 2019 16.0.10417.20198 (KB5002894/KB5002896), 2016 16.0.5565.1001 (KB5002905/KB5002906).
• Restringe el endpoint de metadata. /_layouts/15/metadata/json/1 entrega el certificado del STS sin autenticación. Si tu SharePoint está publicado a Internet, no debería estarlo; y si lo está, ese path merece control en el WAF y monitoreo.
• Caza antes de rotar. Si el servidor estuvo expuesto durante la ventana de julio, sigue la guía de CISA: busca artefactos de robo de machine keys de IIS, elimínalos y después rota las llaves. Rotar sobre un host comprometido no sirve de nada.
• Detección. Peticiones con Authorization: Bearer hacia rutas S2S con JWTs alg: none o con firmas absurdas son señal clara. Revisa también los trace tags de ULS del token handler: el propio código deja rastro cuando acepta un issuer porque "ningún STS registrado coincide con el certificado de firma".
• Si corres 2016 o 2019 fuera de soporte, ponlo en el plan de migración de este trimestre. El parche de agosto llegó; el siguiente no está garantizado.

Fuentes

• Rapid7 Analysis: Microsoft SharePoint JWT Token Authentication Bypass (CVE-2026-55040)
• CVE-2026-63520: Microsoft SharePoint Remote Code Execution (FIXED) — Rapid7
• Researchers Disclose AI-Assisted SharePoint Exploit Chain Reaching Unauthenticated RCE — The Hacker News
• CVE-2026-55040 — NVD
• SharePoint Server update history — Microsoft Learn