SAP warns of maximum severity OAuth2 SSRF security flaw

SAP patched CVE-2026-89111 in its Cloud SDK for Python, the official toolkit for building AI agents and Python applications on SAP BTP services. The flaw affects OAuth2 handling in multi-tenant BTP applications. It is rated maximum severity because an attacker can exploit it remotely, without privileges, to steal credentials.

The attack centers on the tenant_subdomain parameter. If an attacker controls that value, the SDK can send an OAuth2 token request to an attacker-controlled server instead of the intended tenant. The attacker can then capture client credentials included in that request.

SAP recommends installing the October 2026 updates. Customers that need more time can validate tenant_subdomain against an allowlist of registered tenant subdomains before passing it to an SDK call. The issue shows how a small tenant-routing input can expose secrets across cloud applications.

OAuth2 SSRF combines two ideas. OAuth2 is used to obtain tokens for accessing protected services. Server-side request forgery, or SSRF, occurs when an attacker influences a server into making a request to an unintended destination. In this case, the unintended destination can be controlled by the attacker.

SAP’s Cloud SDK for Python accepts tenant_subdomain when handling OAuth2 requests in multi-tenant BTP applications. If that value is not checked, an attacker can redirect the request away from the legitimate tenant and toward an attacker-controlled server. The server can receive sensitive client credentials.

This matters because the request comes from a trusted application, not directly from the attacker. A stolen credential may let an attacker impersonate the application or access connected services, depending on the credential’s permissions. SAP’s stated temporary defense is validating tenant_subdomain against a known allowlist.

The vulnerable flow begins when a consumer application passes tenant_subdomain to the SAP Cloud SDK for Python. The parameter helps identify the tenant involved in a multi-tenant BTP request. Without proper validation, an attacker who controls the value can replace the legitimate tenant destination with an attacker-controlled host.

The SDK then follows that manipulated destination while making an OAuth2 token request. Because the request is generated by the application, it can contain client credentials used to authenticate the application to the OAuth2 service. The attacker’s server receives the request and can exfiltrate those credentials.

This is why CVE-2026-89111 is serious even though the attacker may only control an input value. The flaw turns tenant selection into request redirection. SAP advises validating tenant_subdomain against registered tenant subdomains before sending it to any SDK call, or installing the October updates.

The article identifies multi-tenant SAP BTP applications using the Cloud SDK for Python as the exposed environment. The SDK supports Python applications and AI agents built on SAP BTP services, but the article does not name particular application products. Exposure depends on how a consumer application handles tenant_subdomain during OAuth2 processing.

In a multi-tenant service, one platform serves multiple separate tenants. The tenant_subdomain helps direct a request to the intended tenant. If an attacker can influence that value and the application does not check it, the SDK may treat an attacker-controlled destination as legitimate and send OAuth2 token requests there.

This makes tenant routing a security boundary, not merely a configuration detail. Applications should restrict accepted values to registered tenant subdomains. SAP specifically recommends that allowlist approach while customers deploy the October 2026 patches.

SAP’s temporary mitigation is input validation. A consumer application should compare every tenant_subdomain value with a known allowlist containing registered tenant subdomains. Only approved values should be passed to the Cloud SDK for Python or used in an SDK call.

This defense targets the flaw’s key mechanism. An attacker needs to control tenant_subdomain so the SDK redirects an OAuth2 token request to an attacker-controlled server. Rejecting values outside the approved list prevents that redirection path and helps keep requests aimed at legitimate tenants.

The allowlist is not SAP’s replacement for patching. The company advises customers to install the October 2026 security updates, with validation serving as a temporary measure for those who cannot do so immediately. Teams should also identify applications using the SDK in multi-tenant BTP environments and verify their tenant-routing logic.

SAP’s October 2026 security updates fix 20 flaws across multiple products. The most severe include the Cloud SDK for Python OAuth2 SSRF flaw, a NetWeaver Visual Composer access-control flaw, and a Manufacturing Integration and Intelligence flaw that could enable underlying system takeover.

The potential impact is broad. SAP serves 99 of the 100 largest companies worldwide and reported more than €36 billion in fiscal year 2025 revenue. Onapsis estimated that over 10,000 Internet-facing SAP systems used the vulnerable component affected by the September Kernel flaw, CVE-2026-44756.

The wider record adds urgency. CISA has added 14 SAP flaws to its actively exploited catalog since November 2021, including three abused in ransomware attacks. Defused also flagged an August Commerce Cloud flaw as actively exploited days after SAP fixed it, showing why rapid patching matters.

OAuth2 access tokens are temporary credentials that let an application access protected services. Client credentials identify and authenticate the application requesting a token. Server-side request forgery, or SSRF, is a flaw that lets an attacker influence a server to send a request to an unintended destination. These definitions use established security terminology beyond the article’s brief explanation.

In SAP’s case, a multi-tenant BTP application uses the Cloud SDK for Python to make an OAuth2 token request. If tenant_subdomain is attacker-controlled, the request can be redirected to an attacker’s server. That server may receive the client credentials included in the request.

These mechanisms are fundamental because cloud applications rely on automated identity and service-to-service access. If request destinations are not restricted, trusted credentials can leave the intended environment. SAP’s allowlist guidance and October patches address this specific trust failure.