SAP September patch wave exposes Java RCE and credential leaks

At a glance

What this is: Pathlock’s roundup highlights SAP’s September 2025 patch set, led by two critical Java stack flaws, a re-released ABAP issue, and a credential exposure in Business One.

Why it matters: For IAM and security teams, the article shows how application, platform, and privileged-access failures converge into identity risk across NHI, human admin, and workload paths.

By the numbers:

• SAP’s September 9 release brought 21 new Security Notes and 3 updates.
• The severity snapshot lists 2 new critical issues, 4 high issues, 14 medium issues, and 3 low issues.
• CVE-2025-42944 is rated CVSS 10.0.
• CVE-2025-42922 is rated CVSS 9.9.

👉 Read Pathlock's September SAP vulnerability roundup

Context

SAP’s September patch cycle shows how quickly application flaws become identity and access problems when they touch privileged interfaces, file upload paths, or credential-bearing backend services. In practice, the risk is not limited to code execution. It includes the ability to turn a supported enterprise platform into a launch point for further access, data movement, or account abuse.

For identity programmes, the lesson is that patch management, privileged access controls, and secrets hygiene have to move together. When low-privilege users can reach an upload path, a database credential can be returned in an HTTP response, or a backend service can be coerced into remote execution, the control failure is operational as much as technical.

Key questions

Q: What breaks when SAP application flaws expose privileged interfaces?

A: When privileged SAP interfaces are exposed, the flaw stops being just an application issue and becomes an access-control problem. Attackers can move from web or middleware entry points into code execution, file overwrite, or backend trust abuse. The practical risk is that application hardening, port restriction, and privilege review all have to happen together, not as separate tasks.

Q: Why do SAP credentials exposed in backend responses create broader identity risk?

A: A credential exposed in an HTTP response is no longer confined to its intended service boundary, so it behaves like a compromised identity asset. That matters because database and service credentials often have standing access that is broader than a human user’s privileges. Once leaked, they can be replayed quickly and silently across dependent systems.

Q: How should teams reduce risk from SAP patch notes that affect file upload or host overwrite paths?

A: Teams should treat file upload and host overwrite flaws as control-plane issues, not isolated bugs. The right response is to patch, then verify who can invoke the affected functions, what file locations are writable, and whether the platform still allows executable content or state-changing actions from lower-privilege roles.

Q: Who is accountable when enterprise SAP vulnerabilities are left unpatched?

A: Accountability sits across application owners, infrastructure teams, and identity governance because the exposure spans code, access, and privileged operations. For regulated environments, patching alone is not enough if access remains overly broad or secrets are not rotated. The control failure belongs to the operating model, not just the software vendor.

Technical breakdown

RMI-P4 remote code execution on SAP Java

The RMI-P4 interface in NetWeaver AS Java exposes a remote method invocation path that can be abused if crafted payloads reach the service. When that interface accepts attacker-controlled input, the issue is not just application compromise. It becomes a path to operating-system-level code execution because the Java application server and its underlying host are tightly coupled at the trust boundary. Hardening the JVM and restricting the exposed port reduces the attack surface, but the real issue is that a privileged middleware interface was reachable in the first place.

Practical implication: treat exposed middleware ports as identity-bearing attack surfaces and remove unnecessary P4 access before the patch window closes.

Deploy Web Service file upload and privilege bypass

The Deploy Web Service flaw matters because it collapses the normal assumption that only trusted administrators can place executable content onto the server. In this case, a low-privilege user can abuse the upload path to introduce files the platform should have rejected. That turns an administrative function into an execution primitive. Temporary workarounds help, but the core risk is that a deploy path becomes a privilege boundary failure rather than a simple validation bug. File handling in enterprise application servers must be treated as a control plane issue, not just a web application concern.

Practical implication: restrict deploy functions to tightly controlled admin groups and verify that upload paths cannot be used as execution channels.

ABAP traversal, overwrite potential, and downstream platform control

The re-released ABAP note addresses a directory traversal condition in SAPRSBRO that can be abused to overwrite OS files. That is more serious than a path bug because it changes the integrity of the host itself. Once an attacker can reach file overwrite primitives, the application layer no longer contains the blast radius. SAP’s decision to disable the program after correction signals that the safe operating model depends on removing the vulnerable execution path, not just patching around it. For administrators, this is a reminder that legacy ABAP utilities can still alter the security posture of the whole environment.

Practical implication: inventory ABAP utilities that can write to the host and remove or disable them where the business process no longer justifies the risk.

Threat narrative

Attacker objective: The attacker aims to move from application access into host control, credential theft, or destructive actions that can disrupt core enterprise processes.

1. Entry occurs through exposed SAP middleware or web service interfaces that accept crafted requests or uploads.
2. Escalation follows when the flaw turns that request into executable code, file overwrite, or privileged backend access.
3. Impact is achieved through OS-level code execution, credential exposure, or arbitrary data deletion inside enterprise SAP systems.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Middleware trust boundaries are identity boundaries, not just application boundaries. When an enterprise platform exposes a privileged interface like P4 or a deploy path, the security question is who can reach it and what that access can trigger. The flaw in this release set is that trusted application functions were reachable in ways that bypassed the controls practitioners assumed were already protecting them. For NHI and privileged-access teams, the implication is that platform interfaces must be governed as sensitive access paths, not treated as ordinary application endpoints.

