SAP February 2026 Patch Day exposes trust-boundary failures

At a glance

What this is: SAP’s February 2026 Patch Day highlights critical flaws in trusted CRM, RFC, BI, and XML handling paths that can lead to compromise, disruption, or trust-boundary failure.

Why it matters: IAM, PAM, and NHI teams need to treat SAP execution paths as identity-sensitive control planes, because weak authorisation enforcement and over-trusted interfaces can widen blast radius across integrated environments.

By the numbers:

• SAP’s February 2026 Patch Day includes 26 SAP Security Notes, with 2 Critical and 6 High severity issues.

👉 Read Pathlock’s analysis of SAP February 2026 Patch Day trust-boundary failures

Context

SAP’s February 2026 Patch Day shows what happens when trusted application paths become part of the attack surface. In SAP environments, the issue is often not whether a user is authenticated, but whether the platform enforces the right boundary at the right execution point, especially in CRM scripting, RFC, and signed XML handling.

That matters to identity and access teams because SAP routinely spans human users, service accounts, integration credentials, and backend trust relationships. When authorisation checks fail in those channels, the impact is not limited to one application defect; it becomes a control-plane problem for the broader identity programme.

The article is a typical example of a mature enterprise SAP estate where legacy interfaces, broad RFC reachability, and federated identity paths all coexist.

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: When should SAP teams prioritise trust-boundary fixes over other patch work?

A: Prioritise trust-boundary fixes when a flaw can alter identity, invoke backend functions, or break shared availability across systems. In SAP, those issues often create more risk than isolated application bugs because one execution path can affect data, integrations, and downstream service continuity. The presence of a control-plane weakness should move the note up the queue.

Q: What do security teams get wrong about signed XML in enterprise SSO?

A: They often assume that a valid signature means the whole message is safe. In reality, XML Signature Wrapping can leave the cryptography intact while changing which identity-bearing element the application consumes. Teams should test for signature-consumption alignment, especially in SAML and ABAP web service flows where identity data drives access decisions.

Q: Who is accountable when a trusted SAP endpoint can be abused from the wrong network zone?

A: Accountability sits with the teams that own segmentation, application reachability, and SAP interface governance, not just the patch owner. If a trusted endpoint is reachable from user networks or external paths, the trust model has already failed. Security, Basis, and IAM owners need a shared view of which endpoints are privileged system interfaces.

Technical breakdown

CRM Scripting Editor code injection and generic function calls

The CRM Scripting Editor issue is dangerous because it turns a low-privileged authenticated action into access to generic function module execution. In practice, the weakness is not just input handling, but that the application logic does not sufficiently constrain which backend functions can be invoked through the web UI. Once an attacker reaches that path, the boundary between application user and database-level action collapses. This is why CRM web tooling must be treated as a privileged execution surface, not a normal end-user feature.

Practical implication: remove or tightly restrict the legacy Scripting Editor service and re-check who can invoke CRM scripting-related functions.

RFC authorisation enforcement gaps in SAP kernel paths

RFC is a control plane for SAP because it moves work between systems, users, and background processes. The defect described here is an authorisation enforcement failure, where S_RFC checks are not consistently applied in certain execution scenarios. That means an authenticated low-privileged user can trigger remote-enabled operations that should have been blocked. In integrated SAP landscapes, this is especially serious because RFC trust and permissive roles often accumulate over time, turning one bypass into broad process manipulation.

Practical implication: validate RFC destinations, trusted relationships, and S_RFC assignments after patching, especially where background RFC or cross-system automation is common.

XML signature wrapping in ABAP web services and SAML flows

XML Signature Wrapping breaks the assumption that the signed element and the consumed element are the same thing. A verifier can validate one XML node while the application consumes another, attacker-controlled node inside the same document. In ABAP web services and SAML-adjacent flows, that can turn a valid signed message into a vehicle for identity substitution or privilege confusion. This is a trust model failure, not a simple parsing bug, and it matters whenever federated identity meets signed payload handling.

Practical implication: review ABAP web services and SAML-facing paths for signature-consumption mismatches and treat signed XML as identity-bearing input.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted SAP execution paths into unauthorised control over data, processes, or identity-bearing transactions.

1. Entry occurs when an attacker gains valid low-privileged access to CRM, RFC, or a signed-message path that the system already trusts.
2. Escalation follows when the attacker abuses weak authorisation enforcement, generic function invocation, or signature wrapping to cross an intended boundary.
3. Impact lands as database compromise, process manipulation, service disruption, or impersonation-like access depending on the affected SAP component.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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

NHI Mgmt Group analysis

Trusted execution paths are the real identity perimeter in SAP. This Patch Day shows that the most dangerous failures are not always in authentication itself, but in the application and kernel paths that assume trusted execution once a session exists. RFC, CRM scripting, and signed XML all sit inside that perimeter. For identity teams, the lesson is that SAP authorisation is not just about who logged in, but which execution paths can still be reached after login. The practitioner conclusion is to treat SAP trust boundaries as first-class identity controls.

