Full Disclosure mailing list archives

nullFaktor Security Advisory < 2026-09-10 >
===========================================================
Title:               Pre-Authentication Remote Code Execution in SAP
                     Extended Passport (EPP) processing library
Affected Components: ICM, SAP Web Dispatcher, dialog work processes

Vulnerability:       Stack based Buffer Overflow
CVE:                 CVE-2026-44756

Impact:              Critical
CVSS 4.0 Vector:     CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:
                     H/VI:H/VA:H/SC:H/SI:H/SA:H
CVSS 4.0 Score:      10
SAP CVSS 3.0 Score:  10.0
SAP CVSS Vector:     CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Products:            SAP NetWeaver AS ABAP and Java
                     SAP Web Dispatcher
Affected Versions:   NetWeaver kernel releases and patch levels:
                     see the correction table below
                     SAP Web Dispatcher 9.16, patch level below 100

Vendor Homepage:     http://www.sap.com

SAP Note:            3747649 (version 7, released 2026-09-08)

Date:                2026-09-10
Author:              Raschin Tavakoli | nullFaktor GmbH
                     https://www.nullfaktor.com
                     office () nullfaktor com
Blog:                https://www.nullfaktor.com/blog/
                     cve-2026-44756-sap-netweaver-pre-auth-rce

Vulnerability
===============
During our research we discovered a stack-based buffer overflow in
the Extended Passport (EPP) processing, kernel code shared by
several SAP components: the SAP Internet Communication Manager
(ICM), the SAP Web Dispatcher, and the disp+work work processes of
the ABAP application server. Missing bounds validation on
externally supplied metadata corrupts stack memory and allows an
unauthenticated remote attacker to redirect the execution flow,
gaining full control of the SAP server.

The vulnerable code is reachable through several protocols, all of
them before authentication: HTTP and HTTPS, the WebSocket RFC
(NGRFC) protocol, classic RFC, and the SAP GUI (DIAG) protocol.

This advisory demonstrates three of these paths in the laboratory:

1. HTTP(S) into the ICM: the overflow executes inside the Internet
   Communication Manager itself.
2. WebSocket RFC (NGRFC) into a disp+work dialog work process: the
   Internet-facing ICM terminates the WebSocket connection and
   hands the crafted NGRFC login envelope to a dialog work process,
   which parses it before any logon check. With an SAP Web
   Dispatcher in front, it tunnels the upgraded connection to the
   ICM first.
3. Classic RFC into a disp+work dialog work process: the gateway
   accepts the same TLV login structure, including the crafted
   passport, before sign-on.

NGRFC, SAP's WebSocket-based Next Generation RFC, tunnels classic
RFC (a protocol family from the R/2 and R/3 era) over WebSocket and
HTTPS. Until NGRFC, work processes were reachable only through the
internal DIAG and classic RFC ports. NGRFC exposes the work
process, the component that executes the ABAP business logic and
holds database connections, credentials and active user sessions,
through the Internet-facing HTTPS port for the first time. Systems
whose administrators disabled WebSocket support, believing this
path to be closed, remain fully exposed: laboratory tests showed
the vulnerable code is still reachable without authentication over
the Internet-facing port. The classic RFC protocol carries the same
Extended Passport processing, so transport-level switches cannot
substitute for the kernel patch.

In the laboratory, nullFaktor escalated the overflow over the
network to full remote code execution, in the context of the ICM
process or, via the WebSocket RFC path, of a disp+work dialog work
process. The code execution chain combines control of the saved
instruction pointer with a memory leak that resolves process
addresses and defeats ASLR. The memory-leak primitive, the resolved
address data, the payload and the detailed trigger conditions are
withheld from this advisory for now and will be published at a
later time. The leak will be covered in a separate advisory.

Because the EPP processing code is part of the kernel library linked
into the work processes themselves, the same input also reaches a
disp+work process over classic RFC (gateway port 33<NN>) and over
the DIAG protocol (SAP GUI logons, dispatcher port 32<NN>). The
classic RFC path is confirmed in the laboratory (see the Proof of
Concept section); the DIAG path follows from the same shared code.

