SAP patch day exposes two CVSS 10.0 flaws in core infrastructure

At a glance

What this is: Pathlock’s analysis says SAP’s September 2026 patch day centers on two CVSS 10.0 flaws and a 9.8 cluster trust bypass in core infrastructure.

Why it matters: SAP operators and IAM teams need to treat kernel, Message Server, and Commerce Cloud patching as an access-control problem, because unauthenticated flaws can bypass normal identity gates and turn infrastructure trust into direct compromise.

By the numbers:

• SAP released 33 notes in total, including 7 HotNews items and 2 notes that score a full 10.0.
• Two notes scoring a full CVSS 10.0 are part of this patch cycle.

👉 Read Pathlock's analysis of SAP's September 2026 patch day and core infrastructure flaws

Context

SAP patch governance is not just about application maintenance when core platform components can be exploited before authentication. In this cycle, the key issue is that network-reachable flaws in the kernel, Message Server, and Commerce Cloud can collapse the assumptions that normally separate anonymous traffic from trusted internal execution.

For identity and access teams, this matters because infrastructure trust is a control plane for access, not a background technical detail. Once unauthenticated code execution or rogue cluster registration is possible, normal IAM and PAM controls only start to matter after the attacker has already crossed the boundary.

The pattern is not unusual for SAP estates that treat infrastructure patching, dependency management, and cluster trust as separate work streams; what is unusual here is the concentration and severity in one monthly cycle.

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: How should teams prioritise SAP kernel and Commerce Cloud patching?

A: Teams should prioritise the components that sit closest to unauthenticated entry and shared trust. In practice, that means kernel and Message Server fixes first, then externally reachable Commerce Cloud integration paths, then the rest of the note backlog. Severity matters, but reachability and trust-boundary placement matter more.

Q: What should security teams check after patching SAP infrastructure?

A: They should verify actual exposure conditions, not just patch completion. That means confirming kernel levels, testing cluster registration restrictions, checking whether integration paths are still reachable, and reviewing whether dependency updates introduced a new supply-chain issue. A patched note does not help if the path remains exposed or the topology changed.

Technical breakdown

Pre-authentication flaws in SAP kernel request paths

A pre-authentication flaw exists when an attacker can trigger unsafe behavior before any login or authorization check. In this cycle, the kernel request path and Web Dispatcher 9.16 are exposed through shared processing of EPP headers, which sit deep in the normal traffic path for NetWeaver systems. That makes the bug high impact because the attacker does not need an account, only reachability. Memory corruption in deserialization is especially dangerous because a malformed length or structure can lead to process crashes or code execution under the service account.

Practical implication: patch the kernel and dispatcher layer as the first line of exposure reduction, not as a later infrastructure task.

Cluster trust bypass in the Message Server

The Message Server is the cluster broker that accepts registrations from application server instances and coordinates logon groups and inter-instance communication. When it fails to verify whether a registering node is legitimate, an attacker can impersonate an internal server and enter the trust boundary without credentials. That is a classic control failure because the system is treating network proximity as proof of identity. In distributed SAP landscapes, this turns a single exposed port into a cluster-wide trust problem.

Practical implication: restrict registration reachability and patch the Message Server before treating load-balancing or workload tuning as the priority.

Commerce Cloud exposure depends on reachable integration paths

SAP Commerce Cloud in this cycle shows a different mechanism: unsafe integration endpoints and dependency-level flaws become exploitable when deployment or routing decisions expose paths that were not meant to be public. The Data Hub Adapter issue is only dangerous when the import path is reachable, which means the effective attack surface is shaped by routing, custom deployment, and endpoint exposure. That is a governance problem as much as a coding problem, because the same component can be safe in one topology and critical in another.

Practical implication: validate whether integration endpoints are actually reachable in production topology before deciding patch order and containment.

Threat narrative

Attacker objective: The attacker wants unauthenticated execution or trusted internal foothold in SAP infrastructure, then control of the affected system or cluster.

1. Entry occurs through network reachability to a vulnerable SAP kernel, Message Server, or exposed Commerce Cloud integration path, with no valid credentials required.
2. Escalation follows when malformed input or rogue registration is accepted as trusted processing, letting the attacker execute code or enter the cluster boundary.
3. Impact is full compromise of the SAP service, cluster trust, or Commerce Cloud instance, with potential access to customer, order, payment, and backend administrative data.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

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

NHI Mgmt Group analysis

Core SAP infrastructure trust is the real target, not just individual CVEs. This patch cycle shows that attackers do not need to break identity systems directly when infrastructure components already assume trust at the network or cluster boundary. Once unauthenticated input can reach the kernel, Message Server, or integration adapter, the attacker is operating inside a control gap rather than against a login screen. The practitioner lesson is to treat platform trust boundaries as identity boundaries.

