SAP patch day exposes two CVSS 10.0 flaws in core infrastructure

At a glance

What this is: Pathlock’s analysis of SAP’s September 2026 patch day shows a concentrated set of unauthenticated, network-reachable flaws in kernel, cluster, and Commerce Cloud components, including two CVSS 10.0 issues.

Why it matters: This matters because SAP security teams cannot treat core infrastructure patching as slower back-end hygiene when unauthenticated flaws can deliver full compromise without credential theft.

By the numbers:

• SAP released 19 new Security Notes and updated 14 previously issued ones for the September 2026 Patch Day, 33 notes in total.
• Seven of the 33 notes carry HotNews severity, and two of those seven score a full 10.0.

Context

SAP patch governance is not only about application teams. When flaws land in kernel-level request handling, cluster trust services, or shared commerce components, the exposure spans multiple products and deployment models at once. For SAP environments, that changes the control problem from isolated remediation to core infrastructure resilience, including how quickly patches are tested, approved, and deployed across landscapes.

The primary risk in this article is unauthenticated compromise of SAP core infrastructure, which creates a direct identity and access governance problem even when no human or non-human credentials are stolen first. Once an attacker can execute code or join a cluster as a trusted node, access control, session trust, and downstream privilege boundaries all start from a broken assumption.

In practical terms, this is not a one-off product issue. Pathlock’s analysis shows a patch cycle where the most severe findings sit in the layers every SAP estate depends on, which makes accelerated kernel and cluster patching a standing governance requirement rather than an exception.

Key questions

Q: What breaks when SAP infrastructure flaws are reachable before authentication?

A: When a kernel path, dispatcher, or cluster broker is reachable before authentication, the attacker bypasses the normal identity gate entirely. The result is not just a vulnerability in one component but a collapse of the trust boundary that separates anonymous traffic from privileged internal execution. That is why pre-auth SAP flaws demand platform-wide containment, not just local patching.

Q: Why do unauthenticated SAP cluster flaws create such broad risk?

A: Because cluster components often treat membership as proof of legitimacy. If a rogue node can register or a malformed request can reach shared processing, the attacker inherits trust that was meant for internal systems only. That makes the risk broader than account compromise, because the attacker can pivot through infrastructure assumptions instead of stealing credentials first.

Q: What are the signs that SAP Commerce Cloud exposure is wider than the product team expects?

A: Watch for internal adapter paths that are routed through proxies, published beyond the backoffice boundary, or reachable from places they were never meant to be exposed. In this article, risk depends on whether the Data Hub Adapter path is actually reachable, not only whether the code is present. Exposure drift is the warning sign.

Q: How should teams decide whether to patch SAP core infrastructure before application notes?

A: Patch the components that sit on the trust path first, because if the kernel or Message Server is compromised, every application above it inherits the problem. Application fixes matter, but they do not change the fact that pre-authentication compromise of shared infrastructure can override downstream controls. Prioritise shared services before product-specific defects.

Technical breakdown

Pre-authentication request processing in the SAP kernel

SAP kernel flaws in request processing matter because the kernel sits underneath multiple business applications and handles traffic before application-layer controls can help. In this patch cycle, the vulnerability sits in deserialisation of Extended Passport data, where an externally supplied length field is trusted too early. That is a memory-safety failure in a core path, not an isolated module bug, and it can lead to process crash or code execution before authentication. In identity terms, the system is vulnerable before it even evaluates whether a caller should exist at all.

Practical implication: Patch kernel and Web Dispatcher levels as infrastructure controls, not as application maintenance tasks.

Cluster trust and Message Server registration

The Message Server acts as the trust broker for distributed SAP landscapes. Application server instances register with it, and the cluster then uses that registration for load balancing, logon groups, and internal communication. If the registration path does not sufficiently verify legitimacy, a rogue node can present itself as a trusted cluster member. That turns a network-positioned attacker into an internal actor with inherited trust, which is a classic trust-boundary failure rather than a simple authentication bug.

Practical implication: Restrict cluster registration paths and treat any weakness in Message Server trust as a landscape-wide governance issue.

Commerce Cloud exposure through routed adapter endpoints

SAP Commerce Cloud’s Data Hub Adapter issue shows a different mechanism: unauthenticated code execution becomes possible only when a normally internal endpoint is made reachable by routing or deployment choices. The technical lesson is that exposure is not purely a software property. It is also a consequence of how an endpoint is published, proxied, and permissioned. That makes cloud and platform teams part of the control chain, because an internal-only component can become externally reachable through architecture drift.

Practical implication: Validate which SAP Commerce Cloud endpoints are actually reachable in production and align exposure reviews with deployment changes.

Threat narrative

Attacker objective: The attacker’s objective is to gain full control of SAP infrastructure or a trusted cluster position without valid credentials, then use that foothold to execute code and pivot into business systems.

