SAP OVERPASS CVE-2026-44756: a CVSS 10 RCE Before SAP Checks Who You Are

On September 8, 2026, SAP shipped a kernel patch for a bug that never asks who you are. CVE-2026-44756, named OVERPASS, is a CVSS 10.0 memory-corruption flaw in the shared SAP kernel that Onapsis found and reported. A single crafted request executes operating-system commands on the SAP host as the SAP administrative account — before the system evaluates a single role, authorization object, or logon policy. There is no credential to steal, no session to hijack, no privilege to escalate. The code that mishandles your request runs first.

For most enterprises the SAP estate is the last thing that gets pentested and the first thing that would end the company if it went down. OVERPASS is the kind of finding that turns "we'll get to SAP next quarter" into a same-week emergency change window.

What SAP OVERPASS actually is

The vulnerable code lives in Extended Passport (EPP) processing. EPP is a diagnostic mechanism: when a new session opens, SAP attaches a passport that lets administrators trace a call as it fans out across a distributed landscape — which server handled it, which component, how long each hop took. It is genuinely useful plumbing. It is also parsed at the very start of a connection, which is exactly the problem.

Per Onapsis Research Labs, OVERPASS is a missing boundary validation during deserialization of EPP data: the kernel trusts an externally supplied length field and reads or writes past the bounds of the buffer it was given. A malformed EPP header triggers a memory-safety violation in the process that received it. Because EPP is handled before authentication, the attacker reaches the corrupt-memory code path with nothing more than network access to a listening SAP service.

The Hacker News writeup is blunt about what a successful attacker gets: read the SAP secure store for database credentials and password hashes, extract those credentials for lateral movement, modify business data, and rewrite SAP binaries. Command execution runs with the privileges of the SAP service account — the <sid>adm identity that owns the whole instance. Owning that account is owning the ERP.

"But our SAP systems aren't on the internet." — Neither were most of the hundreds of NetWeaver instances compromised in 2025. An RFC-reachable kernel bug does not need the internet; it needs one foothold anywhere the SAP protocols are spoken, which in a real landscape means every application server, every message server, and every integration host that talks to them.

Why SAP is a target worth this much effort

OVERPASS did not arrive in a vacuum. In April 2025, CVE-2025-31324 — an unauthenticated file-upload flaw in the NetWeaver Visual Composer Metadata Uploader, also CVSS 10.0 — was found under active exploitation. CISA added it to the Known Exploited Vulnerabilities catalog on April 29, 2025. Onapsis and Google-owned Mandiant tracked hundreds of confirmed compromises across utilities, manufacturing, and oil & gas, with a suspected initial-access broker uploading webshells to stage ransomware. That campaign proved the thesis attackers had been testing for years: SAP is where the money, the master data, and the operational control live, and it is chronically under-monitored.

OVERPASS is also not a novel bug class. SAP kernel and RFC deserialization keeps producing the same shape of unauthenticated RCE: CVE-2025-42944 (RMI-P4 deserialization, unauthenticated via an open P4 port) and older NetWeaver ABAP RCEs walk the same path. When the same primitive recurs across kernel releases, "patched last quarter" is not the same as "safe" — the next crafted-payload variant is a research cycle away.

And OVERPASS shipped alongside company on SAP's September Patch Day. Three of the four criticals bypass authentication outright:

CVE	CVSS	Component	Issue
CVE-2026-44756 (OVERPASS)	10.0	SAP Kernel (EPP)	Pre-auth memory-corruption RCE
CVE-2026-58240 (S4GET)	9.8	NetWeaver Message Server	Missing authentication
CVE-2026-76969	9.4	SAP Cloud CAP	Credential disclosure
CVE-2026-66768	9.0	NetWeaver SAP GUI for Java	Improper access control

A patch window that closes only OVERPASS and leaves S4GET open has not fixed the pre-auth exposure — it has moved it one port over.

Three doors into the same kernel bug

The reason OVERPASS earns a 10.0 rather than a 9.x is reachability. The vulnerable EPP code path is behind three independent front doors:

