Der Port, der immer offen sein muss
Im SAP-Cluster ist der Message Server der Broker: Er trackt, welche Application Server laufen, und routet die SAP-GUI-Logon-Anfragen an den nächsten freien Workprocess. Damit jeder GUI-Client loslegen kann, ohne zuerst einen konkreten Application Server zu kennen, lauscht der Message Server auf einem bekannten öffentlichen Port – in der Port-Welt 36NN.
Genau dieser Port ist jetzt das Problem. CVE-2026-58240, von Onapsis Research Labs S4GET benannt, ist eine Pre-Authentication-Schwachstelle in der Message-Server-Logik mit CVSS 9.8. Der Angriff erfordert kein Zertifikat, keine Credentials und keine Vorkonfiguration. Ein crafted Packet auf den öffentlichen Message-Server-Port genügt.
Warum das anders ist als jede bisherige Message-Server-Schwachstelle: Der öffentliche Port muss erreichbar bleiben – er ist der Weg, über den jeder Enduser-Logon läuft. Ihn per Firewall zu schließen, bricht den SAP-GUI-Logon. Es gibt hier keinen Architektur-Hebel, der den Angriff ohne Funktionsverlust abschneidet.
Was genau kaputt ist
S4GET ist ein Logic-Flaw im Kernel, keine Misskonfiguration. Die Mechanik in zwei Schritten:
- Trust-Promotion: Der Message Server hält eine Definition davon, welche Hosts als „intern“ gelten. S4GET erlaubt es einem unauthentifizierten Angreifer, über ein crafted Packet auf den öffentlichen Port einen IP-Host als vertrauenswürdig zu deklarieren. Der Message Server akzeptiert den Claim und propagiert das Vertrauen auf alle Application Server im Cluster.
- Nutzung über den Gateway: Der Gateway (RFC-Eingangspunkt jeder App-Server-Instanz, 33xx) entscheidet, wem er traut, anhand genau dieser intern/extern-Klassifizierung. Die Gateway-ACLs – secinfo und reginfo – definieren, welche Hosts RFC-Server registrieren oder RFC-callable externe Programme aufrufen dürfen, aber sie unterscheiden intern von extern über das, was der Message Server sagt. Vom als „intern“ markierten IP-Host aus verbindet sich der Angreifer zum Gateway, wird als intern akzeptiert und ruft RFC-callable externe Programme auf. Ergebnis: RCE als
<sid>admauf jedem Application Server im Cluster – mit legitimen SAP-Funktionalitäten, ohne je eine Schwachstelle im Gateway selbst zu berühren.
Wichtig für die Beurteilung: Keine der Standard-ACLs liegt auf diesem Pfad. secinfo, reginfo und ms/acl_info werden nicht ausgewertet, weil der Angreifer als internes System eintrifft – und interne Systeme sind exakt die, denen diese Dateien vertrauen. Einziger greifender Kontrollmechanismus: eine separate ACL darüber, welche Hosts eine Verbindung zum externen Port überhaupt öffnen dürfen. Die wird in der Praxis selten gepflegt – und ist Hardening, kein Ersatz für den Patch.
S4GET vs. 10KBLAZE: dieselbe Idee, diesmal die Haustür
Die 2019er-10KBLAZE-Exploits haben dieselbe Grundidee – einen nicht-internen Host zum internen machen und über den Gateway RCE zu fahren. Der Unterschied ist der Weg hinein:
| 10KBLAZE (2019) | S4GET (2026) | |
|---|---|---|
| Root Cause | Misskonfiguration (zu permissive ACL) | Schwachstelle im Code |
| Betroffener Port | Interner Message-Server-Port (39NN) – nicht zur Exposition gedacht | Öffentlicher Message-Server-Port (36NN) – by design erreichbar |
| Internet-reichweite | Selten | Selten |
| LAN-reichweite | Gering (intern-only durch Design) | Hoch (öffentlich durch Design, für jeden GUI-Logon nötig) |
| Authentifizierung | Zum Disclosure-Zeitpunkt nicht nötig (inzwischen default-secured) | Nicht nötig |
| Mitigation ohne Funktionsverlust | Direkt (interne ACL nachziehen) | Architektonisch schwer – bricht Enduser-Logon |
10KBLAZE war „durch den Hinterhof, den man versehentlich offen gelassen hatte“. S4GET ist „durch die Haustür, die offen sein muss“. Deshalb ist die Betroffenheitsklasse bei S4GET fundamental größer.
Wer ist betroffen – der Kernel, nicht die Release
Die betroffene Komponente ist der Kernel, und zwar die 9.x-Kernel-Familie – die Kernel, auf denen S/4HANA und S/4HANA Cloud Private Edition laufen, potenziell auch andere ABAP-basierte Produkte. Zwei Fallstricke bei der Inventur:
- Die Release-Version sagt nichts. Ein S/4HANA-2023-System kann einen 9.16-Kernel laufen haben – die betroffenen 9.x-Kernel sind als Upgrade für frühere Releases verfügbar, und viele Landschaften haben sie bereits.
- Nicht nur S/4HANA. Der Kernel ist Shared Infrastructure für alle ABAP-Systeme – auch ältere ABAP-Landschaften auf 9.x-Kerneln sind betroffen.
Korrekturlevel gemäß SAP Note 3759472 – darunter gilt als verwundbar:
| Kernel | Fix ab Patchlevel |
|---|---|
| 9.16 | PL 100 |
| 9.18 | PL 32 |
| 9.19 | PL 17 |
| 9.20 | PL 7 |
Der Check ist ein einzelner Datenpunkt – Kernel-Release + Patchlevel. Verifizierbar: in SAP GUI über System → Status → Kernel-Information, OS-seitig als <sid>adm mit disp+work -version.
9.16 ist zudem der native Kernel der SAP ABAP Platform 2025 – die Pflicht-Grundlage für S/4HANA 2025 und S/4HANA Cloud Private Edition 2025. Das heißt: Alle frischen 2025er-Landschaften starten mit einem betroffenen Kernel.
Die Erreichbarkeitslogik
Direkte Internet-Exposition des Message-Server-Ports ist glücklicherweise selten. Intern sieht es anders aus: Der öffentliche Port ist durch Design für jeden SAP-GUI-User freigegeben, wird routinemäßig durch die Firewalls vor den SAP-Systemen gelassen und kann nicht geschlossen werden, ohne den Enduser-Logon zu brechen.
Daraus folgt der entscheidende Punkt für die Risikoeinschätzung: Ein LAN-Footprint genügt. Phished-Workstation, kompromittierte Contractor-VPN-Session, exponierter Jump-Host – jeder dieser Wege setzt den Angreifer ins LAN, und von dort ist der Message-Server-Port in den allermeisten Landschaften erreichbar. S4GET macht also auch „saubere“ Systeme ohne Web-Präsenz zu einem relevanten Ziel.
Nach erfolgreichem Exploit gilt das volle Bild: RCE als <sid>adm auf dem gesamten Cluster – Ransomware und Datenzerstörung, Exfiltration, gefälschte Zahlungen, Anlegen privilegierter User. Für SOX-, NIS2-, GDPR-, HIPAA- und PCI-DS-pflichtige Organisationen ist das ein meldepflichtiger Vorfall höchster Schwere.
Was hilft
- Patch Note 3759472 – das einzige Mittel, das die Schwachstelle vollständig schließt. Priorisierung:
- Internet-reichweite Systeme zuerst. Wo der Message-Server-Port direkt exponiert ist (Legacy-DMZ, vergessene NAT-Regel, Testsystem), ist die höchste Risikoklasse. Diese Population aktiv auf „leer“ prüfen statt anzunehmen.
- Interne Systeme als Hauptaufwand. Für die meisten Landschaften ist LAN-Reichweite die Norm, nicht die Ausnahme.
- External-Port-ACL pflegen (welche Hosts den externen Message-Server-Port erreichen dürfen) – wirksames Hardening, weil es der einzige Control ist, der auf diesem Pfad greift. Kein Ersatz für den Patch.
- Monitoring auf anomale Message-Server-Registrierungen im Deployment-Fenster: Ungewohnte „intern“-Klassifizierungen/Registrierungsversuche von Hosts, die im Cluster Inventar nicht vorkommen.
Was nicht hilft: secinfo/reginfo/ms/acl_info nachziehen, SAP-Authorizations oder SoD verstärken, Zertifikate rotieren – keine dieser Instanzen liegt auf dem Angriffspfad, weil der Angreifer als internes System eintrifft.
Exploit-Bewertung: Stand 10.09.2026 keine beobachtete In-the-Wild-Exploitation (vendorseitige Einschätzung Onapsis). Historische Referenz für die Dringlichkeit: RECON (CVE-2020-6287) wurde binnen 72 Stunden aus dem Patch reverse-engineered – und dieses Fenster schrumpft mit KI-gestütztem Tooling.
Das Fazit in einem Satz: S4GET demonstriert, dass die Kontrolle, auf die SAP-Netzwerke seit 10KBLAZE gebaut haben – „intern heißt vertraut“ – durch ein unauthentifiziertes Packet umdefinierbar ist. Und dass der Patch, nicht das ACL-Reporting, der einzige Ausweg ist.