Un fallo con puntuación CVSS de 10,0 en el SDK de SAP Cloud para Python puede desviar credenciales de aplicaciones hacia servidores controlados por atacantes. La incidencia también plantea dudas sobre las versiones posteriores a la primera corrección y obliga a revisar las dependencias utilizadas en entornos empresariales.
La seguridad de las aplicaciones en la nube vuelve a estar bajo presión. SAP ha publicado un aviso sobre una vulnerabilidad crítica que puede permitir el robo de credenciales OAuth2, uno de los mecanismos utilizados por las aplicaciones para autenticarse y acceder a servicios digitales.
El fallo, identificado como CVE-2026-89111, afecta al SDK de SAP Cloud para Python y ha recibido una puntuación de 10,0 sobre 10 en la escala CVSS, el máximo nivel de gravedad. El riesgo descrito consiste en que una aplicación envíe su identificador y su secreto de cliente a un servidor controlado por un atacante, siempre que se den determinadas condiciones relacionadas con el subdominio del inquilino.
La alerta, publicada el 13 de octubre de 2026, no confirma que se hayan producido ataques reales. Sin embargo, las pruebas de versiones adicionales realizadas por The Hacker News introducen un elemento relevante: algunas versiones posteriores a la corrección inicial habrían omitido una comprobación de seguridad en determinadas llamadas del SDK.
CVE-2026-89111: qué se sabe del fallo crítico de SAP
La vulnerabilidad afecta al SDK de SAP Cloud para Python, una biblioteca que permite a las aplicaciones conectarse con servicios de SAP Business Technology Platform (BTP).
El problema se encuentra en la forma en que determinadas versiones gestionan el subdominio del inquilino, un identificador que permite a la aplicación dirigir las solicitudes al entorno correspondiente. Si ese valor no se valida correctamente, puede influir en la dirección a la que el SDK envía la solicitud de autenticación.
Según el aviso de seguridad de SAP, un atacante que controle el subdominio utilizado por la aplicación podría conseguir que las credenciales de cliente OAuth2 se enviasen a un servidor bajo su control.
La incidencia se ha clasificado como una vulnerabilidad de falsificación de solicitud del lado del servidor (SSRF). Este tipo de debilidad permite que una aplicación o un servidor realice solicitudes a destinos que no deberían estar autorizados por la lógica prevista.
En este caso, la consecuencia potencial es especialmente delicada porque la solicitud puede contener información utilizada para autenticar a la aplicación ante los servicios de SAP.
Qué credenciales podrían quedar expuestas
El mecanismo de autenticación descrito utiliza dos elementos principales:
- ID de cliente: identifica a la aplicación ante el servicio de autenticación.
- Secreto de cliente: funciona como una credencial confidencial que permite demostrar la identidad de la aplicación.
Si un atacante consigue obtener ambas credenciales, podría intentar utilizarlas para autenticarse como la aplicación afectada. El alcance de ese acceso dependería de los permisos asignados al cliente, de las políticas de autenticación y de las restricciones adicionales existentes.
Por tanto, el robo de credenciales no equivale automáticamente al control de toda una plataforma SAP. No obstante, puede abrir una vía de acceso a información o servicios para los que la aplicación tenga autorización.
SAP no especifica en el aviso citado qué permisos concretos tendría un atacante en cada posible configuración. El impacto debe evaluarse atendiendo a los privilegios reales de cada aplicación.
El mecanismo del ataque: cómo pueden desviarse las credenciales
El SDK solicita un token de acceso cuando una aplicación necesita autenticarse ante un servicio. Para construir la solicitud, utiliza la dirección del punto de acceso de autenticación configurado y sustituye parte de esa dirección por el subdominio del inquilino.
El problema aparece cuando ese subdominio se acepta sin comprobar adecuadamente que sea un nombre válido y seguro. En las versiones afectadas, un valor manipulado podría alterar la URL resultante y dirigir la solicitud hacia un servidor no previsto.
Si la petición incluye el identificador y el secreto de cliente, el servidor receptor podría obtener las credenciales.
La comprobación introducida por SAP restringe el subdominio a un nombre simple formado por letras, números y guiones, con una longitud máxima de 63 caracteres. Los valores que no cumplen las condiciones deben provocar un error en lugar de utilizarse para construir la URL.
Este control evita que el dato proporcionado por la aplicación se convierta en una vía para alterar el destino de la autenticación.
El fallo no significa que cualquier usuario de Internet pueda robar automáticamente credenciales de cualquier instalación de SAP. Según el aviso, el escenario requiere que se cumplan determinadas condiciones, entre ellas el control del subdominio del inquilino que utiliza la aplicación.
Las versiones del SDK de SAP: una corrección inicial y nuevas dudas
SAP señaló la versión 0.45.2, publicada el 21 de agosto de 2026, como solución para la vulnerabilidad. Sin embargo, el análisis de versiones posteriores descrito por The Hacker News detectó diferencias en la aplicación de la comprobación.
El artículo original señala que, después de introducirse la corrección, varias versiones dejaron de aplicarla en determinadas llamadas al módulo Destination del SDK.
El cambio se habría producido en la versión 0.53.0, cuando parte de la lógica de solicitud de tokens se trasladó a código compartido que no incorporaba la misma validación. Según las notas de la versión 0.55.1, el control volvió a incluirse en ese componente el 18 de septiembre.
La situación requiere distinguir entre la vulnerabilidad reconocida formalmente por SAP y los resultados de las pruebas adicionales realizadas por el medio especializado.
Qué versiones requieren atención
La información publicada el 13 de octubre recoge el siguiente estado:
| Versiones del SDK | Resultado descrito en las pruebas |
|---|---|
| Anteriores a 0.45.2, incluidas algunas de la rama 0.36 | No incorporan la comprobación indicada |
| 0.45.2 a 0.52.2 | Incluyen la validación |
| 0.53.0 a 0.55.0 | La comprobación falta en determinadas llamadas al módulo Destination |
| 0.55.1 a 0.58.4 | Superan las pruebas citadas de validación |
The Hacker News indica que las seis versiones comprendidas entre la 0.53.0 y la 0.55.0 no superaron nueve de las once pruebas añadidas por SAP en la versión 0.55.1. La versión 0.55.1 y las once versiones posteriores analizadas superaron las once pruebas.
El artículo también señala que las versiones 0.36.1 y 0.36.2 de una rama antigua no incluyen la comprobación, pese a haberse publicado después de la corrección inicial.
Esta diferencia es importante para los responsables técnicos: no basta con comprobar que una versión sea posterior a la primera corrección. Es necesario verificar que la versión instalada incorpora efectivamente el control en los módulos y flujos de autenticación que utiliza la aplicación.
El aviso de SAP, tal como se describe en la información original, no enumera todas esas versiones posteriores como afectadas por la CVE-2026-89111. Por ello, no debe afirmarse que SAP haya clasificado oficialmente cada versión señalada por el análisis como vulnerable a esa misma CVE.
La versión 0.58.4 figuraba como la más reciente publicada en PyPI el 13 de octubre, según The Hacker News. Antes de actualizar, los administradores deben confirmar la versión recomendada y las instrucciones vigentes en el repositorio oficial del SDK.
Qué es OAuth2 y por qué preocupa la exposición de sus credenciales
OAuth 2.0 es un marco de autorización que permite a una aplicación obtener acceso limitado a recursos protegidos mediante tokens. En el flujo de credenciales de cliente, una aplicación utiliza su propia identidad para solicitar un token, sin que sea necesaria una sesión interactiva de un usuario final.
Este mecanismo resulta habitual en servicios empresariales, integraciones entre aplicaciones y procesos automatizados que necesitan comunicarse con otros sistemas.
El secreto de cliente debe tratarse como información confidencial. Si se filtra, un tercero podría intentar obtener tokens en nombre de la aplicación, siempre dentro de los permisos y las condiciones que permita la configuración.
La gravedad aumenta cuando la aplicación dispone de privilegios amplios o accede a datos empresariales sensibles. Una integración que puede consultar información de clientes, gestionar documentos o comunicarse con varios servicios podría tener consecuencias muy diferentes de otra con permisos mínimos.
Por eso, la protección de las credenciales de aplicación es una parte esencial de la seguridad en la nube. Las organizaciones deben limitar los permisos, evitar almacenar secretos innecesariamente en el código y revisar qué sistemas pueden acceder a ellos.
La versión 0.45.2 corrigió el problema, pero el aviso llegó semanas después
Según la información publicada por The Hacker News, la corrección se incluyó en la versión 0.45.2, publicada el 21 de agosto de 2026. El aviso específico sobre la vulnerabilidad apareció el 13 de octubre, es decir, varias semanas después.
Las notas de la versión de agosto describían el cambio como una corrección de errores y no lo presentaban expresamente como una actualización de seguridad. La explicación indicaba que determinados valores no válidos se utilizaban anteriormente para construir una URL mal formada.
El aviso de SAP atribuye el descubrimiento y la comunicación de la vulnerabilidad a un usuario de GitHub identificado como SunandM.
La secuencia pone de relieve la importancia de que las organizaciones no dependan exclusivamente de los avisos de vulnerabilidad para mantener sus sistemas protegidos. Las notas de versiones, los cambios de código y las actualizaciones de dependencias también pueden contener correcciones relevantes para la seguridad.
No obstante, el intervalo entre la publicación del parche y el aviso no demuestra por sí solo que SAP ocultara deliberadamente el problema. Para sostener esa conclusión serían necesarias pruebas adicionales sobre la comunicación interna, el proceso de divulgación y las decisiones adoptadas por la compañía.
Qué deben hacer las empresas que utilizan SAP Cloud SDK para Python
Las organizaciones que desarrollan aplicaciones con SAP Business Technology Platform deben revisar cuanto antes qué versiones del SDK utilizan y cómo gestionan la autenticación.
Las medidas recomendadas son las siguientes:
- Inventariar las dependencias. Comprobar la versión exacta del paquete
sap-cloud-sdken cada aplicación, entorno de pruebas, servidor de producción y proceso automatizado. - Actualizar a una versión que incluya la validación. Consultar el aviso oficial de SAP y el repositorio del SDK para confirmar la versión recomendada y comprobar la compatibilidad antes del despliegue.
- Revisar el uso del módulo Destination. Las aplicaciones que utilicen este módulo deben comprobar que la validación se aplica al flujo de autenticación que ejecutan.
- Validar los subdominios antes de enviarlos al SDK. Si una actualización inmediata no es viable, SAP recomienda comparar cada subdominio con una lista de inquilinos registrados y autorizados.
- Revisar los permisos de las aplicaciones. Reducir los privilegios a los estrictamente necesarios limita el impacto potencial si una credencial queda expuesta.
- Investigar posibles indicios de exposición. Revisar registros de solicitudes, eventos de autenticación y destinos inesperados, cuando esa información esté disponible.
- Valorar la rotación de secretos. Si existe evidencia de que las credenciales pudieron enviarse a un destino no autorizado, revocarlas y generar otras nuevas según los procedimientos de respuesta a incidentes.
La última medida merece especial atención. El aviso citado no especifica si todas las aplicaciones que utilizaron versiones sin la comprobación deben sustituir sus credenciales. Esa decisión debe basarse en el análisis del riesgo, la versión instalada, el uso real del flujo afectado y cualquier indicio de exposición.
Si se sospecha que un secreto ha quedado comprometido, mantenerlo activo puede prolongar el riesgo. La rotación debe coordinarse con los servicios que dependen de la credencial para evitar interrupciones innecesarias.
El reto de la seguridad en la nube: corregir y comprobar
La vulnerabilidad de SAP ilustra un problema recurrente en el desarrollo de software: una corrección puede dejar de aplicarse en una ruta del código cuando se reorganizan componentes o se trasladan funciones compartidas.
En este caso, el análisis publicado apunta a que la validación se introdujo en una versión y posteriormente no se mantuvo en determinados flujos relacionados con Destination, hasta su reincorporación en la versión 0.55.1.
La lección para los fabricantes es que las correcciones de seguridad deben contar con pruebas automatizadas que comprueben su permanencia en las versiones posteriores. Para los clientes, el episodio demuestra que actualizar no consiste únicamente en instalar la última versión disponible: también hay que verificar que la corrección cubre los componentes utilizados en producción.
La puntuación CVSS de 10,0 refleja la gravedad máxima asignada a la vulnerabilidad reconocida por SAP. Pero el riesgo concreto de cada organización depende de la configuración, los permisos de la aplicación, el uso del SDK y la posibilidad de que un atacante controle el subdominio utilizado.
La prioridad inmediata es comprobar las dependencias, confirmar la validación y proteger cualquier credencial que pudiera haberse expuesto. En plataformas empresariales, una integración aparentemente secundaria puede convertirse en una vía de acceso a servicios críticos si sus mecanismos de autenticación no se validan correctamente.
Ahora mismo no se pueden mostrar productos de esta tienda.