SAP S/4HANA code injection exposes the limits of low-privilege trust

At a glance

What this is: This is a critical SAP S/4HANA code injection vulnerability that can let a low-privilege account escalate to full system control through vulnerable RFC paths.

Why it matters: It matters because SAP often sits at the centre of finance, operations, and supply chain workflows, so identity controls, patch discipline, and RFC governance all become part of the blast-radius problem.

By the numbers:

• CVE-2025-42957 is a critical (9.9) SAP S/4HANA Code Injection Vulnerability allowing an attacker with low user privileges to take full control of an organization’s SAP system.
• SAP released fixes on August 12, 2025 for Note 3627998 and, if SLT/DMIS is in scope, Note 3633838.
• Pathlock Research Lab telemetry has detected outlier activity consistent with exploitation attempts of CVE-2025-42957.

👉 Read Pathlock's analysis of CVE-2025-42957 and SAP S/4HANA code injection

Context

CVE-2025-42957 is a code injection problem in SAP S/4HANA, where a request reaching a vulnerable RFC path can be used to inject ABAP and escalate from a basic account to broad control. The identity lesson is simple: low privilege does not matter if the execution path itself is trusted too much.

Because SAP often carries core financial, supply chain, and operational workflows, a compromise is not just an application issue. It becomes an identity and governance problem for the organisations that rely on service access, authorisation design, and privileged change control around the SAP estate.

Pathlock’s article frames the issue as urgent because exploitation is already being observed in the wild and SAP says patching is the only effective remediation. That makes this a classic case of a control boundary failing at the intersection of application logic, RFC exposure, and operational identity governance.

Key questions

Q: What breaks when SAP RFC modules are reachable by low-privilege users?

A: A low-privilege account can become a code execution path when a remote-enabled function module accepts injected ABAP. The caller’s entitlement level stops being protective because the module boundary is doing the real trust work. That is why RFC scope and module allowlisting matter as much as user roles in SAP governance.

Q: Why do SAP code injection flaws create such large identity risk?

A: They let an ordinary user leverage application trust to cross into privileged execution without first compromising an admin account. In SAP, that can affect business processes, not just technical settings. The risk grows when authorisation design, callback trust, and remote function exposure are treated as separate problems.

Q: What do security teams get wrong about patching SAP vulnerabilities?

A: They often treat patching as an infrastructure task instead of a control-state change. In a system like SAP, a known code injection flaw leaves the environment operationally exposed until the note is applied and verified everywhere. Patch status should be managed as part of identity and access governance for the platform.

Q: Who is accountable when an unpatched SAP injection flaw is exploited?

A: Accountability usually spans SAP platform owners, security operations, and the teams governing privileged access and change control. If RFC exposure, patch verification, and authorization review are split across functions, no one owns the full blast radius. That makes governance alignment as important as technical remediation.

Technical breakdown

How RFC reachability turns a low-privilege account into code execution

The exploit chain starts when a network-reachable RFC module accepts crafted input that should never have been executable by a basic user. In SAP, RFCs are remote-enabled function modules, so the risk is not just access to a screen or transaction. It is access to code paths that can call ABAP logic directly. Once the vulnerable function is reachable, the attacker does not need elevated identity first. The privilege inversion happens because the application trusts the module boundary more than the caller identity.

Practical implication: reduce RFC exposure with allowlists and UCON so low-privilege identities cannot reach high-risk function modules.

Why ABAP injection becomes privileged control inside SAP

ABAP injection is dangerous because SAP application logic often sits close to business authority. If an attacker can alter code flow or execute injected logic, they may create reports, change destinations, or pivot into admin-level actions without needing a separate admin account. That is why the flaw is more than a software bug. It is a trust failure in how execution and authorisation are separated. Once arbitrary ABAP runs, the attacker can use SAP-native capabilities to extend control inside the environment.

Practical implication: review S_RFC permissions and callback controls for any destination that can reach sensitive business modules.

Why patching is the only real containment path here

Pathlock states there is no effective workaround, which means compensating controls can reduce exposure but cannot remove the vulnerable code path. That matters for identity teams because the boundary is not just authentication or authorisation. It is the executable trust surface inside the SAP stack. When vulnerable code remains present, even a correctly provisioned user can become a launch point for compromise. In other words, the control failure is structural, not merely procedural.

Practical implication: treat patch verification as a governance control, not just an infrastructure task, and confirm coverage across all clients and systems.

Threat narrative

Attacker objective: The attacker aims to convert ordinary SAP user access into administrator-level control over the SAP system and, potentially, adjacent operating-system actions.

1. Entry occurs when an attacker uses a low-privilege SAP account to reach a vulnerable RFC module exposed over the network.
2. Escalation happens when the attacker injects ABAP through the vulnerable path and turns basic access into privileged SAP execution.
3. Impact follows when the attacker uses the resulting control to steal data, create backdoors, manipulate business processes, or stage ransomware.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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

NHI Mgmt Group analysis

