SAP September patch wave exposes Java RCE and credential leaks

At a glance

What this is: Pathlock's September SAP patch roundup highlights two critical Java flaws, a re-released ABAP traversal issue, and a Business One credential exposure that all point to control failures around access and interface hardening.

Why it matters: IAM and PAM teams should read this as a reminder that patch cadence, exposed administrative surfaces, and credential handling are intertwined, especially where enterprise platforms mix application, database, and OS-level privileges.

Context

SAP's September security notes show how quickly platform patching becomes an identity and access problem when privileged interfaces, upload paths, and backend credentials are in play. In environments like NetWeaver, Business One, and S/4HANA, the practical question is not only whether the code is fixed, but whether exposed ports, upload rights, and account protections were already too permissive.

For identity teams, the pattern is familiar: high-severity vulnerabilities often become worse when operational access is broad, privileged users are over-trusted, or backend secrets can surface in traffic. This article is about the controls that fail first when SAP estates depend on both application hardening and access governance.

The September set is a typical enterprise patch scenario, but the mix of Java RCE, traversal, credential leakage, and authorization bugs makes it a strong example of how identity-adjacent controls determine blast radius.

Key questions

Q: What breaks when SAP patches are applied but exposed interfaces stay open?

A: The fix can still be bypassed in practice if high-risk interfaces remain reachable from broad network zones or untrusted users. In SAP environments, exploitability depends on both the code correction and the surrounding access boundary. If the boundary stays permissive, RCE, upload abuse, or traversal can still become operational compromise.

Q: Why do exposed SAP service ports and deployment paths increase compromise risk?

A: Because they turn application bugs into reachable execution paths. When P4, deployment services, or similar interfaces are available too widely, an attacker does not need privileged local access to reach code execution, file overwrite, or executable upload behavior. The control failure is excessive trust in the interface itself.

Q: What are the signs that SAP credential handling is failing?

A: Look for secrets appearing in HTTP responses, backend logs, support tickets, or integration traces, especially when those secrets belong to database or service accounts. Any case where a business application reveals credentials should be treated as a credential lifecycle failure, not only as a disclosure bug.

Q: How should teams prioritize SAP fixes after a patch wave like this?

A: Start with vulnerabilities that expose execution, secrets, or destructive actions through reachable interfaces, then move to medium-severity issues that affect business workflows. Prioritization should follow exploitability and blast radius, not CVSS alone, because broad privileges and exposed services make certain flaws far more damaging.

Technical breakdown

NetWeaver AS Java RCE and exposed service interfaces

CVE-2025-42944 and CVE-2025-42922 both show how exposed service interfaces turn application bugs into infrastructure-level compromise. In the first case, crafted traffic to the P4 interface can reach remote code execution, which means the service boundary effectively becomes an execution boundary. In the second, low-privilege users can abuse the Deploy Web Service to upload executables, so the trust model around upload and deployment is already broken before patching. The technical issue is not just code defects, but unauthenticated or weakly controlled entry points into privileged runtime paths.

Practical implication: treat P4 exposure and deployment rights as security-critical assets, not routine application settings.

ABAP traversal and privileged file overwrite risk

The ABAP directory traversal issue re-released in CVE-2023-27500 matters because it converts application reach into filesystem control. When a program such as SAPRSBRO can write outside its intended directory boundary, attackers can overwrite OS files and move from business logic into host impact. Re-release notes are especially important operationally, because they signal that earlier remediation may have been incomplete or not uniformly deployed. The control problem here is path validation plus runtime restrictions around a program that should not retain broad file-writing authority.

Practical implication: verify that affected ABAP components are disabled or corrected everywhere they still have filesystem reach.

Credential leakage and authorization failures in SAP business processes

The Business One issue is a classic example of a backend service exposing database credentials in HTTP responses, which creates immediate reuse risk across other systems. The S/4HANA and LT replication bugs show a different but related failure mode: insufficient validation lets privileged users delete arbitrary tables, so authorization checks exist in name but not in practice. These flaws are identity-adjacent because the damage depends on who can reach the function, what privileges the backend trusts, and whether secrets or destructive actions are insulated from routine business traffic.

Practical implication: rotate any exposed credentials and re-test destructive functions against least-privilege assumptions, not just patch status.

Threat narrative

Attacker objective: The attacker aims to convert trusted SAP interfaces and leaked credentials into host compromise, destructive data access, or durable operational disruption.

