Die Zahlen zuerst
CVSS 10.0 – die volle Punktzahl. Pre-Authentication, remote, ohne Zertifikat, ohne Rolle, ohne Login-Versuch. Und laut Scan der Onapsis Research Labs stehen mehr als 10.000 eindeutige IP-Adressen mit SAP-Web-Oberfläche direkt im öffentlichen Netz. Die Zahl gilt als konservativ: Sie zählt nur HTTP-reichweite und strukturell unterzählt die SAP Web Dispatcher, die ihr Backend proxifizieren und auf dem Root-Pfad kein SAP-Banner liefern.
SAP hat am 08.09.2026 mit Security Note 3747649 gefixt. Onapsis Research Labs, die die Lücke verantwortungsvoll gemeldet haben, benennen sie OVERPASS. Unabhängig davon hat nullFaktor eine eigene Analyse veröffentlicht – und darin einen vierten Angriffsvektor dokumentiert, den die öffentliche Onapsis-Darstellung nicht abbildet: NGRFC über WebSocket.
Was EPP ist – und warum es der Hebel
Der Extended Passport (EPP) ist eine Standard-Struktur der SAP-Plattform für das Tracing verteilter Aufrufketten. Laut SAP-Dokumentation ermöglicht er die Analyse von Aufrufsequenzen in verteilten Systemlandschaften und das End-to-End-Tracing über integrierte SAP- und Nicht-SAP-Systeme hinweg. Drei Eigenschaften erklären, warum ein Fehler in seiner Verarbeitung so schwer wiegt:
- Er wird beim Öffnen einer neuen Benutzersession erstellt. Die Verarbeitung passiert also am allerersten Punkt der Verbindung – bevor die Session authentifiziert ist.
- Er wird über Kommunikationsprotokolle transportiert – RFC und HTTP –, und er geht immer von Client zu Server. Die Daten stammen clientseitig, und mehr als ein Protokoll trägt sie.
- Zwischen ABAP-Systemen ist er standardmäßig aktiv. Die betroffene Funktionalität ist also ohne jegliche Kundeneinrichtung vorhanden.
Die Ursache von OVERPASS liegt laut nullFaktor-Advisory in einer fehlenden Bounds-Validierung auf extern gelieferte EPP-Metadaten: ein Stack-basiertes Buffer-Overflow im Kernel-Code, der die EPP-Struktur verarbeitet. Der betroffene Stack-Frame trägt keinen Stack-Canary – obwohl das Binary mit Canary-Support kompiliert wurde –, und ein Memory-Leak liefert einen ASLR-Bypass. Das Ergebnis: Kontrolle des Programmlaufs des empfangenden Prozesses und Ausführung beliebiger OS-Befehle als der SAP-OS-User.
Warum kein Login, keine Rolle, keine Berechtigung hilft: Weil die verwundbare Verarbeitung als Teil des Session-Opens stattfindet, ist jede SAP-Instanz, die erst entscheidet, wer was darf – User-Locks, Rollen, Authorization-Objects, Logon-Policies – chronologisch hinter dem Punkt, an dem die Lücke erreicht wird. SAP-Authorizations und Segregation of Duties sind auf diesem Pfad irrelevant.
Vier Vektoren, ein Code
Weil die EPP-Verarbeitung geteilter Kernel-Code ist, ist derselbe Defekt über getrennte Protokolle und Systemkomponenten erreichbar – in jedem Fall ohne Authentifizierung:
- HTTP(S) über den ICM – oder über einen SAP Web Dispatcher: die Web-Tier-Ebene, die Fiori, WebGUI, Web Services und API-basierte Integrationen bedient. Genau die Schicht, die Unternehmen typischerweise ins Internet veröffentlichen.
- NGRFC über WebSocket auf dem HTTPS-Port – der Vektor, den die meisten nicht auf dem Schirm haben. NGRFC ist das SAP-RFC über WebSocket, das den klassischen RFC-Traffic durch den HTTPS-Port tunnelt. Vor NGRFC war der Dialog-Workprocess ausschließlich über die internen DIAG-Ports (32xx) und den RFC-Gateway-Port (33xx) erreichbar. NGRFC ändert das fundamental: Der Workprocess – der Prozess, der Datenbank-Konnektionen, Credentials und aktive Benutzersessions hält – ist damit erstmals über den Internet-facing HTTPS-Port erreichbar. Wer diesen Port hat, hat den Workprocess.
- Classic RFC über den Gateway (33xx): die RFC-Schicht, über die sich SAP-Systeme untereinander – und Drittsystem-Integrationen – mit SAP austauschen.
- SAP GUI / DIAG (32xx) über den Dispatcher: der Weg, den jeder klassische GUI-Logon nimmt.
Onapsis bestätigt drei dieser Vektoren (Web, SAP GUI, Classic RFC); den NGRFC-WebSocket-Vektor dokumentiert nullFaktor. Es sind nicht vier Schwachstellen, sondern vier Wege zum selben Defekt. Darum bearbeitet SAP sie mit einem einzigen CVE und einer einzigen Note – und darum reicht keine einzelne Protokolleinschränkung: Web-Tier gehärtet? Über RFC erreichbar. RFC blockiert? Über GUI oder NGRFC erreichbar. Nur der Kernel-Patch schließt alle Wege.
Der WebSocket-Switch ist eine Fassade
Die kontrainuitive Kernfinding: Wer den SAP-Config-Switch für den WebSocket-Support deaktiviert hat, ist nicht geschützt. Die verwundbare Envelope-Parsing läuft vor jeder Logon-Validierung – also vor jeglicher anwendungsebenen Konfigurationslogik. Der Internet-reichweite Port genügt. „WebSocket-Support deaktiviert“ erzeugt ein falsches Sicherheitsgefühl: Die Parsing-Schicht, die angreifbar ist, läuft trotzdem.
Wer ist betroffen
Die Betroffenheit definiert der Kernel – nicht die Anwendung, die oben läuft. Die Fußspur reicht von S/4HANA über ERP/ECC, NetWeaver AS ABAP und Java, BW/4HANA, Enterprise Portal, PI/PO bis Solution Manager. Korrekturlevel gemäß Note 3747649 (v7, 08.09.2026):
| Komponente | Fix ab Patchlevel |
|---|---|
| SAP Kernel 7.22_EXT / EX2 / EX3 | 1518 |
| SAP Kernel 7.53 | 1610 |
| SAP Kernel 7.54 | 646 |
| SAP Kernel 7.77 | 912 |
| SAP Kernel 7.93 | 401 (auch 412, höhere Patches enthalten die Korrektur) |
| SAP Kernel 8.04 | 242 |
| SAP Kernel 9.16 | 100 |
| SAP Kernel 9.18 | 29 |
| SAP Kernel 9.19 | 14 |
| SAP Kernel 9.20 | 4 |
| SAP Web Dispatcher 9.16 (Standalone) | 100 |
Sonderfall: SAP Kernel 7.22 (plain) und 7.89 haben kein Fix. Betroffene Systeme müssen per DCK-Upgrade migriert werden (Note 2083594).
Die Release-Version sagt nichts – ein S/4HANA-2023-System kann einen verwundbaren 9.16-Kernel laufen haben. Ablesbar OS-seitig als <sid>adm via disp+work -version, in SAP über System-Status – der Kernel ist der einzige relevante Datenpunkt.
Was nicht hilft – und was tatsächlich hilft
Nicht hilfreich: Firewall-Regeln allein, ACLs, SAP-Authorizations, SoD, User-Locks, Passwort-Policies. Der Code wird vor all dem erreicht.
Tatsächlich wirksam:
- Kernel-Patch gemäß Note 3747649 (SP Stack Kernel bzw. dw.sar-Hotfix); EOL-Kernel: DCK-Upgrade.
- Web Dispatcher 9.16 patchen (Standalone via SAPWEBDISP.SAR, Note 908097; Embedded über das Kernel-Verfahren).
- Temporärer Workaround gemäß Note 3756304 – schützt allerdings nur HTTP(S)-Traffic, der über einen entsprechend gepatchten Web Dispatcher läuft. Kein Schutz für andere Protokolle, kein Schutz vor direkt erreichbaren Application Servern.
- Netzwerk-Ebene: WebSocket-Upgrade-Anfragen am RFC-Endpunkt per Firewall auf allen ICM/WDP-Ports blockieren – auch wenn der SAP-Switch deaktiviert ist – und die RFC-Ports 32xx/33xx/36xx auf vertrauenswürdige Quellen einschränken.
- Host Agent auf ein aktuelles Patchlevel bringen.
- SAP FAQ zu Note 3747649: Note 3776034.
Wie lang ist das Fenster?
Stand 13.09.2026: kein öffentlicher PoC (nullFaktor hält die Primitiven zurück), keine Listung in CISA KEV (Feed-Stand 11.09.2026), keine beobachtete In-the-Wild-Exploitation (vendorseitige Einschätzung Onapsis). Das Fenster existiert – aber die Historie gibt Orientierung: Die RECON-Lücke (CVE-2020-6287) wurde binnen 72 Stunden aus dem Patch reverse-engineered, und dieses Fenster schrumpft mit KI-gestütztem Tooling weiter. Die Mass-Exploitation von CVE-2025-31324 im Frühjahr 2025 hat gezeigt, was passiert, wenn eine kritische Pre-Auth-SAP-Lücke gemonetisiert wird, bevor die Verteidigung Schritt halten kann – Mandiant nannte sie die am häufigsten ausgenutzte Schwachstelle des Jahres. Und die ICMAD-Familie 2022 hat gelehrt, dass Defekte in geteiltem Kernel-Code ein enormes Blast-Radius haben.
OVERPASS ist dasselbe Muster – diesmal in vier Protokollen.
Das Fazit in einem Satz: Ein einzelner Kernel-Patch schließt alle vier Wege. Die offene Frage ist nicht, ob gepatcht wird – sondern welche Systeme und welche Kernel betroffen sind. Und ob die NGRFC/HTTPS-Route in der Exposure-Analyse überhaupt betrachtet wurde.