SAP Overpass S4Get Critical Vulnerabilities 2026 Report

SAP teams need to assess more than internet-facing services when a critical flaw can be reached through familiar business connections. The September 2026 update concerns two serious SAP security issues that may put business systems and connected networks at risk. Administrators need to identify affected systems, judge which connections can reach them, and plan fixes across production and non-production environments. The work matters even when a system does not accept traffic from the public internet. Internal links between SAP systems can still create exposure.

This briefing focuses on decisions SAP administrators and security teams can make now. It explains the issues, outlines the systems and connections to review, and gives a practical way to assign remediation work. The goal is a clear view of exposure and ownership, not alarm for its own sake.

Key Takeaways

• Two critical SAP flaws were addressed on September 8, 2026.
• OVERPASS affects EPP processing, while S4GET affects Message Server authentication.
• Internal SAP GUI and RFC connections can matter alongside web access.
• Review kernel builds and patch levels across all environments.
• Plan downtime for kernel updates and keep monitoring after patching.
• Assign an owner to confirm both security notes are applied.

What Are the SAP Overpass S4Get Critical Vulnerabilities 2026?

SAP’s September 8, 2026 Patch Day addressed two critical, remotely exploitable flaws in SAP components. OVERPASS is CVE-2026-44756, a memory corruption vulnerability in Extended Passport (EPP) Processing. EPP is an SAP request-tracing structure that helps correlate calls across connected systems.

OVERPASS has a CVSS score of 10.0, and S4GET has a CVSS score of 9.8. S4GET is CVE-2026-58240, a missing authentication check in SAP NetWeaver Message Server. SAP Security Note 3747649 addresses OVERPASS, while Security Note 3759472 addresses S4GET. Readers looking up SAP CVE-2026-44756 will find it listed under the OVERPASS identifier.

OVERPASS corrupts memory, while S4GET bypasses an authentication check.

The two lead flaws drove the September security story because of their severity and reach. The same patch day included 19 new security notes and one update to an earlier note. The table also lists two other critical issues from that release, but they are distinct vulnerabilities with separate notes.

CVE-2026-76969 is a credential disclosure flaw in multitenant SAP Cloud Application Programming Model applications. CVE-2026-66768 involves improper access control in SAP NetWeaver SAP GUI for Java. Administrators should track each note separately rather than treat the release as one bundled fix.

How Do OVERPASS and S4GET Work?

The two vulnerabilities fail in different places: one mishandles supplied tracing data, while the other accepts an unauthenticated component registration. OVERPASS stems from missing boundary validation during EPP deserialization, the step that reads structured data into memory.

Normal logon controls do not block OVERPASS because EPP is processed before authentication. An attacker can supply length fields that lead to a memory-safety violation. EPP processing is the vulnerable parsing stage, not a separate network service.

Between ABAP systems, EPP functionality is enabled by default. The tracing structure travels as a connection opens, before normal authentication begins. That timing means roles, password policies, and authorization checks do not stop this attack path.

S4GET affects the Message Server’s check of internal application-server components during registration. Its validation does not adequately confirm that a registering component is authentic. CVE-2026-58240 is therefore a missing-authentication flaw.

An attacker with network access can register an unauthorized component without logging in. This is why CVE-2026-58240 matters even when an organization has strong account controls. The Message Server must be reachable for the registration attempt to matter.

In practical terms, the two flaws involve separate code paths: EPP parsing and Message Server registration. A security review should map which systems can reach those paths, rather than assume user permissions are the main barrier.

For both flaws, administrators should treat network reachability, not account permissions, as the key exposure question.

Which SAP Connections Can Reach OVERPASS?

A vulnerable kernel can be reached through three distinct SAP communication paths, so one closed port does not close the flaw. Web, SAP GUI, and RFC connections can each carry EPP to a vulnerable component.

These are alternate routes to one vulnerability, not three separate flaws. A reachable route can bring tracing data to the same vulnerable EPP processing code, even when another route has been restricted.

The web route can pass through the SAP Internet Communication Manager or SAP Web Dispatcher. Both can process EPP supplied with a web request. A web server or dispatcher in the path does not create a separate vulnerability.

Web requests through ICM and Web Dispatcher

The SAP Internet Communication Manager (ICM) handles web traffic for an SAP system. SAP Web Dispatcher can also receive and pass along web requests. In either setup, EPP supplied with the request can reach the vulnerable processing stage.

Security teams should map the route from the network edge to the application server. A policy that protects one web entry point may leave another route available through a different system.

SAP GUI connections through the Dispatcher

SAP GUI traffic follows a different path. The SAP Dispatcher processes EPP supplied over the SAP GUI protocol. An internal SAP GUI connection can therefore matter even when public web access is blocked.

