A server-side request forgery in a cloud SDK sounds like a lower-tier finding until you consider what the SDK is holding. For CVE-2026-89111 in the SAP Cloud SDK for Python, the answer is OAuth2 client credentials in multi-tenant SAP Business Technology Platform environments.

The disclosure

CVE-2026-89111 is rated 10.0 and affects SAP Cloud SDK for Python versions below 0.45.2. The flaw is server-side request forgery. Public reporting reviewed here notes that no in-the-wild exploitation had been observed at the time of writing, which distinguishes it from the KEV-listed issues covered elsewhere in this series.

Severity without exploitation is still severity. A 10.0 SSRF in a library that handles tenant-scoped credentials deserves attention before someone builds an exploit.

Why SSRF in an SDK is different

SSRF in a web application lets an attacker make the server issue requests on their behalf, typically to internal endpoints the attacker cannot reach directly.

SSRF in a shared SDK is a different shape. The SDK runs inside the customer's application, and that application holds credentials issued for its tenant. If request construction can be influenced so that the credential-bearing call goes to an attacker-chosen destination, the outcome is credential exfiltration rather than internal port scanning.

The distinction matters for impact assessment. A traditional SSRF is an access bypass. This one is closer to a credential leak: the tenant's OAuth2 client secret, presented to the wrong host, is a durable compromise.

The multi-tenant dimension

The affected environment is described as multi-tenant BTP. Two aspects deserve emphasis.

First, credentials in this environment authorize access to services across a subscription. A leaked client credential is not a read-only token for one endpoint; its scope is defined by the service instance it was created for.

Second, SDKs are consumed by application developers rather than operated by platform teams. The library version in use is often decided by a dependency lock file and updated when someone runs an upgrade. That makes remediation a code change in every consuming application, distributed across teams.

This is why library vulnerabilities with credential impact age badly. There is no single appliance to patch, and the dependency may sit several levels deep.

Practical remediation

  1. 1.

    Identify consuming applications. Search dependency manifests and lock files for the SDK. Container images reveal what actually shipped, which is often more accurate than repository manifests.

  2. 2.

    Upgrade to 0.45.2 or later in each application, then rebuild and redeploy so the runtime image contains the fixed version.

  3. 3.

    Verify at runtime. Log or assert the SDK version during startup. A repository that declares the fixed version and an image that contains the old one is a common mismatch.

  4. 4.

    Rotate client credentials for tenant service instances where the vulnerable version was deployed in an environment that processes untrusted input.

  5. 5.

    Review outbound traffic. If the SDK's request destinations are logged or observable, examine historical records for calls to unexpected hosts.

Step five is where an SSRF can be confirmed or ruled out in retrospect. Most organizations have proxy or egress logs that would show a credential-bearing request leaving for an unexpected destination, and few have looked at them for this reason.

The dependency problem this exposes

Credential-handling libraries occupy a privileged position in an application's dependency graph and are usually treated like any other package. They get updated on a release cadence, not a security one.

The practical improvement is to classify dependencies that hold credentials separately from those that do not, and apply a faster update policy to the first group. That is a policy change, not a tooling purchase, and it directly reduces the window in which a flaw like this one remains deployed.

References