Generic authorisation checks are too weak for control-plane SAP functions. The RFC finding illustrates a familiar governance gap: a permission model that exists on paper but fails under specific runtime execution paths. That is the kind of defect that makes privilege reviews look healthier than the platform really is. In an enterprise landscape where RFC is used for integrations, batch work, and administrative tooling, inconsistent enforcement can silently widen blast radius. The practitioner conclusion is to re-evaluate any SAP control that depends on a single access check to protect multi-system execution.

Signed XML handling is an identity assurance problem, not just a message-validation problem. The XML wrapping issue shows that federated identity breaks when the system trusts the wrong element in a signed transaction. That undermines the basic assurance model behind SAML and WS-Security because the message can remain cryptographically valid while the consumed identity context changes. This is especially relevant where SAP sits behind an enterprise IAM stack. The practitioner conclusion is to test not only signature validity, but whether the application consumes the same identity-bearing content that was signed.

Legacy SAP interfaces create identity blast radius when they remain broadly reachable. BusinessObjects DoS and CRM web exposure reinforce the same field-level problem: over-trusted internal endpoints become externally reachable attack surfaces once network segmentation is loose. That does not require a new authentication flaw to become serious. It only requires a service that assumes the caller is already safe. The practitioner conclusion is to inventory every SAP endpoint that functions as a privileged trust anchor and reduce its reach before prioritising the next patch cycle.

Patch prioritisation in SAP should be driven by trust boundary failure, not CVSS alone. The article correctly places emphasis on the functions that can alter database state, bypass kernel checks, or disrupt shared services. That is the right governance lens for SAP estates because a medium-severity issue in a control-plane path can outrank a higher-score issue in a narrow component. The practitioner conclusion is to prioritise fixes that compromise authorisation enforcement, signed identity handling, or shared availability first.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to our Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, which is why trust-boundary failures often persist after the original issue is identified.
• The 52 NHI breaches Report provides the incident patterns that help teams distinguish exposed credentials from broader control-plane compromise.

What this signals

Trusted control planes are becoming the weakest part of SAP identity programmes. As SAP estates mix human users, technical accounts, and federated identity, the governance question is no longer whether login is strong enough. The question is whether the platform still enforces the right boundary after login, especially across RFC and signed-message flows. Teams should map privileged SAP interfaces to the same scrutiny they already apply to crown-jewel service accounts and publish a clear owner for every trust anchor.

Identity blast radius is the right concept for SAP patch prioritisation. A flaw that changes authorisation, backend execution, or shared service availability should be treated differently from a narrow UI defect. That means patch queues should reflect control-plane exposure, not just CVSS or module criticality. For practitioners, the operational signal is simple: if an issue can change what the system trusts, it deserves fast-track handling.

Service accounts and integration paths need the same lifecycle discipline as human access. SAP programmes often separate user governance from technical access, but the attack paths in this Patch Day do not respect that distinction. Offboarding, role review, and reachability control need to cover RFC users, support users, and any identity that can reach an internal trust anchor. The practical implication is to unify lifecycle review across human and non-human access rather than treating them as separate problems.

For practitioners

• Tighten SAP CRM scripting access immediately Disable the legacy Scripting Editor service if it is not operationally required, and reduce access to CRM scripting-related functionality to a minimal admin set. Review whether standard agent roles can still reach paths that should be reserved for support staff.
• Revalidate RFC trust and S_RFC assignments After applying the kernel fix, inspect trusted RFC destinations, background RFC usage, and permissive S_RFC roles for cross-system reachability that exceeds business need. Focus on integration users and technical accounts that can trigger remote-enabled functions.
• Test signed XML consumption, not just signature acceptance Review ABAP web services and SAML-connected flows to confirm the application consumes the same XML element that was signed. Treat any mismatch between verified content and processed identity data as a remediation priority.
• Separate privileged SAP interfaces from user networks Place BusinessObjects trusted endpoints, RFC paths, and other internal trust anchors behind strict segmentation and backend-only access controls. If the endpoint is meant for system-to-system traffic, do not leave it reachable from general user zones.
• Re-rank SAP patching by blast radius Prioritise fixes that affect identity trust, kernel enforcement, and shared service availability before lower-impact defects. Use the operating question, can this issue change who the system trusts, to decide sequence rather than relying on severity score alone.

Key takeaways

• SAP’s February 2026 Patch Day is really about trust-boundary failure, not just a collection of bugs.
• The most dangerous issues let authenticated users cross execution boundaries, while unauthenticated DoS paths threaten shared reporting services.
• Teams that own SAP identity, Basis, and network segmentation should patch, reduce reachability, and re-check every trusted execution path now.

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 technique where a message keeps a valid signature but the application consumes a different XML element than the one that was signed. In identity flows, that can create a mismatch between cryptographic proof and the data actually used for access decisions.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and processes that can be affected when one identity or trust path fails. It is a useful way to rank SAP and IAM issues because a small-looking flaw can cascade across integrations, shared services, and privileged back-end functions.

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: SAP’s February 2026 Patch Day analysis. Read the original.