SAP February 2026 Patch Day exposes trust-boundary failures

At a glance

What this is: Pathlock analyses SAP’s February 2026 Patch Day and shows that the most urgent risks are not isolated bugs but failures in trusted execution paths, identity enforcement and internal service boundaries.

Why it matters: IAM, PAM and NHI teams should treat SAP patching as trust-boundary governance, because low-privilege account abuse, RFC reachability and signed-message handling can turn ordinary access into platform compromise or outage.

By the numbers:

• SAP’s February 2026 Patch Day includes 26 SAP Security Notes.

Context

SAP Patch Day is the recurring monthly release of security notes for SAP products, and February 2026 is notable because several issues land in trusted paths rather than in obvious edge cases. The primary identity and governance concern is that authenticated users, internal services and signed messages are all being treated as trustworthy for too long.

For identity teams, that creates a governance problem rather than a simple vulnerability list. The article’s emphasis on CRM scripting, RFC execution and XML signature handling shows that SAP risk often emerges when access control, service trust and message validation are assumed to be stable after initial authentication.

The article also makes clear that availability matters here, not just confidentiality. BusinessObjects denial-of-service paths and ABAP trust-boundary failures show that patch prioritisation has to account for service continuity, identity assurance and control-plane exposure together.

Key questions

Q: What breaks when SAP authorisation checks fail in RFC paths?

A: When RFC checks fail, a low-privileged authenticated user can trigger remote-enabled operations that were meant to be blocked. That turns integration plumbing into an unauthorised execution path and can expand impact across connected systems. The control that matters most is consistent RFC enforcement across kernel execution scenarios, not just role design on paper.

Q: Why do trusted SAP execution paths create such high risk after authentication?

A: Because authentication does not equal authorization depth. Once a user is inside CRM scripting, RFC or signed-message workflows, the platform may continue to trust that path more than it should. That is why incomplete authorization checks and weak message validation are so dangerous in SAP landscapes.

Q: What are the most important signs that SAP trust boundaries are too wide?

A: Look for privileged admin roles that are shared, RFC destinations that are callable from many systems, scheduler hosts with direct network exposure, and patch fixes that are applied but not verified in production. Those signals show that access and reachability remain broader than the business can safely tolerate.

Q: How should teams respond when SAP systems rely on trusted internal endpoints?

A: Treat them as privileged interfaces, not internal conveniences. Restrict network reachability, require backend-only communication where possible, and validate that the endpoint cannot be reached from user-facing segments. If the trust boundary is visible to ordinary users, it is already too broad.

Technical breakdown

Why trusted SAP execution paths fail first

SAP landscapes often centralise trust into a few execution channels, such as RFC, CRM scripting and web service entry points. Those channels are designed to make business processing efficient, but they also concentrate privilege. When authorization checks are incomplete or inconsistent, a low-privileged authenticated user can move from ordinary application access into higher-impact actions. That is why the article repeatedly points to “trusted plumbing” rather than exotic exploit chains. The security issue is not only code flaws, but the assumption that internal or authenticated paths are inherently safe once a user is inside the system.

Practical implication: treat internal execution channels as privileged attack surfaces and review them separately from normal user-facing application controls.

How RFC authorization enforcement becomes a control-plane risk

Remote Function Call, or RFC, is SAP’s cross-system execution mechanism and behaves like a control plane because it links integrations, background jobs and administrative processes. If S_RFC checks are not enforced consistently, authenticated users can trigger remote-enabled functions without the intended privilege boundary. That matters because RFC is rarely isolated to one system. It connects systems, trust relationships and batch automation across the SAP estate. A flaw here does not just expose one transaction. It can let a low-privilege foothold become system-wide operational manipulation, which is why the article treats RFC reachability as a structural exposure.

Practical implication: validate RFC authorisation behaviour after patching and reduce RFC reachability wherever business process design allows it.

Why XML signature wrapping breaks identity assurance

XML signature wrapping is a message-validation failure where the system verifies one XML element but processes another, attacker-controlled element in the same signed document. In SAP ABAP environments, that becomes especially sensitive when SAML assertions or WS-Security payloads carry identity or authorization attributes. The signature may still validate, but the application can consume altered fields that change who the system thinks the caller is. That is a trust model failure, not just a parsing bug. Once signed identity data can be repackaged this way, federation and web service trust no longer guarantee message integrity at the business logic layer.

Practical implication: inspect signed-message handling as an identity control, not only an application parser issue.

Threat narrative

Attacker objective: The attacker wants to turn a low-friction SAP foothold into unauthorized execution, data compromise or service outage inside trusted business systems.

