Dominic Jainy has built a distinguished career at the intersection of emerging technologies, specializing in the delicate architecture of cloud infrastructure and application security. With a deep background in artificial intelligence and machine learning, he brings a unique perspective to how automated systems and software development kits can inadvertently create catastrophic security gaps. Today, he joins us to discuss a critical vulnerability within the SAP Cloud SDK for Python, a flaw so severe it earned the highest possible risk rating. Our conversation explores the mechanics of credential theft in multi-tenant environments, the surprising regression of security patches across different software versions, and the broader implications of how organizations manage high-stakes security disclosures in a cloud-first world.
How can an attacker leverage a multi-tenant application’s failure to validate subdomains to steal sensitive credentials?
The core of this vulnerability lies in a fundamental breach of trust during the authentication handshake. When a multi-tenant application passes a tenant subdomain to the SDK, the system is designed to request an access token specifically for that tenant by modifying a pre-configured URL. However, because the SDK failed to validate these subdomains, an attacker could inject URL delimiters to redirect the entire request. Instead of the SDK communicating with a legitimate SAP service, it silently routes the application’s client ID and client secret—its digital keys to the kingdom—directly to a server the attacker controls. This is a textbook example of a server-side request forgery (SSRF), where a trusted server is tricked into sending sensitive data to an unintended and malicious destination. It is a chilling scenario because the developer might believe they are following standard OAuth2 protocols, while the underlying SDK is essentially handing over credentials on a silver platter.
What happened during the rollout of the fixes that led to some versions remaining vulnerable despite the initial patch?
It was a frustrating case of security regression where a fix was implemented but then accidentally bypassed in subsequent updates. The initial fix was introduced in version 0.45.2 on August 21, which added a critical check to ensure tenant subdomains were simple names. However, when the development team moved the Destination service module onto new shared code for token requests in version 0.53.0, that protective check was left out of the new logic. This meant that versions 0.53.0 through 0.55.0, released between September 10 and September 18, were once again wide open to credential theft when calling specific modules. It highlights how easily a “secured” gate can be left swinging open when code is refactored or shared across different services without a rigorous re-testing of security parameters. Even the Document Management Service in version 0.55.0 was missing this validation, proving that security is never a “set it and forget it” task in complex cloud ecosystems.
Given the complexity of these versions, how can developers verify if their current SDK environment is truly secure?
Verification requires a very granular look at the version history because the path to a secure state was not a straight line. Developers need to understand that the fix wasn’t just missing in older versions, but also in specific “pockets” of newer releases due to the regressions we discussed. For instance, testing against the source code showed that versions 0.53.0 to 0.55.0 failed 9 of the 11 security tests that SAP eventually finalized. The only way to be certain is to ensure you are running version 0.55.1 or higher, such as version 0.58.4, which was the most current release as of mid-October. Any version on the older 0.36 line, including 0.36.1 and 0.36.2, is fundamentally unsafe because those releases never received the subdomain check at all. If a developer cannot upgrade immediately, they must manually test their input; if passing a subdomain with URL delimiters doesn’t trigger an immediate ValueError, the application is likely leaking data.
For those unable to upgrade their systems immediately, what manual safeguards can be implemented to protect their tenant data?
If you find yourself in a position where an immediate upgrade is blocked by internal dependencies, you have to step in and act as the manual gatekeeper for the SDK. SAP’s primary recommendation is to implement a strict validation layer that compares every incoming tenant subdomain against a pre-approved list of your own registered tenants. You should write a validation function that rejects any input that isn’t a simple name—specifically, it must be limited to letters, digits, and hyphens, and it cannot exceed 63 characters in length. This prevents any malicious delimiters from ever reaching the SDK’s internal URL construction logic. While it adds a layer of maintenance to keep that tenant list updated, it is a necessary shield to prevent an SSRF attack from succeeding. It’s about creating a “zero trust” environment at the application level until the underlying infrastructure can be properly patched.
Why is the timing of this disclosure and the nature of the “bug fix” particularly significant for the cybersecurity community?
The timeline of this event is quite revealing because there was a significant 53-day gap between the release of the fix in August and the formal security advisory in October. In the initial August release notes, the fix was buried under general “Bug Fixes” and described merely as a correction for “malformed URLs,” with no mention of the potential for OAuth2 credential theft or the CVSS 10.0 rating. This kind of “silent patching” can be dangerous because it doesn’t give security teams the urgency they need to prioritize an update. Many organizations might have looked at those notes and decided to delay the update, unaware that they were sitting on a critical vulnerability for nearly two months. It underscores a persistent tension in the industry between wanting to fix bugs quietly to prevent exploitation and the need for transparent disclosure so that users can accurately assess their own risk.
What is your forecast for cloud SDK security?
I anticipate that the next few years will see a massive shift toward “secure-by-default” URL construction where SDKs no longer treat external inputs as trusted components of a request path. We are moving away from the era where a simple string check is enough; instead, I expect to see cloud providers integrating cryptographic identity checks directly into the SDK’s internal routing. We will likely see more automated regression testing suites that specifically target SSRF vulnerabilities, ensuring that if a check is added in version 0.45, it cannot be accidentally omitted in version 0.53. The “ping-pong” nature of this specific SAP flaw will serve as a landmark case study for why shared code modules need their own independent security audits. Ultimately, the industry will have to move toward more transparent, real-time disclosure protocols to close the dangerous 50-day windows that currently leave so many enterprises exposed.