Low privilege is not a meaningful safety boundary when the execution path is trusted more than the caller. CVE-2025-42957 shows that SAP identity assumptions can fail even when the user account itself is ordinary. The real problem is that a reachable RFC path can convert basic access into code execution before conventional privilege controls ever matter. Practitioner implication: identity governance has to account for trusted execution surfaces, not just user entitlements.

RFC exposure is a governance issue, not only an application hardening issue. Remote-enabled function modules create a control surface that sits between IAM, application security, and SAP administration. When allowlists are too broad and callback trust is too permissive, the organisation has created an identity-to-code bridge that attackers can cross with minimal access. Practitioner implication: governance teams need to treat RFC scope as part of privilege design.

Patch delay turns a known code path into a standing attack condition. Pathlock says the exploit exists in the wild and SAP’s notes are the only effective remediation, which means unpatched landscapes are not merely outdated, they are operationally exposed. That is a lifecycle failure in the broadest sense: the vulnerable state persists until the change is applied. Practitioner implication: remediation status must be tracked as a control state, not a ticket status.

Identity blast radius in SAP is defined by business reach, not by account tier. A low-privilege user on a central ERP system can still affect financial, supply chain, and operational processes if the application boundary is weak. That makes SAP a high-consequence identity environment even before an attacker gains administrative access. Practitioner implication: teams should prioritise the systems where identity abuse can touch the most business logic.

Standing trust in callback and destination settings creates the wrong kind of persistence. When RFC callback security and destination trust are left broad, the organisation preserves execution pathways that attacker-controlled code can reuse. This is a failure mode of trust inheritance, where one permitted action silently opens a larger control surface. Practitioner implication: review whether destination trust and callback permissions are narrower than the business function actually requires.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to the 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to the same report.
• For a wider breach pattern view, see The 52 NHI breaches Report for how exposed credentials and standing trust repeatedly turn into operational compromise.

What this signals

RFC governance is becoming a first-class identity control. SAP landscapes concentrate business authority, so a flaw like CVE-2025-42957 should push teams to map every remote-enabled execution path to an owner, an approval path, and a patch verification state. The operational question is no longer whether SAP is authenticated, but whether its trusted execution surface is actually bounded.

The broader signal is that low-privilege access on a central platform can still produce enterprise-scale impact when application trust and identity governance are misaligned. That means access reviews alone are not enough. Teams also need to understand which destinations, callbacks, and module paths can silently expand privilege through the back door.

Identity blast radius: when a core business system can be reached through a narrow but trusted execution path, the control objective shifts from user restriction to business-function containment. That is why SAP hardening, patch validation, and privilege scoping now belong in the same programme conversation. Practitioners should align this work with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 where remote trust paths intersect with identity-controlled execution.

For practitioners

• Patch SAP S/4HANA immediately Apply SAP Note 3627998 for CVE-2025-42957 and, where relevant, Note 3633838 for SLT/DMIS. Confirm patch coverage across every client and system, then verify that the vulnerable code path is removed rather than merely suppressed.
• Restrict RFC reachability to the smallest viable module set Use UCON and RFC allowlists to expose only approved remote-enabled function modules. Remove broad access to sensitive destinations and review whether any user, technical account, or trusted connection can still reach execution paths that should be closed.
• Review S_RFC and callback trust as one control surface Check S_RFC permissions, RFC callback allowlists, and rfc/callback_security_method together so a permitted destination cannot become a code execution path. Pay special attention to modules and destinations that support business-critical ABAP execution.
• Hunt for pre-patch abuse indicators Search for anomalous RFC_PING usage, unexpected report or program creation, new admin users, and destination or trust-setting changes. If the environment is still unpatched, treat those signals as possible exploitation attempts rather than routine administrative activity.

Key takeaways

• CVE-2025-42957 shows that a low-privilege SAP account can still become a full-control pathway when RFC trust is too broad.
• Pathlock says exploitation attempts are already visible and SAP’s August 2025 notes are the only effective remediation, which raises the urgency of patch verification.
• The control that matters most is not just user privilege, but the combination of RFC exposure, callback trust, and verified patch state.

Key terms

• Remote-enabled function module: An SAP function that can be called remotely through RFC rather than only inside the local application context. These modules become security-critical when they expose business logic or code execution paths that a low-privilege user should never be able to reach directly.
• RFC callback trust: The permission model that governs whether an SAP system accepts callback activity during remote function calls. If it is too broad, an allowed destination can become a larger execution path than the business case requires, creating a hidden privilege expansion route.
• ABAP injection: The insertion of malicious or attacker-controlled ABAP into a code path that should only process trusted logic. In practice, this can turn an application flaw into privileged execution, report creation, or process manipulation inside the SAP environment.
• Identity blast radius: The amount of business, technical, and operational damage a compromised identity can cause once trust is abused. In SAP environments, blast radius is often defined less by the user’s role and more by which function modules, destinations, and callbacks remain reachable.

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 covering CVE-2025-42957 in SAP S/4HANA. Read the original.