The affected stack frame is not protected by a stack canary,
although the binary is compiled with canary support, so the
overwrite continues uninterrupted until the function returns into
the chosen address. The Proof of Concept section verifies this
against the binary and at runtime.

The EPP component and the missing boundary validation are identified
in SAP Security Note 3747649.

Vendor description:
===================
SAP SE is a European multinational software company based in Walldorf,
Baden-Wuerttemberg, Germany. It develops enterprise software to manage
business operations and customer relations.

SAP is the world's largest enterprise resource planning (ERP) vendor and
the largest software company in Europe. 77% of the world's transaction
revenue touches an SAP system, and 87% of total global commerce is
generated by SAP customers. 92% of the Forbes Global 2000 companies run
SAP, as do 98% of the 100 most valued brands, with over 440,000
customers in 180+ countries.

Tested Environment:
====================
Product:     SAP NetWeaver AS ABAP (S/4HANA)
Kernel:      793, patch 101 (Aug 2 2024)
SAP_BASIS:   757 SP 3
Platform:    Linux x86_64

Affected Products and Correction Levels:
========================================
The following vendor scope and correction levels are taken from SAP
Security Note 3747649, version 7, released September 8, 2026.

Affected products according to SAP:

- SAP NetWeaver AS ABAP and Java with kernel patch levels below the
  applicable correction level listed in the note.
- SAP Web Dispatcher 9.16 with patch levels below 100.

SAP explicitly excludes other SAP Web Dispatcher versions and the Web
Dispatcher included in SAP HANA Extended Application Services.

All kernel releases named in the note are listed with their correction
levels in the table below.

Correction entries from the note's Support Package Patches section:

Software component / variant                 Support Package Patch Level
-------------------------------------------  --------------- -----------
SAP KERNEL 7.22 EXT, 64-BIT / 64-BIT UC      SP1518           001518
SAP KERNEL 7.22_EX2, 64-BIT / 64-BIT UC      SP1518           001518
SAP KERNEL 7.22_EX3, 64-BIT / 64-BIT UC      SP1518           001518
SAP KERNEL 7.53, 64-BIT / 64-BIT UNICODE     SP1610           001610
SAP KERNEL 7.54, 64-BIT / 64-BIT UNICODE     SP646            000646
SAP KERNEL 7.77, 64-BIT UNICODE              SP912            000912
SAP KERNEL 7.93, 64-BIT UNICODE              SP401            000401
SAP KERNEL 7.93, 64-BIT UNICODE              SP412            000412
SAP KERNEL 8.04, 64-BIT UNICODE              SP242            000242
SAP KERNEL 9.16, 64-BIT UNICODE              SP100            000100
SAP KERNEL 9.18, 64-BIT UNICODE              SP029            000029
SAP KERNEL 9.19, 64-BIT UNICODE              SP014            000014
SAP KERNEL 9.20, 64-BIT UNICODE              SP004            000004
SAP WEB DISPATCHER 9.16                      SP100            000100

SAP states that higher patch levels also contain the correction for
the applicable release. For kernel 7.93, the note lists both patch 401
and patch 412 without explaining the distinction. Both entries are
preserved here. Consult SAP's package applicability when selecting the
update for a particular installation.

As of note version 7 (September 8, 2026), no separate correction entry
exists for plain kernel 7.22 or kernel 7.89, so no fixed patch level
can be stated for these releases. SAP advises that kernels that are
out of maintenance and for which no correction is available be
upgraded to the corresponding downward-compatible kernel (DCK). See
SAP Note 2083594.

The note's Software Components section also lists WEBDISP 9.18,
9.19 and 9.20. The note does not explain these entries. Because
SAP's explicit affected-release statement limits the affected Web
Dispatcher product to version 9.16 and states that other Web
Dispatcher versions are not affected, these component entries are
not treated as affected Web Dispatcher versions in this advisory.

Timeline:
=========
2026-07-14 nullFaktor reports the vulnerability to SAP PSRT
           (responsible disclosure)