Teams should include user-facing SAP GUI routes in their exposure review. The connection may begin from a managed workstation or a network segment that still has access to the application server.

RFC connections between systems

SAP systems exchange EPP while establishing Remote Function Call (RFC) connections. RFC links support calls between systems and may cross internal network zones. A system that has no public web service can still receive EPP over an RFC connection.

Onapsis identified these three routes, and the MS-ISAC advisory on EPP processing describes their components. Restricting only one route leaves the others in scope.

Treat every reachable route as relevant until the patched kernel is in place.

What Can Attackers Do After Exploiting These Flaws?

Both flaws can move an attacker from an unauthenticated network request to control over SAP-hosted processes. Successful exploitation can affect the host, stored secrets, business data, and connected systems.

OVERPASS can allow operating-system commands on the SAP host with SAP administrative privileges. S4GET can allow remote code execution as adm on every application server in the cluster, not just one server.

• Run operating-system commands with SAP administrative privileges on the host.
• Read secure-store contents, including database credentials and password hashes.
• Access live session data and extract credentials stored within the system.
• Change application data, system settings, or SAP binaries.
• Use stored credentials or connected systems to move laterally through the network.

These are possible outcomes, not a promise that every exploit will produce each one. The result can depend on which flaw is exploited, the access path, and the system’s role in the SAP environment.

Secure-store contents deserve special attention because they may include credentials used by other services. Teams that find exposed credentials should replace them and review where those credentials grant access. Strong, unique passwords and multi-factor authentication help reduce later misuse, but they do not repair the vulnerable code. A guide to password managers and safer credentials can help teams understand password storage choices.

Session data can also expose active business activity. Changes to configuration or binaries may affect more than a single application, especially when systems share trusted links or accounts.

The business risk includes loss of confidentiality, integrity, and availability, not just a disrupted logon service.

Which SAP Kernel Versions Are Affected?

Kernel release and patch level are the practical starting points for deciding whether a system is in scope. OVERPASS and S4GET have different version ranges, so administrators should check each note against each installed component.

Verify the actual kernel build and patch level instead of relying on the product name alone. A product label may not show which kernel release the system runs.

OVERPASS release lines and Web Dispatcher scope

CVE-2026-44756 affects several kernel families and Web Dispatcher builds. The exact ranges appear in the table. Each row identifies the affected component, so teams can match inventory records to the right release line.

S4GET kernel releases and exclusions

CVE-2026-58240 affects KERNEL versions 9.16, 9.18, 9.19, and 9.20. S4GET appears across the modern 9.x kernel family, including SAP S/4HANA 2025 systems and earlier releases moved to those kernels.

For OVERPASS, Web Dispatcher versions other than 9.16 are not affected. Web Dispatcher included as part of SAP HANA Extended Application Services is also outside the affected scope. These qualifications do not extend to every Web Dispatcher release.

A product name alone cannot show whether a system runs an affected build. Inventory the installed component, release, and patch level, then compare those details with the relevant security note.

Do not treat a Web Dispatcher exclusion as evidence that the connected SAP application servers are patched.

How Broad Is the Current Exposure?

More than 10,000 internet-facing SAP systems were estimated to be potentially exposed to OVERPASS, but that count does not capture every route. The estimate focused on HTTP-reachable systems and undercounted systems behind SAP Web Dispatcher.

Internal reachability still matters, even when public exposure is absent. SAP GUI and RFC connections can reach systems through private networks, so a public-facing count cannot describe an organization’s full exposure.

S4GET adds a practical network concern because it uses the same public port SAP GUI clients use. Blocking that port can disrupt end-user logon, so a broad firewall change may carry a business cost. Security teams need to weigh reachability against the users and services that depend on the connection.

The September 9, 2026 U.S. MS-ISAC advisory reported no known in-the-wild exploitation of CVE-2026-44756 at that time. That dated report describes the status on September 9, not a guarantee about later activity.

Onapsis said the SAPMAP Exploitation Toolkit included proof-of-concept exploits for both OVERPASS and S4GET. A proof of concept shows that an exploit can be demonstrated; it does not establish that criminals used it against live systems.

These details call for care in reading exposure reports. Public web counts, firewall rules, and reports of exploit code each describe different parts of the threat. Internal system-to-system paths can remain open even when an organization has no public SAP entry point.

A proof-of-concept exploit raises urgency, but it is not by itself evidence of confirmed in-the-wild exploitation.

What Should SAP Teams Patch First?

Apply the two September notes promptly, beginning with an inventory that includes systems outside production. Security Note 3747649 is the definitive OVERPASS kernel fix, and Security Note 3759472 addresses S4GET.

