Am Mittwoch, dem 9. September, um 10:00 Uhr EDT veranstalten SAP und das „ Onapsis Research Labs “ ein gemeinsames Webinar zum Thema Sicherheitsbedrohungen, um diese Schwachstellen und weitere kritische Probleme zu erörtern, die im Rahmen des SAP Patch Tuesday im September 2026 behoben wurden. Hier registrieren
CVSS-Wert: 9,8 (kritisch) | Risikostufe: kritisch, sofortige Maßnahmen erforderlich
Onapsis und SAP haben sich zusammengeschlossen, um S4GET (CVE-2026-58240) zu beheben, eine kritische Sicherheitslücke vor der Authentifizierung im SAP NetWeaver Message Server. Der offizielle Patch ist ab sofort in der SAP-Sicherheitsmitteilung 3759472 verfügbar, und dessen Installation sollte für jedes betroffene Unternehmen oberste Priorität haben.
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.
Zum Zeitpunkt dieser Veröffentlichung hat die Onapsis Research Labs noch keine aktive Ausnutzung dieser Schwachstellen in der Praxis festgestellt. Wir überwachen weiterhin unser SAP Global Threat Intelligence Network und werden unseren Kunden in diesem Fall Produkt-Updates sowie Informationen zu Bedrohungen (einschließlich Indikatoren für Kompromittierung) zur Verfügung stellen. Wir werden diesen Blogbeitrag mit allen Beobachtungen aktualisieren, um die Öffentlichkeit darüber zu informieren.
Die „ Onapsis Research Labs “ halten sich an strenge Richtlinien für die verantwortungsvolle Offenlegung. Daher werden in diesem Beitrag technische Details zur Ausnutzung der Schwachstelle vorerst bewusst ausgelassen; der Beitrag konzentriert sich ausschließlich darauf, SAP-Kunden dabei zu helfen, die Schwachstelle „ assess “ zu erkennen und umgehende Maßnahmen zur Risikominderung zu ergreifen.
Was ist die S4GET-Sicherheitslücke (CVE-2026-58240)?
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.
Zwei Komponenten auf niedriger Ebene spielen hier eine Rolle. Der SAP Message Server fungiert als Broker des Clusters: Er verfolgt, welche Anwendungsserver in Betrieb sind, und leitet SAP-GUI-Anmeldeanfragen weiter. Er lauscht auf einem bekannten öffentlichen Port, da jeder SAP-GUI-Client zuerst auf ihn zugreift. Das SAP-Gateway ist der RFC-Einstiegspunkt jedes Anwendungsservers und wird durch ACL-Dateien (secinfo, reginfo) geschützt, die festlegen, welche Hosts RFC-Server registrieren oder RFC-aufrufbare externe Programme aufrufen dürfen.
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.
Es ist keine Authentifizierung erforderlich, und es wird kein Zertifikat überprüft. Da der Angriff auf den öffentlichen Port gerichtet ist – also den Port, mit dem sich jeder SAP-GUI-Client rechtmäßig verbindet –, ist er selbst dann erfolgreich, wenn sichere Kommunikation strikt aktiviert ist und die ACLs, auf die sich Sicherheitsverantwortliche normalerweise verlassen (secinfo, reginfo, ms/acl_info), einwandfrei konfiguriert sind. Keine dieser ACLs befindet sich in diesem Pfad. Eine „ control “ gilt jedoch: Eine separate ACL regelt, welche Hosts eine Verbindung zum externen Port selbst herstellen dürfen. In der Praxis wird diese aus Gründen, die im Abschnitt „Behebung“ erläutert werden, selten gepflegt, und es handelt sich um eine Sicherheitsmaßnahme – nicht um einen Ersatz für den Patch.
Risiken und Auswirkungen von S4GET auf SAP-Landschaften
Was S4GET von einer typischen kritischen CVE abhebt, ist seine Erreichbarkeit. Eine direkte Exposition im Internet ist glücklicherweise selten, und es lohnt sich, dies klar zu betonen: In den meisten Umgebungen befindet sich der Message-Server hinter der Perimeter-Firewall. Innerhalb des Unternehmensnetzwerks sieht die Lage anders aus. Der öffentliche Port ist von Natur aus für jeden SAP-GUI-Benutzer erreichbar, wird routinemäßig durch die Firewalls vor den SAP-Systemen zugelassen und kann nicht geschlossen werden, ohne die Anmeldung der Endbenutzer zu unterbrechen. Jeder Angreifer, der bereits einen Fuß in das LAN gesetzt hat – sei es über eine durch Phishing kompromittierte Workstation oder eine VPN-Sitzung eines Auftragnehmers –, befindet sich bereits in einer günstigen Position. Hier gibt es keinen architektonischen Schutzraum, sondern nur den Patch.
Sobald die Sicherheitslücke ausgenutzt wurde, hat der Angreifer die effektive Kontrolle über das System: Ransomware und Datenvernichtung, das Abziehen beliebiger Geschäftsdaten, betrügerische Zahlungen und die Erstellung von Benutzern mit Sonderrechten sind allesamt möglich. Für Unternehmen, die den Vorschriften von SOX, NIS 2, DSGVO, HIPAA oder PCI-DSS unterliegen, würde jede derartige böswillige Handlung einen meldepflichtigen Vorfall von höchster Schwere darstellen.
Ein Vergleich von S4GET mit der SAP-Sicherheitslücke „10KBLAZE“
10KBLAZE stellte 2019 ein ähnliches Risiko dar, indem es eine zu freizügige Zugriffskontrollliste (ACL) am internen Port des Message-Servers ausnutzte, der niemals für den Zugriff von außen vorgesehen war (und anschließend von SAP abgesichert wurde). S4GET gelangt zum selben Ziel, allerdings über die „Vordertür“:
| 10KBLAZE (2019) | S4GET (2026) | |
|---|---|---|
| Grundursache | Fehlerhafte Konfiguration | Verwundbarkeit |
| Externe (Internet-)Erreichbarkeit | Selten | Selten |
| Interne Erreichbarkeit (Unternehmens-LAN) | Niedrig (konstruktionsbedingt nur intern) | Hoch (von Natur aus öffentlich, für die SAP-GUI-Anmeldung erforderlich) |
| Betroffener Port | Interner Anschluss (39NN) | Öffentlicher/externer Port (36NN) |
| Authentifizierung | Bei der Offenlegung nicht erforderlich (seitdem standardmäßig gesichert) | Nicht erforderlich |
| Abhilfemaßnahmen ohne Auswirkungen auf die Funktionalität | Einfach | Architektonisch nicht umsetzbar, unterbricht die Anmeldung des Endbenutzers |
Weitere Informationen: 10KBLAZE-Webinar | ursprüngliche Bekanntmachung
Warum es wichtig ist, hier einen Schritt voraus zu sein
Die SAP-Community muss sich nicht mehr vorstellen, was passiert, wenn eine kritische SAP-Sicherheitslücke vor der Authentifizierung ausgenutzt wird, bevor die Verteidiger reagieren können. Anfang 2025 wurde CVE-2025-31324, eine Schwachstelle beim nicht authentifizierten Hochladen von Dateien in einer SAP-NetWeaver-Komponente, durch aktive Ausnutzung in der Praxis entdeckt. SAP reagierte rasch mit Patches für diese Schwachstelle und die damit verbundene CVE-2025-42999, doch mehrere Angreiferwellen hatten bereits Webshells eingesetzt und Code auf ungepatchten Systemen ausgeführt, lange bevor viele Unternehmen die Patches installieren konnten. Der Mandiant 2026 M-Trends-Bericht bezeichnete CVE-2025-31324 als die am häufigsten ausgenutzte Schwachstelle des Jahres. Es ist zudem erwähnenswert, dass Angreifer SAP-Patches in der Vergangenheit innerhalb von 72 Stunden rückentwickeln konnten, um Schwachstellen auszunutzen (wie wir es bei der RECON-Schwachstelle (CVE-2020-6287) gesehen haben), und dass sich dieses Zeitfenster durch KI-gestützte Tools weiter verkürzt.
Genau das ist das Ergebnis, das unsere strategische Partnerschaft und unsere Zusammenarbeit im Bereich der koordinierten Offenlegung mit SAP verhindern soll. Mit S4GET wird die Tür hoffentlich geschlossen, bevor ein Angreifer die Schwachstelle entdeckt, sodass Kunden möglichst viel Zeit haben, sich vorzubereiten und Patches zu installieren.
So ermitteln Sie das S4GET-Risiko
Die Sicherheitsrisiken hängen vom Kernel ab, auf dem ein System läuft, und nicht von der darauf ausgeführten Anwendung.
Kernel 9.16 ist der native Kernel von SAP ABAP- Platform 2025 – die obligatorische Grundlage für SAP S/4HANA 2025, S/4HANA Cloud Private Edition 2025 sowie eigenständige ABAP- Platform -2025-Systeme. Gehen Sie nicht davon aus, dass frühere Releases sicher sind. Die betroffenen Kernel-Versionen stehen für frühere Releases als Upgrade zur Verfügung, und viele Kunden haben dieses bereits durchgeführt – ein SAP-S/4HANA-2023-System könnte beispielsweise durchaus eine davon ausführen. Das Release allein gibt hier keinen Aufschluss; nur der Kernel tut dies.
Beschränken Sie sich nicht auf S/4HANA. Die betroffene Komponente ist der Kernel – eine gemeinsame Infrastruktur für alle ABAP-basierten Systeme, nicht etwas S/4HANA-Spezifisches –, sodass auch andere ABAP-Systeme in Ihrer Landschaft möglicherweise mit einem betroffenen Kernel laufen und ebenso betroffen wären.
Laut SAP-Sicherheitshinweis 3759472 sind dies die Patch-Level, die den Fix für jeden der vier betroffenen Kernel enthalten. Alle Versionen darunter sollten als anfällig betrachtet werden:
- 9,16 — PL 100
- 9.18 – PL 32
- 9.19 – PL 17
- 9.20 – PL 7
Die Überprüfung besteht aus einem einzigen Datenpunkt: Ihrer Kernel-Version und dem zugehörigen Patch-Level. Überprüfen Sie dies wie folgt:
- SAP GUI: System → Status → Kernel-Informationen
- OS level as <sid>adm: disp+work -version.
Werte unterhalb dieser Grenzwerte erfordern sofortige Abhilfemaßnahmen.
So beheben Sie die Sicherheitslücke S4GET (CVE-2026-58240)
Die Anwendung des SAP-Sicherheitshinweises 3759472 ist die endgültige Lösung und die einzige, die die Sicherheitslücke vollständig behebt. Die folgenden Schritte beschreiben, wie Sie den Sicherheitshinweis in der richtigen Reihenfolge implementieren und die Sicherheitslücke in der Zwischenzeit schließen können.
- Assess und ermitteln. Erstellen Sie eine Bestandsaufnahme aller SAP-Systeme, auf denen eine der oben aufgeführten anfälligen Kombinationen aus Kernel- und Patch-Level läuft. Ermitteln Sie für jedes System, welche Netzwerke den öffentlichen Port (36NN) des Message-Servers erreichen können.
- Patchen Sie zunächst alle Systeme, die mit dem Internet verbunden sind. Eine direkte Internetanbindung des Message-Server-Ports ist glücklicherweise selten, aber wo sie besteht (sei es bei einer veralteten DMZ-Bereitstellung, einer falsch konfigurierten NAT-Regel oder einem vergessenen Testsystem), stellt sie die Gruppe mit dem höchsten Risiko in Ihrer Infrastruktur dar. Vergewissern Sie sich, dass diese Gruppe leer ist, anstatt einfach davon auszugehen, dass dies der Fall ist.
- Interne Systeme patchen – das ist der Großteil der Arbeit. Hier befinden sich fast alle betroffenen Systeme, und die Erreichbarkeit über das Unternehmens-LAN ist bei diesem Port eher die Regel als die Ausnahme. Diese stehen an zweiter Stelle in der Reihenfolge, nicht jedoch in der Wichtigkeit.
- Überwachen Sie die Systeme auf Ausnutzungsversuche. Stellen Sie sicher, dass Sie Einblick in Ihre SAP-Anwendungsschicht haben, damit Versuche, diese Schwachstellen auszunutzen, erkannt und untersucht werden können.
Sollten Sie den Patch aufgrund betrieblicher Einschränkungen nicht umgehend installieren können, empfehlen wir Ihnen dringend, Ausgleichsmaßnahmen zu ergreifen, um aktiv auf Angriffe und Anzeichen für eine Kompromittierung zu achten, bis die Installation des Patches erfolgen kann.
Wie Onapsis die Abwehr und den Schutz vor S4GET automatisiert
Als einer der produktivsten Mitwirkenden an der SAP-Sicherheitsforschung hat das „ Onapsis Research Labs “ weit über 1.000 Zero-Day-Schwachstellen in SAP-Geschäftsanwendungen aufgedeckt und bei deren Behebung mitgewirkt und arbeitet weiterhin eng mit SAP zusammen, um den weltweiten SAP-Kundenstamm zu schützen. Dies spiegelt die starke, langjährige Beziehung zwischen dem „ Onapsis Research Labs “ und dem „Product Security Response Team“ von SAP sowie die proaktiven Investitionen von SAP in die Sicherung seiner „ platform “ wider.
Geschützt VOR dem Patch
Da das „ Onapsis Research Labs “ die Sicherheitslücke entdeckt und SAP bei deren Behebung unterstützt hat, wurden die zum Schutz vor solchen Angriffen erforderlichen Informationen und Erkennungsinhalte im Rahmen des koordinierten Offenlegungsprozesses entwickelt und bereitgestellt, sodass unsere Kunden bereits vor der Veröffentlichung des Patches durch einen Zero-Day-Schutz abgesichert waren. Während dieses Zeitraums haben die „ Onapsis Research Labs “ über unser „Global Threat Intel Network“ die globale SAP-Bedrohungslandschaft auf erste Anzeichen böswilliger Aktivitäten überwacht. Im Produktbereich hat Onapsis „ Defend “ die Kundenumgebungen bereits lange vor der heutigen Patch-Veröffentlichung aktiv auf S4GET überwacht und so den Schutz unserer Kunden während des gesamten Zeitraums der koordinierten Offenlegung gewährleistet.
Wird NACH dem Patch unterstützt
Die Zero-Day-Regeln in „ Defend “ werden mit sofortiger Wirkung zu etablierten Produktionsregeln erhoben. Darüber hinaus können Onapsis-Kunden sofort im Onapsis- Platform entsprechende Maßnahmen ergreifen:
- Onapsis Assess wurde um neue Prüfungen erweitert, die genau ermitteln, welche Systeme in Ihrer Infrastruktur von S4GET betroffen sind, sodass Sicherheits- und Basis-Teams die Bereitstellung von Patches präzise priorisieren können, anstatt die gesamte Infrastruktur pauschal zu überarbeiten.
- Onapsis Defend bietet eine kontinuierliche Erkennung des Ausnutzungsmusters und schützt Teams somit in der Zeitspanne zwischen der Bekanntgabe und der vollständigen Bereitstellung des Patches – also in dem Zeitraum, in dem das Risiko am größten ist.
Und die „ Onapsis Research Labs “ verfolgen weiterhin Exploit-Aktivitäten, Indikatoren und das Verhalten von Angreifern in der Praxis und speisen aktualisierte Erkenntnisse in die Erkennungsinhalte und „Threat Dispatches“ für Kunden ein, damit der Schutz mit der sich ständig weiterentwickelnden Bedrohungslage Schritt halten kann.
Insgesamt verwandelt die umfassende Produktabdeckung von Onapsis ein kritisches Patch-Ereignis unter hohem Druck in einen strukturierten, messbaren Prozess. Genau das bedeutet es für einen Sicherheitsanbieter, SAP-Kunden zu informieren und ihnen einen deutlichen Vorsprung gegenüber der Bedrohung zu verschaffen: robuster Schutz bereits vor der Veröffentlichung des Patches, fachkundige Begleitung bei der Behebung nach der Veröffentlichung des Patches sowie eine kontinuierliche Überwachung der Bedrohung noch lange nach dem „Patch Tuesday“, um sicherzustellen, dass die Kunden weiterhin geschützt sind.
Fazit
S4GET stellt eine schwerwiegende, aus der Ferne ausnutzbare und ohne Authentifizierung realisierbare Bedrohung für jedes System dar, auf dem einer der betroffenen Kernel läuft. Der Schweregrad dieser Schwachstelle entspricht einigen der folgenschwersten SAP-Sicherheitslücken, die Onapsis in seiner Geschichte jemals offengelegt hat, und ihr Ausnutzungsprofil (nämlich ein öffentlicher Port, keine Authentifizierung und keine Fehlkonfiguration erforderlich) erfordert sofortige Maßnahmen seitens jeder Organisation, die die betroffene Version einsetzt.
Dank der abgestimmten Bekanntgabe durch Onapsis und SAP ist diese Lücke nun geschlossen. Dieser Vorteil gilt jedoch nur, wenn Sie entsprechend handeln.
Zur Erinnerung: Nehmen Sie am Mittwoch, dem 9. September, um 10 Uhr EDT live an unserem Webinar zum Thema „Threat Briefing“ mit SAP teil. Melden Sie sich hier an.
Über den Autor
