TL;DR: SAP’s June 2026 patch day includes 15 Security Notes, with Critical issues in ABAP kernel RFC processing, SAML authentication, and Java directory traversal plus High-priority Commerce Cloud and Tomcat weaknesses that affect externally reachable services, according to Pathlock. The pattern is less about isolated bugs than trust-boundary failures across authentication, runtime validation, and exposed interfaces.
At a glance
What this is: Pathlock's analysis of SAP's June 2026 patch day shows a cluster of Critical and High issues where authentication, runtime validation, and exposed interfaces all weaken core trust boundaries.
Why it matters: IAM, PAM, and NHI teams should treat these SAP notes as governance signals, because trust failures in ABAP, SAML, and customer-facing commerce services can turn patching into an access-control and exposure-management exercise.
Context
SAP patch cycles are not only vulnerability inventories. In this case, the relevant question is where the trusted execution boundary actually sits, because the most serious notes affect RFC processing, SAML authentication, Java request handling, and Commerce Cloud exposure.
For identity and access programmes, that matters because SAP environments often rely on delegated trust, technical users, and federated access paths that assume validation is happening exactly where it should. When those assumptions weaken, patching alone does not restore control.
This article is best read as a governance signal for SAP estates rather than a simple patch bulletin. The recurring issue is that access decisions and trust decisions are being made in components that operators often treat as stable infrastructure.
Key questions
Q: What breaks when SAP trust boundaries are not validated before authentication or request handling?
A: Authentication can succeed while the wrong object, file, or request path is consumed, which means an attacker may cross into trusted processing with less resistance than the system assumes. In SAP estates, that can expose data, corrupt runtime state, or let an unauthorised request become a platform-level issue.
Q: Why do SAML and certificate-based controls create high-impact failure modes in SAP environments?
A: Because they sit at the point where identity or device trust becomes application access. If message binding, certificate state, or validation logic is wrong, the control can appear to work while admitting the wrong principal or accepting stale trust information.
Q: What are the signs that SAP internet-facing services need tighter exposure management?
A: Look for Java Web Container endpoints, RFC services, and commerce services that remain reachable from broad network segments, especially where security patches still require rebuild or redeploy steps. Exposure plus delayed remediation is a strong indicator that trust boundaries are too wide.
A: When the note affects login flows, technical users, federated assertions, or externally reachable services that mediate access to business data. At that point, the issue is not only code health but also who can be trusted to enter, act, or impersonate within the platform.
Technical breakdown
Why unauthenticated RFC kernel flaws become platform-level risk
RFC processing sits deep in SAP NetWeaver ABAP, so a kernel flaw in that path is not a single application defect. It affects how incoming requests are parsed, validated, and handed to lower layers that many business functions depend on. If an unauthenticated attacker can influence kernel memory state, the result can be code execution, a crash, or an integrity failure that crosses multiple applications. That is why kernel-level RFC issues are qualitatively different from user-interface bugs: they sit below many compensating controls and can destabilise the trust base for the entire ABAP instance.
Practical implication: Treat RFC exposure as a boundary control problem, not just a patching task.
How SAML XML Signature Wrapping breaks authentication trust
XML Signature Wrapping exploits a mismatch between what is signed and what the application later consumes. In SAML, the verifier may accept a valid signature while the application uses modified XML content from a different location in the message. That means the signature still looks correct, but the identity assertion no longer matches the signed object the verifier intended to trust. In SAP authentication flows, that is especially dangerous because SAML often anchors portal access, partner access, and single sign-on across connected systems. Once the trust check and the consumed assertion diverge, identity assurance collapses.
Practical implication: Validate that signed assertions are bound to the exact payload the application uses.
Why Java Web Container traversal becomes a perimeter exposure issue
Directory traversal is a path-validation failure. The application receives a request that should stay within a safe directory, but the attacker manipulates the path so the runtime resolves content outside the intended scope. In a Web Container, that can expose files, configuration data, or other resources that were never meant to be reachable through HTTP. The important point is not the file read itself, but what the file reveals about the wider estate. In SAP Java landscapes, that often means credentials, deployment details, or environmental information that supports follow-on compromise.
Practical implication: Audit which Java endpoints are reachable outside trusted network segments and remove unnecessary exposure.
Threat narrative
Attacker objective: The objective is to turn a reachable SAP trust boundary into unauthorized access, broader platform control, or sensitive data exposure.
- Entry begins with direct network reachability to exposed SAP RFC, SAML, Java, or commerce endpoints rather than with a traditional phishing path.
- Credential or trust abuse occurs when an attacker leverages a weak validation path, such as a malformed RFC request or a manipulated SAML assertion, to cross an authentication boundary.
- Escalation follows when the attacker uses the accepted request path to obtain higher trust than intended, reaching data, configuration, or execution surfaces that should have stayed protected.
- Impact appears as platform compromise, unauthorized access, data exposure, or service instability across SAP business processes and customer-facing services.
Breaches seen in the wild
- 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
SAP patch day is exposing a trust-boundary problem, not a patching problem. The cluster of Critical notes shows that authentication, request validation, and runtime safety are failing in places operators often assume are already trusted. When those controls sit inside core SAP paths, the issue becomes governance over where trust is established, not just when software is updated. Practitioners should treat these notes as evidence that boundary validation still needs explicit ownership.
Identity trust in SAP is only as strong as the weakest assertion parser. The SAML issue demonstrates that federated identity controls can fail even when the surrounding login architecture looks mature. A signed message is not enough if the application can be tricked into consuming a different XML object than the one that was signed. The implication is that SAP identity programmes must validate message binding, not merely authentication success.
Runtime exposure and identity exposure now converge in SAP estates. The RFC kernel flaw, the Java traversal issue, and the Commerce Cloud notes all show that externally reachable services can become identity-adjacent attack surfaces. Once an attacker reaches configuration, headers, files, or runtime services, the path to trusted access becomes shorter. Practitioners should stop separating infrastructure patching from identity governance when the platform itself brokers access.
Customer-facing SAP services require a different trust model than internal ABAP systems. Commerce Cloud and Tomcat weaknesses matter because they sit in channels where browser protections, certificate handling, and deployment hygiene directly shape access decisions. That changes the control conversation from hardening a server to proving that externally reachable identity flows still enforce the right state. Teams should align remediation with the trust assumptions of the service, not the convenience of the release cycle.
Identity blast radius expands when technical users and technical controls are left to drift. The article's recurring advice to review exposed services, RFC users, and trust boundaries points to a wider governance issue: technical accounts and technical interfaces are often managed separately even though they fail together. A clean patch state does not mean a clean trust state. Practitioners need to manage the full access path, not just the software version.
What this signals
Trust boundaries need to be managed as a live control surface: SAP estates that still assume kernel validation, SAML parsing, and web container routing are automatically trustworthy will continue to accumulate avoidable exposure. The practical shift is to review where access decisions are actually enforced, then align exposure, patching, and identity controls around those points.
For practitioners, the useful question is not whether the next patch is installed, but whether the platform still accepts traffic, assertions, and technical-user activity from places it should never trust. That is the line between a patched system and a governable one.
For practitioners
- Patch the Critical ABAP kernel and SAML notes first Prioritise the unauthenticated RFC memory-corruption issue and the SAML XML Signature Wrapping issue before lower-severity items, because they affect core trust decisions rather than isolated features.
- Reduce RFC and Java endpoint reachability Limit network exposure for RFC services and Java Web Container endpoints until the fixed notes are deployed, especially where the systems are reachable from untrusted networks.
- Validate SAML message binding Check that the signed assertion is the exact object consumed by the application and confirm that identity handling does not accept modified XML content.
- Review technical RFC users and trust boundaries Inventory the technical accounts and interfaces that can exercise RFC paths, then confirm which of them still have unnecessary access or unmanaged exposure.
- Rebuild and redeploy Commerce Cloud fixes Treat the Commerce Cloud Spring Security and Tomcat notes as deployment issues as well as patch issues, because the corrected state may require rebuild and redeploy work.
Key takeaways
- This patch cycle shows that SAP risk is concentrated where trust is established, not only where code is missing fixes.
- The most serious notes affect core access paths, including RFC processing, SAML authentication, and externally reachable Java and commerce services.
- Teams that only patch binaries without narrowing exposure or validating identity flows will leave the same governance gap in place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0004; TA0040 — Credential Access; Privilege Escalation; Impact | The article centers on trust abuse, authentication bypass, and platform compromise paths. |
| Recommendation — Map exposed SAP attack paths to TA0006 and TA0004, then hunt for requests that cross trust boundaries. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The SAML and certificate issues are authentication and trust-validation failures at access boundaries. |
| Recommendation — Apply API2 thinking to SAP access paths that accept tokens, assertions, or certificate-based trust decisions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The notes involve credential, assertion, and certificate handling across SAP authentication flows. |
| AC-6 — Least Privilege | The article repeatedly warns that technical users and exposed services have more access than they should. | |
| Recommendation — Review authenticator lifecycle controls for SAP technical users, federation, and certificate-based access. Use AC-6 to reduce technical-user and service exposure across RFC, SAML, and commerce paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | The guidance to review technical RFC users and exposed services maps directly to account governance. |
| Recommendation — Apply CIS-5 to inventory and remove unnecessary SAP technical accounts and service access paths. | ||
Key terms
- 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.
- 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.
- Technical RFC User: A technical RFC user is a non-human account used to call SAP Remote Function Call interfaces between systems or components. These accounts often have broad operational reach, so their permissions and network exposure must be governed as part of identity and trust management.
- Runtime validation: A control practice that tests how an AI system behaves while it is connected to real tools and data, rather than only reviewing configuration or design documents. It matters because agentic systems can appear safe on paper and still fail when prompted, chained, or given access to connected services.
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.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org