On Wednesday, September 9th at 10:00am EDT, SAP and the Onapsis Research Labs will host a joint threat briefing webinar to discuss these vulnerabilities and other critical issues patched as part of the September 2026 SAP Patch Tuesday release. Register here
CVSS Score: 9.8 (Critical) | Risk Level: Critical, Immediate Action Required
Onapsis and SAP have partnered to mitigate S4GET (CVE-2026-58240), a critical pre-authentication vulnerability in the SAP NetWeaver Message Server. The official fix is available now in SAP Security Note 3759472, and applying it should be an immediate priority for every affected organization.
S4GET is a logic flaw, not a misconfiguration. It is present in SAP’s 9.x kernel lines — the kernels that SAP S/4HANA and SAP S/4HANA Cloud Private Edition run on, and potentially other ABAP-based products as well.. What makes it uniquely dangerous is its reachability: the flaw is triggered through the same public port that every SAP GUI client connects to, so it cannot be firewalled away without breaking the end-user logon. Exploitation requires no credentials, no certificate, and no pre-existing misconfiguration. A successful attack yields full remote code execution as <sid>adm, the OS-level user that runs SAP, on every application server in the cluster.
For veteran SAP defenders, this will sound familiar: S4GET shares the core concept and profile of the 2019 10KBLAZE exploits, but with a significantly broader attack surface.
Onapsis reported this issue to SAP through our ongoing coordinated-disclosure partnership. SAP Product Security Response Team responded swiftly and released a fix as part of its September Security Patch Day, serving as a reflection of the maturity of SAP’s security response process and its strong commitment to protecting its customers. This post makes defenders aware of the risk, describes the shape of the vulnerability at a level actionable for security and SAP Basis teams, and explains what protections are already in place.
As of the date of this publication, the Onapsis Research Labs have not observed active in-the-wild exploitation of these vulnerabilities. We continue to monitor our SAP Global Threat Intelligence Network and will deliver in-product updates and threat insights (including indicators of compromise) to our clients if that happens. We will update this blogpost with any observations for public knowledge and consumption as well.
The Onapsis Research Labs adhere to a strict set of responsible disclosure practices. Consequently, this post will intentionally omit technical exploitation details at this time and is solely focused on helping SAP customers assess exposure and support prompt risk remediation actions.
What is the S4GET (CVE-2026-58240) Vulnerability?
S4GET lets an unauthenticated attacker on the network promote themselves to a trusted node inside an SAP cluster. From there, the path to remote code execution as <sid>adm uses only legitimate SAP functionality.
Two low-level components matter here. The SAP Message Server is the cluster’s broker: it tracks which application servers are up and routes SAP GUI logon requests. It listens on a well-known public port because every SAP GUI client hits it first. The SAP Gateway is the RFC entry point of each application server protected by ACL files (secinfo, reginfo) that define which hosts can register RFC servers or invoke RFC-callable external programs.
The Gateway decides what to trust based on which hosts count as “internal”, and that definition is controlled by the Message Server. S4GET lets an attacker influence it. With a specially crafted packet sent to the Message Server’s public port, an unauthenticated attacker can have an IP treated as trusted. The Message Server accepts the claim and propagates that trust across every application server in the cluster. The attacker then connects to the Gateway from that IP, is admitted as internal, invokes RFC-callable external programs, and obtains remote code execution as <sid>adm.
No authentication is required, and no certificate is checked. Because the attack is delivered against the public port, the one every SAP GUI client legitimately connects to, it succeeds even when secure communications are strictly enabled and the ACLs defenders normally rely on (secinfo, reginfo, ms/acl_info) are flawlessly configured. None of them sits in this path. One control does apply: a separate ACL governs which hosts may open a connection to the external port itself. In practice, it is rarely maintained for reasons covered in the remediation section, and it is a hardening measure – not a substitute for the patch.
The Risk and Impact of S4GET on SAP Landscapes
What elevates S4GET beyond a typical critical CVE is its reachability. Direct internet exposure is fortunately rare, and worth stating plainly: in most estates, the Message Server sits behind the perimeter. Inside the corporate network, it is a different picture. The public port is reachable by every SAP GUI user by design, routinely allowed through the firewalls in front of SAP systems, and cannot be closed without breaking the end-user logon. Any attacker with a foothold on the LAN, whether a phished workstation or a contractor VPN session, is already in position. There is no architectural safe harbor here, only the patch.
Once exploited, the attacker effectively owns the system: ransomware and data destruction, exfiltration of any business record, fraudulent payments and privileged user creation are all possible. For organizations subject to SOX, NIS 2, GDPR, HIPAA, or PCI-DSS, any such malicious action would be a reportable incident of the highest severity.
Comparing S4GET to the 10KBLAZE SAP Vulnerability
10KBLAZE represented a similar risk in 2019 by abusing a permissive ACL on the Message Server’s internal port that was never meant to be exposed (and subsequently hardened by SAP). S4GET arrives at the same destination but through the front door instead:
| 10KBLAZE (2019) | S4GET (2026) | |
|---|---|---|
| Root cause | Misconfiguration | Vulnerability |
| External (Internet) reachability | Rare | Rare |
| Internal (Corporate LAN) reachability | Low (internal-only by design) | High (public by design, required for SAP GUI logon) |
| Affected port | Internal port (39NN) | Public/External port (36NN) |
| Authentication | Not required at disclosure (secured by default since) | Not required |
| Mitigation without functional impact | Straightforward | Architecturally hard, breaks end-user logon |
More information: 10KBLAZE webinar | original disclosure
Why Getting Ahead of This Matters
The SAP community no longer needs to imagine what happens when a critical pre-authentication SAP vulnerability is weaponized before defenders can respond. In early 2025, CVE-2025-31324, an unauthenticated file upload flaw in a SAP NetWeaver component, was discovered through active exploitation in the wild. SAP responded rapidly with patches for it and the related CVE-2025-42999, but multiple waves of attackers had already deployed webshells and executed code on unpatched systems long before many organizations could deploy them. Mandiant 2026 M-Trends report named CVE-2025-31324 the single most exploited vulnerability of the year. It’s also worth noting that, historically, attackers can reverse-engineer SAP patches to weaponize vulnerabilities within 72 hours (as we saw with the RECON vulnerability (CVE-2020-6287), and that window continues to shrink with AI-assisted tooling.
That is precisely the outcome our strategic partnership and coordinated-disclosure partnership with SAP is designed to prevent. With S4GET, the door is hopefully closed before any adversary’s potential discovery, giving customers the maximum possible runway to prepare and patch.
How to Determine Exposure to S4GET
Exposure depends on the kernel a system runs, not the application on top of it.
Kernel 9.16 is the native kernel of SAP ABAP Platform 2025 — the mandatory foundation of SAP S/4HANA 2025, S/4HANA Cloud Private Edition 2025, and standalone ABAP Platform 2025 systems. Do not assume earlier releases are safe. The affected kernel lines are available to previous releases as an upgrade, and many estates have already taken it — an SAP S/4HANA 2023 system, for example, may well be running one. The release tells you nothing here; only the kernel does.
Do not stop at S/4HANA. The affected component is the kernel — shared infrastructure for every ABAP-based system, not something specific to S/4HANA — so other ABAP systems in your landscape may be running an affected kernel, and they would be just as affected.
According to SAP Security Note 3759472, these are the patch levels that carry the fix for each of the four affected kernels. Anything below them should be considered vulnerable:
- 9.16 — PL 100
- 9.18 — PL 32
- 9.19 — PL 17
- 9.20 — PL 7
The check is a single data point: your kernel release and its patch level. Confirm it via:
- SAP GUI: System → Status → Kernel information
- OS level as <sid>adm: disp+work -version.
Anything below these levels requires immediate remediation.
How to Remediate S4GET (CVE-2026-58240)
Applying SAP Security Note 3759472 is the definitive fix, and the only one that fully mitigates the vulnerability. The steps below are about getting it deployed in the right order, and covering the gap in the meantime.
- Assess and identify. Inventory every SAP system running one of the vulnerable kernel/patch-level combinations listed above. For each, determine which networks can reach the Message Server’s public port (36NN).
- Patch anything Internet-facing first. Direct Internet exposure of the Message Server port is fortunately uncommon, but where it exists (whether a legacy DMZ deployment, a misconfigured NAT rule or a forgotten test system), it is the highest-risk population in your estate. Confirm this population is empty rather than assuming it is.
- Patch internal systems, the bulk of the work. This is where nearly all affected systems will sit, and corporate-LAN reachability is the norm for this port rather than the exception. These are second in sequence, not second in importance.
- Monitor for exploitation attempts. Ensure you have visibility into your SAP application layer so that attempts to exploit these vulnerabilities can be detected and investigated.
If you are unable to apply the patch promptly due to operational constraints, we strongly recommend leveraging compensating controls to actively monitor for exploitation and indicators of compromise until patch implementation can occur.
How Onapsis Automates S4GET Mitigation and Protection
As one of the most prolific contributors to SAP security research, the Onapsis Research Labs has discovered and helped remediate well over 1,000 zero-day vulnerabilities in SAP business applications, and continues to partner closely with SAP to protect the global SAP customer base. This reflects the strong, long-standing relationship between the Onapsis Research Labs and SAP’s Product Security Response Team, and SAP’s proactive investment in securing its platform.
Protected BEFORE the Patch
Because the Onapsis Research Labs discovered the vulnerability and helped SAP mitigate it, the intelligence and detection content required to protect against them were developed and delivered as part of the coordinated disclosure process, providing our customers with zero-day coverage prior to the patch being available. Throughout this period, the Onapsis Research Labs have been monitoring the global SAP threat landscape via our Global Threat Intel Network for any early signs of malicious activity. In product, Onapsis Defend has been actively monitoring customer landscapes for S4GET since well before today’s patch release, keeping our customers protected throughout the coordinated-disclosure window.
Supported AFTER the Patch
Zero-day rules in Defend are now promoted to established production rules, effective immediately. Furthermore, Onapsis customers are able to take action within the Onapsis Platform immediately:
- Onapsis Assess has been updated with new checks that identify exactly which systems in your estate are exposed to S4GET, so security and Basis teams can prioritize the patch rollout precisely rather than sweeping the whole landscape.
- Onapsis Defend provides continuous detection for the exploitation pattern, giving teams coverage during the window between disclosure and full patch deployment, the period when exposure is highest.
And the Onapsis Research Labs continue to track exploitation activity, indicators, and attacker behavior in the wild, feeding updated intelligence back into detection content and Threat Dispatches for customers, so protection keeps pace with the evolving threat.
Taken all together, the full product coverage by Onapsis transforms a high-pressure critical patching event into a guided, measurable process. This is what it means for a security vendor to inform and keep SAP customers well ahead of the threat: robust protection before the patch is released, expert guidance through remediation when a patch is released, and continuous monitoring of the threat long after Patch Tuesday has come and gone to ensure customers remain protected.
Conclusion
S4GET is a serious, remotely exploitable, unauthenticated threat to any system running one of the vulnerable kernels. Its severity matches some of the most impactful SAP vulnerabilities Onapsis has disclosed in its history, and its exploitability profile (namely a public port, no authentication and no misconfiguration required) requires immediate attention from every organization running the affected release.
Thanks to the coordinated disclosure between Onapsis and SAP, this door is now closed. That advantage only holds if you act on it.
As a reminder, join us live for our threat briefing webinar with SAP on Wednesday, September 9th at 10 a.m. EDT. Register here.
About the Author
