SAP January 2026 patch day exposes trust-path abuse in core systems

At a glance

What this is: Pathlock’s analysis of SAP January 2026 patch day shows that the highest-risk issues cluster around core trust paths, especially RFC reachability, database user separation, and privileged admin workflows.

Why it matters: IAM, PAM, and Basis teams need to treat internal trust relationships as attack surface because valid credentials and broad authorisations can turn routine SAP access into compromise.

By the numbers:

• SAP released 17 Security Notes on the January 2026 Patch Day.
• The January 2026 patch day was published on 13 January 2026.

Context

SAP’s January 2026 patch day is a reminder that identity and access risk in ERP platforms is not limited to internet-facing entry points. The more important question is which internal trust paths can be reached once an attacker has a valid credential, a technical account, or a privileged admin workflow.

In SAP landscapes, RFC authorisation, database privilege boundaries, and legacy admin tooling often sit closer to business operations than security teams expect. That makes them attractive for post-compromise abuse, because the attacker does not need to break the perimeter if the trust model already grants enough reach.

This month’s patch set is a typical example of that pattern in large enterprise SAP estates, where integration sprawl and administrative convenience can outgrow the controls that were meant to contain them.

Key questions

Q: What breaks when SAP RFC trust paths are too broad?

A: Broad RFC trust breaks the assumption that internal access is inherently safe. If technical users or trusted destinations can invoke sensitive function groups, a compromised credential can reach finance logic, transformation routines, or monitoring workflows and turn normal integration traffic into lateral movement or data manipulation.

Q: Why do valid SAP credentials create so much risk in these patch day issues?

A: Valid credentials matter because several of the highest-risk notes depend on authenticated access rather than unauthenticated internet exposure. Once an attacker has a technical account, a low-privileged HANA login, or access to admin tooling, the attack shifts from entry to privilege escalation and internal abuse.

Q: How can security teams tell whether SSRF controls are actually working?

A: Look for evidence that untrusted input cannot change upstream destinations, that egress policies block unexpected targets, and that internal services still require authentication even when reached from inside the network. Good controls reduce both successful connections to private resources and the amount of useful data an application can return if probed.

Q: What should Basis and IAM teams do when admin tooling sits inside privileged networks?

A: They should assume those tools are part of the identity plane, not just operational support. Access should be limited to named admin paths, launch mechanisms should be reduced where possible, and phishing-resistant handling should be used for any workflow that can trigger privileged execution.

Technical breakdown

RFC reachability turns trusted function groups into attack paths

RFC is SAP’s remote function call mechanism, and in practice it often carries more trust than teams intend. When function groups are callable from technical users or trusted destinations, the security boundary is no longer the network perimeter but the authorisation design behind S_RFC. In this patch set, the critical issue is not that RFC exists, but that sensitive logic can be reached with permissions broad enough to let a compromised technical account invoke privileged backend behaviour. That is why RFC exposure becomes a lateral movement path rather than a simple application bug.

Practical implication: review RFC destinations, function-group permissions, and technical-user reachability before patching windows close.

Why HANA user impersonation is a privilege-boundary failure

The HANA flaw described here matters because it attacks the database’s user-separation model, not just a single login. If a valid user can switch context into another account, then the database no longer treats authentication as a stable identity boundary. That breaks the assumption that low-privileged users remain confined to their original role. In practical terms, once impersonation is possible, audit trails, data access controls, and privilege checks all inherit the wrong security context. For an SAP estate, that means compromise can jump from a limited login to administrative authority without leaving the application stack.

Practical implication: tighten HANA reachability, verify auditing, and treat any valid credential as a potential privilege-escalation starting point.

Legacy admin tooling expands the blast radius of a phishing click

The Introscope issue shows how privileged tooling can become the real target even when the vulnerable service is not directly internet-facing. A weaponised JNLP launch flow turns a normal admin workflow into an execution path, especially when the people operating the tooling already hold elevated network reach or credentials. That is a classic identity-security failure in the admin plane: the interface is trusted, the user is trusted, and the workstation often sits inside a privileged network segment. Once the launch path is abused, compromise can move from a single click to broader SAP administration.

Practical implication: constrain admin-tool access to dedicated segments and remove browser-based launch paths wherever they are still enabled.

Threat narrative

Attacker objective: The attacker wants to turn legitimate SAP trust relationships into privileged control over finance, database, or admin operations.

