SAP corrige en su SDK de Python un fallo CVSS 10 que filtra credenciales

SAP ha corregido en su Patch Day del 13 de octubre de 2026 un fallo con CVSS 10 en SAP Cloud SDK for Python (CVE-2026-89111) que puede enviar el client ID y el client secret de OAuth2 de una aplicación a un servidor controlado por el atacante. Con él llegan otras tres vulnerabilidades críticas en S/4HANA, NetWeaver Visual Composer y Manufacturing Integration and Intelligence, sin explotación conocida a fecha de hoy.

Qué ha pasado

SAP publicó el 13 de octubre de 2026 su boletín mensual de seguridad, que INCIBE-CERT resume en 22 vulnerabilidades, de las que 4 son críticas, 3 altas, 14 medias y 1 baja. El CERT español emitió su aviso INCIBE-2026-739 el 14 de octubre con importancia 5 (crítica). El recuento de notas varía según quién cuente. Onapsis habla de 21 notas de seguridad y SecurityWeek de 22 notas nuevas y actualizadas, así que conviene contrastar con la lista oficial de SAP antes de planificar el ciclo de parches.

La puntuación más alta es para CVE-2026-89111, con CVSS 10,0. SAP la clasifica como SSRF (server-side request forgery) en el flujo OAuth2 de SAP Cloud SDK for Python, el cliente oficial de Python para los servicios de SAP Business Technology Platform (BTP). En su advisory de GitHub, que SecurityWeek reproduce, SAP explica que un atacante que controle el parámetro tenant_subdomain puede «redirect OAuth2 token requests to an attacker-controlled server» (redirigir las peticiones de token OAuth2 a un servidor controlado por el atacante). El advisory acredita el hallazgo al usuario de GitHub SunandM. El registro de NVD se publicó el mismo 13 de octubre y sigue con estado «Received», es decir, sin análisis propio.

SAP no menciona explotación activa de ninguna de las vulnerabilidades del mes y el advisory del SDK tampoco recoge ataques. Ninguna de las fuentes consultadas habla de una PoC pública. El gráfico siguiente, de elaboración propia con los datos de INCIBE-CERT, reparte las 22 vulnerabilidades por gravedad y deja ver que las cuatro críticas son una minoría frente a las 14 de gravedad media.

Detalles técnicos

El SDK toma la URL de token de la configuración de la aplicación y sustituye una parte por el subdominio del tenant. Según el análisis del código que hizo The Hacker News, las versiones sin comprobación usaban cualquier valor recibido y mandaban el client ID y el client secret a la URL resultante para pedir el token. Si un tercero consigue que la aplicación use un subdominio suyo, esas credenciales terminan en su servidor. La corrección valida el valor contra las reglas de etiqueta DNS de la RFC 1123 y solo acepta un nombre formado por letras, cifras y guiones, de hasta 63 caracteres. Cualquier otra cosa lanza un ValueError.

La condición de explotación es que el atacante controle el tenant_subdomain que la aplicación pasa al SDK. El vector CVSS no exige autenticación ni interacción, pero en la práctica todo depende de cómo obtenga cada aplicación ese valor. El advisory no dice qué puede hacer el atacante con las credenciales robadas, algo que depende de los permisos del cliente OAuth2 afectado.

Lo más llamativo está en la cronología de versiones. SAP corrigió el fallo en la 0.45.2, publicada el 21 de agosto, y lo hizo sin etiqueta de seguridad. Las notas de esa versión lo listaban entre las correcciones de errores. El aviso formal llegó 53 días después. En el diagrama de elaboración propia, hecho con las fechas que recoge The Hacker News, se ve que entre medias salieron versiones sin la comprobación. Es una cronología de lanzamientos y no describe el mecanismo interno del SDK, que SAP no ha publicado.

Según esas pruebas, las versiones 0.36.1 y 0.36.2, publicadas el 4 y el 10 de septiembre, no incluyen la comprobación. Tampoco la tienen las 0.53.0 a 0.55.0, publicadas entre el 10 y el 18 de septiembre, en las llamadas a Destination, y la 0.55.0 la omite también en Document Management Service. La causa es que la 0.53.0 movió el módulo Destination a un código compartido de peticiones de token que carecía de la validación. La 0.55.1 la restituyó el 18 de septiembre. Las seis versiones fallaron 9 de las 11 pruebas que SAP añadió con la 0.55.1. Ni el advisory ni las notas de versión aclaran si esas seis quedan dentro del CVE. Las notas de la 0.55.1 indican que el SDK ahora «raises ValueError immediately instead of silently routing credentials to an attacker-controlled endpoint» (lanza un ValueError de inmediato en lugar de enviar en silencio las credenciales a un destino controlado por el atacante).