Kernel patching requires a maintenance window and a reboot. SAP provides patches for ABAP and Java kernels, plus Web Dispatcher version 9.16, through Note 3747649.

CERT-EU recommends applying both notes as soon as possible. Its advisory on the SAP kernel and Message Server flaws also describes their remote risk. SAP recommends prioritizing patches to protect SAP systems.

Use this four-step work order to turn the notes into assigned tasks:

1. Inventory production and non-production systems, including development, test, disaster recovery, and standalone systems.
2. Compare each installed kernel release and patch level with Security Notes 3747649 and 3759472.
3. Prioritize internet-facing systems, then systems reachable through internal network paths.
4. Schedule downtime and reboots, apply the fixes, and verify patch completion.

The inventory should cover ABAP and Java application servers as well as Web Dispatcher 9.16. Include systems that may not appear in the main production register, such as disaster recovery instances and standalone deployments.

Kernel work needs coordination with service owners because the patch changes running components and requires a restart. A maintenance window gives teams time to apply the update and confirm the system returns to service.

Compare the installed build with the corrected level named in each note. Record the result for every system, rather than closing a task because one server in a cluster was updated.

Record an owner and a confirmed maintenance window for every affected system.

What Can Reduce Risk While Patching?

Network controls can narrow the paths attackers can reach while a kernel update is pending. Access restrictions are temporary defenses, and they need to cover web, SAP GUI, and RFC services where those routes exist.

A temporary HTTP-layer workaround is not a kernel patch. Limit SAP GUI access to managed networks or controlled jump hosts, and restrict RFC services to known systems.

SAProuter and jump hosts can narrow which networks reach SAP services. These controls can reduce exposure by forcing connections through known points. They do not remove vulnerable code from a kernel.

SAP Security Note 3756304 provides an interim filter for HTTP(S) traffic that passes through a properly patched Web Dispatcher. The filter does not cover RFC, DIAG, or ngRFC traffic. It also does not protect application servers that users or systems can reach directly.

That scope matters in mixed SAP environments. A web request may pass through the dispatcher, while an RFC or SAP GUI connection takes another route. Teams should not assume that filtering the web layer covers every connection to the application server.

Standalone Web Dispatcher deployments have a separate distinction. SAP Security Note 908097 applies to standalone Web Dispatcher deployment. Administrators should use the note that matches how the dispatcher runs.

Network changes can also affect normal business traffic. Limit access with the service owners in view, especially where SAP GUI users share a public port or applications rely on RFC links.

Keep the workaround in its HTTP-only scope and do not count it as complete remediation.

How Should Teams Detect and Validate an Attack?

A clean patch status does not establish that a system was not targeted before remediation. Keep monitoring after the fix because activity may have occurred before the vulnerable code was removed.

Suspicious signs need investigation, but no single sign proves exploitation. Combine SAP application records with network and host-level visibility to understand what happened.

Look for unusual SAP and network activity

Review SAP and network activity for changes that do not fit normal service patterns. Check the following five areas:

• Unexpected SAP process terminations or restarts.
• Unusual requests to SAP web services or connections from unapproved IP addresses.
• Abnormal RFC activity, including calls that do not match expected system links.
• Unexpected operating-system commands or new files under SAP service accounts.
• SAP configuration changes or unexpected outbound network connections.

Compare events with known maintenance and business activity before drawing conclusions. A restart can have a routine cause, while an unexpected command may need immediate review. Host records can show actions that SAP application logs do not capture.

Network records add another view by showing where connections began and what systems they reached. Application logs can help teams spot unusual requests or technical-user behavior. Together, these records give investigators a fuller timeline.

Check operating-system activity and post-patch state

Review operating-system activity tied to SAP service accounts, including adm. Look for commands, files, and executables that lack an approved owner or change record.

Validate that the patched kernel is running on each affected system and check that connected application servers match the deployment record. A corrected build closes the vulnerable code path, but it cannot show whether someone used the earlier version.

Keep the same monitoring in place after remediation. Search for older activity that may have started before the patch window, and retain enough event history to compare system, application, and network records.

Patch completion and incident clearance are separate checks; a fixed kernel does not rule out earlier access.

Escalate unexplained SAP service-account commands for immediate host and application investigation.

Conclusion

Treat both issues as urgent landscape-wide work, not isolated internet-facing server problems. Kernel patches close the vulnerable code paths; network controls only reduce risk while teams prepare the update.

Assign owners to check the affected systems, apply both notes, and confirm each deployment. Keep monitoring after patching so earlier activity does not go unnoticed.

Assign an owner today to verify deployment of both SAP Security Notes across the affected estate.