• The web layer — the Internet Communication Manager (ICM) and Web Dispatcher, which process Extended Passport over HTTP/S. This is the door most likely to be exposed beyond the corporate LAN.
• The SAP GUI layer — the Dispatcher accepting DIAG connections from thick clients. Reachable from any workstation subnet that talks to the app server.
• The RFC layer — EPP exchanged between SAP systems on Remote Function Call connections. This is the internal blast radius: RFC trust between systems means one compromised instance reaches its neighbours.

One kernel patch closes all three. But the three doors matter enormously for the interim, because a control that only inspects HTTP does nothing for the RFC and DIAG paths — and RFC is exactly the path an attacker who already has a toehold will use.

Why your SAP logs won't save you

Here is the operational trap. SAP has a respectable audit surface — the Security Audit Log (SAL), the system log, the gateway logs. Security teams that monitor SAP monitor those. OVERPASS renders that monitoring blind in two directions at once.

First, the crafted EPP header is processed before SAP authenticates the session. There is no user, no successful or failed logon event, nothing for the Security Audit Log to record about the request that corrupts memory. The application-layer log begins its story after the point where the attacker has already won.

Second, once the exploit lands, code runs as <sid>adm — the account that owns the SAL files, the trace directory, and the SAP binaries themselves. An attacker with that identity can rotate, truncate, or rewrite the very logs a hunter would consult. Evidence living on the compromised host, written by an account the attacker now controls, is evidence you cannot trust.

What the attacker cannot rewrite is the network. The malformed EPP request had to arrive over ICM, DIAG, or RFC. The reverse shell had to beacon somewhere. The secure-store credentials that got exfiltrated had to leave over a socket. The lateral RFC calls to neighbouring SAP systems crossed the wire as SAP protocol traffic. The packets are the one part of the incident the <sid>adm account cannot go back and edit.

Remediation

A complete runbook for OVERPASS and its Patch-Day siblings. Do these in order.

1. Am I affected?

OVERPASS is a kernel bug, so the vulnerable surface is defined by kernel release and patch level, not by your S/4HANA or ECC application version. Identify every kernel in the estate:

• In each system: transaction SM51 → Release Notes, or System → Status, to read the kernel release and patch number. From the OS, run disp+work -version as <sid>adm and note the kernel release and patch level lines.
• Check those values against SAP Security Note 3747649 — it is the authoritative list of affected kernel families and the exact fixed patch levels. Treat the Note's version strings as ground truth; do not trust a third-party summary for the fixed build number.
• Inventory exposure per vector: which systems present ICM/Web Dispatcher (default ports 80xx/443xx), which accept SAP GUI DIAG (32xx), and which accept RFC/gateway (33xx, 48xx). Anything reachable from an untrusted segment is a priority.

2. Patch — the exact fixed versions

Apply the kernel patch referenced in SAP Security Note 3747649 for every affected kernel family, then restart the instance so the new disp+work binaries are loaded — a downloaded patch that hasn't been activated by a restart does not close the bug. Because OVERPASS is in shared kernel code, one patch closes the HTTP, DIAG, and RFC paths simultaneously. While the change window is open, apply the same day's fixes for CVE-2026-58240 (S4GET), CVE-2026-76969, and CVE-2026-66768 — leaving those open re-exposes what OVERPASS forced you to touch.

3. Can't patch this hour? Compensating controls

• Apply the HTTP-path workaround in SAP Security Note 3756304, which documents mitigations to blunt exploitation over ICM. This is a stopgap, not a fix — it does not cover the DIAG and RFC vectors.
• Restrict ICM/Web Dispatcher exposure: no SAP HTTP endpoint should face the internet. Put it behind a reverse proxy or VPN, or firewall it to known clients.
• Lock down the gateway and RFC: enforce gw/reg_info and gw/sec_info allowlists, set gw/rem_start = DISABLED where feasible, and segment RFC so a single compromised instance cannot reach every neighbour.
• Constrain the SAP GUI subnet to the workstation ranges that legitimately need DIAG.

4. Hunt for compromise