1. Entry begins through exposed SAP interfaces such as P4 or Deploy Web Service, where crafted requests or low-privilege access reach privileged code paths.
2. Credential access emerges when a backend response leaks database credentials or when weak controls let attackers operate with more trust than intended.
3. Escalation follows as RCE, file overwrite, or arbitrary table deletion turns application reach into OS-level or data-layer impact.
4. Impact is system compromise, data destruction, or broader operational disruption across SAP-managed business processes.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-adjacent SAP vulnerabilities fail first at the interface boundary. The article's critical issues are not random code defects. They cluster around exposed service endpoints, deployment paths, and backend responses, which is where access governance and application security overlap. That means patch management alone does not contain the blast radius unless interface exposure, privilege scope, and secret handling are also tightened.

Persistent administrative trust is the hidden amplifier in enterprise SAP estates. When low-privilege users can upload executables, privileged users can delete arbitrary tables, or backend services can surface credentials, the real failure is excessive trust in operational paths. This is a classic least-privilege problem at system level, not just account level. Practitioners should read the September wave as evidence that SAP risk often lives in who can trigger an action, not only in whether the code path is patched.

Control validation has to move from patch presence to exploitability conditions. A fixed note does not matter if P4 remains exposed, deployment remains broad, or destructive functions remain reachable by more accounts than necessary. This is where NIST-CSF access control and OWASP-NHI-style trust assumptions meet practical SAP governance. The practitioner conclusion is simple: validate the control boundary, not just the correction status.

Credential exposure in SAP business workflows is a non-human identity event, even when the application is the source. The Business One issue demonstrates that secrets embedded in backend responses are still credential lifecycle failures. Once those credentials are exposed, the account that receives them becomes a machine identity risk immediately. That makes rotation, scoping, and offboarding part of the patch response, not a separate hygiene task.

September's SAP mix shows why security teams must connect platform patching to identity governance. RCE, traversal, and credential leakage are different flaws, but they converge on the same operational question: which identities and interfaces are allowed to touch privileged functions? The answer determines whether a vulnerability is a contained bug or a business outage.

What this signals

Identity governance has to be part of SAP patch triage. When enterprise application flaws expose runtime execution, backend secrets, or destructive business actions, the right response is not only faster patching. Teams need to verify which accounts, ports, and deployment paths made exploitation possible in the first place, then narrow those boundaries before the next cycle.

Interface exposure is the common failure pattern. P4 access, web-service upload paths, and backend responses all become risk multipliers when they are reachable from more than the minimum required set of users and systems. For SAP estates, the practical signal is that identity and network boundaries are still too generous if a flaw can turn into host impact so quickly.

For practitioners

• Lock down exposed Java service ports Restrict P4 access and similar NetWeaver service endpoints until the latest fixes are deployed, then confirm only approved administrative networks can reach them.
• Tighten deployment and upload rights Review who can use the Deploy Web Service and remove low-privilege paths to executable upload or runtime deployment in J2EE environments.
• Disable or correct vulnerable ABAP file-write paths Apply the ABAP traversal corrections everywhere SAPRSBRO or similar report paths still have filesystem reach, and verify the program is no longer usable for arbitrary overwrite.
• Rotate credentials exposed in backend responses Treat leaked database credentials as compromised immediately, rotate them, and confirm no other services reused the same secret material.
• Re-test destructive authorizations in S/4HANA and LT Validate that only explicitly approved privileged roles can delete tables or trigger replication-related destructive actions, and remove inherited access that is broader than necessary.

Key takeaways

• SAP's September security notes show that interface exposure, deployment rights, and backend credential handling can turn ordinary patch issues into high-impact compromise paths.
• The article combines two critical Java flaws, an ABAP traversal re-release, and a credential disclosure issue, which together demonstrate how quickly SAP trust boundaries can collapse.
• The best response is to patch, restrict exposed services, rotate any leaked credentials, and re-check who can reach destructive functions before the next maintenance cycle.

Key terms

• SAP Interface Exposure: SAP interface exposure is the condition where service ports, upload endpoints, or backend responses are reachable from more actors than the environment intended. In practice, it turns ordinary application flaws into exploitation paths because the boundary controlling who can touch the function is too permissive.
• Credential Leakage: Credential leakage occurs when secrets such as tokens, passwords, API keys, or certificates are exposed outside approved storage or transmission paths. In CI/CD environments, this can happen in source code, logs, build output, or environment variables. Once leaked, credentials can be reused quickly for lateral movement or unauthorized deployment access.
• Privilege Scope: Privilege scope is the set of actions, data, and tools an identity is allowed to use. For AI agents, scope must be defined around the task and the acceptable blast radius, because broad or persistent privileges can turn a small mistake into a production-level incident.
• Exploitability Gap: The exploitability gap is the difference between a security finding and a working attack path. A control may detect or report exposure, but if the environment allows an attacker to chain that exposure into privilege gain or data access, the risk is operational rather than theoretical.

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 building or maturing an IAM programme, it is worth exploring.