2026-07-14 SAP assigns ticket PSINC0012548
2026-07-15 SAP PSRT informs nullFaktor that the vulnerability was
           also discovered by another researcher and that a patch is
           planned for the August 11 patch day
2026-07-15 SAP PSRT confirms that nullFaktor will be credited on
           SAP's security acknowledgement page
2026-08-06 nullFaktor asks SAP whether the patch will be released
           on the August patch day as planned
2026-08-06 SAP PSRT confirms a delay. The patch is now scheduled
           for September
2026-09-08 SAP releases the patch (SAP Security Note 3747649).
           SAP's security acknowledgement page lists the other
           researcher for CVE-2026-44756, but not nullFaktor.
           nullFaktor asks SAP PSRT to correct this
2026-09-10 SAP PSRT apologizes for the omission and commits to
           crediting nullFaktor on the acknowledgement page with
           the October 2026 patch day
2026-09-10 Public advisory release

Attribution: nullFaktor identified this vulnerability independently
during its own research and confirmed it in the laboratory. SAP PSRT
informed nullFaktor on 2026-07-15 that the vulnerability had also
been discovered by another researcher. Onapsis Research Labs
separately reported the vulnerability to SAP and published it under
the name OVERPASS, describing the web, SAP GUI and classic RFC
access vectors without technical exploitation detail. The WebSocket
RFC (NGRFC) transport into dialog work processes documented in this
advisory is not covered there.

Vendor Recommendations (SAP Security Note 3747649)
=================================================
Apply the corrections described in SAP Security Note 3747649, released
on September 8, 2026, using the applicable correction levels listed in
this advisory.

SAP NetWeaver AS ABAP and Java:

1. Apply the latest SP Stack Kernel if it already contains the
   correction. Consult SAP Note 2083594 for kernel versions and patch
   levels. Otherwise, SAP states that the next SP Stack Kernel will
   deliver the correction. Use the hotfix if the correction is needed
   on short notice.
2. If no correction is available for an out-of-maintenance kernel,
   upgrade to the corresponding downward-compatible kernel (DCK),
   following SAP Note 2083594.
3. Before installing, review the regression note for the target patch
   level. SAP Note 1802333 explains how to find this information.
4. Follow SAP Note 19466 for downloading and installing kernel patches.

Kernel update packages named by SAP:

- Hotfix: dw.sar.
- SP Stack Kernel: SAPEXE.SAR and SAPEXEDB.SAR.

For detailed update-strategy recommendations, SAP refers to the paper
"Update Strategy for the Kernel of the Application Server ABAP in On
Premise Landscapes".

SAP Web Dispatcher:

- Standalone deployment: use SAPWEBDISP.SAR and follow SAP Note 908097
  for the recommended version, download and installation procedure.
- Embedded deployment: use dw.sar, or SAPEXE.SAR and SAPEXEDB.SAR,
  following the Application Server kernel patching procedure.
- SAP Note 3115889 explains standalone versus embedded deployment.

SAP Host Agent:

- SAP also recommends installing the newest SAP Host Agent patch
  level. The note does not specify a minimum Host Agent level.

Temporary workaround:

SAP Note 3756304 documents a workaround exclusively for HTTP(S)
traffic received via an SAP Web Dispatcher updated to the patch
levels listed there. It does not protect other protocols or a
directly reachable application server. SAP describes this as a
temporary measure and strongly recommends applying the
correction from SAP Note 3747649.

For frequently asked questions, refer to SAP Note 3776034.

Additional interim recommendations from nullFaktor:

Until the affected systems are patched, restrict network access to
their SAP services (HTTP/HTTPS as well as RFC/WebSocket RFC) to
trusted source addresses.

For the WebSocket RFC path in particular:

1. Block WebSocket upgrade requests to the RFC endpoint at the
   firewall on all Internet-facing ICM and SAP Web Dispatcher ports.
   Apply this block even where WebSocket support is already disabled
   in the SAP configuration: the toggle is an application-side
   setting, while the vulnerable envelope parsing runs before any
   logon validation. Enforce the restriction at the network perimeter
   instead of relying on the configuration switch.