Assume the app-layer logs are incomplete or tampered, and hunt from the network and the OS both. Map to MITRE ATT&CK:

• T1190 Exploit Public-Facing Application — malformed or oversized Extended Passport headers on ICM/DIAG/RFC; SAP protocol traffic on non-standard ports; RFC connections from hosts that have never spoken RFC before.
• T1059 Command and Scripting Interpreter — child processes spawned by disp+work / icman that are shells, interpreters, or network tools (sh, bash, python, curl, nc). A dispatcher spawning /bin/sh is not normal SAP behaviour.
• T1552.001 Unsecured Credentials and T1003 OS Credential Dumping — reads of the SSFS secure store files (SSFS_<SID>.DAT/.KEY) and SECSTORE access outside a maintenance window.
• T1210 / T1021 Remote Services — a burst of outbound RFC to neighbouring SAP systems shortly after the initial request; new trusted-RFC destinations.
• T1070 / T1562.001 Indicator Removal / Impair Defenses — gaps, truncation, or configuration changes in the Security Audit Log; SAL switched off; trace files cleared.
• T1071 / T1041 Application-Layer C2 / Exfiltration — outbound sessions from an SAP host to never-before-seen destinations; sustained egress from a system that historically only ingests.

Run the Onapsis/Mandiant-style IOC scan against the host and correlate anomalous SAP-facing traffic with unexpected OS command execution and changes to sensitive SAP data or binaries.

5. Eradicate and verify

If you find evidence of execution, patching is not the end. Because the attacker ran as <sid>adm and could read the secure store, rotate everything that account could reach: the SAP database credentials, the SSFS store, any service and RFC-trust credentials, and OS passwords for <sid>adm and sapadm. Verify SAP binaries against known-good checksums. Re-enable and baseline the Security Audit Log, then confirm the system is clean after the patch is live and the credentials are rotated — not before.

Where Zero Hunt fits

Everything above turns on one asymmetry: OVERPASS wins in the pre-auth kernel and then erases its footprints from the host, but it cannot erase the packets. That is the surface Zero Hunt's AI Traffic Analysis was built for. A proprietary deep-learning model trained on billions of PCAP sequences runs four inference heads in parallel — suspicious-traffic detection, malware classification, attack-type identification, and application fingerprinting — at 2.7+ Gbit/s on the appliance GPU, entirely on-prem. The application-fingerprinting head recognises SAP ICM, DIAG, and RFC even on non-standard ports, so a malformed Extended Passport header, a disp+work process suddenly beaconing to a never-seen ASN, or a fan-out of RFC calls to hosts that never receive them is flagged while it happens — not in tomorrow's SIEM digest, and not from a Security Audit Log the <sid>adm attacker already rewrote. When the app-layer evidence is compromised by construction, the wire is the honest witness.

Ahead of the incident, the 10-agent generative pentest answers the reachability question the CVSS score only implies. A change-triggered campaign fires within the hour of a new SAP port appearing on the perimeter; the Recon, Exploit, and Pivot agents map which of your instances expose ICM, DIAG, or RFC, and a per-target exploit written by a local LLM — not pulled from ExploitDB, because during a zero-day window there is nothing to pull — validates whether the crafted EPP path is actually reachable from where an attacker would stand. Every attempt runs in an ephemeral gVisor-hardened container that never touches the host, is backtested in the AI Gym before it reaches production, and is ECDSA-signed for the evidence chain.

That evidence chain is where Automatic Compliance closes the loop: an SAP estate is squarely in NIS2 scope for energy and manufacturing operators and in DORA scope for financial entities, and "show me your last SAP pentest" is a question auditors and insurers now ask by name. Every OVERPASS finding, exposure check, and remediation is mapped across the 32 frameworks and signed at write time, so the record that you found it, proved it, and fixed it is verifiable by construction rather than reconstructed from logs an attacker had write access to.

OVERPASS is patchable in an afternoon. Knowing whether it was already used against you — and being able to prove either answer — is the harder problem, and it is a network-and-evidence problem, not a log problem.