Standing trust in cluster membership is a brittle assumption. The Message Server issue is especially instructive because it relies on the idea that only legitimate application servers will register. That assumption fails when registration is reachable from outside the intended trust zone. For identity teams, this is a reminder that implicit infrastructure trust needs explicit governance, logging, and network confinement.

Infrastructure identity sprawl: SAP landscapes often distribute trust across kernels, dispatchers, cluster brokers, and integration endpoints without a single ownership model. That fragmentation creates patch delay, exposure ambiguity, and control gaps across teams. The path to better governance is to inventory each trust-bearing component as part of the identity surface, not as a separate ops concern.

Commerce Cloud risk is topology-sensitive, which complicates governance. A component may appear safe in a default configuration yet become critical once routing or custom deployment exposes it. That means security teams need configuration-aware risk scoring, not just note severity triage. The practical conclusion is to assess exposure conditions before assuming a fixed severity ranking tells the whole story.

The open-source layer inside SAP is now part of the core attack surface. Jetty, Log4j, CAP tooling, and npm dependencies are not peripheral details when they sit inside business-critical SAP workflows. This is where software supply chain governance and identity governance intersect, because dependency abuse often becomes credential or execution abuse downstream. Practitioners should fold dependency control into the same patch and access review discipline they use for privileged systems.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
• OWASP NHI Top 10 helps teams map agentic access risk to practical control failures and governance gaps.

What this signals

SAP-style infrastructure risk is now converging with identity governance because the most dangerous flaws are the ones that bypass authentication altogether. The lesson for practitioners is to treat core platform components as trust anchors and verify whether your access model still makes sense when the attacker never needs to log in.

The programme-level shift is toward exposure-aware patch governance. A note that sits behind an internal boundary is not the same as a note exposed through a public port, a partner route, or a custom integration path. Teams that can separate nominal severity from actual reachability will make better decisions about which systems need emergency treatment.

This is also a reminder that dependency management belongs in the same governance conversation as privileged access, especially when vendor-shipped open-source packages are part of business-critical workflows. If you are already tracking machine and service access, extend that discipline to the software components that can turn a trust bypass into execution.

For practitioners

• Accelerate kernel and Message Server patching Place SAP kernel, Web Dispatcher, and Message Server fixes on a same-cycle emergency track when unauthenticated exposure exists, rather than waiting for the normal application patch window.
• Constrain cluster registration to trusted hosts Restrict the Message Server internal registration port to known application-server hosts and verify that no broader network paths can reach it.
• Map exposed Commerce Cloud endpoints before triage Confirm whether the Data Hub Adapter import path or similar integration endpoints are reachable in your production topology before assuming default configuration lowers the risk.
• Treat dependencies as part of SAP exposure review Audit SAP-shipped open-source components and pinned package versions alongside kernel notes so that dependency issues, patch releases, and secret exposure are handled in one change cycle.

Key takeaways

• This patch cycle is unusual because the highest-risk issues sit in shared SAP infrastructure, not just in isolated application modules.
• The evidence points to a concentrated trust-boundary problem: unauthenticated reachability, rogue registration, and exposed integration paths can all lead to compromise.
• Teams should prioritise exposure-aware patching, cluster confinement, and dependency review together, because those controls reduce the attack surface before identity controls ever get a chance to work.

Key terms

• Pre-authentication exploitation: An attack that succeeds before a system performs authentication, signature verification, or other trust checks. This raises severity because the attacker does not need valid credentials or a legitimate session to reach the vulnerable code path.
• Directory trust boundary: The directory trust boundary is the point where identity authority becomes security authority. In Active Directory environments, that boundary is often crossed by administrators, service accounts, and integrated systems, so controls must distinguish routine use from abuse in real time.
• Exposure-Aware Patching: A patching approach that ranks remediation by real attack reach, not by severity alone. It considers whether a component is internet-facing, internally reachable, or protected by topology, which is especially important when an unauthenticated flaw only matters if the vulnerable path is reachable.
• Integration Path Exposure: The situation where an internal or partner-facing workflow endpoint becomes reachable in production and can be abused by crafted requests. In SAP Commerce Cloud and similar systems, this often turns a design-time internal interface into a runtime attack surface.

What's in the full report

Pathlock's full analysis covers the operational detail this post intentionally leaves for the source:

• Patch note-by-note remediation guidance for the September 2026 SAP cycle, including affected component versions and release levels.
• Detailed exploit conditions for the kernel, Message Server, and Commerce Cloud issues, including where exposure depends on topology.
• SAP-specific mitigation notes for Web Dispatcher, cluster registration limits, and rebuild-and-redeploy timing.
• The open-source supply-chain watch items affecting CAP, Jetty, Log4j, and npm dependencies inside SAP environments.

👉 Pathlock's full post covers the patch-by-patch detail, exposure conditions, and mitigation timing for SAP estates.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps security practitioners connect identity controls to the infrastructure and access decisions that shape real-world risk.