SAP patch day exposes critical RCE and traversal risks

At a glance

What this is: This is Pathlock’s breakdown of SAP’s October Security Patch Day, highlighting critical RCE, traversal, and access-control flaws across core SAP components.

Why it matters: It matters because SAP estates often combine internet-facing services, shared kernels, and third-party libraries, so patch priority and temporary hardening directly affect breach exposure and operational continuity.

Context

SAP patch day is the routine release cycle where SAP publishes security notes for product flaws across its application and platform stack. In this case, the primary issue is not just volume, but the presence of a critical unauthenticated remote code execution path alongside traversal and authorization weaknesses that can be reached from exposed services.

For IAM and security teams, the governance problem is sequencing: internet-facing components, shared middleware, and privileged back-end services rarely fail in isolation. When patching is delayed or staged without exposure-based prioritisation, low-level application flaws can become high-impact entry points into business systems.

The article’s focus is typical of SAP patch cycles, where security teams must balance emergency remediation with regression testing across tightly coupled systems. The operational question is which fixes materially reduce attack surface first, and which can wait for controlled rollout.

Key questions

Q: What should teams do first when a SAP patch day includes unauthenticated remote code execution?

A: Start with externally reachable services, then move inward. If a flaw can be reached without credentials, patch order should follow exposure and exploitability, not product hierarchy. Teams should isolate vulnerable ports, apply vendor fixes quickly, and validate business-critical integrations after containment so that emergency remediation does not create avoidable outages.

Q: Why do directory traversal flaws in SAP services create such high risk?

A: Because traversal bugs let an attacker escape the intended file boundary and act on the server’s filesystem. In an enterprise SAP environment, that can mean overwriting application files, altering configuration, or disrupting service availability. The risk rises sharply when the affected service is reachable from outside the network and has no practical workaround beyond patching.

Q: What do security teams get wrong about patching SAP vulnerabilities?

A: They often treat patching as an infrastructure task instead of a control-state change. In a system like SAP, a known code injection flaw leaves the environment operationally exposed until the note is applied and verified everywhere. Patch status should be managed as part of identity and access governance for the platform.

Q: What happens when SAP internet-facing services are patched without regression testing?

A: Teams can remove one risk while breaking authentication, printing, integration, or upload flows that the business still depends on. SAP estates are tightly coupled, so patching without controlled validation can create outage risk or force teams to roll back security fixes. The safer pattern is containment first, then structured testing of affected paths before reopening access.

Technical breakdown

Unauthenticated RCE in NetWeaver AS Java

The most severe issue in the patch set is an insecure deserialization path in NetWeaver AS Java’s RMI-P4 stack. Malicious objects sent to P4 or P4S can trigger operating-system commands without authentication, which is why SAP pairs the patch with JVM deserialization filters and network isolation guidance. The mechanism matters because deserialization flaws are not simple validation bugs. They allow attacker-controlled object graphs to become executable logic before the application can apply normal authorization controls. That makes exposed middleware a high-value entry point.

Practical implication: treat P4 exposure as an externally reachable execution path and remove or isolate it before routine patching completes.

Directory traversal and file overwrite in SAPSprint

SAPSprint’s flaw is a classic path-validation failure. An unauthenticated network attacker can manipulate file paths to escape the intended directory boundary and overwrite system files. This is different from a normal application bug because the vulnerable logic sits at the boundary between user input and the file system, where even a small parsing mistake can become full host-level integrity impact. SAP notes that there is no workaround beyond patching, which signals that compensating controls are limited once the service is exposed.

Practical implication: assume internet-facing print and file-transfer services need immediate isolation until the fixed build is deployed.

Why kernel and library updates change attack surface

Several other notes in the release are not standalone headline flaws, but they matter because they sit in shared libraries and kernel-adjacent components. Jetty, Apache CXF, and Apache POI updates show how third-party dependencies inside SAP products can create resource exhaustion, code execution, or integrity issues even when the application layer looks stable. In practice, these issues widen the blast radius because one vulnerable shared component can affect multiple business functions at once. That is why patch sequencing has to consider dependency reuse, not just CVSS score.

Practical implication: inventory shared libraries and kernel dependencies before applying only the most visible application patches.

Threat narrative

Attacker objective: The attacker aims to turn exposed SAP services into host-level execution, data tampering, or service disruption without valid credentials.