1. Entry occurs when an attacker obtains a valid technical account, admin session, or convincing phishing route into an SAP trust path.
2. Credential access or abuse follows through RFC reachability, HANA login misuse, or admin-tool interaction that accepts a trusted context.
3. Escalation happens when vulnerable function groups or database context switching let the attacker move from limited access into privileged execution.
4. Impact is landscape-wide compromise, with data corruption, persistence, credential theft, or deeper movement across connected SAP systems.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Storm-2949 Azure Breach: Storm-2949 social engineering attack turns one cloud identity compromise into full Azure tenant breach.

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

Core SAP risk is trust-path abuse, not perimeter failure: The highest-risk notes in this patch day cluster around RFC, HANA authentication boundaries, and admin tooling. That pattern matters because SAP intrusions often start after a credential is already valid, not after an internet-facing exploit lands. Practitioners should read this as a control-design problem: trusted internal pathways need the same scrutiny as external entry points.

RFC authorisation is a governance layer, not a technical detail: The recurring dependency on S_RFC and RFC-enabled modules shows that access scope is doing the real work of containment. When broad technical users can call sensitive function groups, the control assumption is that trust remains benign inside the network. That assumption is fragile in large SAP estates, so identity governance has to account for internal abuse as a primary scenario.

Ephemeral trust is not how SAP integrations actually behave: Many SAP landscapes still rely on durable technical users, broad integration reach, and long-lived admin relationships. That creates identity blast radius, where one compromised credential can traverse finance, monitoring, and database functions in sequence. The practical conclusion is that privilege boundaries must be designed around the blast radius of valid access, not the presence of a perimeter.

Legacy admin tooling remains part of the attack surface: Introscope and similar tools persist because operational teams still need them, but that also preserves privileged workflows attackers understand well. A phishing-delivered launch path is not a side issue when the user already has access to high-value administration networks. Teams should treat admin tooling as governance-critical identity infrastructure, not as peripheral support software.

Identity controls in SAP fail when access outlives task context: Broad RFC destinations, shared technical accounts, and admin-network tooling all assume that trust will be used only for legitimate operations. That assumption breaks when compromise or social engineering enters the chain, and the result is privilege reuse at machine speed. Practitioners need to judge SAP controls by how quickly they collapse once one credential is lost.

What this signals

Identity blast radius is the right SAP metric here: January’s patch day shows that the real question is how far a valid credential can travel once it lands inside the trust boundary. That means SAP security decisions should be evaluated by the number of systems and business functions one account can reach, not just by whether a note is marked Critical.

Internal trust boundaries only work when they are narrow, explicit, and monitored. In SAP estates, that means S_RFC scope, HANA context switching, and admin-tool access all need to be treated as governance objects, because each one can convert a single compromise into multi-system exposure.

For practitioners

• Tighten RFC authorisation boundaries Audit S_RFC, RFC destinations, and trusted RFC relationships around finance, transformation, and monitoring functions. Remove wildcard function access and confirm that only explicitly required modules remain callable by technical users.
• Segment privileged admin tooling Place Introscope and similar admin components on dedicated management networks, then restrict access to the subnets and jump points actually required for Basis and monitoring operations.
• Treat valid HANA credentials as escalation inputs Review HANA network reachability, impersonation risk, and database auditing together so that low-privileged accounts cannot be assumed harmless once authenticated.
• Prioritise patching by trust-path exposure Patch the Critical notes first where RFC reachability, database privilege boundaries, or admin-launch workflows are present, because those are the paths most likely to turn a foothold into compromise.

Key takeaways

• The patch day’s main risk is not perimeter exposure but abuse of trusted SAP pathways after a valid foothold exists.
• The highest-priority issues cluster around RFC access, HANA privilege boundaries, and privileged admin tooling, which are exactly the surfaces attackers use to move from access to control.
• Teams that want to reduce landscape-wide compromise should focus on trust-path restriction, admin-network segmentation, and sharply scoped technical-user permissions.

Key terms

• RFC trust path: An RFC trust path is a remote function route that SAP systems accept as authorised because of destination settings, technical-user scope, or legacy trust relationships. In practice, it can become an internal attack path when broad permissions let a compromised account invoke sensitive backend logic.
• Privilege Boundary: A privilege boundary is the control line that separates ordinary user actions from elevated administrative actions. When the boundary is poorly enforced, attackers can repurpose normal tools or policy logic to cross into root-level execution without going through intended approval or validation steps.
• Admin-tool blast radius: Admin-tool blast radius is the amount of system access that can be reached if a privileged monitoring or operations workflow is abused. In SAP estates, legacy tooling often sits close to production, so a single click or session can expose more than the tool itself.
• Technical User: A technical user is a non-human account used by systems, integrations, or background processes to perform business actions in SAP and related platforms. These accounts matter because they often hold standing access, interact with RFC or API paths, and can turn a configuration weakness into broad operational impact.

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.