Para comprobar qué versión corre en cada entorno y subir a una que incluya la validación bastan dos comandos.

pip show sap-cloud-sdk | grep -i '^version'
pip install --upgrade "sap-cloud-sdk>=0.55.1"

Elaboración propia a partir de las versiones corregidas que publica The Hacker News.

Mientras no puedas actualizar, la mitigación que propone SAP es comparar el tenant_subdomain con una lista de tenants conocidos antes de pasarlo al SDK. Un ejemplo mínimo de esa comprobación, con la misma regla de formato que aplica la versión corregida.

import re

TENANTS_REGISTRADOS = {"cliente-a", "cliente-b"}  # sustituir por la lista real

def tenant_valido(subdominio: str) -> str:
    if subdominio not in TENANTS_REGISTRADOS:
        raise ValueError("tenant_subdomain no registrado")
    if not re.fullmatch(r"[A-Za-z0-9-]{1,63}", subdominio):
        raise ValueError("tenant_subdomain con formato no válido")
    return subdominio

Elaboración propia a partir de la mitigación del advisory de SAP y de la regla de validación que describe The Hacker News.

A quién afecta

El fallo del SDK afecta a las aplicaciones multitenant (una misma aplicación que atiende a varios clientes) desplegadas en SAP BTP que usan el SDK de Python y le pasan un subdominio de tenant. Según The Hacker News, solo importa donde la aplicación pasa ese valor al SDK. El arreglo de agosto cubrió los módulos Agent Gateway, Destination y Document Management Service.

Las otras tres críticas del boletín afectan a componentes muy extendidos en entornos SAP, como S/4HANA o los componentes Java de NetWeaver. Las tres exigen cierto nivel de acceso previo, algo que baja la urgencia frente al SDK pero no la elimina en entornos con muchos usuarios de negocio.

CVE-2026-89110 es un control de acceso defectuoso en la funcionalidad de portal de Visual Composer. Según Onapsis, permite a un atacante con pocos privilegios invocar operaciones internas en un sistema remoto preconfigurado y comprometerlo por completo. CVE-2026-89107 es una inyección de código en la gestión de reglas de sustitución y validación de S/4HANA. La validación de entrada falla en el proceso de definición de reglas y el contenido enviado se interpreta como código ABAP. CVE-2026-89108 permite a un administrador XMII crear una cuenta administrativa en el servidor de aplicaciones Java subyacente. Onapsis indica que lo notificó su laboratorio de investigación, Onapsis Research Labs.

El gráfico de Onapsis resume el Patch Day por componente y prioridad. Muestra una nota HotNews en ABAP con CVSS máximo 9,9, otra en MII con 9,1 y otra en Visual Composer con 9,9, además de la nota 3765424, con CVSS 7,5, que también afecta a SAP Web Dispatcher, SAP HANA XSC/XSA y SAP Content Server. El SDK de Python no aparece porque no es un componente ABAP ni Java.

En prioridad alta figura CVE-2026-89113, una inyección SQL en SAP Commerce Cloud (COM_CLOUD 2211-JDK21) con CVSS 8,8, y CVE-2026-58249, una corrupción de memoria en el manejo de HTTP/2 de ICM y Web Dispatcher que un atacante sin autenticar puede usar para tumbar el proceso. Esta última solo afecta a instalaciones con HTTP/2 activado. Sobre el ángulo español, INCIBE-CERT asigna al boletín importancia 5 sobre 5 y recomienda aplicar con prioridad las notas, pero ni INCIBE-CERT ni CCN-CERT dan cifras de instalaciones expuestas en España.

Qué hacer

