SAP patch Tuesday exposes identity and secret management gaps

At a glance

What this is: SAP’s November patch cycle concentrates on unauthenticated exposure, insecure secret handling, and middleware injection paths across core enterprise components.

Why it matters: It matters because SAP estates often carry privileged service identities and connected systems, so a single weak component can expand blast radius across IAM, NHI, and platform operations.

By the numbers:

• SAP released 20 Security Notes this month, including 18 new and 2 updates to previously released security notes.
• Three of the notes are critical, including two CVSS 10.0 issues and one CVSS 9.9 issue.
• The SQL Anywhere Monitor issue is rated CVSS 10.0 and uses hard-coded credentials.

👉 Read Pathlock's SAP November patch analysis for critical middleware vulnerabilities

Context

SAP’s November patch cycle is really about identity trust boundaries inside enterprise middleware. When a monitoring component ships with hard-coded credentials or an admin protocol accepts unsafe deserialisation, the problem is not just vulnerability density. It is that long-lived platform identities and internal management paths were assumed to be trustworthy by default.

For IAM, NHI, and platform teams, this is a reminder that SAP landscapes are not isolated application islands. They contain service access, remote-enabled functions, and internal control planes that often sit outside normal identity governance routines. Once those paths are exposed, the gap is not only technical patching but also inventory, ownership, and exposure control.

The pattern described by Pathlock is typical in large enterprise estates: legacy middleware and operational tooling keep privileged access alive long after teams stop looking at them as active attack surfaces.

Key questions

Q: What breaks when SAP management components still rely on hard-coded credentials?

A: Hard-coded credentials turn a management component into a standing access path that bypasses normal secret lifecycle controls. In SAP estates, that means the service can be reached and used without a rotation event, owner review, or meaningful expiry. Once discovered, the credential often gives direct access to the underlying system rather than a limited application function.

Q: Why do privileged SAP middleware services increase lateral movement risk?

A: Privileged SAP middleware increases lateral movement risk because it often sits between operational tooling, production systems, and connected business applications. If an attacker compromises one trusted component, they may inherit the access relationships attached to it. The result is a wider blast radius than the original vulnerability would suggest.

Q: How should security teams prioritise SAP patching when multiple notes are released?

A: Prioritise exposed and remotely reachable components first, especially those that combine authentication weakness, code execution potential, or trusted admin protocols. In practice, that means critical issues on internet-facing or broadly reachable middleware move ahead of lower-risk defects, even if the CVSS spread seems narrow.

Q: Who should own SAP exposure risk when middleware and service access overlap?

A: Ownership should sit with both the SAP platform team and the identity or infrastructure security function, because the risk spans patching, exposure control, and service identity governance. If one team owns only remediation and the other owns only access policy, the gap remains open.

Technical breakdown

Hard-coded credentials in SQL Anywhere Monitor create instant trust failure

Hard-coded credentials are embedded authentication values that never change with the environment. In the SQL Anywhere Monitor case, that means the monitor itself becomes a reusable access path rather than a managed identity. If the service is reachable, an attacker does not need to break authentication logic or steal a separate secret. They can simply use the built-in credential set and reach the underlying database. This is a classic non-human identity failure because the secret is not just exposed, it is structurally baked into the component. The control problem is visibility, ownership, and retirement of forgotten services.

Practical implication: inventory legacy monitors and treat any exposed instance as an active secret-management incident, not a minor configuration issue.

Insecure deserialisation in AS Java turns internal protocols into execution paths

Insecure deserialisation happens when a system accepts serialised data and reconstructs objects without sufficiently restricting what classes or behaviours can be instantiated. In SAP NetWeaver AS Java, RMI/P4 is the internal admin protocol, so exposure of those ports turns a management channel into a code execution path. The vendor’s patch adds stricter class filtering because the core risk is not just bad input, but trusting object graphs from a network-reachable source. In identity terms, the platform is treating an internal service interaction like a pre-authorised relationship even when the caller may not be legitimate.

Practical implication: restrict RMI/P4 exposure at the network edge and verify that any Java admin protocol is not reachable beyond the smallest trusted segment.

Solution Manager code injection shows how privileged RFC trust becomes lateral movement

Code injection in a remote-enabled function module means an attacker can influence executable logic over a trusted interface. In Solution Manager, RFC access is especially dangerous because SolMan often sits at the centre of connected SAP systems and carries broad administrative visibility. Once arbitrary ABAP can run there, the attack is no longer local to one application. It becomes a pivot into the wider SAP landscape through inherited trust and high-value integrations. This is why middleware governance and service-account governance must be treated together, not separately.

Practical implication: review remote-enabled function exposure and revoke unnecessary RFC trust before patching can be completed.