2. Also restrict classic RFC access (SAP dispatcher port 32<NN>,
   gateway 33<NN>, message server 36<NN>) to trusted system-to-system
   networks.

These are interim measures only; the kernel patch from SAP Note
3747649 is the sole complete fix.

Attack Scenario
===============
An unauthenticated network attacker sends a crafted HTTP request to
an affected ICM or SAP Web Dispatcher service, a crafted WebSocket
RFC (NGRFC) request that reaches the same vulnerable processing
inside a disp+work dialog work process, or a crafted SAP GUI (DIAG)
or classic RFC request carrying the same metadata to a work
process. Vulnerable request-metadata processing occurs before
authentication. The trust boundary that RFC traffic is
internal-only, valid since the R/2 era, no longer holds: NGRFC
moves it onto the same TLS port that serves ordinary HTTPS. In the
laboratory, the resulting stack-memory corruption was escalated
from process crash to remote code execution.

Request construction and technical trigger details are withheld from
this public advisory.

Proof of Concept
================

PoC source code is withheld from this public advisory. The proof of
concepts will be published after a grace period, giving customers
time to patch.

The PoC scripts shown below read the target process addresses from
/proc (laboratory convenience). Remote exploitation resolves the
same values through the memory leak. The leak will be published in
a separate advisory.

The following console output from the laboratory was run against the
HTTPS port, without any debugger attached. The crash is observable
purely from the outside through the ICM process restart (function
name masked):

$> python3 poc-icm-https.py 192.168.13.37 50001
[*] 192.168.13.37:50001 (HTTPS)  rip=0xdeadbeef
[*] icman pid before: 2539932
[+] sent; ********() returns into 0xdeadbeef
[+] ICM restarted (pid 2539932 -> 2543020)

The request again, this time with the debugger attached to the fresh
Internet Communication Manager process (icman, pid 2543020):

$> sudo pwndbg -p 2543020   # target: icman (ICM)

The following is an excerpt from the debugger output from that run
(pwndbg 2026.07.29 / GNU gdb 17.2). The dereferenced memory contents
at the end of pointer chains are masked, as they derive from the
crafted request payload:

pwndbg> continue
Continuing.

Thread 4 "SAP_LAB_00_ICM" received signal SIGSEGV, Segmentation fault.
0x00000000deadbeef in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | WX | RODATA
---------------------------[ REGISTERS ]---------------------------
 RAX  0x7
 RBX  0x55ee46afc000 --> 0x55ee463b1128 --> ********
 RCX  0x7f691d0cb287 (<lseek64+9>:    cmp rax,0xfffffffffffff000)
 RDX  0x1
 RDI  0x55ee46bbbaf0 --> 0x0
 RSI  0x1
 R8   0x55ee46bbbaf0 --> 0x0
 R9   0x0
 R10  0x48 ('H')
 R11  0x246
 R12  0x55ee46afc000 --> 0x55ee463b1128 --> ********
 R13  0x55ee46afc000 --> 0x55ee463b1128 --> ********
 R14  0x55ee46afc000 --> 0x55ee463b1128 --> ********
 R15  0x55ee46afc000 --> 0x55ee463b1128 --> ********
 RBP  0x55ee46afc000 --> 0x55ee463b1128 --> ********
 RSP  0x7f68e00a5250 --> 0x55ee46afc000 --> ********
 RIP  0xdeadbeef
---------------------------[ DISASM ]------------------------------
Invalid address 0xdeadbeef
---------------------------[ STACK ]-------------------------------
00:0000| rsp 0x7f68e00a5250 --> 0x55ee46afc000 --> ********
...         3 skipped
04:0020|     0x7f68e00a5270 --> 0x0
05:0028|     0x7f68e00a5278 --> 0x55ee46afc000 --> ********
...         2 skipped
--------------------------[ BACKTRACE ]-----------------------------
 > 0 0xdeadbeef
   1 0x55ee46afc000 ********
   2 0x55ee46afc000 ********
   3 0x55ee46afc000 ********
   4 0x55ee46afc000 ********
   5 0x0