1. Entry occurs through a network-reachable SAP kernel, Message Server, or Commerce Cloud endpoint that should not accept unauthenticated hostile input.
2. Credential harvest is not required because the attacker abuses pre-authentication trust and, in the cluster case, can register as a rogue node.
3. Escalation happens when the attacker gains code execution or trusted cluster position, allowing them to act with the privileges of the service or application server.
4. Impact includes full compromise of SAP infrastructure, unauthorized actions inside the application environment, and potential exposure of business data and administrative controls.

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

Core SAP infrastructure now needs identity-style governance, not just patch hygiene. The most severe issues in this cycle sit in the kernel, Message Server, and commerce integration layers, which means the control failure is at the trust boundary, not only in the application code. When those components are exposed pre-authentication, every downstream access decision inherits a broken starting point. Practitioners should treat patch cadence, reachability, and trust-path verification as one governance problem.

Unauthenticated compromise changes the meaning of least privilege. Least privilege assumes the system first knows who or what is asking. Here, the attack works before that assumption even exists, so the decisive control is reducing exposed trust paths, not only tightening authorisations after login. The relevant governance concept is pre-auth trust collapse: a condition where core services accept input or registration from a caller that has never been authenticated. Teams should design reviews around that collapse point.

Cluster trust is an identity boundary, even when no user account is involved. A rogue Message Server registration is effectively an impersonation event for an application server, which is why this belongs in the same governance conversation as machine identity and service trust. NHI programmes should notice that service-to-service trust can fail before any token or password is seen. Practitioners should inventory which components can claim trust on behalf of others and verify those claims at the network edge.

SAP Commerce Cloud’s risk cluster shows how platform governance and exposure management intersect. Four notes in one cycle, with two at or near maximum severity, means deployment choices and endpoint reachability are now part of the security model. That is especially relevant for teams governing non-human identities and service endpoints, because internal integration paths can become externally reachable by architecture drift. Practitioners should tie exposure reviews to build and redeploy changes, not only to vulnerability scans.

What this signals

Pre-auth trust collapse is the organising concept here: when the kernel or cluster accepts hostile input before authentication, the rest of the stack inherits a broken trust model. SAP teams should review whether their patch governance gives shared services a faster path than application defects.

The practical signal for SAP practitioners is that exposure management now belongs in the same conversation as patching. If an internal adapter path, cluster registration port, or shared request handler is reachable from an unexpected network zone, the vulnerability becomes materially more dangerous even before exploitation.

Teams running distributed SAP landscapes should prepare for a more aggressive approval model around kernel, Web Dispatcher, and Message Server updates. The governance question is no longer whether these components matter, but whether patch cycles are fast enough to outrun unauthenticated attack paths.

For practitioners

• Patch kernel and Web Dispatcher first Move the CVSS 10.0 kernel request-processing flaw and the Message Server fix into an emergency change path, then verify every NetWeaver and Web Dispatcher instance in the landscape, including sandboxes and QA systems.
• Restrict cluster registration reachability Limit the Message Server internal registration port to trusted application-server hosts and monitor for any new or unexpected component registrations as a sign of trust-boundary abuse.
• Separate Commerce Cloud into its own patch track Treat Commerce Cloud as a distinct accelerated change stream when notes affect the Data Hub Adapter, Spring Security, Jetty, or Log4j, because those fixes require rebuild and redeploy steps.
• Audit externally reachable integration endpoints Review which adapter paths, backoffice functions, and proxy-routed services are actually exposed in production, and close any route that turns an internal integration endpoint into an internet-reachable attack surface.
• Tie endpoint patching to client risk Patch SAP GUI for Java clients with the same urgency as backend systems, because endpoint compromise can expose cached credentials, SSO tokens, and multiple backend access paths.

Key takeaways

• This patch cycle shows that the highest-risk SAP failures can live in shared infrastructure, not just in application modules.
• Two CVSS 10.0 notes and a 9.8 cluster-trust issue make unauthenticated compromise the central concern in this cycle.
• The control that matters most is accelerated patch governance for kernel, Message Server, and exposed integration paths before attacker reach becomes attacker control.

Key terms

• Pre-authentication trust collapse: A failure mode where a system accepts hostile input or registration before it has established who is allowed to participate. In SAP core services, this means the boundary that should separate strangers from trusted components disappears, making compromise possible before account controls or role checks can help.
• Cluster trust boundary: The set of rules that determines which application servers, nodes, or services are treated as legitimate members of a shared environment. When that boundary is weak, a rogue component can inherit internal trust and act as though it belongs inside the landscape.
• Shared service exposure: The condition where a foundational platform component, such as a kernel, dispatcher, or message broker, is reachable in ways its designers did not intend. Because many systems depend on it, exposure at this layer has broader consequences than a defect in a single application module.
• Rebuild-and-redeploy patching: A remediation pattern where fixing a component requires rebuilding the software artifact and redeploying it, rather than applying a simple in-place update. This raises operational complexity and makes change scheduling, testing, and sequencing part of the security control itself.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that helps practitioners connect identity controls to shared infrastructure risk.It is suited to security teams that need a stronger identity governance lens across both human and non-human access paths.