TL;DR: CVE-2025-42957 is a critical SAP S/4HANA code injection flaw that lets a low-privilege user reach vulnerable RFC paths and take full control, with SAP fixing it in August 2025 and Pathlock reporting exploitation attempts in telemetry. The incident shows that privilege level alone is not a safety signal when network-reachable execution paths remain open.
At a glance
What this is: This is an analysis of CVE-2025-42957, a critical SAP S/4HANA code injection flaw that allows low-privilege access to become full system control through a vulnerable RFC path.
Why it matters: It matters because SAP privilege design, RFC exposure, and patch timing all affect whether a basic account can become an enterprise-wide control break in core business systems.
Context
CVE-2025-42957 is a code injection problem in SAP S/4HANA, where a low-privilege account can reach a vulnerable remote-enabled function and inject ABAP into execution. The issue matters to SAP security and identity teams because access level alone does not tell you whether execution paths are actually safe.
Pathlock says the exploit is already in the wild and that unpatched organisations remain exposed until SAP's August 2025 fixes are applied. The governance problem is not just authorisation, but whether remote execution routes stay reachable to identities that were never meant to cross from user access into administrative control.
For SAP programmes, this is a classic case of privilege trust being too coarse. A user may look low-risk on paper while still retaining a path to sensitive runtime behaviour, which is why RFC surface reduction and patch coverage both belong in the control model.
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: How should SAP security teams respond when RFC exposure meets low-trust identities?
A: They should treat RFC reachability as an identity governance issue, not just an application setting. The practical question is which identities can reach remote-enabled functions, whether callbacks are constrained, and whether those paths can still be abused after patching. That is how exposure becomes measurable.
Technical breakdown
How RFC-reachable code injection turns user access into execution
SAP remote function calls, or RFCs, let systems invoke ABAP-capable modules across a network boundary. When a vulnerable remote-enabled function remains reachable, a low-privilege user can supply input that is interpreted as executable code rather than treated as ordinary data. The problem is not that the account is powerful at login, but that the execution path behind the login is powerful once reached. In SAP environments, that distinction matters because the trust boundary is the function module, not the role name attached to the user.
Practical implication: review which remote-enabled function modules remain reachable from low-trust identities and remove unnecessary exposure.
Why low privilege does not equal low impact in SAP S/4HANA
In enterprise SAP landscapes, a basic user can still interact with business logic that bridges into administrative actions if the underlying module is unsafe. Once arbitrary ABAP runs, the attacker is no longer constrained by the original user role, because the code execution context can inherit far broader system abilities. That is why the article frames CVE-2025-42957 as a code injection issue rather than a conventional authorisation flaw. The control failure sits in execution reachability, not just in permission granularity.
Practical implication: treat role reviews as insufficient unless they are paired with execution-path validation and RFC hardening.
Why patching and RFC surface reduction are linked controls
SAP's August 2025 fixes remove the vulnerable code path, but that only closes the specific flaw. If RFC allowlists, callback security, and destination controls remain loose, the environment can still expose other remote execution paths that make the same trust assumption fail elsewhere. In other words, patching is necessary for this CVE, while RFC governance determines whether similar weaknesses stay reachable in future. The article's mitigation advice reflects that layered reality.
Practical implication: pair patching with RFC allowlisting and callback hardening so remote execution paths cannot stay broadly reachable.
Threat narrative
Attacker objective: The attacker aims to turn basic user access into full SAP and potentially OS-level control over a business-critical enterprise system.
- Entry occurs through a low-privilege SAP account that can reach a vulnerable RFC module exposed over the network.
- The attacker injects ABAP through the reachable function path and gains code execution in the S/4HANA context.
- Execution can escalate into administrator-level control, followed by persistence, credential harvesting, or business-process manipulation.
- The end state is full compromise of the SAP system and the ability to pivot into operating system-level actions and ransomware deployment.
Breaches seen in the wild
- SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.
- SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.
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
Low privilege is not a meaningful safety boundary when execution paths stay open. In SAP environments, the dangerous object is often the reachable function module, not the nominal user role. That distinction matters because the attacker does not need elevated identity if the code path itself can be abused. Practitioners should treat user privilege and execution reachability as separate governance questions, not a single control outcome.
Execution-path trust is the real weakness this CVE exposes. CVE-2025-42957 shows that an RFC path can turn an ordinary account into a system-level actor when the module accepts executable input. The same logic applies across complex enterprise platforms: if remote execution is reachable, role design alone cannot prove safety. The implication is that SAP governance must test runtime pathways, not just authorisation matrices.
Remote function governance needs the same discipline as privileged access governance. Once low-trust identities can touch sensitive RFC routes, the environment has effectively created an unreviewed bridge from access to control. This is not just a vulnerability-management problem, but a lifecycle and exposure-management problem. Practitioners should regard RFC reachability as part of the identity attack surface, not merely an application detail.
Patch dependence is a signal of structural exposure, not just vendor response time. The article is explicit that no effective workaround exists, which means organisations cannot compensate for exposure with policy alone. That creates a hard operational truth for SAP programmes: when a flaw sits in a network-reachable execution path, remediation timing becomes a business-risk variable. Security teams should treat patch coverage as control-state evidence, not an afterthought.
Identity blast radius in SAP is determined by code reachability plus business centrality. SAP S/4HANA is not just another application, so a flaw that crosses from basic access into execution has outsized governance impact. The named concept here is identity blast radius: how far a compromised account can move once runtime trust breaks. For practitioners, that means SAP exposure analysis must combine access scope, RFC surface, and business criticality in one model.
What this signals
Identity blast radius is the useful lens here: the same account that looks low-risk in a role catalogue can become a high-impact actor if it reaches a vulnerable execution path. For SAP programmes, that means entitlement reviews must be paired with runtime-path reviews, or the control model will keep missing the real escalation route.
Patch dependency is also a governance signal. When a flaw has no effective workaround, the organisation's risk posture is determined by how quickly patch state becomes control state across every system and client, not by how clean the role design appears on paper.
For practitioners
- Patch the affected SAP notes immediately Apply Note 3627998 for S/4HANA and, where relevant, Note 3633838 for SLT or DMIS. There is no effective workaround, so any delay preserves reachable exploit paths.
- Reduce RFC exposure with allowlists Use UCON and RFC allowlists to keep only necessary remote-enabled function modules reachable. Remove broad remote execution paths that low-privilege users should never be able to touch.
- Harden RFC callback security Review callback behaviour in SM59 and enforce a secure RFC callback security method so callback abuse does not remain a viable escalation route.
- Review sensitive S_RFC access Reassess S_RFC permissions on destinations and remote-enabled function modules, especially where those paths can reach administrative or transport-related behaviour.
- Hunt for exploitation patterns now Look for anomalous RFC_PING usage, unexpected ABAP report creation, new admin users, changed trust settings, and other signs of post-exploitation activity.
Key takeaways
- CVE-2025-42957 shows that low-privilege SAP access can still become full system control when a reachable RFC module accepts injected code.
- Pathlock says exploitation attempts are already visible in telemetry, which makes unpatched S/4HANA systems an active exposure rather than a theoretical one.
- The control that matters most is not role trimming alone, but closing the vulnerable code path and narrowing RFC reachability so remote execution cannot be abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The flaw turns nominally low-privilege access into far broader system control. |
| NHI-06 — Insecure Cloud Deployment Configurations | The article focuses on exposed remote function paths and insecure runtime exposure. | |
| Recommendation — Treat low-trust SAP accounts as potentially high-impact if they can reach remote execution paths. Review exposed SAP execution surfaces and remove unnecessary remote reachability. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is undermined when execution paths exceed the intended user role. |
| Recommendation — Apply least-privilege reviews to both user permissions and reachable function paths. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The attack path uses low access to reach code execution and then escalate control. |
| Recommendation — Map SAP exploitation patterns to credential access and privilege escalation detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SAP entitlements must be evaluated alongside the execution paths they unlock. |
| Recommendation — Validate that permissions do not open unauthorized execution paths in SAP. | ||
Key terms
- Protocol Reachability: The set of network paths through which an identity can interact with a service. In identity security, reachability matters as much as authentication because a valid credential is still dangerous if the service is broadly exposed and not limited by task, host, or time.
- Code Injection: Code injection is a vulnerability where attacker-controlled input is interpreted as executable instructions. Instead of being treated as data, the input changes program behaviour, allowing actions such as database reads, shell commands, script execution, or unsafe object reconstruction.
- Execution-Path Exposure: Execution-path exposure is the risk that a credential or sensitive action becomes dangerous because it is used inside an attacker-influenced workflow. The secret may be valid, but the path it takes can still hand control to an adversary. This is a runtime identity problem, not only a storage problem.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
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.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org