1. Entry begins with either a compromised low-privileged SAP user or an unauthenticated request to an exposed BusinessObjects endpoint, depending on the affected note.
2. Credentialed abuse or request abuse then targets trusted SAP execution paths such as CRM scripting, RFC execution or signed XML processing where authorization is incomplete.
3. Escalation follows when the attacker uses those trusted paths to trigger unauthorized database actions, remote functions or identity-bearing message manipulation.
4. Impact is platform compromise, service disruption or unauthorized access to customer, operational or reporting data through abused trust boundaries.

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

Trusted execution paths are the real SAP attack surface. The article shows that CRM scripting, RFC and signed XML are not edge cases. They are control-plane surfaces where the system still assumes trust after authentication or signature validation. That assumption is what makes low-privilege abuse so dangerous, because the attacker does not need to defeat the whole platform, only the path that the platform already trusts.

RFC is a governance problem before it is a technical bug. RFC creates a multi-system identity and execution fabric, which means least privilege is only meaningful if every destination, role and execution mode enforces it consistently. When S_RFC checks fail in some paths, the control boundary is no longer deterministic. Practitioners should read this as a warning that trust inheritance across SAP integrations can outgrow the access model that was designed for it.

XML signature wrapping exposes a message-trust boundary failure. The issue is not that signatures disappear, but that identity-bearing data can be rearranged after verification. That breaks the premise that signed content and consumed content are the same object. In federation-heavy SAP environments, that is a direct challenge to message authenticity, not just to web service hygiene.

Availability and integrity are now inseparable in SAP Patch Day prioritisation. The BusinessObjects denial-of-service issues show that internal trust assumptions can be abused for repeated service disruption, while the CRM and RFC issues show how the same trust model can become an integrity and access-control failure. Teams should stop ranking SAP notes only by CVSS and start ranking them by how much trust the affected path inherits.

Identity governance for SAP has to extend into application logic. The article makes clear that role design, authenticated access and signature validation all fail when the system treats privileged business workflows as if they were already trustworthy. The practical conclusion is that SAP access governance cannot stop at provisioning. It has to include execution path review, trust-boundary testing and post-patch verification.

What this signals

Identity assurance in SAP now depends on execution-path review, not just role review. Patch cycles like this one show that a valid account can still be too much access if the application logic, RFC layer or message parser is over-trusted. The practical shift is from asking who can log in to asking which paths can still be invoked without revalidating trust.

Control-plane exposures deserve higher priority than their CVSS score suggests. RFC, CRM scripting and signed XML are the kinds of paths that quietly define how SAP systems behave across modules and integrations. When those paths fail, the blast radius is larger than a single note implies, because the failure can propagate across business processes and identity boundaries.

For practitioners

• Patch the CRM scripting and RFC notes first Prioritise the CRM / S/4HANA Scripting Editor and RFC authorization enforcement corrections before lower-impact defects because both can convert authenticated access into unauthorized execution.
• Disable legacy scripting exposure where possible If the legacy CRM Scripting Editor is not required, remove or disable the SICF service so the vulnerable path is not reachable during the patch window.
• Review S_RFC and trusted RFC destinations Audit which users, service accounts and integrations can invoke RFC-enabled functions, then reduce trusted destinations and broad S_RFC assignments to the minimum needed.
• Treat signed XML handling as an identity control Revalidate SAML and WS-Security message handling in ABAP systems so the verified XML object is the same object the application consumes.
• Segregate BusinessObjects trusted endpoints Block user-network access to trusted backend endpoints, enforce backend-only reachability and monitor repeated authentication failures or restart loops that indicate abuse.

Key takeaways

• The February 2026 SAP Patch Day is fundamentally about trust-boundary failures in control-plane paths such as CRM scripting, RFC and signed XML.
• Pathlock’s analysis highlights 26 security notes, including 2 Critical and 6 High issues, with the highest-risk flaws concentrated in authenticated execution and availability-sensitive services.
• The right response is to patch quickly, shrink reachability and revalidate trusted execution paths as part of SAP identity governance, not as a separate technical afterthought.

Key terms

• Trusted Execution Path: A trusted execution path is a system route that assumes the caller is already authorised once initial access is granted. In SAP, these paths often include RFC, web service, and legacy UI functions. If enforcement is inconsistent, the path becomes a control-plane weakness rather than a normal application feature.
• RFC Authorisation Enforcement: RFC authorisation enforcement is the check that determines whether a user or technical account may invoke remote-enabled SAP functions. It matters because RFC is a cross-system control plane, not just a transport mechanism. Weak enforcement can let low-privileged identities trigger higher-impact backend activity.
• Xml signature wrapping: XML Signature Wrapping is an attack pattern where a signed XML document is altered so the parser validates one node but the application consumes another. It exploits implementation flaws, which is why secure parsing and full-document validation are essential.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

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.