SAP patch day exposes critical RCE and traversal risks

At a glance

What this is: Pathlock’s October SAP patch summary highlights critical unauthenticated RCE, directory traversal, and other exploitable flaws across NetWeaver, SAPSprint, Commerce, S/4HANA, and BusinessObjects.

Why it matters: SAP administrators and IAM-adjacent security teams need to treat patch sequencing, service exposure, and regression testing as governance issues because unpatched enterprise application stacks can become direct paths to system compromise and access abuse.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Pathlock’s October SAP patch day analysis for critical RCE and traversal fixes

Context

SAP’s October Security Patch Day is a reminder that enterprise application security is not only about fixing application bugs. It is also about how exposed services, kernel components, and third-party libraries interact with identity, transport, and trust boundaries across the SAP estate.

For IAM and security teams, the issue is broader than a single vulnerable component. Unauthenticated network paths, weak input handling, and missing authorization checks can turn operational SAP services into control-plane shortcuts that bypass the governance assumptions behind access, session, and system boundary controls.

Key questions

Q: How should teams prioritise SAP patching when multiple critical notes land at once?

A: Start with unauthenticated, internet-facing flaws that can lead to remote code execution or file overwrite, then move to lower-severity application defects and internal issues. In SAP estates, reachability and privilege impact matter more than headline CVSS alone. A service that is exposed externally and can be abused without credentials should be patched before anything that requires local access or user interaction.

Q: Why do SAP application flaws often become identity and governance problems?

A: Because enterprise SAP services sit inside trusted business processes, and a flaw in input handling or authorization can let an attacker act as the application itself. That turns a technical bug into a boundary failure. When a system is allowed to execute commands, write files, or bypass checks without proper entitlement, the issue is no longer just vulnerability management.

Q: What breaks when third-party libraries in SAP stacks are not patched quickly?

A: The application inherits the library’s attack surface even if the business logic is unchanged. That means Jetty, CXF, or POI flaws can create code execution, denial of service, or parsing abuse inside trusted SAP workflows. Teams should treat embedded libraries as security assets, not passive dependencies, and maintain an inventory that ties each library to the deployed service.

Q: Who should be accountable for SAP exposure when a critical flaw is public?

A: Application owners, platform teams, and security operations should share accountability, but the control owner must be explicit. If a service is reachable from the internet, the team responsible for exposure management should confirm patch status, segmentation, and interim hardening. Governance fails when everyone assumes another team owns the risk.

Technical breakdown

Unauthenticated remote code execution in NetWeaver AS Java

The NetWeaver AS Java issue is a classic deserialization problem. Malicious objects sent over the P4/P4S interface can be interpreted by the Java runtime in a way that triggers OS-level command execution. SAP’s hardening note adds JVM deserialization filters so the runtime rejects dangerous classes before they are instantiated. The important architectural point is that deserialization is not just data parsing, it is code-adjacent execution when object graphs are trusted too early. In SAP environments, that makes network exposure and runtime filtering part of the same control plane.

Practical implication: isolate P4/P4S, patch the affected libraries, and enforce deserialization filtering before the interface is left reachable.

Directory traversal, file overwrite, and unauthenticated service exposure

SAPSprint’s flaw shows what happens when path validation is weak. If a service accepts user-controlled paths and fails to constrain them to approved directories, an attacker can traverse the filesystem and overwrite files outside the intended scope. This is not an identity problem in the narrow sense, but it is an access problem at the application boundary because the service grants write capability to inputs that were never authenticated for that level of reach. Similar patterns appear in admin consoles and endpoint exposure gaps when deployment isolation is incomplete.

Practical implication: remove unnecessary network reachability, validate paths rigorously, and treat any file-handling service as a high-risk boundary.

Third-party library hygiene in SAP Commerce and integration stacks

The Commerce, Data Hub, and BusinessObjects issues underline a recurring reality: upstream libraries often carry the exploit path, while the enterprise application carries the blast radius. Jetty HTTP/2 resource exhaustion, Apache CXF JMS/JNDI endpoint control, and Apache POI parsing weaknesses all sit inside trusted application flows. Once those libraries are embedded, their attack surface becomes part of the business service, not just a dependency note. That is why patch cadence, component inventory, and release rebuilds matter as much as vulnerability disclosure. Integration stacks amplify this risk because trust boundaries are spread across messaging, parsing, and transport layers.

Practical implication: inventory embedded libraries, patch them as first-class assets, and rebuild affected SAP packages before redeploying to production.

Threat narrative

Attacker objective: The attacker aims to gain privileged execution or reliable disruption inside enterprise SAP services so they can alter systems, steal data, or break business operations.

