SAP patch day exposes RFC code injection risk across core systems

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pathlock's report: SAP's August 2025 patch day includes three CVSS 9.9 code injection flaws that can let low-privilege RFC access become arbitrary ABAP execution and broad system compromise.

Why it matters: IAM, PAM, and SAP platform teams need to treat RFC exposure as an authorization boundary, because application trust assumptions can collapse into privilege escalation, data exposure, and operational takeover.

By the numbers:

• SAP released 15 new Security Notes and 4 updates in the August 12, 2025 Patch Day.

Context

SAP’s August 12, 2025 Patch Day is a governance problem as much as a patching event. When RFC-exposed function modules can accept attacker-controlled input, the issue is not just vulnerable code, but the trust boundary that lets low-privilege access become execution inside core SAP systems.

For IAM and PAM teams, this is a reminder that SAP authorisation is not only about who can log in. It is also about which RFC paths remain callable, which transformation modules are reachable, and whether privilege checks still hold once integration traffic reaches ABAP runtime.

The article centres on S/4HANA, Landscape Transformation, SAP Business One, and NetWeaver components. That makes the starting position typical for large SAP estates, where integration convenience often outpaces boundary 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 RFC code injection flaws create such a high SAP compromise risk?

A: Because the injected content can execute inside trusted ABAP processing rather than a sandboxed front end. When execution happens in a privileged backend context, confidentiality, integrity, and availability all move at once. The risk is especially high where transformation services already sit close to business-critical data flows and elevated privileges.

Q: How can security teams tell whether SAP RFC access is too broad?

A: Look for RFC paths that are reachable by low-privilege identities, transformation modules callable outside their expected business role, and role design that assumes trusted callers. If a user or service can trigger administrative or code-executing functions without a strong business justification, the RFC boundary is already too open.

Q: Should organisations patch first or rework SAP RFC authorisation first?

A: Patch first for immediate exposure reduction, but do not stop there. If RFC authorisation remains broad after remediation, the same structural weakness persists and the next flaw can reuse it. The practical answer is to patch urgently while also re-scoping callable RFC functions and reviewing the authorisation concept behind them.

Technical breakdown

RFC-exposed function modules as execution boundaries

Remote Function Call, or RFC, is SAP’s interface for invoking backend functions across systems. In a secure design, RFC should expose only tightly controlled business logic, not arbitrary execution paths. The vulnerabilities in this patch cycle matter because input reaching RFC function modules can be processed inside privileged ABAP contexts, which means a low-privilege caller may influence code paths that were never intended to be externally reachable. Once that boundary is crossed, the problem is no longer simple input validation. It becomes runtime trust in a function interface that can execute with more authority than the caller should have.

Practical implication: treat RFC exposure as a privileged control surface and review every externally reachable module for abuse paths.

How code injection becomes ABAP takeover

Code injection in SAP is especially dangerous because ABAP runs inside the application layer that governs business data and transactions. If an attacker can place controlled input into a function module that later interprets it as executable logic, the result can be remote ABAP execution rather than a narrow application error. That changes the blast radius from a single transaction to the broader SAP runtime. In these cases, the real failure is the combination of over-trusted input, reachable execution entry points, and business logic that assumes callers are already authorised for the action being performed.

Practical implication: validate which RFC paths can reach executable ABAP logic and remove any caller assumptions that are not enforced at the edge.

Why transformation layers amplify privilege escalation

Landscape transformation and analytics layers are attractive targets because they sit between source and target systems, often with elevated access to move or reshape data. When those layers accept malicious input through RFC interfaces, the attacker is not merely probing a peripheral service. They are using a trusted integration plane to obtain higher privilege inside the SAP estate. That is why the article’s three CVSS 9.9 issues are not isolated bugs. They are examples of the same architectural condition: a transformation boundary that is callable, privileged, and too trusting of the request origin.

Practical implication: harden transformation layers as privileged integration services, not as ordinary application endpoints.

Threat narrative

Attacker objective: The attacker aims to convert reachable RFC access into privileged ABAP execution and control of core SAP systems.

1. Entry occurs through RFC-exposed function modules that accept attacker-controlled input in S/4HANA, Landscape Transformation, and Analytics components.
2. The attacker injects arbitrary ABAP code or malicious logic, turning low-privilege access into execution inside trusted application workflows.
3. Privilege escalation follows because the injected code runs with the authority of the backend service rather than the original caller.
4. Impact can include full system compromise, confidentiality loss, integrity loss, and broader operational disruption across the SAP landscape.

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.

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

