SAP Patches Maximum

SAP has released a fix for a maximum-severity vulnerability in its Cloud SDK for Python that could allow remote attackers to steal application credentials, placing the security of multi-tenant cloud integrations under scrutiny.

Tracked as CVE-2026-89111 , the OAuth2 server-side request forgery flaw carries a published severity score of 10.0 . SAP identifies versions of the sap-cloud-sdk package earlier than 0.45.2 as affected, with the corrected release available now. The company’s security advisory describes an authentication vulnerability affecting multi-tenant applications on SAP Business Technology Platform, or BTP.

The disclosure leads a broader October patch release spanning cloud development tools and enterprise applications. In its October 2026 Security Patch Day bulletin , SAP lists 16 new security notes, four GitHub security advisories and two updates to previously issued notes.

How the Credential-Theft Flaw Works

The vulnerable flow uses a parameter named tenant_subdomain when constructing an OAuth2 token URL. An attacker able to control that value can cause the application to send its token request to a server the attacker operates, exposing client credentials.

SAP’s fix validates the parameter against RFC 1123 DNS-label rules before inserting it into the URL. For applications that cannot be upgraded immediately, the company recommends checking tenant values against an allowlist of registered tenant subdomains before passing them to SDK calls.

The advisory describes network-based exploitation requiring neither prior privileges nor user interaction. It does not report an active exploitation campaign. That absence should not be interpreted as proof that no exploitation has occurred.

Why Application Credentials Matter

The potential consequences extend beyond disclosure of a single authentication request.

Under the OAuth 2.0 authorization framework , confidential clients can authenticate to an authorization server when requesting access tokens. In the client-credentials flow, the application acts using its own authorization rather than relying on an interactive user login.

This makes the distinction between a client secret and an access token important. A token represents a particular authorization and may expire. A valid client credential can potentially be used to request additional tokens, subject to the authorization server’s policies and the permissions granted to that client.

For an affected deployment, the practical impact would therefore depend on the services the application can access, its assigned privileges and any additional controls. Credential exposure should not automatically be described as unrestricted access to every connected SAP system.

The relevant business question is what an attacker could do while impersonating the affected application. That requires examining its permissions, rather than relying solely on the vulnerability’s severity score.

A Dependency That May Sit Inside Custom Applications

SAP’s project documentation describes the SDK as its official Python client for BTP services. It provides interfaces for authentication, configuration and secrets handling, alongside capabilities covering destination management, object storage, audit logging and other services.

The project also includes functionality for AI applications and agents, including AI Core integration, agent memory and an agent gateway. This broad role makes dependency visibility especially relevant: security teams need to establish which internally developed applications include the package.

An inventory should extend beyond centrally managed SAP servers. Python services, containers, background jobs and application build pipelines may have separate owners and release schedules.

The operational implication is that a software-library fix needs to reach the running application. Updating a dependency declaration is only one step; teams should also confirm that rebuilt and redeployed workloads actually contain the corrected package.

Other Critical Fixes Broaden the October Workload

The October bulletin identifies three additional critical vulnerabilities:

These issues involve different attack conditions and should be assessed individually. Their inclusion in the same release does not establish a combined attack chain.

For Visual Composer, the National Vulnerability Database entry identifies insufficient authorization checks in portal functionality. Its published vector describes a network-accessible attack requiring low privileges, with potentially severe effects on confidentiality, integrity and availability.

That prerequisite matters when prioritizing exposure. An authenticated vulnerability still warrants urgent attention, particularly where accounts are widely available or where compromised credentials could provide the required access.

S/4HANA Rule Processing Can Become a Code-Execution Path

The S/4HANA issue illustrates how a business configuration feature can become security-sensitive.

According to Spain’s CCN-CERT vulnerability bulletin , the affected rule-definition functionality does not adequately validate input processed through a domain-specific scripting language.

An authenticated attacker with the necessary business privileges could submit crafted input that the application interprets as executable ABAP code. Successful exploitation could compromise the affected system.

This is a different exposure from an anonymous internet attack. Assessment should include which users hold the relevant business permissions, how those accounts are protected and whether rule changes are reviewed.

The required remediation is documented in SAP Security Note 3805589 . Organizations should use the note to establish applicability and implementation requirements for their installed systems.

Manufacturing Software Flaw Crosses an Administrative Boundary

The Manufacturing Integration and Intelligence vulnerability concerns the separation between application administration and control of the underlying server.

CCN-CERT’s description states that an attacker who already holds MII administrator privileges could issue a crafted request to create an account with elevated privileges on the underlying Java application server.

The risk is an expansion of authority: access intended for administering one application could be used to gain broader system control. This is why existing administrator access does not make the weakness inconsequential.

Organizations should consult SAP Security Note 3798788 , while reviewing administrative account ownership and unexpected account-provisioning activity.

Defensive Controls Should Address Outbound Requests

The SDK disclosure also highlights the importance of controlling where an application sends sensitive information.

OWASP’s SSRF prevention guidance recommends layered protection through application validation and network controls. Where destinations are known, allowlisting can restrict communication to approved targets.

For authentication services, the destination is part of the security boundary. Protecting inbound application traffic is insufficient if attacker-influenced input can alter an outbound request carrying credentials.

Network restrictions can provide an additional safeguard, but they need to reflect legitimate service dependencies. Organizations should assess outbound access carefully and test changes against required authentication flows.

These are broader defensive measures, rather than evidence that any particular SAP customer has suffered a compromise.

What Organizations Should Do

A practical response should coordinate application developers, SAP administrators, identity teams and security operations:

Identify deployed exposure. Check application dependencies and running workloads, then map affected services to accountable owners. Deploy and verify fixes. Rebuild and redeploy affected applications, checking the installed package in the runtime rather than only the source repository. Assess credential exposure. Where suspicious activity or credible exposure is identified, rotate affected secrets and review associated authorizations. Investigate relevant telemetry. Examine unexpected outbound authentication traffic, unusual service-client activity and unexplained administrative changes. Prioritize the wider release. Evaluate each critical issue against installed components, access requirements and business impact. Record completion evidence. Track successful deployment, remaining exceptions and the owners responsible for unresolved exposure.

Identify deployed exposure. Check application dependencies and running workloads, then map affected services to accountable owners.

Deploy and verify fixes. Rebuild and redeploy affected applications, checking the installed package in the runtime rather than only the source repository.

Assess credential exposure. Where suspicious activity or credible exposure is identified, rotate affected secrets and review associated authorizations.

Investigate relevant telemetry. Examine unexpected outbound authentication traffic, unusual service-client activity and unexplained administrative changes.

Prioritize the wider release. Evaluate each critical issue against installed components, access requirements and business impact.

Record completion evidence. Track successful deployment, remaining exceptions and the owners responsible for unresolved exposure.

These steps are operational recommendations based on the disclosed failure modes. They are not a claim that exploitation has been observed in a particular environment.

For executives, the immediate requirement is a clear account of affected applications, the access their identities hold and when remediation will be complete. That connects the patching effort to the business services and data that need protection.