SAP's CVSS 10.0 SDK Flaw Is the Same Trust Bug That Broke the Bridges
Version 0.53.0 shipped and moved the Destination service module onto new shared token-request code. The validation check that had guarded that module since August 21 did not come along. Six releases later it still had not.
That is the detail worth holding onto, not the score. CVE-2026-89111, disclosed on the October 13 SAP Security Patch Day, lets an attacker hijack OAuth2 token requests in the SAP Cloud SDK for Python by manipulating the tenant_subdomain parameter. The SDK reads the token URL from application configuration, splices in the subdomain value, and posts the client ID and client secret to whatever URL results. Whoever controls that subdomain receives the credentials in transit. No authentication required. Server-Side Request Forgery, CWE-918, CVSS 10.0 out of 10.
Testing reported by The Hacker News found six releases between 0.53.0 and 0.55.0 failing 9 of the 11 tests SAP added with 0.55.1. The fix had been fixed once already, and the second fix silently undid it. That is not a hypothetical; it is a measured regression.
The affected component is not exotic. The SDK handles authentication for multi-tenant SAP Business Technology Platform applications using the client-credentials grant โ a client ID, a client secret, a token endpoint. Multi-tenancy is the default architecture for anything sold as a service: custody dashboards, white-label exchange front ends, RPC providers, portfolio trackers, compliance tooling. Any of those built on BTP inherits this token flow whether or not anyone on the team has read the code.
The timeline matters more than the mechanics. The vulnerable pattern existed from the SDK's first release on PyPI, March 16, 2026. Version 0.45.2, on August 21, added a check rejecting any tenant subdomain that is not a single RFC 1123 label โ letters, digits, hyphens, 63 characters maximum. The release notes filed it under "Bug Fixes." No security language. The formal advisory arrived 53 days later.
Affected range, per the advisory and subsequent testing: 0.36.1 and 0.36.2 on the older line, plus 0.53.0 through 0.55.0. Version 0.55.1, released September 18, restored the check into the shared code. Version 0.58.4, current on PyPI as of October 13, carries it. Applications that cannot upgrade can validate the subdomain against an allowlist of registered tenants before handing it to the SDK.
What broke is more interesting than what leaked. The August patch added validation to three modules: Agent Gateway, Destination, and Document Management Service. In September, Destination migrated onto shared code for requesting tokens. The shared code did not include the check. The security invariant migrated partially โ one module's worth of protection absorbed into a common layer, minus the invariant itself.
That is the same structural failure this desk has logged eleven times since September 26, now sitting inside a vendor's own repository rather than at the identity layer. A system trusts that its components carry a guarantee without verifying that the guarantee survived refactoring. Keycloak masked-secret reuse, Better Auth OAuth state reuse, Frontegg's SAML validation gap, the WorkOS dual-view XML problem, ConnectWise credential abuse โ each one a component assuming a sibling had done the checking. Speed reveals truth; patience reveals value. The value here is that the pattern is now provably recursive: it applies to fixes as readily as to features.
I have spent enough hours inside cross-chain verification code to recognize the shape. LayerZero's verification stack relies on an oracle and a relayer that are trusted to agree; the protocol does not verify that the assertion means what the protocol assumes it means. Bridge exploits in 2022 and 2023 were largely this. The SAP regression is the same error at a smaller radius: not a message passing between chains, but a credential passing between modules.
And the blast radius lands squarely on crypto's least-examined surface โ the off-chain SDKs. A custody provider's BTP tenant is a string an attacker may control. A white-label exchange's per-tenant login page is a string an attacker may control. Nobody audits the client-credentials flow because it is boring, and boring infrastructure is where credentials go to die. On-chain attestation does not cover this. You can verify a proof on-chain all day; the secret that signs the transaction was mailed to a stranger by a Python library that skipped a regex.
The escalation curve is worth stating plainly. Eleven incidents in this sequence, and CVE-2026-89111 is the first 10.0. The previous ten scored lower because they lived in misconfigured defaults, framework logic, or supply-chain credential abuse. This one is foundational tooling โ the layer developers never think to distrust.
If I were auditing a BTP deployment this week, I would not start with the SDK version. I would start with where tenant_subdomain originates. If it arrives from a request parameter, a JWT claim, or a subdomain header, it is attacker-adjacent until proven otherwise, and the version number is secondary. Then I would grep the dependency tree for pinned versions on the 0.36 line, which nobody upgrades because nothing on that line appears to be doing anything important.
Here is the angle nobody is running. The advisory is silent on credential rotation. It does not say whether applications that executed an unchecked release should replace their client IDs and secrets. Every practitioner I know treats that silence as an answer, and the answer they assume is no. In a market that has been chopping sideways for months, where infrastructure teams are already rationing attention, "no confirmed exploitation" becomes "no action required," which becomes the actual vulnerability.
Devil's advocate, properly stated: CVSS 10.0 may be generous. Exploitation requires the application to accept an attacker-supplied tenant subdomain, and plenty of single-tenant deployments hardcode it. Fair. But multi-tenant SaaS is precisely the deployment model where the subdomain is user-controlled by design โ the score is not measuring likelihood, it is measuring a trust assumption being inverted. The August release notes are the more damning artifact. A security fix shipped under "Bug Fixes" is a fix that reached production without reaching the people who needed to schedule around it. Speed reveals truth; patience reveals value โ and 53 days of patience bought the attacker a wider window than the patch closed.
Watch three things. Whether SAP issues rotation guidance, which tells you how the vendor models its own exposure. Whether crypto wallet and custody SDKs publish equivalent regression tests for shared token code โ ask your vendor for the test count, not the changelog. And whether the next 10.0 in this sequence lands on a bridge relayer or an exchange signer rather than a Python package. The next one is already sitting in some repository's "Bug Fixes" section, waiting out its 53 days. Speed reveals truth; patience reveals value.