Credential exposure in an enterprise backend becomes an NHI problem the moment secrets leave their intended storage boundary. The Business One issue shows that a database credential exposed in HTTP responses is not just a leak, it is an identity failure. Once a service credential is visible outside its control plane, the environment loses the distinction between authenticated service behavior and attacker-replayed access. That is the kind of failure OWASP-NHI and zero-trust governance are meant to prevent, but only if secrets are treated as operational identities with lifecycle and exposure controls.

Standing administrative trust creates the blast radius that attackers look for in SAP environments. The most dangerous part of this patch wave is not the existence of flaws, but the fact that some of them become severe only because privileged paths remain broadly reachable. A low-privilege upload flaw, a host overwrite condition, or an auth bypass turns into enterprise impact when there is too much persistent access around the system. This is where PAM, IGA, and NHI governance intersect: the same patch can have very different outcomes depending on how much standing privilege still surrounds the affected service.

Patch severity is not the same as operational priority, and identity teams should read SAP notes through that lens. The article’s own ordering shows that the Java issues are the headline risks, but the credential exposure and deletion bugs can be equally disruptive in day-to-day operations. That matters because identity programmes often focus on authentication events while missing application-layer actions that alter accounts, files, or database trust. Practitioners should treat these notes as a reminder that access scope, service credentials, and platform hardening all contribute to the real attack surface.

Derived concept: privileged platform interface exposure. SAP’s September notes show how a routine enterprise service becomes a security boundary failure when admin-grade functions are reachable from broader networks or lower-privilege users. That concept is useful because it links application vulnerability management to identity governance, especially where service accounts, backend credentials, and administrator workflows overlap. The practical conclusion is that platform exposure should be reviewed as part of identity risk, not after the patch cycle alone.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That visibility gap is compounded by the fact that 38% have no or low visibility and a further 47% have only partial visibility, according to the same report.
• For a wider view of how these identity gaps turn into breaches, see the 52 NHI breaches Report.

What this signals

Privileged platform interface exposure is the right mental model for this patch wave. When application middleware, deploy functions, or response paths can be reached outside intended trust boundaries, the identity problem is no longer limited to authentication. Teams should review privileged interfaces as part of their access model, not just their vulnerability backlog.

The control signal is not patch volume, it is whether sensitive functions are still reachable from broad networks or low-privilege roles after remediation. If they are, the enterprise has only reduced exploitability at the margin. Identity, PAM, and platform teams need a shared view of which SAP functions behave like administrative identities in practice.

The September notes also reinforce how quickly a backend credential can become an operational incident once it appears outside the intended storage boundary. That is why service-account governance, secrets rotation, and response logging need to be linked. For practitioners, the next step is to map SAP backend credentials to the same lifecycle discipline used for other non-human identities.

For practitioners

• Restrict high-risk SAP interfaces immediately Lock down P4 ports, Deploy Web Service access, and any other privileged middleware entry points until the affected notes are fully patched and validated.
• Separate patching from privilege review Apply the Java, ABAP, Business One, IBM i, and S/4HANA fixes, then verify which users and service accounts can still reach the affected functions.
• Rotate secrets exposed through backend responses Treat any credential disclosure in HTTP responses as an active identity compromise and rotate the affected database credentials immediately.
• Reassess ABAP utilities with file system reach Inventory programs that can overwrite OS files or alter host state, and disable legacy components where the platform no longer needs that capability.
• Fold medium-severity control gaps into the next review cycle Use the medium and low issues to clean up authorisation checks, UI5 exposure, and XSS paths so they do not accumulate into larger access risk.

Key takeaways

• SAP’s September security notes show that middleware and deploy-path flaws can turn ordinary enterprise functions into identity and access failures.
• The strongest evidence of risk is not just the two critical Java flaws, but also credential exposure and file overwrite paths that can change host-level trust.
• Practitioners should patch quickly, then verify interface exposure, rotate leaked secrets, and tighten who can invoke privileged SAP functions.

Key terms

• Privileged platform interface: A privileged platform interface is an administrative or backend function that can change system state, execute code, or expose sensitive data. In SAP environments, these interfaces matter because they sit at the boundary between application logic and host-level trust, making exposure a direct access-control risk.
• Credential exposure in responses: Credential exposure in responses occurs when secrets, tokens, or database credentials are returned in application output instead of remaining in secure storage. For identity governance, this is effectively a compromised non-human identity because the secret can be replayed outside its intended lifecycle and control boundary.
• Host overwrite primitive: A host overwrite primitive is an application flaw that lets an attacker write or replace files on the underlying operating system. That capability can change executables, configuration, or scripts, which means the defect crosses from application vulnerability into system integrity risk.
• Standing administrative trust: Standing administrative trust is persistent privileged access that remains available whether or not it is actively needed. In SAP and other enterprise systems, it widens the blast radius of a vulnerability because exposed functions and always-on privileges combine into faster escalation paths.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pathlock: SAP’s September security notes and critical vulnerability roundup. Read the original.