1. Localiza todas las aplicaciones multitenant de BTP escritas en Python e identifica la versión de sap-cloud-sdk que corre en cada entorno, incluidas las imágenes de contenedor ya desplegadas. Un requirements.txt no basta, porque la versión real puede ser otra.
2. Actualiza el paquete a la 0.55.1 o posterior (la 0.58.4 era la más reciente en PyPI el 13 de octubre) y redespliega. Evita las 0.36.x y las 0.53.0 a 0.55.0, que según The Hacker News no incluyen la comprobación, y no des por buena una versión solo porque sea superior a la 0.45.2.
3. Si no puedes actualizar hoy, compara cada tenant_subdomain con tu lista de tenants registrados antes de llamar al SDK, tal y como indica SAP.
4. Revisa de dónde sale el tenant_subdomain en cada aplicación. Si se deriva de la cabecera Host, de un parámetro de la petición o de cualquier dato que un tercero pueda manipular, trátalo como el vector de ataque y valida en origen.
5. Busca en los logs de red conexiones salientes de esos servicios hacia dominios que no pertenezcan a tu subcuenta de BTP, en especial en las peticiones de token. SAP no dice si hay que sustituir las credenciales, así que nuestra recomendación es rotar el client secret de las aplicaciones que hayan ejecutado versiones sin la comprobación.
6. Aplica la nota 3805589 en S/4HANA. Como medida temporal, SAP propone desactivar el servicio OData afectado, lo que impide crear, modificar o borrar reglas de sustitución y validación desde las aplicaciones Fiori relacionadas. RedRays recomienda avisar antes a Finanzas.
7. Aplica la nota 3797111 en Visual Composer. Antes del parche puedes activar a mano la configuración de lista de permitidos de servicios de datos. El parche cambia ese valor por defecto.
8. Aplica la nota 3798788 en Manufacturing Integration and Intelligence. No hay medida temporal descrita, así que revisa las cuentas administrativas del servidor Java y restringe el acceso de red al servicio de configuración mientras tanto.
9. Actualiza SAP Commerce Cloud a 2211-jdk21.18 o posterior y reconstruye la aplicación, según RedRays. Para la nota 3765424 de ICM y Web Dispatcher, Onapsis no describe medida temporal y RedRays apunta a desactivar HTTP/2 donde sea posible.
10. Si detectas actividad sospechosa, notifícala a INCIBE-CERT si eres empresa o ciudadano, o al CCN-CERT si formas parte del sector público.

Análisis

El fallo del SDK tiene una puntuación de 10 y, en la práctica, un perímetro estrecho. Necesita que la aplicación entregue a un tercero el control de un parámetro y que esa aplicación sea multitenant en BTP. Quien gestione estos entornos debe mirar la CVSS como punto de partida y priorizar por el origen del tenant_subdomain, porque en una aplicación que lo saca de una tabla interna el riesgo real es bajo y en una que lo toma de la cabecera Host puede ser inmediato.

Lo que más nos preocupa es el hueco de 53 días entre la corrección silenciosa y el aviso. Quien leyó las notas de agosto vio una corrección de errores. Quien confía en un escáner de dependencias que aplique el rango del advisory (versiones anteriores a 0.45.2) puede dejar pasar las 0.53.0 a 0.55.0, que numéricamente son posteriores y, según las pruebas de The Hacker News, carecen de la validación en Destination. Es una lectura nuestra y SAP no ha aclarado si esas versiones entran en el CVE. Hasta que lo haga, conviene tratarlas como afectadas.

Tampoco dice el aviso cuántas aplicaciones de clientes usan el SDK ni si SAP ha detectado intentos de abuso. La ausencia de explotación conocida depende de que alguien la esté buscando. En un SDK de código abierto con una corrección pública desde el 21 de agosto, cualquiera ha podido comparar versiones y deducir el fallo antes del aviso, algo que cabe esperar cuando un parche precede a su advisory. En el modelo post-perímetro, donde la credencial hace de frontera, un client secret expuesto equivale a una puerta abierta.

Contexto

El Patch Day de SAP cae en una semana cargada de correcciones críticas. El blog ya ha contado otro fallo con CVSS 10 en GitLab, los zero-days de Ivanti Connect Secure y un zero-day de Windows Shell que ya se explota. A diferencia de esos casos, ninguna de las críticas de SAP consta como explotada, de modo que hay margen para parchear con orden.

Para los equipos de desarrollo, el caso recuerda que una librería cliente forma parte de la superficie de ataque tanto como el servidor. Las aplicaciones multitenant montadas sobre microservicios multiplican los puntos donde un valor externo acaba en una URL, y cada uno necesita su propia validación.

Preguntas frecuentes

¿Me afecta si mi aplicación de BTP no es multitenant?

El advisory limita el fallo a las aplicaciones multitenant de BTP que usan el SDK. Según The Hacker News, solo importa donde la aplicación pasa un tenant_subdomain al SDK. Una aplicación de un solo tenant que no lo use queda fuera, pero comprueba igualmente la versión, porque el paquete puede llegar como dependencia de otro componente.

¿Basta con comprobar que la versión es superior a la 0.45.2?

No basta. The Hacker News probó el código de cada versión y encontró que de la 0.53.0 a la 0.55.0 faltaba la comprobación en las llamadas a Destination. Los rangos seguros que publica son 0.45.2 a 0.52.2 y 0.55.1 a 0.58.4. Lo más sencillo es fijar la 0.55.1 o posterior y volver a construir la imagen.

¿Hay que cambiar las credenciales OAuth2 de mis aplicaciones?

SAP no indica si las aplicaciones que ejecutaron versiones afectadas deben sustituir sus credenciales. Rotar el client secret tiene poco coste frente al riesgo de que se haya enviado a un tercero, sobre todo si el tenant_subdomain se toma de datos externos. Revisa también los permisos del cliente OAuth2, porque limitan lo que podría hacer quien se haga con él, y repasa las buenas prácticas para proteger las APIs.