En solo un mes, Claude descubrió cómo acceder a cuentas corporativas de otras empresas mediante SAML

El desarrollador dio a Claude la tarea de revisar implementaciones de inicio de sesión corporativo mediante SAML y, en el transcurso de un mes, encontró vulnerabilidades que permitían acceder a cuentas ajenas, exponer datos y dejar servicios inoperativos. Parte de los problemas detectados aún no se ha corregido.

El director técnico de Oblique, Eric Chiang, inspeccionó con la ayuda de Claude Opus prácticamente todas las implementaciones de SAML que pudo encontrar. En lugar de instrucciones detalladas, describieron las amenazas posibles y permitieron al modelo buscar de forma autónoma comportamientos atípicos en las bibliotecas, para después agrupar los hallazgos y verificarlos con ejemplos funcionales.

SAML se usa para el inicio de sesión único en aplicaciones corporativas. Un punto débil del protocolo desde hace tiempo es la forma en que los programas procesan XML y firmas digitales. Componentes distintos pueden interpretar de manera diferente un mismo documento. Como resultado, el programa verifica la firma de una parte del mensaje pero luego confía en los datos de otra.

Claude descubrió que era posible eludir por completo la autenticación en cuatro proyectos a la vez: Authentik, LightSaml, OneUptime y la biblioteca Java saml-client. En Authentik la vulnerabilidad CVE-2026-57580 obtuvo 8,7 sobre 10. Un NameID especialmente formado con un comentario XML permitía vincular la identidad externa del atacante con una cuenta existente y después iniciar sesión como la víctima sin su contraseña.

El problema afectaba a Authentik hasta las versiones 2026.5.4 y 2026.2.5 inclusive. Los desarrolladores corrigieron la vulnerabilidad en las versiones 2026.5.5 y 2026.2.6. Para explotar la vulnerabilidad se requería una cuenta en el proveedor de identidad y la posibilidad de establecer un NameID propio.

En la biblioteca PHP LightSaml se detectó otra forma de eludir la verificación. Los componentes definían de manera distinta qué elemento XML estaba protegido por la firma digital. Un atacante podía usar una estructura firmada legítima pero hacer que la aplicación aceptara datos falsos del usuario. El fallo afectaba a versiones hasta la 5.0.0 inclusive y se corrigió en la 5.0.1.

Tras verificar el mecanismo principal de inicio de sesión, Chiang pasó a mensajes SAML menos estudiados. En doce proyectos se hallaron métodos para eludir la verificación de firmas cuando el sistema solicita autenticación, recibe atributos o el usuario cierra sesión. Tales fallos podían revelar información o forzar la terminación de sesiones ajenas. Uno de los ejemplos lo publicó el desarrollador para samlify.

Una categoría separada de problemas está relacionada con la denegación de servicio. Muchas bibliotecas SAML aceptan documentos XML arbitrarios desde internet, por lo que una petición especialmente preparada puede aumentar drásticamente el consumo de memoria. Para Go ya se corrigió el problema en goxmldsig, por el cual la memoria podía crecer de forma cuadrática. En las bibliotecas para Python y Node.js, según Oblique, parte de esos errores sigue abierta. Para python3-saml y PySAML2 se publicaron informes separados sobre que los recursos se pueden agotar excesivamente mediante transformaciones XSLT.

Chiang llegó a la conclusión de que las bibliotecas SAML maduras se han vuelto notablemente más resistentes a intentos de eludir por completo el inicio de sesión, pero las nuevas implementaciones siguen repitiendo errores antiguos. A los desarrolladores les aconseja no crear una implementación de SAML desde cero y, en su lugar, someter las soluciones existentes a comprobaciones automáticas para detectar clases de errores conocidas.