As reported by The Hacker News, SAP has disclosed CVE-2026-89111 — a CVSS 10.0 vulnerability in its Cloud SDK for Python that enables OAuth2 client credential theft from multi-tenant applications running on SAP Business Technology Platform. What makes this disclosure particularly noteworthy is not just the severity rating, but the regression pattern that saw the fix silently disappear and reappear across multiple release lines, with the official advisory failing to capture the full picture.

Security Impact: As reported by The Hacker News, SAP has disclosed CVE-2026-89111 — a CVSS 10.0 vulnerability in its Cloud SDK for Python that enables OAuth2 client credential theft from multi-tenant applications running on SAP Business Technology Platform.

Vulnerability at a Glance

FieldDetail
CVECVE-2026-89111
CVSS10.0 (Critical)
Affected ProductSAP Cloud SDK for Python (BTP client)
Advisory-Affected RangeBelow 0.45.2
Actually Affected (per testing)Below 0.45.2, 0.53.0–0.55.0, and 0.36.1–0.36.2
Patched Versions0.45.2–0.52.2, 0.55.1+, latest is 0.58.4
Exploitation in the WildNot confirmed; no public PoC referenced
Vendor AdvisorySAP Security Advisory, October 13, 2026

Why This Matters

The core mechanism is deceptively simple: the SDK accepts a tenant subdomain string and uses it to construct token requests for OAuth2 client credentials. If an attacker can control that subdomain — for instance, by registering a malicious tenant or manipulating tenant routing in a multi-tenant SaaS deployment — the SDK silently dispatches the application's client_id and client_secret to an attacker-controlled endpoint. There is no error, no warning, no log entry. The credentials simply leave the building.

This is a worst-case scenario for multi-tenant architectures. OAuth2 client credentials are typically long-lived, non-interactive, and grant programmatic access to an entire service surface. Unlike a stolen user session token, a stolen client secret can be used repeatedly until rotated, and it may grant access well beyond the specific tenant the attacker targeted. In environments where a single compromised client secret can reach downstream data, billing APIs, or integration layers, the blast radius is substantial.

The Regression Nobody Flagged

The more alarming story is what happened after the initial fix. SAP introduced the tenant subdomain validation check in version 0.45.2 on August 21. Then, when the Destination service module was refactored onto shared token-request code in version 0.53.0, that check was omitted. Six releases shipped without it. The advisory, as of October 13, lists no version above 0.45.2 as affected — meaning organizations that upgraded past the original vulnerable range and into the 0.53.0–0.55.0 window may believe they are patched when they are not.

Any organization running SAP Cloud SDK for Python versions 0.53.0 through 0.55.0 in production is exposed despite the advisory suggesting otherwise.

This is a textbook example of why dependency version pinning and patch-gap analysis matter. Security teams that patched to 0.45.2 and later auto-updated into the 0.53.0 range may have unknowingly reintroduced the vulnerability into their environment. The advisory's version range does not reflect this gap, and that is a disclosure failure that could lead to false assurance in vulnerability scans and compliance reports.

Who Is Most at Risk

  • Organizations running multi-tenant applications on SAP BTP using the Python SDK
  • Teams that auto-update dependencies and landed on 0.53.0–0.55.0 between September 10–18
  • Applications using the SDK's Destination service module or Document Management Service calls (0.55.0 specifically)
  • Environments where tenant subdomains are user-controllable or dynamically provisioned

Immediate Actions

  • Inventory and version-check: Identify all Python services using sap-cloud-sdk or sap-cloud-sdk-core. Confirm the exact installed version against the safe ranges (0.45.2–0.52.2 or 0.55.1+).
  • Upgrade to 0.58.4 or later: This is the simplest mitigation. Do not stop at 0.45.2 — the regression means intermediate versions are unsafe.
  • Rotate OAuth2 client secrets: If any affected version was ever deployed, treat credentials as potentially compromised. Rotate all client_id/client_secret pairs used by those services.
  • Audit for credential exfiltration: Review network egress logs and token endpoint access patterns for unexpected or non-SAP destinations. Look for outbound calls to domains not in SAP's BTP infrastructure ranges.
  • Restrict tenant subdomain inputs: As a defense-in-depth measure, validate tenant subdomain strings at the application layer before passing them to the SDK. Reject any input containing URL delimiters, path characters, or non-alphanumeric symbols.

Shield53 Recommendations

Beyond the immediate patch, this incident reinforces three broader practices:

  1. Never trust advisory version ranges alone. When a CVE is published, map it against your actual dependency tree using lockfiles and SBOMs. Regression windows are common and advisories are frequently incomplete at publication.
  2. Pin and review dependency upgrades. Auto-updating SDKs that handle authentication is high-risk. Every minor version bump on auth-adjacent libraries should trigger a security review, not just a CI green-light.
  3. Assume credential compromise for any CVSS 10.0 credential-theft bug. The cost of rotation is low; the cost of a long-lived stolen client secret is potentially catastrophic. Rotate first, investigate second.

SAP should update its advisory to explicitly call out the 0.53.0–0.55.0 and 0.36.1–0.36.2 gaps. Until it does, defenders must treat the advisory as incomplete and rely on independent version verification.