-------------------------[ LAST SIGNAL ]---------------------------
Program received signal SIGSEGV (fault address: 0xdeadbeef).

This output documents instruction-pointer redirection in the
laboratory. Combined with the withheld memory leak, this primitive
was escalated to full remote code execution in the tested
environment.

The missing stack canary may seem to contradict the binary's hardening
status, so it is verified explicitly. pwndbg's checksec reports:

pwndbg> checksec
File:       /usr/sap/LAB/D00/exe/icman (kernel 793 patch 101)
Arch:       amd64
RELRO:      Full RELRO
Stack:      Canary found
NX:         NX enabled
PIE:        PIE enabled
FORTIFY:    Enabled
...

"Canary found" only means the mechanism is compiled in; the compiler
instruments only functions matching its default heuristic, and the
affected function is not one of them: its 473-instruction disassembly
contains no canary check. The crash above proves it at runtime, as the
function returns into 0xdeadbeef instead of aborting in
__stack_chk_fail.

Second transport: WebSocket RFC (disp+work work process)
--------------------------------------------------------
The same vulnerable deserialization is reachable without any HTTP
header: via a WebSocket upgrade to the RFC endpoint on the ICM TLS
port, followed by one NGRFC login envelope whose inner TLV carries the
crafted passport. This path executes inside a disp+work dialog work
process, before the logon is checked. The affected function in the
work process binary is likewise built without a canary (214-instruction
disassembly, no canary check).

Console output from the laboratory run, without any debugger attached.
The crash is observable from the outside through the work process
dying and being restarted by the SAP dispatcher (trigger details
masked):

$> python3 poc-dia-wsrfc.py
[*] 192.168.13.37:50001 (WS-RFC/TLS)  ********  rip=0xdeadbeef
[+] CRASH: DIA WP [2164291] died; ********() returned into 0xdeadbeef

For the debugger run, any free dialog work process may serve the
request, so a debugger was attached to each of them:

$> ps -eo pid,comm | grep SAP_LAB_00_W
2385293 SAP_LAB_00_W1
2416269 SAP_LAB_00_W4
...                        # 8 dialog work processes in total
$> sudo pwndbg -p <pid>    # repeated for each work process

The debugger excerpt below is from the work process that served the
request (pid 2385293):

$> sudo pwndbg -p 2385293   # target: disp+work
                            # (DIA work process)

Debugger output from that run (pwndbg 2026.07.29 / GNU gdb 17.2), same
masking rules as above:

pwndbg> continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00000000deadbeef in ?? ()
LEGEND: STACK | HEAP | CODE | DATA | WX | RODATA
---------------------------[ REGISTERS ]---------------------------
 RAX  0x7
 RBX  0x55bc1645a000 --> 0x55bc15314d98 --> ********
 RCX  0x7fa5b72cb287 (<lseek64+9>:    cmp rax,0xfffffffffffff000)
 RDX  0x7fa5b72cb287 (<lseek64+9>:    cmp rax,0xfffffffffffff000)
 RDI  0x55bc4007e830 --> 0x0
 RSI  0x7
 R8   0x247cbd8
 R9   0x0
 R10  0x35
 R11  0x246
 R12  0x55bc1645a000 --> 0x55bc15314d98 --> ********
 R13  0x55bc1645a000 --> 0x55bc15314d98 --> ********
 R14  0x55bc1645a000 --> 0x55bc15314d98 --> ********
 R15  0x55bc1645a000 --> 0x55bc15314d98 --> ********
 RBP  0x55bc1645a000 --> 0x55bc15314d98 --> ********
 RSP  0x7fffd6c21cc0 --> 0x55bc1645a000 --> ********
 RIP  0xdeadbeef
