SAP May 2026 patch day expands risk across ABAP, commerce and CI/CD

At a glance

What this is: SAP’s May 2026 Patch Day surfaces 16 Security Notes, led by two Critical CVSS 9.6 flaws and a High-severity command injection path.

Why it matters: For IAM and NHI practitioners, the advisory shows that authenticated abuse, privileged technical users, and CI/CD exposure can all become identity-driven attack paths.

By the numbers:

• SAP released 16 Security Notes as part of the May 2026 Patch Day.

👉 Read Pathlock’s analysis of the SAP May 2026 Security Notes

Context

SAP patch days are no longer just application-maintenance events. In this case, the exposed surfaces include search input, commerce configuration upload, forecast and replenishment execution, and developer packaging workflows, which means the governance problem extends into identities, privileges, and build-time secrets.

For NHI governance, that matters because service accounts, technical users, CI/CD credentials, and administrative roles often sit closest to the affected paths. When those identities are over-privileged or poorly segmented, a vulnerability becomes a privilege problem as much as a code problem.

Key questions

Q: How should teams reduce the impact of SAP vulnerabilities that require authentication?

A: Teams should reduce the number of identities that can reach the affected function, then shorten the time those privileges remain available. Use role scoping, segmentation, and review of technical users to make exploitation harder. A patch closes the flaw, but access reduction limits how far an authenticated attacker can move if the flaw is still reachable.

Q: Why do privileged SAP accounts increase the risk of command injection and configuration abuse?

A: Privileged accounts turn a single flaw into a high-impact event because the attacker inherits trusted execution paths. In SAP environments, that can mean data access, service disruption, or code execution with little extra friction. Standing privilege also makes detection harder, because malicious activity can resemble normal administrative work.

Q: How do teams know whether SAP patching has actually reduced risk?

A: Measure whether the vulnerable functionality is still reachable, whether privileged accounts were reduced, and whether logs show failed or suspicious attempts against the affected paths. A successful patch programme changes exposure, not just version numbers. If the same identities still have broad access, residual risk remains high.

Q: What should security teams do in the first 24 to 72 hours after a malicious package advisory?

A: Isolate any system that installed the package, inspect caches and workflows, rotate secrets that could have been reachable, and review repository activity for tampering. Then verify whether build or deployment identities were exposed. The immediate goal is containment of secret leakage and downstream propagation, not just package removal.

Technical breakdown

Why SQL injection in SAP S/4HANA Enterprise Search matters

Enterprise Search sits close to business data and accepts user-controlled input that is translated into database queries. If the application fails to validate that input, an authenticated low-privilege user can manipulate query structure and reach data outside the intended search scope. In practical terms, this is not just about data theft. Search-layer injection can also destabilize the application, create error conditions, and turn a normal user workflow into a database attack path. The important architectural point is that authentication does not equal trust. Once a user is in the application, query construction still has to defend against malicious input.

Practical implication: Treat search interfaces as sensitive data access surfaces and verify that input handling is patched, logged, and reviewed like any other database-adjacent control.

Missing authentication checks in commerce configuration paths

Commerce Cloud configuration upload paths are high-value because they can influence how the platform behaves at runtime. When security rules are misordered or too permissive, unauthenticated requests can reach functionality that was meant to be restricted. If malicious configuration is uploaded and later processed by a legitimate user or system component, the result can become server-side code execution. The technical lesson is that access control bugs are often more dangerous than generic input bugs because they shift the attack from malformed data to trusted execution. In commerce environments, that can affect storefront behavior, integrations, and customer-facing availability.

Practical implication: Audit authentication boundaries on configuration and admin workflows, then validate that restricted paths are blocked before they reach any runtime processing step.

How malicious NPM packages turn build systems into identity exposure points

Package compromise in developer ecosystems is an identity problem because build tools frequently hold secrets, tokens, and deployment credentials. If a malicious package is installed on a workstation or CI/CD runner, it can read environment variables, harvest cached credentials, modify workflow files, or create downstream contamination in repositories. That makes the build environment part of the attack surface, not just the delivery pipeline. For SAP CAP and MTA Build Tool users, the operational risk is not the package alone but everything reachable from the system that installed it. That is why package auditing and secret rotation have to be treated as one response sequence.

Practical implication: Assume any affected build environment may have exposed reachable secrets and review caches, workflows, and credentials before returning it to service.

Threat narrative

Attacker objective: The attacker aims to turn normal SAP application, commerce, or build trust into privileged execution, data access, or secrets exposure.

1. Entry occurs through low-privilege authenticated access to Enterprise Search, unauthenticated access to Commerce Cloud configuration upload paths, or installation of a malicious NPM package in a build environment.
2. Escalation happens when malicious search input, permissive configuration processing, or package execution reaches trusted database, application, or CI/CD contexts.
3. Impact includes data exposure, server-side code execution, compromised secrets, and disruption of SAP business workflows and delivery pipelines.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Identity-aware SAP patching is now an access-governance problem, not a pure vulnerability-management exercise. The May patch set spans authenticated users, unauthenticated commerce paths, privileged administrators, and developer systems with secrets. That mix means remediation has to account for who can reach each function, which identities are trusted, and where standing privilege exists. Practitioners should treat these notes as evidence that SAP security and IAM governance are converging.