RFC trust is the real control plane in SAP estates: These flaws are not just patchable code defects, they expose a governance assumption that RFC callers are already sufficiently trusted. That assumption fails when low-privilege access can reach executable ABAP paths. The implication is that SAP programmes must treat RFC reachability as an authorisation decision, not just an integration detail.

Transformation layers create identity amplification risk: Landscape Transformation and analytics services often hold more effective power than the identities that invoke them. When a callable service can reshape data or trigger execution with elevated authority, the identity in front of it is no longer the only security question. Practitioners need to understand where execution authority accumulates across the integration chain.

Privilege escalation in SAP often begins before authentication looks broken: These CVEs show that a session can be legitimate and still become dangerous if the function exposed to it interprets input as code. That shifts focus from user logon controls to runtime access governance, especially for RFC endpoints and ABAP-executing services.

ABAP execution exposure is a named concept that teams should track: When business logic and execution logic are reachable through the same interface, the boundary between data handling and code execution collapses. Teams should treat that as a distinct risk class in SAP threat modelling, because the control failure is not generic vulnerability management but excessive trust in callable runtime paths.

Emergency patching only works if authorisation boundaries are re-reviewed: The August patch cycle is a reminder that fixed vulnerabilities do not automatically restore governance. If RFC exposure remains broad, the same structural condition persists after patching. Practitioners should use this class of issue to re-evaluate how SAP integration privileges are scoped and reviewed.

What this signals

RFC entry points deserve the same scrutiny as administrative interfaces: In SAP estates, integration convenience can hide privilege concentration, so the right control question is who can invoke which backend function, not just who can log on. When RFC access is broad, patching reduces one exploit path but does not remove the underlying trust problem.

ABAP execution exposure should be treated as a distinct SAP risk class: These flaws show how ordinary-looking integration calls can become code execution paths inside core business systems. That is a governance signal for IAM, PAM, and SAP platform teams to model callable runtime logic as a privileged asset, not an application detail.

For practitioners

• Restrict RFC-exposed function modules Inventory every externally reachable RFC path in S/4HANA, SLT, and analytics components, then remove or lock down modules that do not need broad caller access.
• Revalidate SAP authorisation concept controls Review SACF rules and custom role mappings so low-privilege users cannot invoke transformation or administrative functions through integration interfaces.
• Patch the CVSS 9.9 issues first Prioritise CVE-2025-27429, CVE-2025-42950, and CVE-2025-42957 before routine maintenance windows because they enable code injection into core SAP runtime paths.
• Monitor for abnormal ABAP execution patterns Alert on unusual RFC call volume, unexpected ABAP runtime behaviour, and transformation-module access that does not fit normal business workflows.
• Segment high-value SAP integration paths Place extra network and access controls around transformation and analytics endpoints so one compromised caller cannot pivot into broader SAP control planes.

Key takeaways

• RFC-exposed SAP functions can turn low-privilege access into arbitrary ABAP execution if the callable boundary is too trusting.
• The August 12, 2025 patch cycle includes three CVSS 9.9 code injection issues in S/4HANA, Landscape Transformation, and Analytics.
• Restricting RFC reachability and re-scoping SAP authorisation rules are the controls that matter most for limiting blast radius.

Key terms

• RFC-exposed function module: An RFC-exposed function module is a remotely callable SAP routine that can be reached from another system or service. In identity terms, it is a high-value execution boundary because access to the module can become access to trusted business logic if authorization and input validation are weak.
• ABAP Code: ABAP code is the custom application logic used to extend or modify SAP systems. Because it can change business behaviour, it must be governed like production software. Security teams should review it for unsafe logic, unauthorized access paths, and controls that prevent unapproved changes from reaching live environments.
• Authorization Boundary: The authorization boundary is the defined scope of systems, identities, and dependencies that must satisfy a compliance programme. In FedRAMP, it determines what the assessor evaluates and what must be documented as external, so boundary accuracy is a control decision, not a paperwork exercise.
• Transformation layer: A transformation layer is the part of an application stack that moves, reshapes, or prepares data between source and target systems. In SAP, these layers can hold elevated access, so compromise there often has outsized impact compared with ordinary application endpoints.

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.