Introduction
A critical SAP advisory arrives while the team is planning its next maintenance window. A week later, researchers publish a toolkit containing proof-of-concept code for the newly patched flaws. The vulnerable software has not changed. The assumptions behind the response timetable may have.
That is the question raised by SAPMAP: how should defenders react when specialized exploitation knowledge becomes easier to obtain and combine? Answering it requires care. Public code establishes that a capability is available; an incident report establishes that someone used it against a victim.
This assessment uses public information reviewed on October, 6th 2026. It separates reported capabilities from our assessment of their implications for defenders.
What appeared in September
SAP’s 8 September Patch Day included two particularly serious fixes: Security Note 3747649 for CVE-2026-44756, known as OVERPASS, and Note 3759472 for CVE-2026-58240, known as S4GET. SAP rates them 10.0 and 9.8 respectively.
On 15 September, researchers publicly released SAPMAP. Onapsis’s analysis describes discovery and exploitation capabilities, including proof-of-concept code for both flaws. It also reports finding OVERPASS-related code in the repository history despite an initial indication that it was being withheld. At publication, Onapsis said it had not observed threat actors actively using SAPMAP.
Figure 1. A week separates the vendor fixes from publication of the toolkit. Original illustration based on SAP and Onapsis. These are disclosure milestones, not an attack timeline.
Our assessment is that packaging capabilities together could reduce the preparation needed to attempt an intrusion. That is a reason to revisit prioritization. It does not establish mass exploitation, reliable execution in every environment or adoption by a particular criminal group.
OVERPASS reaches a shared component
OVERPASS affects the SAP kernel’s handling of the Extended Passport, a structure used to trace requests between components. Here, “kernel” means the core SAP runtime, not the operating-system kernel. Onapsis, which discovered the flaw, describes access through HTTP, SAP GUI and Remote Function Call traffic. RFC is one of the mechanisms SAP systems use to communicate with each other.
The processing happens before authentication. According to the researchers, successful exploitation can execute commands under the operating-system account running SAP. Restricting one protocol therefore does not necessarily remove the other routes to the same vulnerable code.
For exposure assessment, ask which source networks can reach each relevant service. An internet-facing inventory answers only part of that question. A second view should show what a compromised workstation, partner connection or administration host could reach. This is a defensive scoping exercise, not evidence that those routes have already been used.
S4GET abuses who the cluster trusts
S4GET concerns the Message Server, a component that tracks application servers and helps route client logons. Onapsis’s technical explanation describes an unauthenticated attacker being accepted as a trusted internal node. That trust can then affect access to application-server Gateways and enable command execution as the SAP operating-system user.
The distinction matters when assigning the fix. This is a flaw in how a component establishes trust, not simply an overprivileged business account. Tightening a user’s transaction permissions does not repair it.
SAP’s public bulletin lists kernel releases 9.16, 9.18, 9.19 and 9.20 for S4GET. OVERPASS has a broader list. The security notes should decide whether an installed build is affected; a product label such as “S/4HANA” is not enough to finish that check.
Figure 2. A simplified trust model based on Onapsis’s S4GET analysis. Successful exploitation depends on affected components and network reachability; the diagram does not imply that every SAP deployment is vulnerable.
What the threat assessment should say
A useful assessment makes its reasoning visible. Here, it should distinguish three statements:
| Statement | What supports it |
|---|---|
| The flaws warrant urgent remediation. | Vendor advisories and the impact described by the researchers. |
| Public tooling may make attempted exploitation easier to organize. | Our assessment of the reported availability and packaging of capabilities. |
| A specific organization or actor has used SAPMAP maliciously. | This requires incident evidence; the cited toolkit analysis does not establish it. |
The final statement should remain open until suitable reporting appears. An absence of observations in one vendor’s telemetry does not prove that attacks are absent everywhere. Equally, an available exploit is not sufficient grounds to announce a campaign.
This approach also helps avoid false attribution. If an incident later contains code found in a public toolkit, that overlap may identify a capability. Attribution would still need independent evidence about the operator, infrastructure or wider activity.
Give the SOC and SAP team a shared task
The first deliverable should be a short, agreed inventory: system owner, kernel build, applicable security note, reachable networks and patch status. CERT-EU’s advisory recommends applying both notes promptly and describes the affected release families.
For practical triage, add one business question to each entry: what depends on this system? A test environment holding copied production data or trusted connections may deserve attention before its label suggests it would. Record the actual dependency rather than assuming that production and non-production are isolated.
Then check visibility with the SAP Basis team, which administers the platform. Can investigators establish when server membership changed? Can they review unusual Gateway activity and operating-system processes started by SAP services? Are application logs retained centrally, and can their timestamps be aligned with network and identity records?
These questions are proposed investigation priorities, not published SAPMAP signatures. Validate what each deployment logs before writing a detection. Unexpected activity needs comparison with transports, maintenance and legitimate integrations; an event that looks suspicious in isolation may have a documented operational cause.
While remediation proceeds, keep one named owner responsible for checking new vendor and researcher updates. A confirmed exploitation report, a revised affected-version list or a change in reachability should trigger another look at the order of work. Avoid letting the original severity label become the only input after the situation changes.
Conclusion
SAPMAP is a useful case study in how CTI supports a decision before campaign reporting is complete. The immediate work is specific: verify the builds, map reachability, apply the relevant fixes and establish whether the SOC can investigate activity in the SAP environment.
Keep the uncertainty visible as that work progresses. It is possible to justify urgent action from exposure and impact without claiming to have observed an attack. A good assessment tells the team both why it should act and what evidence would change the assessment next.