Threat narrative

Attacker objective: The attacker aims to turn a trusted SAP management or middleware component into a foothold for broader system compromise and lateral movement across the enterprise SAP estate.

1. Entry occurs when an exposed SAP middleware component, such as SQL Anywhere Monitor or an internet-reachable AS Java service, accepts hostile input or embedded credentials.
2. Credential access or abuse follows when hard-coded secrets, trusted RFC access, or unsafe deserialisation let the attacker move from reachability to control.
3. Impact occurs through remote code execution, arbitrary ABAP execution, or database compromise, which can then be used to pivot across connected SAP systems.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Hard-coded secrets in management tooling are not just a configuration flaw, they are a governance failure. When an operational component ships with fixed credentials, the identity lifecycle has already broken before deployment. The access path exists without a provisioning event, rotation plan, or meaningful owner. The implication is that teams cannot treat embedded credentials as ordinary secrets management debt; they are unmanaged non-human identities that bypass the governance model entirely.

Legacy middleware remains one of the most underestimated identity attack surfaces in SAP estates. AS Java, Solution Manager, and related platform services often carry implicit trust that no longer matches current exposure. That trust allows remote interfaces to behave like internal-only identities even when they are reachable beyond the intended boundary. Practitioners should re-evaluate whether their SAP governance model actually inventories and classifies these components as active identities.

Privilege concentration in SAP control planes creates a wider blast radius than vulnerability scoring suggests. A single code-injection or deserialisation flaw can expose not only one server, but the trust relationships attached to it. That is why SAP remediation is really about identity containment, not only patch cadence. The practical conclusion is that teams must map which service identities can reach production, administration, and downstream integrations before they decide what “critical” means in their environment.

Identity governance for SAP has to include the old, the remote, and the forgotten. Components that are no longer front-and-centre in architecture reviews often remain the easiest route into high-value environments. That means inventory, ownership, exposure control, and offboarding matter as much as patch installation. The conclusion for practitioners is straightforward: if a component can authenticate, execute, or pivot, it belongs inside the identity programme.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A further 47% of organisations report only partial visibility into those third-party OAuth connections, which means the majority cannot fully map delegated access paths.
• For a broader operating model view, read NHI Lifecycle Management Guide for how visibility, ownership, and offboarding fit together across non-human identities.

What this signals

Third-party and internal service identities fail in the same way when visibility is incomplete: teams cannot govern what they have not inventoried, and SAP environments still contain far more hidden trust paths than most programmes assume. The practical signal is to treat middleware exposure review as part of identity governance, not just application hardening.

A useful next step is to align exposure review with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, because this patch cycle spans identify, protect, detect, respond, and recover concerns rather than a single vulnerability class.

The governance lesson is simple. If an SAP component can authenticate or execute remotely, it should be managed like an identity with lifecycle, ownership, and revocation requirements, not like a passive application asset.

For practitioners

• Inventory exposed SAP management components Identify SQL Anywhere Monitor, AS Java admin ports, Solution Manager RFC endpoints, and Business Connector services that are still reachable from internal or external networks.
• Retire hard-coded and embedded credentials Treat embedded keys and secrets in legacy SAP utilities as unmanaged identities. Rotate or remove them, then confirm the service no longer depends on fixed credentials for access.
• Restrict admin protocols to trusted segments Block RMI/P4 and similar internal management interfaces at the network edge unless there is a documented business need. Validate that only intended administration paths remain reachable.
• Review remote-enabled trust relationships Map which RFC or remote-enabled functions can execute code or reach connected systems, then remove unnecessary access before patching windows close.

Key takeaways

• This SAP patch cycle shows how old middleware, hard-coded secrets, and trusted admin interfaces can still create modern identity risk.
• The operational impact is broad because one exposed service can become a pivot into databases, Java stacks, and connected SAP systems.
• The control that matters most is not just patch speed, but inventory, exposure reduction, and removal of unmanaged non-human identities.

Key terms

• Hard-coded credential: A hard-coded credential is a secret embedded directly into software rather than issued and managed separately. In identity terms, it behaves like a standing access path with no normal rotation or offboarding lifecycle, which makes it difficult to govern once the component is deployed.
• 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.
• Remote-enabled function module: A remote-enabled function module is an SAP callable component that can execute logic over a network interface. When it has privileged access or can reach other systems, it becomes an identity and trust boundary, not just a technical API endpoint.
• Standing access path: A standing access path is a persistent way into a system that remains usable without a fresh authorisation event. For non-human identities, it often appears as a service credential, admin channel, or embedded secret that survives long after the original operational need has changed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by Pathlock: SAP November Security Notes analysis covering critical middleware vulnerabilities. Read the original.