SAP OVERPASS (CVE-2026-44756) remains an urgent patching priority for SAP solutions. As reported in our advisory earlier this month, the vulnerability affects the processing of SAP Extended Passport (EPP) data in shared SAP Kernel code. It can enable attackers to execute arbitrary operating system commands with SAP service account privileges by triggering memory corruption through a buffer overflow prior to authentication. SAP Security Note 3747649 provides the applicable corrections.
There have been several important developments since the original disclosure of the vulnerability. Security researchers have identified an additional attack route through WebSocket-based RFC and proof-of-concept material has been released in a publicly available exploitation toolkit.
Researchers investigating the EPP flaw demonstrated pre-authentication attack paths through HTTP(S), RFC and WebSocket-based Next Generation RFC (NGRFC). The NGRFC attack path enables attackers to deliver an RFC login envelope to a dialog work process through an HTTPS endpoint, routed through the SAP Web Dispatcher. Restricting traditional RFC ports alone therefore does not address every RFC-related route. Researchers also identified SAP GUI (DIAG) as a reachable protocol path. The public advisory withholds the full exploit construction details.
Another change is the release of SAPMAP on September 16, a public SAP discovery and exploitation toolkit. Security researchers report that OVERPASS proof-of-concept material was present in the repository history for OVERPASS even though the toolkit’s maintainers initially indicated that the related exploits were withheld. The researchers advise defenders to assume that copies of this material are publicly available.
Given the recent developments in the OVERPASS vulnerability, customers should urgently patch affected systems. Inventory ABAP and Java application servers and standalone and embedded Web Dispatchers. Review the Kernel release and patch levels for each system and component against the required levels detailed in SAP Security Note 3747649. Where immediate patching is not possible, review the prerequisites and scope of the temporary HTTP(S) workaround in Note 3756304 and the FAQ in Note 3776034.
In addition, the compensating controls below can be considered while patches are being deployed.
Filter SAP-Passport at the Web Layer
For incoming HTTP(S) traffic routed through SAP Web Dispatcher, administrators can use an HTTP modification action to remove the SAP-Passport header before forwarding the request. This include the following profile parameter setting:
icm/HTTP/mod_0 = PREFIX=/,FILE=$(DIR_GLOBAL)/security/data/icm_filter_rules.txt
The referenced file in the parameter value should contain:
RemoveHeader SAP-Passport
An available icm/HTTP/mod_<xx> slot may be used instead of _0. PREFIX=/ applies the rule across the HTTP URL namespace. HTTP header names are case-insensitive. Further details on Web Dispatcher header-modification mechanisms are available in the SAP Help Portal.
For HTTPS requests, Web Dispatcher must terminate TLS to inspect and remove the header. Verify that clients cannot bypass the Web Dispatcher and reach application-server ICM ports directly. Test the rule against important applications and integrations: removing SAP Extended Passport data can affect distributed tracing, request correlation, diagnostics and performance analysis. Log attempted submissions from untrusted sources before the removal point where possible.
This filter addresses the specified HTTP header route only. It does not remove EPP data carried in SAP GUI, classic RFC or WebSocket RFC protocol structures, and it must not be presented as complete protection against OVERPASS. Where NGRFC is unnecessary, consider blocking WebSocket upgrades to RFC endpoints at the perimeter.
Limit SAP GUI, RFC and Network Access
For SAP GUI (DIAG), restrict access to managed user networks, authorized VPNs, and controlled jump hosts. Configure an SAP GUI access control list on each relevant application server instance and set rdisp/acl_file to its file path to limit which client hosts can connect. Confirm the actual dispatcher listeners, including instance-dependent ports commonly numbered 32<NN> and any alternate routes, and apply network restrictions to all of them. EPP cannot be stripped from DIAG using an HTTP header rule. SNC, where configured and enforced for the relevant clients, can strengthen connection authentication and protection, but it does not replace patching or source restrictions.
For RFC, restrict gateway and related SAP service access to known SAP systems and authorized integration servers. Configure a network-based gateway ACL and set gw/acl_file in each relevant gateway instance profile to permit connections only from approved client IP addresses. Review the actual dispatcher 32<NN>, gateway 33<NN>, and message-server 36<NN> ports as applicable; 34<NN> is commonly associated with a secure gateway configuration and should not be treated as the sole RFC port. Enforce SNC where supported and operationally appropriate, and review trusted RFC destinations and gateway reginfo and secinfo rules. An HTTP RemoveHeader action does not sanitize RFC payloads.
Limit inbound access to SAP Web Dispatcher and ICM HTTP(S) listeners through firewalls, network ACLs, and cloud security groups. For each relevant icm/server_port_<xx> listener, use the ACLFILE option to restrict client IP addresses or ranges, and the HOST option to bind the port to the intended network interface. These options apply to both Web Dispatcher and ICM listeners. Where traffic arrives through a reverse proxy, account for the proxy’s source address in the listener ACL.
Route external traffic through an approved reverse proxy, block direct access to backend application-server ICM listeners, and allow only the required proxy-to-backend addresses and ports. On Internet-facing installations, restrict source IPs where feasible. Use wdisp/permission_table to publish only required URL paths through Web Dispatcher, or icm/HTTP/auth_<xx> where request-level URL and client restrictions are needed. Keep administrative and diagnostic endpoints off the public Internet. Apply the same segmentation review to development, test, and recovery systems that have connections or credentials providing a route into production.
Monitor for Attempted Exploitation Activity
Monitor Web Dispatcher and ICM access, security, error and trace logs centrally, together with SAP process, operating-system and network telemetry. Review repeated malformed requests, unusually large or abnormal EPP-related data, parsing errors, abnormal connection closures, and unexpected ICM or work-process crashes. Baseline ordinary HTTP, SAP GUI and RFC traffic so repeated attempts from one source, probing of multiple SAP systems and traffic from untrusted networks stand out. Note that removing a header before it reaches a backend may also remove backend evidence of the attempted request. Configure logging or detection at the entry point.
Investigate suspected attempts by correlating request timing with SAP traces, host audit events and outbound connections. Look for OS commands run by SAP service accounts such as <SID>adm, access to the SAP secure store, new or altered files, changes to binaries or profiles, and unusual connections to other SAP systems. Block suspect sources where appropriate and isolate an affected host if evidence indicates compromise. Preserve logs and process evidence for the investigation. A crash or malformed header is an indicator to investigate, not proof of successful code execution.
Prioritize Patching
Prioritize the deployment of SAP corrections for systems exposed to untrusted networks, including Internet-facing SAP Web Dispatcher and SAP NetWeaver environments. Once externally accessible systems have been secured, remediate internally accessible production systems, integration platforms, and non-production environments in order of business criticality and exposure. Verify that SAP Kernel, SAP Web Dispatcher, and other affected components have been updated to the corrected versions specified in the latest SAP Security Notes and confirm successful implementation through post-deployment validation.
Until remediation is fully completed across the landscape, implement compensating controls to reduce the attack surface and limit the likelihood of successful exploitation. These controls may include network segmentation, access restrictions, Web Application Firewall (WAF) protections, strengthened monitoring and alerting, and enhanced logging of HTTP(S) requests targeting SAP services. Organizations should maintain heightened monitoring during and after the rollout to detect potential indicators of compromise and verify the effectiveness of remediation activities.
This vulnerability should be treated as a high-priority security issue due to the potential for unauthenticated remote exploitation of affected SAP systems.
Cybersecurity Extension for SAP
The Cybersecurity Extension for SAP identifies affected SAP solutions, validates compensating controls, and detects indicators of attempted exploitation for OVERPASS. The SAP-certified add-on supports the following to help protect SAP systems from the vulnerability:
- Discovery of affected systems and components, including ABAP, Java, SAP Kernel, and standalone or embedded SAP Web Dispatcher installations.
- Identification of vulnerable Kernel and Web Dispatcher versions requiring remediation, prioritizing systems exposed to untrusted networks or interconnected through trusted SAP communications.
- Review of profile parameters associated with compensating controls for OVERPASS, including HTTP header filtering, network access restrictions, protocol restrictions, and other recommended mitigations.
- Assessment of protocol access controls for HTTP(S), DIAG, RFC, and other potentially exposed communication paths, ensuring access is restricted to authorized users, systems, and networks.
- Analysis of secure communication configurations, including Secure Network Communications (SNC) settings for RFC traffic and TLS/SSL configurations for HTTP(S), SAP Web Dispatcher, and ICM services, to identify weak encryption, missing protections, or insecure trust configurations.
- Discovery and mapping of trusted RFC connections across the SAP landscape, including trusted RFC destinations, stored credentials, and cross-system trust relationships that could enable lateral movement or privilege escalation following compromise of a vulnerable system.
- Analysis of security configurations for Gateway ACLs, secinfo, reginfo, SAP GUI ACLs, Web Dispatcher permission tables, ICM listener ACLs, SNC settings, and RFC destination security controls.
- Detection of suspicious or malformed HTTP requests, abnormal SAP-Passport usage, protocol parsing errors, unusual WebSocket activity, and other indicators of attempted OVERPASS exploitation.
- Monitoring of Web Dispatcher, ICM, audit, system, and operating system logs for indicators of attempted exploitation, unauthorized access attempts, and anomalous communications between SAP systems.
- Identification of suspicious operating system activity, including command execution by SAP service accounts, unauthorized file changes, and access to sensitive SAP resources.
- Detection of insecure exposure of SAP services to untrusted networks, including externally accessible application servers, message servers, gateways, RFC services, and Web Dispatcher instances.
- Support for attack path analysis and remediation prioritization by correlating vulnerable systems, trusted RFC relationships, SNC/TLS configurations, and network exposure to identify the highest-risk paths an attacker could use to traverse the SAP landscape.
The Cybersecurity Extension for SAP provides organizations with the capability to identify vulnerable SAP assets, validate mitigation measures, detect indicators of compromise, and accelerate the response to emerging SAP threats such as OVERPASS.