SAP kernel RCE exposure shows how pre-auth parsing breaks SAP trust

At a glance

What this is: CYCOGNITO’s analysis shows that a critical SAP kernel flaw in EPP parsing allows pre-authentication OS command execution before SAP trust and authorization checks can intervene.

Why it matters: This matters because exposed SAP endpoints can be compromised before identity governance ever comes into play, so asset inventory, patch timing, and protocol reachability become control priorities for IAM and security teams.

By the numbers:

• The flaw carries a CVSS v3.1 base score of 10.0, according to CYCOGNITO.

Context

CVE-2026-44756 is a pre-authentication remote code execution issue in the SAP kernel, which means the vulnerable parsing logic is reached before normal identity and authorization controls can evaluate the session. In practice, that shifts the control problem away from user permissions and toward externally exposed services, kernel patch state, and protocol-level reachability.

For IAM, PAM, and NHI teams, the important point is that trust decisions are being made too late in the flow. When a shared kernel accepts attacker-controlled input before authentication, downstream controls such as role checks, segregation of duties, and session governance cannot prevent the initial compromise.

The affected surface spans multiple SAP product lines and protocol paths, so this is not a narrow application issue. It is a governance problem typical of large SAP estates where published services, third-party operation, and delayed patch windows combine to obscure exposure until a critical flaw appears.

Key questions

Q: What fails when SAP kernel parsing happens before authentication?

A: The trust boundary fails before identity controls can run. If a kernel parses attacker-controlled data before authentication, authorization, segregation of duties, and session governance are all downstream of the exploit path. The practical problem is not weak user access control. It is unsafe pre-auth processing in shared infrastructure code that must be patched and externally constrained.

Q: Why does a pre-authentication SAP kernel vulnerability create such high risk for enterprises?

A: It is high risk because the vulnerable code runs before authentication, so password policy, MFA, user locks, roles, and segregation of duties do not help. A crafted request can reach shared kernel parsing logic on multiple transports, which means an attacker without an account may trigger memory corruption, denial of service, or even remote code execution with enough effort.

Q: How can teams tell whether exposed SAP endpoints are actually in scope for this risk?

A: Check whether the service is internet-facing or reachable from partner and internal networks, then confirm the exact kernel patch level behind that endpoint. Fingerprinting alone may show the asset is present even when version detection is incomplete. If the endpoint can reach the vulnerable kernel path, it is in scope until patched.

Q: What should IAM and security teams do when a critical SAP kernel issue is discovered?

A: Prioritise remediation based on exposure, not just asset count. Patch externally reachable systems first, restrict protocol reachability where patching lags, and verify who owns each SAP landscape so approvals do not delay containment. Identity teams should focus on reducing the blast radius of post-exploit credential and session access.

Technical breakdown

Why pre-auth parsing in the SAP kernel breaks trust boundaries

The vulnerability sits in Extended Passport parsing inside the SAP kernel, where externally supplied length fields are deserialized before authentication completes. That matters because memory safety failures at this stage are reached by unauthenticated network traffic, not by a compromised user or privileged insider. Once the kernel misreads the input boundary, the attacker does not need valid SAP credentials to trigger unsafe memory behavior. The issue is therefore not a business logic flaw inside a role-protected application screen. It is a trust-boundary failure in shared kernel code that sits below normal SAP identity enforcement.

Practical implication: Treat pre-auth parsing paths as exposure points that must be controlled by patching and external reachability limits, not by user authorization design.

How one kernel flaw reaches HTTP, SAP GUI, and RFC services

Because the affected code lives in the shared kernel, the same vulnerability is reachable through HTTP and HTTPS via Internet Communication Manager and SAP Web Dispatcher, through SAP GUI via the SAP Dispatcher, and through system-to-system RFC connections. That architecture matters: a single code path can be reachable from multiple protocol entry points, so blocking one service does not remove the underlying flaw. This is a classic shared-component risk. The attack surface is determined by where the kernel is published, not by which SAP module the user thinks they are accessing.

Practical implication: Map every exposed SAP protocol path to the same kernel patch level and do not assume one closed interface eliminates the exposure.

Why post-auth controls cannot contain this class of SAP exploit

SAP user authorizations and segregation of duties checks only run after the vulnerable code path has already been reached. If the kernel has already accepted and processed malformed EPP data, identity controls are no longer the front line. Successful exploitation can yield operating system command execution under the SAP system account, which then becomes a launch point for credential theft, session inspection, configuration tampering, and binary modification. This is why pre-auth RCE in infrastructure software is fundamentally different from ordinary privilege misuse: the attacker first takes the platform, then uses platform-level access to reach identity assets.

Practical implication: Assume identity controls are bypassed at the entry point and focus containment on patch state, service exposure, and system account hardening.

Threat narrative

Attacker objective: The attacker’s objective is to gain pre-authentication command execution on the SAP kernel and then use system-level access to compromise credentials, sessions, and platform integrity.