Configuration upload and build pipeline abuse are the same category of risk when identities are over-trusted. In one case, a platform processes malicious configuration as trusted runtime input. In the other, a package or runner processes malicious code inside a build trust zone. The common failure is not the payload type but the lack of identity scoping around execution surfaces. Practitioners should re-evaluate where trusted automation begins and ends.

Search-layer and admin-layer attacks show the identity blast radius problem clearly. A low-privilege user can abuse search logic, while a privileged operator can abuse an administrative command path. Those are different entry points, but the same governance flaw appears when access is broader than task scope. Identity blast radius: the amount of damage a compromised or over-privileged account can cause before detection or containment. Practitioners should reduce that blast radius across SAP roles, not only patch code.

The supply chain note confirms that NHI governance now has to extend into CI/CD and developer tooling. If build systems carry tokens, SSH keys, cloud credentials, or repository access, then package compromise becomes identity compromise. That shifts the response from simple version control to secret rotation, cache inspection, and repository review. Practitioners should formalise build identity hygiene as part of SAP security operations.

Standing privilege remains the quiet enabler behind high-severity SAP abuse paths. Several of these notes require authentication, but they become exploitable when administrative accounts, shared technical users, or broad role assignments are left in place. The lesson for the field is straightforward: patching reduces exposure, but privilege scoping determines how far an exploit can travel. Practitioners should pair remediation with privilege reduction.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• For the next step, review the Shai Hulud npm malware campaign for a concrete example of how build-time exposure becomes identity compromise.

What this signals

Identity governance has become the control plane for SAP remediation. The same patch set can look routine until you map it to the identities that can reach the affected paths. When technical users, CI/CD runners, and admin roles are over-broad, patching alone only shrinks the exploit window. With 70% of organisations already granting AI systems more access than human employees, according to the 2026 Infrastructure Identity Survey, the broader pattern is clear: enterprises keep widening non-human trust faster than they can govern it.

Build systems are becoming identity inventory, not just delivery infrastructure. If a package compromise can expose secrets, then package scanning, cache hygiene, and secret rotation belong in the same operational workflow. That is the same governance shift practitioners need for service accounts and automation identities: know what can act, what it can reach, and how quickly you can remove access when trust fails.

Runtime and build-time controls need to converge around blast radius. The practical question is no longer whether a vulnerability exists in SAP, but how many identities, credentials, and downstream systems sit within reach of that flaw. Teams that can map those dependencies early will recover faster and contain more narrowly when the next note lands.

For practitioners

• Prioritise patching by access path Patch SAP S/4HANA Enterprise Search and Commerce Cloud first, then validate which user groups, portals, or admin paths reach the affected functionality. Focus on exposed business roles, remote access paths, and any system that processes user-controlled search or configuration input.
• Review standing privilege across SAP technical accounts Inventory administrative users, shared technical users, RFC-style access, and automation accounts that can reach search, commerce, or forecasting functions. Remove unnecessary access, separate duties, and require task-scoped permissions where the business process allows it.
• Treat build runners as secret-bearing identities Isolate affected developer workstations and CI/CD runners, clean package caches, inspect lockfiles and workflow files, and rotate any reachable secrets. Assume cloud credentials, SSH keys, tokens, and deployment secrets on those systems may be exposed.
• Monitor for abuse patterns, not just missing patches Track SQL errors, abnormal search requests, suspicious configuration uploads, unexpected OS process launches from SAP hosts, and repository or workflow tampering in build environments. Detection should reflect how the notes can be turned into identity-based abuse.
• Embed SAP security into identity governance Bring Basis, DevOps, commerce owners, and IAM teams into the same remediation workflow so patching, privilege review, and secret rotation happen together. This is the most reliable way to reduce the blast radius of these notes.

Key takeaways

• SAP May 2026 patching is an identity problem as much as a vulnerability problem because the affected paths depend on who can authenticate, administer, or build.
• The advisory spans low-privilege search abuse, unauthenticated commerce exposure, privileged command execution, and malicious package activity, which broadens the governance scope beyond one application layer.
• The fastest risk reduction comes from pairing patching with privilege reduction, secret rotation, and tighter control of build and administrative identities.

Key terms

• Identity blast radius: The amount of damage an account, token, or technical user can cause if it is abused or compromised. In SAP environments, blast radius is shaped by role scope, admin reach, and what connected systems a credential can touch before detection or revocation.
• Standing privilege: Persistent access that remains available outside a specific task window. In non-human and administrative identities, standing privilege increases the chance that a vulnerability becomes an execution path rather than a contained event, especially when access is broad and rarely reviewed.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.

Deepen your knowledge

SAP patch prioritisation and identity scoping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme around SAP administration, commerce, or CI/CD identities, it is worth exploring.

This post draws on content published by Pathlock: SAP May 2026 Security Notes and patch prioritisation. Read the original.