1. Entry occurs through exposed SAP services such as NetWeaver AS Java P4/P4S or SAPSprint endpoints that accept unauthenticated requests. Attackers do not need user credentials when the service boundary itself is vulnerable.
2. Credential access is not the main stage here, because the flaws bypass authentication and rely on deserialization, traversal, or logic errors instead of stolen identities. That makes the entry path especially dangerous for perimeter-facing SAP systems.
3. Escalation happens when malicious input becomes executable code, file overwrite, or privileged application behaviour, allowing the attacker to act inside the SAP host or application context.
4. Impact follows as remote code execution, system file corruption, denial of service, or data integrity loss across connected SAP workloads and business processes.

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

Exposure management, not patch count, is the real control boundary: This patch day shows that the highest-risk SAP issues are the ones reachable from outside the trust boundary. Unauthenticated RCE and directory traversal matter because they turn service exposure into immediate compromise potential, which means patch sequencing must start with externally reachable middleware and print services. Security teams that treat all notes as equal miss the basic governance point: reachable attack surface is the decisive variable.

Shared components create identity-adjacent blast radius even when the flaw is not identity-specific: SAP environments often concentrate transport, session, and integration logic in a small number of shared services and libraries. When those components fail, one flaw can affect multiple applications, user groups, and operational workflows at once. That is why the practical risk is not just exploitation of one system but propagation across a coupled estate, which is exactly where change control and regression testing have to be disciplined.

Directory traversal and insecure deserialization are governance failures at the interface boundary: Both flaw classes show that input handling, path handling, and object handling are still being trusted too early in enterprise software stacks. These are not exotic edge cases. They are recurring control failures that expose the gap between secure design intent and the reality of internet-facing SAP services. The implication is that boundary validation remains a first-order governance issue, not a specialist code review detail.

Third-party library hygiene now behaves like patch governance, not software maintenance: The Jetty, CXF, and POI items illustrate that upstream components can alter risk across several business functions at once. In identity and access terms, that means the estate’s effective security posture depends on dependencies that application owners may not see directly. Security leaders should treat library provenance and kernel maintenance as part of operational access control over the runtime environment, not as a separate engineering concern.

Network isolation is the compensating control when no workaround exists: For the highest-severity notes, the article repeatedly points to isolation, exposure reduction, or service separation as the interim defence. That pattern is important because it shows which SAP issues can be reduced with compensating controls and which require direct remediation. Practitioners should read that as a signal to prioritise containment first, then restore normal access paths only after patch validation is complete.

What this signals

Patch sequencing should follow exposure, not vendor note order: The practical lesson from this release is that externally reachable services deserve the first maintenance window, because unauthenticated flaws collapse the time between discovery and exploitation. Security teams should build triage around reachability, not just CVSS labels or product families.

Runtime dependency control is now part of SAP governance: Jetty, CXF, and POI show how third-party libraries can widen the blast radius across multiple business functions. That makes dependency hygiene a governance issue for SAP owners, not a background task for platform teams.

For practitioners

• Prioritise internet-facing SAP services first Patch NetWeaver AS Java, SAPSprint, and any externally exposed SAP service before moving to lower-reachability items. Exposure, not release order, should drive sequencing.
• Isolate high-risk middleware during remediation Restrict or segment P4 and P4S ports, separate print and integration services from broad network access, and keep those boundaries in place until the fixed builds are validated.
• Add JVM deserialization hardening where applicable Apply the SAP-recommended deserialization filters alongside the code fix so malicious object payloads cannot reach execution paths if the service remains temporarily reachable.
• Rebuild regression tests around coupled SAP functions Test SSO flows, printing, upload paths, and integration services after patching because shared kernels and third-party libraries can introduce breakage across multiple modules.
• Inventory shared libraries and patch dependencies together Track Jetty, CXF, POI, and kernel-level components as part of the same change set so one vulnerable dependency is not left behind inside a patched application.

Key takeaways

• SAP’s October patch set is dominated by flaws that become dangerous as soon as they are reachable from the network.
• The most urgent issues include unauthenticated remote code execution in NetWeaver AS Java and unauthenticated directory traversal in SAPSprint.
• The right response is to isolate exposed services first, patch shared components second, and verify regression risk before restoring normal access.

Key terms

• Insecure deserialisation: Insecure deserialisation is a flaw where software rebuilds objects from incoming data without tightly controlling what can be instantiated. In platform software, it can turn a management interface into a code execution path when hostile payloads are accepted from a trusted channel.
• Directory Traversal: Directory traversal is an attack technique that manipulates file paths to escape the intended directory and reach other parts of the filesystem. In enterprise applications, it often becomes a privilege problem when a service accepts path input without constraining where that input can point.
• Risk-Based Patch Prioritisation: A patching method that ranks vulnerabilities by how likely they are to be exploited and how much damage they can cause in the real environment. It combines exposure, active exploitation, automation potential, and asset value instead of relying on severity alone.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.

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.