Eine SAP-Sicherheitslücke im NetWeaver Message Server lässt sich ohne ein einziges Passwort ausnutzen und betrifft jedes S/4HANA-2025-System. Am 8. September hat SAP den Fehler mit dem Schweregrad 9,8 geschlossen, entdeckt haben ihn die Onapsis Research Labs.[1] Über die Schwachstelle meldet ein Angreifer einen eigenen Server im Cluster an und liest den Anmeldeverkehr der SAP-GUI mit.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügenDas Wichtigste in Kürze
- CVE-2026-58240 im SAP NetWeaver Message Server trägt den CVSS-Score 9,8 und ist unauthentifiziert über das Netz ausnutzbar.
- Der Message Server prüft anmeldende Applikationsserver nicht ausreichend, ein untergeschobener Server fängt den SAP-GUI-Anmeldeverkehr ab oder leitet ihn um.
- Betroffen sind die Kernel-Generationen 9.16 bis 9.20, also jedes S/4HANA-2025-System.
- SAP lieferte den Fix im September-Patchday mit 22 Security Notes, davon fünf HotNews.
Was macht die Message-Server-Lücke so gefährlich?

Kein Passwort nötig, kein Konto, nur Netzwerkzugang zum richtigen Port. Der Message Server ist der zentrale Vermittler eines SAP-Systems und verteilt die Anmeldungen der SAP-GUI auf die einzelnen Applikationsserver. Genau bei dieser Anmeldung prüft er laut Onapsis nicht zuverlässig, ob ein neu hinzukommender Server überhaupt dazugehört.[1] Ein Angreifer schiebt so einen eigenen Server in den Verbund und liest oder manipuliert den Anmeldeverkehr, ohne je gültige Zugangsdaten zu besitzen.
Warum SAP-Systeme immer wieder am selben Punkt brechen
Muster statt Einzelfall. Am selben Patchday stufte SAP mit der OVERPASS-Lücke im Kernel eine zweite Schwachstelle auf den Höchstwert 10,0 ein.[2] Die Lücke reiht sich in eine Serie: Im Juli traf eine 9,9-Lücke den Kern jedes ABAP-Systems, bei der SAP Commerce Cloud schlugen Angreifer drei Tage nach dem Patch zu. Der Message Server steht seit Jahren im Visier, weil viele Betriebe seinen internen Port unbeabsichtigt ins offene Netz stellen.
Ein SAP-Cluster ist nur so vertrauenswürdig wie der Anmeldeweg über seinen Message Server. Ein intern erreichbarer Port, offen im Netz, macht jede Härtung darüber zunichte.
— Michael Dobler, Herausgeber Dr. Web
Das eigentliche Risiko ist selten die einzelne Lücke, sondern die Sichtbarkeit im Netz. Automatisierte Scanner suchen exponierte SAP-Dienste im Minutentakt und greifen zu, sobald ein Patch öffentlich wird. Manche tarnen sich dabei als harmlose KI-Bots. Eine abgesicherte Software-Lieferkette verschafft Zeit, wie es GitHubs neue Wartezeit bei Dependabot vormacht.
Die Message-Server-Lücke CVE-2026-58240 und ihr Umfeld
Was deutsche SAP-Betreiber jetzt tun müssen
Patch und Portsperre. SAP ist das Rückgrat fast jedes DAX-Konzerns und tausender Mittelständler. Die Haftung für einen offenen Anmeldeweg bleibt beim Betreiber. Unter NIS2 zählen viele dieser Firmen als besonders wichtige Einrichtungen, für die zügiges Patchen und die Meldung von Vorfällen Pflicht sind. Drei Schritte stehen jetzt an:
- SAP Security Note 3759472 einspielen und die betroffenen Kernel-Stände 9.16 bis 9.20 im Bestand erfassen.
- Den internen Port des Message Servers vom offenen Netz trennen und die Zugriffsliste ms/acl_info restriktiv setzen.
- Die Anmeldungen im Cluster überwachen, um einen untergeschobenen Applikationsserver früh zu erkennen.
Zuerst der Anmeldeweg. Das BSI warnt seit Jahren vor SAP-Systemen, die ungeschützt am Internet hängen. Diese Lücke ist die Erinnerung, ihn abzusichern, bevor der nächste Scanner ihn findet.
Quellen
[1] Onapsis Research Labs: „SAP Security Patch Day September 2026“
[2] SAP: „SAP Security Patch Day – Security Notes News“
Mehr Newshunger?
- OVERPASS: SAP-Kernel-Lücke mit CVSS 10.0 trifft jedes ABAP-System
- SAP Commerce Cloud: Angreifer nutzen die kritische Lücke drei Tage nach dem Patch
- SAP Commerce Cloud: Eine 10.0-Lücke öffnet den Webshop für Angreifer
- SAP-Patchday im Juli: Eine 9,9-Lücke trifft den Kern jedes ABAP-Systems
- Massenhafte Schwachstellen-Scans tarnen sich als KI-Bots wie ClaudeBot
- Dependabot wartet jetzt drei Tage: GitHubs neue Standard-Wartezeit