SAP's Python SDK for Business Cloud Had a Hole That Leaked Login Keys

Key points

• SAP's Cloud SDK for Python, the official toolkit for building apps on SAP Business Technology Platform, shipped with a flaw that could leak OAuth2 client credentials to an attacker's server.
• The bug is tracked as GHSA-4mv3-jxxm-9cx2 and SAP disclosed it on October 13.
• Version 0.45.2 fixes the flaw by checking the tenant subdomain against standard DNS naming rules before using it.
• Only multi-tenant apps, meaning apps that serve several customer accounts from one deployment, are at risk.
• Teams that can't patch straight away can mitigate by checking the tenant subdomain against a list of known good values before passing it to the SDK.

SAP has patched a flaw in its Python toolkit for cloud apps that could let an attacker steal the login keys those apps use to talk to SAP services.

The bug sits in the SAP Cloud SDK for Python, the official library developers use to build on SAP Business Technology Platform, which SAP shortens to BTP. BTP is where many large companies run custom extensions to their SAP finance and supply chain systems.

SAP's advisory, published on GitHub on October 13, describes the problem as a server-side request forgery in the OAuth2 flow. In plain words: the toolkit was asking a server for an access token, and an attacker could change the address of the server it asked. The token request carried the application's client credentials, so those credentials ended up on the attacker's machine. This is the third SAP vulnerability we've reported since July, including a buffer overflow in the SAP Kernel that could hand unauthenticated attackers full control of exposed business servers.

First reported by The Hacker News, the flaw carries the highest severity score the industry uses.

How did the attack work?

An attacker had to control a value called tenant_subdomain that the application passes into the SDK. In a multi-tenant app, that value usually identifies which customer is logging in. If an app took that value from a web request and handed it to the SDK without checking it, the attacker could stuff in their own hostname.

The SDK then built the OAuth2 token URL around that hostname and sent the client ID and client secret to it. Those secrets are the keys the application uses to prove it is itself. Anyone holding them can impersonate the app against SAP's cloud services.

What has SAP changed?

Version 0.45.2 validates the subdomain against standard DNS label rules before putting it into the token URL. Legal hostname segments allow letters, digits, and hyphens. Nothing exotic. A value with slashes or a full domain embedded in it will now be rejected before any network call goes out.

SAP also spells out a workaround for teams that can't upgrade immediately: keep a list of registered tenant subdomains in the consuming application and reject anything that isn't on it.

Should ordinary customers worry?

Not directly. This is a developer library, not something an end user installs. The risk sits with companies that built BTP apps on top of the Python SDK, and from there with the SAP tenants those apps connect to. If one of your suppliers runs such an app, they should be patching this week and rotating any client credentials that might have been exposed.

A CVSS 10 on a developer SDK sounds alarming, but the exploit path is narrow. You need a multi-tenant deployment, attacker-controlled input feeding straight into the SDK call, and a pre-0.45.2 build. Organizations that can't quickly answer whether their BTP extensions meet all three of those conditions are the ones with the most to do. The fix, a DNS label check, is input validation that should've been there from the start.