1. Entry occurs when an unauthenticated attacker reaches a listening SAP service over HTTP, SAP GUI, or RFC and supplies crafted EPP data to the kernel parser.
2. Credential or session access follows once arbitrary OS command execution is obtained under the SAP system account, allowing the attacker to read active sessions and recover database credentials or password hashes.
3. Escalation and impact follow as the attacker alters system configuration, modifies SAP binaries, and uses kernel-level access to expand control over the SAP landscape.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

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

Pre-auth kernel parsing is a governance failure, not just a vulnerability. Once a shared SAP kernel processes attacker-controlled input before authentication, the trust model has already failed. Identity controls can still matter downstream, but they cannot protect the entry point that was reached without identity. The practitioner conclusion is that externally exposed kernel paths must be governed as pre-auth attack surfaces, not as ordinary application access.

Shared SAP kernels create blast-radius problems that exceed single-system thinking. One kernel flaw reaches Web Dispatcher, Internet Communication Manager, SAP GUI, and RFC paths, so exposure is determined by the published landscape rather than one service name. That makes inventory accuracy and patch synchronization the real control problem. The practitioner conclusion is that SAP security has to be managed at the platform boundary, not endpoint by endpoint.

Privilege controls are too late if the system account is the post-exploit prize. The article shows that exploitation leads to OS command execution under the SAP system account, which then exposes credentials, session state, and configuration. This is the kind of failure that turns identity governance into damage limitation rather than prevention. The practitioner conclusion is to harden the system account and reduce exposure windows before exploitability becomes operational.

External exposure visibility is the named concept that matters here: published SAP endpoints outlive the patch window. The article shows that service fingerprinting often identifies assets before confirmed versioning does, especially in partner-operated, subsidiary, or regional landscapes. That creates a verification gap between what teams think is internal and what is actually reachable. The practitioner conclusion is to treat exposure discovery as a standing governance control, not a one-off audit.

Patch timing is now an access-control problem in disguise. When a critical SAP flaw is reachable pre-auth, the difference between a patched and unpatched kernel is the difference between protected and exploitable trust. In practice, change windows, restart requirements, and cross-ownership delays become part of the risk model. The practitioner conclusion is to align remediation SLAs with the reachability of the service, not with the convenience of the release cycle.

What this signals

External exposure visibility is the control gap that decides whether a SAP kernel flaw remains theoretical or operational. Teams often know the landscape exists, but not which endpoints are still published, who owns them, or which path is still open. That means the first governance question is inventory fidelity, followed immediately by patch prioritisation and reachability reduction.

The identity lesson is simple: once exploitation lands in the SAP system account, IAM is managing the aftermath, not preventing the breach. That makes system account privilege, SAP landscape ownership, and external service discovery part of the identity security perimeter.

Pre-auth trust collapse: when a shared kernel accepts attacker-controlled input before authentication, conventional access governance is too late. Security and IAM teams should treat exposed SAP services as high-priority assets until the vulnerable kernel is patched and the published attack paths are reduced.

For practitioners

• Inventory every exposed SAP entry point Build and continuously refresh a list of internet-facing SAP Web Dispatcher, Internet Communication Manager, SAP GUI, and RFC endpoints, then tie each one to a known kernel patch state and owner.
• Confirm operational ownership across subsidiaries and providers Assign clear remediation responsibility for SAP landscapes run by third parties, regional teams, or managed service providers so patch approval does not stall at organizational boundaries.
• Restrict protocol reachability while patching is pending Limit RFC and SAP Dispatcher access to known source ranges and remove unnecessary external exposure before the kernel update is completed.
• Apply the HTTP workaround only as temporary containment Use the SAP Note 3756304 workaround where immediate patching is impossible, but treat it as a narrow control because SAP GUI and RFC paths remain reachable.
• Audit the SAP system account for excessive privilege Review local operating system privileges, recent process spawning, and any permissions that would let a post-exploit command execution pivot into broader host control.

Key takeaways

• The article shows that the important failure is not a user access problem but a pre-auth parsing flaw in shared SAP kernel code.
• The exploit path spans multiple published SAP protocols, which means exposure is determined by reachability and patch state rather than by a single application screen.
• The strongest control response is to inventory exposed endpoints, patch the kernel quickly, and narrow protocol access until the vulnerable path is closed.

Key terms

• Unauthenticated Remote Code Execution: A flaw that lets an attacker run code on a target system without first proving who they are. In enterprise applications, this is especially dangerous because the code executes inside a trusted workload context, which can expose data, internal services, and downstream privileges.
• Shared Kernel Vulnerability: A defect in a common system component that affects multiple products or services at once. Shared kernel issues create broad blast radius because one flawed code path can expose many applications, interfaces, and operational environments that depend on the same underlying layer.
• Extended Passport Processing: Extended Passport Processing is a SAP kernel function that reads a small tracing record attached to incoming connections. In this flaw, the parser trusts the sender’s declared length and copies data into a fixed buffer without adequate bounds checking, which can turn a malformed request into memory corruption and execution control.
• System Account: A system account is a non-human account created for automation, integrations, or service workflows rather than for an individual person. It can be assigned roles directly or through a team, and its access token reflects that assigned privilege, making ownership and lifecycle control essential.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for security practitioners who need to connect identity governance with access, privilege, and lifecycle control across modern environments.