---------------------------[ DISASM ]------------------------------
Invalid address 0xdeadbeef
---------------------------[ STACK ]-------------------------------
00:0000| rsp 0x7fffd6c21cc0 --> 0x55bc1645a000 --> ********
...         4 skipped
05:0028|     0x7fffd6c21ce8 --> 0x0
06:0030|     0x7fffd6c21cf0 --> 0x55bc1645a000 --> ********
07:0038|     0x7fffd6c21cf8 --> 0x55bc1645a000 --> ********
--------------------------[ BACKTRACE ]-----------------------------
 > 0 0xdeadbeef
   1 0x55bc1645a000 ********
   2 0x55bc1645a000 ********
   3 0x55bc1645a000 ********
   4 0x55bc1645a000 ********
   5 0x55bc1645a000 ********
   6 0x0
-------------------------[ LAST SIGNAL ]---------------------------
Program received signal SIGSEGV (fault address: 0xdeadbeef).

0xdeadbeef in RIP is the synthetic marker. The crashing thread is
a disp+work dialog work process, demonstrating that identical
control is reachable through the WebSocket RFC transport.

Third transport: classic RFC (disp+work work process)
-----------------------------------------------------
The same TLV login structure, including the crafted passport, is
also accepted by the native RFC protocol on the gateway port. The
parse runs before sign-on; console output from the laboratory run
(function name masked):

$> python3 poc-classic-rfc.py 192.168.13.37 3300
[*] 192.168.13.37:3300 (RFC)  ********  rip=0xdeadbeef
[+] CRASH: DIA WP [2231557] died; ********() returned into 0xdeadbeef

Full remote code execution (both paths)
---------------------------------------
With the instruction pointer under control, a short ROP chain riding
in the same crafted request executes an arbitrary command via
system() in the target process. This was verified in the laboratory
for both paths, fired over the network against the target system.
Each run creates a marker file on the target system, owned by the
operating-system account that runs the SAP kernel:

ICM path (HTTPS):

$> python3 poc-icm-rce.py
[*] 192.168.13.37:50001 (HTTPS)  pie=********  S=********
[*] chain: ******** -> system@plt -> ********
[+] sent; system() runs as the icm process user
$> ls -la /tmp/nullfaktor_proof_icm      # on the target system
-rw-r--r-- 1 labadm sapsys 0 Sep 10 09:53 /tmp/nullfaktor_proof_icm

WebSocket RFC path (disp+work dialog work process):

$> python3 poc-dia-rce.py
[*] pie=********  S=********
[*] chain: ******** -> system@plt -> ********
[*] 192.168.13.37:50001 (WS-RFC/TLS)  ********  envelope=2860B
[+] sent; system() runs as the SAP work process user
[+] MARKER: -rw-rw---- 1 labadm sapsys 0 /tmp/nullfaktor_proof_dia

In the laboratory, process addresses were read from /proc. In the
remote attack this role is filled by the memory leak referenced
above, which discovers both values. Chain contents, gadget offsets
and the executed command line are withheld from this advisory.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

About nullFaktor

nullFaktor is an Austrian Cyber Security company offering services such
as Penetration Testing, Cyber Defense, and IT Security Consulting.

In addition, nullFaktor runs a dedicated SAP Security Division focused
on SAP Cyber Security. Services include SAP Penetration Testing as well
as strategic SAP Security Advisory.

Ongoing research activities strengthen nullFaktor's consulting and
assessment services by ensuring up-to-date knowledge of modern attack
vectors, misconfigurations, and pitfalls in secure architecture
patterns. This enables clients to make informed decisions and improve
their IT security posture based on real-world risk scenarios.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Want to strengthen your IT or SAP security posture?
Get in touch at https://www.nullfaktor.com/#kontakt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mail:  office at nullfaktor dot com
Web:   https://www.nullfaktor.com
Blog:  https://www.nullfaktor.com/blog
X.com: https://x.com/_nullfaktor

EOF Raschin Tavakoli / @2026
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

• CVE-2026-44756: Pre-Auth RCE in SAP EPP Processing (ICM, Web Dispatcher, disp+work) Raschin Tavakoli via Fulldisclosure (Sep 22)