1. Entry begins with unauthenticated exposure of internet-facing SAP services such as P4/P4S and SAPSprint, or with remote attackers reaching weakly isolated administrative and integration endpoints.
2. Escalation occurs when malformed objects, traversal payloads, or crafted protocol streams are processed by trusted components and turn input handling into code execution, file overwrite, or denial of service.
3. Impact is system compromise, service disruption, data tampering, or broad operational outage across SAP application, integration, and business-process layers.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Patch day risk in SAP is really identity boundary risk: These flaws matter because they let unauthenticated or low-privilege actors cross boundaries that enterprise governance assumes are already enforced. Once a service accepts unsafe input, the control failure is not only technical patch lag but misplaced trust in the application perimeter. For SAP estates, the practitioner conclusion is that exposure management and authorization design have to be treated as one problem, not two.

Deserialization and path traversal are governance failures disguised as application bugs: They both convert external input into privileged behaviour without the intended approval path. That means the organisation has granted execution or filesystem reach to a component without proving that the actor or payload is entitled to it. The implication is that SAP security teams need to track where trust is being delegated to runtime libraries, because that is where the boundary silently collapses.

Library inheritance creates identity blast radius: Once Jetty, CXF, or POI is embedded in an enterprise platform, the organisation inherits the trust model of those libraries as well as the platform. A patch missed in a shared library can therefore become an enterprise-wide control weakness across commerce, integration, and reporting stacks. Practitioners should treat dependency governance as part of access governance because shared components define who or what can act inside the application boundary.

Kernel and ticketing fixes show how weak session assumptions persist across enterprise systems: Multiple SAP notes touch authentication artefacts, CSRF handling, and ticket verification, which is a reminder that session and trust decisions are still being made deep in the stack. When those layers are stale, even low-privilege users can cross into actions they should never reach. The field-level conclusion is that identity assurance in ERP environments depends on keeping runtime trust decisions current, not just user entitlements.

Operational exposure is now a security model problem, not a deployment detail: The article’s repeated guidance to isolate services, harden interfaces, and rebuild patched components shows that reachability is part of the attack surface. If a service is exposed to the network, the governance question becomes whether the organisation can defend that exposure with the same discipline it uses for privileged access. Security teams should therefore align patching, segmentation, and entitlement review as one control cycle.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That remediation gap is why the 52 NHI breaches Report is useful for teams that want to understand how control failure turns into real-world exposure.

What this signals

Pathlock’s patch summary reinforces a familiar pattern: exposure management fails fastest where trusted services are left reachable longer than necessary. The operational lesson for SAP teams is to align patch cadence, network isolation, and regression testing so that public-facing services do not stay open while fixes are staged. For deeper context on why trust boundaries matter across machine identities, see the Ultimate Guide to NHIs.

Identity blast radius: once a shared SAP component is exploitable, the security problem is no longer a single CVE but the number of workflows that depend on that component. That is why dependency inventory and service reachability need to be part of the same risk view.

The broader signal is that SAP patching is increasingly a governance exercise. Teams that can map internet exposure, component ownership, and business criticality into one triage model will reduce the window in which a published flaw becomes a production incident.

For practitioners

• Prioritise internet-facing SAP services first Patch NetWeaver AS Java, SAPSprint, and any externally reachable Commerce or integration endpoints before working through lower-risk internal items. Service exposure should drive the queue, because reachable flaws create the fastest path to exploitation.
• Apply deserialization hardening alongside code fixes Where SAP provides JVM filters or companion hardening notes, deploy them with the patch rather than treating them as optional defence in depth. Deserialization controls reduce risk while maintenance windows and regression testing are still in progress.
• Rebuild and redeploy affected SAP packages after library updates Do not assume dependency patching is complete once a note is applied. Rebuild Commerce, Data Hub, and BI packages so updated Jetty, CXF, or POI libraries are actually present in the deployed artefact.
• Review exposure for admin and print-style endpoints Audit whether SAPSprint, HAC, and similar utilities are reachable from networks that do not require them. Restricting access to these services reduces the chance that path traversal or console exposure becomes an operational breach.

Key takeaways

• The article shows that SAP patch risk is really exposure risk, because unauthenticated flaws in reachable services can become direct system compromise paths.
• The most dangerous issues are the ones that combine weak input handling, embedded libraries, and trusted enterprise workflows, which broadens the blast radius beyond a single component.
• Teams should prioritise external exposure, deserialization hardening, and redeployment of patched packages as one control cycle rather than isolated fix actions.

Key terms

• Deserialization: Deserialization is the process of turning stored or transmitted data back into an object the application can use. In security contexts, it becomes dangerous when untrusted input is allowed to create executable behaviour or invoke sensitive classes without strict filtering and validation.
• 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.
• Exposure Management: Exposure management is the discipline of reducing the number of systems, services, and interfaces that an attacker can reach and abuse. It combines patching, segmentation, hardening, and ownership clarity so that a vulnerability is not left sitting on an open path.
• Identity Blast Radius: Identity blast radius is the amount of access, business process reach, and operational damage that becomes possible once one trusted component is compromised. In SAP and other enterprise platforms, shared libraries and exposed services can expand that radius far beyond the original flaw.

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 October Security Patch Day analysis covering critical RCE and traversal issues. Read the original.