--- service: "Publicasta" schema_version: "1.0" article_id: 577 title: "SAPs Kernel-Lücken vom September 2026 erfordern Inventarisierung und Patching" language: "de" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=de" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=de" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=de" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-10T13:50:42+00:00" updated_at: "2026-09-10T13:50:42+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=de" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=de" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=en" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=es" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=es" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=zh" --- # SAPs Kernel-Lücken vom September 2026 erfordern Inventarisierung und Patching > Zwei kritische SAP-Schwachstellen erreichen zentrale Kommunikationspfade und können ganze ERP-Landschaften gefährden. Dieser Überblick trennt bekannte Fakten von offenen Fragen und zeigt, wie sich die eigene Exposition prüfen lässt. SAPs Security Patch Day im September 2026 enthält zwei kritische Schwachstellen, die für Unternehmen mit SAP-Landschaften sofort relevant sind. Die erste ist eine SAP-Kernel-Lücke mit maximalem Schweregrad in der Verarbeitung von Extended-Passport-Daten. Sie wird als CVE-2026-44756 geführt und von den Onapsis Research Labs OVERPASS genannt. Die zweite, CVE-2026-58240, betrifft den SAP NetWeaver Message Server und trägt die Bezeichnung S4GET. Beide Schwachstellen lassen sich auf betroffenen Systemen aus der Ferne und ohne Authentifizierung erreichen. ![Unternehmensserverraum mit abstrakter Netzwerkkarte und Anzeigen für Sicherheitsupdates](https://publicasta.com/storage/projects/9/pages/577/2026/09/0eecf113-0be8-4e9f-9929-205dcb47ba8d.webp) Entscheidend ist nicht die Annahme, jede SAP-Installation sei bereits kompromittiert. Entscheidend ist, dass die Lücken in gemeinsam genutzter Infrastruktur liegen, über die mehrere Kommunikationswege laufen. Dazu gehören auch Pfade, die Administratoren möglicherweise für geschützt halten, nur weil die zentrale Geschäftsanwendung nicht direkt im öffentlichen Internet steht. Die erste Aufgabe besteht deshalb nicht darin, auf einen spektakulären Einbruchsbericht zu warten. Zuerst muss geklärt werden, welche Kernel- und Message-Server-Komponenten vorhanden sind, ob sie aus nicht vertrauenswürdigen Netzen erreichbar sind und ob die Korrekturen des Herstellers tatsächlich installiert und die betroffenen Prozesse neu gestartet wurden. Dieser Artikel konzentriert sich auf die defensive Frage: Wie wird aus einem Hinweis mit hoher Schwere eine belastbare Aussage über die eigene SAP-Umgebung? ## Was SAP am 8. September veröffentlichte SAP veröffentlicht seinen regulären Security Patch Day am zweiten Dienstag jedes Monats. Das September-Bulletin führt die einschlägigen Security Notes, betroffenen Produktversionen und Korrekturen für unterstützte Releases auf. Bei den beiden hier behandelten Problemen handelt es sich nicht um gewöhnliche Anwendungsfehler, die auf eine optionale Geschäftsfunktion beschränkt wären. Betroffen sind der SAP Kernel und der NetWeaver Message Server – Komponenten, die unter mehreren Produkten und Protokollen liegen können. CVE-2026-44756 wird durch die SAP Security Note 3747649 behandelt. Das zugrunde liegende Problem ist eine unzureichende Grenzwertprüfung, während der SAP Kernel Extended-Passport-Daten verarbeitet. Ein Extended Passport ist eine mit Anfragen übertragene Struktur für Tracing-Zwecke. In einer verwundbaren Implementierung können manipulierte Daten Speicherfehler oder anderes undefiniertes Verhalten auslösen. Der CVE-Eintrag beschreibt eine über das Netzwerk erreichbare Bedingung mit erheblichen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Onapsis bewertet die praktische Folge als mögliche Ausführung von Betriebssystembefehlen auf dem SAP-Host. CVE-2026-58240 wird durch die SAP Security Note 3759472 behandelt. Die Schwachstelle betrifft eine fehlende Authentifizierungsprüfung im SAP NetWeaver Message Server, konkret in der Komponente BC-CST-MS. Der Message Server koordiniert die Registrierung von Applikationsservern und die Kommunikation innerhalb einer SAP-Umgebung. Akzeptiert ein System eine nicht autorisierte Komponente als vertrauenswürdig, kann aus einer Grenze, die eigentlich nur für interne Cluster-Mitglieder gedacht ist, ein Weg zu einer weitergehenden Kompromittierung werden. Die technische Zusammenfassung stammt nicht von der Agentur der Europäischen Union für Cybersicherheit. Zuständig ist CERT-EU, das Computer Emergency Response Team für die Institutionen, Einrichtungen, Ämter und Agenturen der Europäischen Union. CERT-EU bewertet die operative Bedeutung als ernst, weil beide Schwachstellen ohne Authentifizierung aus der Ferne ausnutzbar sind, und empfiehlt, die beiden SAP Security Notes so bald wie möglich einzuspielen. ## Warum die Kernel-Lücke über einen einzelnen Web-Endpunkt hinausgeht Der Name OVERPASS kann den Eindruck erwecken, es handle sich um einen engen Fehler in einer einzelnen Funktion. Das wäre irreführend. Die Verarbeitung von Extended Passports ist eine gemeinsam genutzte Kernel-Funktion. Nach Angaben von Onapsis kann die verwundbare Verarbeitung über mehrere Protokolle und mehr als eine SAP-nahe Schicht erreicht werden. Genannt werden unter anderem die dem Internet ausgesetzte Web-Schicht, die SAP-GUI-Kommunikation und RFC-Verbindungen zwischen SAP-Systemen. Das bedeutet nicht, dass in jeder Umgebung jedes Protokoll exponiert ist. Es bedeutet aber, dass die Aussage, die SAP-Weboberfläche liege hinter einem VPN, für die Untersuchung nicht ausreicht. Derselbe Kernel-Code kann in einem System vorhanden sein, das über einen Reverse Proxy, einen Fernzugriff, eine Partnerverbindung, ein internes Integrationssegment oder ein anderes SAP-System erreichbar ist. Die richtige Frage lautet: Welche betroffenen Kernel-Binärdateien sind installiert, welche Schnittstellen laden sie und welche Netzteilnehmer können diese Schnittstellen erreichen? Diese Unterscheidung ist bei der Priorisierung wichtig. Eine Schwachstelle kann unauthentifiziert sein, ohne öffentlich im Internet zu stehen. Ein interner Angreifer, ein kompromittierter Arbeitsplatz, ein verletztes Partnernetz oder eine schlecht segmentierte Verwaltungszone kann ausreichen, wenn der relevante Dienst erreichbar ist. Umgekehrt muss auch ein wirklich isolierter Dienst gepatcht werden, weil sich Isolationsannahmen ändern und eine verwundbare Komponente bei einer späteren Architekturänderung wiederverwendet werden kann. Onapsis hält technische Exploit-Details in der öffentlichen Mitteilung bewusst zurück. Für Verteidiger ist das hilfreich: Es liegen genügend Informationen vor, um die Behebung zu priorisieren, ohne aus einem Nachrichtenbeitrag eine Ausnutzungsanleitung zu machen. Gleichzeitig darf das Fehlen eines öffentlich verfügbaren Proof of Concept kein Grund sein, die Maßnahme aufzuschieben. ## Warum S4GET die Diskussion über Vertrauensgrenzen verändert Die zweite Schwachstelle funktioniert anders, kann aber eine ähnliche Tragweite haben. Der NetWeaver Message Server koordiniert Komponenten in einem SAP-Cluster. Dieses Modell setzt voraus, dass legitime Applikationsserver von nicht autorisierten Systemen unterschieden werden können. CVE-2026-58240 zeigt, dass die betreffende Authentifizierungsprüfung in betroffenen Versionen nicht ausreicht. Nach der Zusammenfassung von CERT-EU zu den Ergebnissen der Forscher kann ein nicht authentifizierter Akteur mit Netzwerkzugang eine nicht autorisierte Komponente registrieren. Onapsis beschreibt das Risiko so, dass ein Angreifer sich als vertrauenswürdiger Knoten ausgibt und dieses Vertrauen über den Cluster weitergegeben wird. Bei erfolgreicher Ausnutzung kann dies die Ausführung von Betriebssystembefehlen unter dem Konto ermöglichen, mit dem SAP läuft. Deshalb spielt der Netzwerkstandort eine so große Rolle. Der Message Server ist nicht einfach ein weiterer Port, den man nach dem Patchen der Anwendung schließen kann. Er gehört zur Steuerungsebene einer SAP-Landschaft. Ist er aus einem Benutzernetz, einem großen Serversegment, einem Partnernetz oder dem Internet erreichbar, wird die Menge der erreichbaren Systeme zu einem Teil der Risikobewertung. Netzwerkfilterung ist allerdings eine kompensierende Maßnahme und kein Ersatz für die Korrektur des Herstellers. Sie kann die Exposition während der Vorbereitung eines Changes verringern, aber keine fehlerhafte Vertrauensprüfung reparieren. Onapsis weist außerdem auf eine schwierige operative Einschränkung hin: Der verwundbare Pfad kann denselben öffentlich erreichbaren Port verwenden wie SAP-GUI-Clients. Eine undifferenzierte Sperre könnte legitime Anmeldungen unterbrechen. Das ist eine wichtige Warnung vor eilig vorgenommenen Firewall-Änderungen ohne Einbindung des Anwendungsowners. Die Reaktion sollte aus dem Patch, einer geprüften Expositionskarte und eng begrenzten Einschränkungen bestehen, die den notwendigen Geschäftsverkehr erhalten. ## Was betroffen ist Die Listen betroffener Versionen sind technisch und müssen mit dem exakten SAP-Komponentenbestand abgeglichen werden, nicht mit einem Produktnamen, den ein Scanner gefunden hat. CERT-EU nennt für CVE-2026-44756 im Wesentlichen folgende Versionsfamilien: KRNL64NUC 7.22 und 7.22EXT; KRNL64UC 7.22, 7.22EXT, 7.53 und 8.04; KERNEL 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, 9.16, 9.18, 9.19 und 9.20; sowie WEBDISP 9.16, 9.18, 9.19 und 9.20. Der genaue verwundbare und korrigierte Build hängt von der SAP Security Note und der jeweiligen Plattformkombination ab. Für CVE-2026-58240 nennt CERT-EU die Familien KERNEL 9.16, 9.18, 9.19 und 9.20. Das Problem steht mit der NetWeaver-Message-Server-Komponente BC-CST-MS in Verbindung. Eine allgemeine Suche nach SAP-Servern erzeugt daher sowohl Fehlalarme als auch übersehene Treffer, wenn sie nicht an Daten zu installierten Komponenten und Patchständen gekoppelt ist. Diese Listen sind kein Anlass, aus einer abweichenden Versionsnummer automatisch Sicherheit abzuleiten. SAP-Landschaften enthalten häufig mehrere Systeme, alte Kernel-Binärdateien für Kompatibilitätszwecke, Applikationsserver mit unterschiedlichen Patchständen, Web Dispatcher, Entwicklungs- und Qualitätssicherungsumgebungen sowie System-zu-System-Verbindungen, die im Inventar der internetnahen Assets nicht auftauchen. Eine vollständige Reaktion muss all diese Bestandteile berücksichtigen. ## Ausnutzungsstatus: Dringlichkeit bedeutet keinen bestätigten Einbruch Die am 9. September öffentlich verfügbaren Informationen belegen nicht, dass eine der beiden Schwachstellen in großem Umfang aktiv ausgenutzt wird. Onapsis erklärt, zum Zeitpunkt seiner Mitteilung keine aktive Ausnutzung von OVERPASS beobachtet zu haben. CERT-EU empfiehlt eine sofortige Behebung, weil technische Auswirkungen und unauthentifizierte Erreichbarkeit ein hohes Risiko bedeuten – nicht, weil eine bestätigte Kampagne gegen alle SAP-Kunden gemeldet worden wäre. Diese Unterscheidung sollte erhalten bleiben. Kritisch ist ein Signal für Schweregrad und Priorität. Aktiv ausgenutzt beschreibt eine Beobachtung zum Verhalten von Angreifern. Beides ist nicht austauschbar. Ein verantwortungsvoller Prozess zur Behandlung von Sicherheitsvorfällen darf weder aus einem CVE-Wert auf einen Einbruch schließen noch eine CVE abtun, weil noch keine öffentliche Kampagne dokumentiert ist. Sicherheitsteams sollten Herstelleraktualisierungen, Hinweise von CERT-EU oder nationalen CERTs und die eigene Telemetrie beobachten. Lokale Belege sind wertvoller als allgemeines Gerede im Internet: unerwartete Registrierungen am Message Server, neue Prozesse unter dem SAP-Betriebssystemkonto, ungewöhnliche administrative Aktivitäten, unerklärte Änderungen an Profilen oder Kernel-Dateien, anomale RFC-Verbindungen und ausgehender Datenverkehr von SAP-Hosts zu geschäftlich nicht verwendeten Zielen sind Gründe für eine Eskalation. Keiner dieser Hinweise beweist für sich allein eine Kompromittierung. Zusammen können sie aber zeigen, ob Patching genügt oder ob zusätzlich eine Incident-Response-Untersuchung erforderlich ist. ## Eine praktische Reaktionsfolge ### 1. Verantwortliche benennen und Annahmen einfrieren Eine Person oder ein Team sollte die SAP-Basisadministration, den Security-Betrieb, das Netzwerkteam und den fachlichen Owner des betroffenen Systems koordinieren. Die Koordination sollte Entscheidungen und Zeitpunkte dokumentieren. So lässt sich ein typisches Problem beim Enterprise-Patching vermeiden: Das Basis-Team glaubt, das Firewall-Team sei für die Exposition zuständig, das Firewall-Team geht von einem bereits installierten Patch aus, und niemand kann belegen, dass sich der laufende Prozess geändert hat. Beginnen Sie nicht ausschließlich mit einem allgemeinen Schwachstellenscan. Ausgangspunkt sollte das maßgebliche SAP-Systeminventar sein. Prüfen Sie, welche Systeme tatsächlich laufen. Dazu gehören Produktion, Disaster Recovery, Qualitätssicherung, Entwicklung, Sandboxes, Integrations-Hubs, Web Dispatcher sowie temporäre Systeme für Migrationen oder Tests. ### 2. Betroffene Binärdateien und aktive Netzwerkpfade erfassen Für jedes System sollten Kernel-Familie, exakter Patchstand, Betriebssystem, vorhandener Message Server, vorhandener Web Dispatcher, SAP-GUI- oder RFC-Exposition und die Netzzonen dokumentiert werden, die die relevanten Dienste erreichen können. Vergleichen Sie die installierte Version mit der korrigierten Version aus den SAP Security Notes 3747649 und 3759472. Die Karte sollte konkrete Fragen beantworten: Ist ein relevanter Dienst an eine extern routbare Adresse gebunden? Kann ein Arbeitsplatz direkt darauf zugreifen? Gibt es Zugänge aus einem Partner- oder Integrationsnetz? Bestehen alternative Wege über Load Balancer, Reverse Proxy, VPN-Konzentrator, Bastion Host oder Cloud-Sicherheitsgruppe? Sind Produktions- und Nichtproduktionssysteme so segmentiert, dass dies kürzlich getestet wurde? Halten Sie die Belege fest, nicht nur das Ergebnis. Ein Ticket mit dem Vermerk nicht exponiert ist schwach. Ein Ticket, das Schnittstelle, Firewall-Regel, Datum der letzten Prüfung und freigebenden Owner nennt, kann bei einer späteren Architekturänderung erneut bewertet werden. ### 3. Herstellerkorrekturen installieren, neu starten und prüfen Befolgen Sie die veröffentlichten SAP Security Notes und den Change-Prozess der Organisation. Kernel-Updates erfordern häufig Abstimmung zwischen Instanzen, Betriebssystemen, Hochverfügbarkeitskonfigurationen und Wartungsfenstern. Eine auf einen Server kopierte Datei ist nicht dasselbe wie ein laufender Prozess, der den korrigierten Build verwendet. Prüfen Sie nach der Änderung die laufende Version jeder relevanten Instanz. Kontrollieren Sie, dass alle Applikationsserver eines Clusters denselben vorgesehenen Kernelstand verwenden. Prüfen Sie Web Dispatcher und andere Komponenten separat. Stellen Sie sicher, dass ein Failover-Knoten, eine Disaster-Recovery-Umgebung oder eine scheinbar inaktive Instanz nicht zurückgeblieben ist. Nutzt die Umgebung Automatisierung, sollte das Deployment-Ergebnis erfasst und mit unabhängigen Laufzeitdaten verglichen werden. Das Erfolgskriterium lautet nicht: Der Patchjob ist durchgelaufen. Es lautet: Jeder betroffene Dienst im definierten Umfang läuft mit der korrigierten Version, die Änderung ist dokumentiert und die Erreichbarkeitsbewertung stimmt weiterhin mit der eingesetzten Architektur überein. ### 4. Vorübergehende Kontrollen während der Vorbereitung einsetzen Ist ein sofortiges Upgrade nicht möglich, sollte die Exposition reduziert werden, ohne die Zwischenmaßnahme mit einer Behebung zu verwechseln. Beschränken Sie den Zugang zu SAP-Diensten auf die kleinste Gruppe autorisierter Netze. Entfernen Sie unnötige Internet-Exposition. Begrenzen Sie administrative Schnittstellen und Message-Server-Pfade aus Benutzer- und Partnernetzen, sofern das Geschäftsdesign dies erlaubt. Prüfen Sie Regeln auf Reverse Proxies und Load Balancern und ändern Sie nicht nur die Server-Firewall. Bei S4GET ist besondere Vorsicht bei einer pauschalen Port-Sperre nötig. Eine Regel, die SAP-GUI- oder Cluster-Kommunikation unterbricht, kann einen Verfügbarkeitsvorfall erzeugen, ohne jeden Weg zur verwundbaren Komponente zu beseitigen. Änderungen sollten gemeinsam mit dem SAP-Basisowner vorgenommen, gegen den notwendigen Datenverkehr getestet und mit einem Rückfallplan versehen werden. Kann ein System nicht zeitnah gepatcht werden, müssen Grund, kompensierende Kontrollen, die Person mit der Risikoakzeptanz und der Termin für eine erneute Bewertung dokumentiert werden. Wir patchen später ist kein Maßnahmenplan. ### 5. Nach Anzeichen einer Kompromittierung suchen Patching bleibt erforderlich, auch wenn keine verdächtigen Hinweise vorliegen. Es reicht aber nicht aus, wenn ein Zugriff auf das System möglich gewesen sein könnte. Prüfen Sie Betriebssystem-Prozessstarts, Dateiintegrität, geplante Aufgaben, Dienstdefinitionen, SAP-Sicherheitsaudit-Logs, Message-Server- und Applikationslogs, Authentifizierungsereignisse, administrative Änderungen und Netzwerkverbindungen aus dem Zeitraum vor dem Patch. Sichern Sie relevante Protokolle, bevor Aufbewahrungsfristen sie löschen. Die Prüfung sollte SAP-Betriebssystemkonten und privilegierte SAP-Benutzer einschließen, aber dort nicht enden. Ein Angreifer, der den Host erreicht, kann das Betriebssystem manipulieren, ohne einen offensichtlichen SAP-Dialog-Login zu erzeugen. Achten Sie auf unerklärte Binärdateien, veränderte Startskripte, neue lokale Konten, ungewöhnliche ausgehende Verbindungen und Änderungen an Ort oder Eigentümer von Kernel-Dateien. Deuten die Belege auf eine Kompromittierung hin, sollte die Isolation sorgfältig mit dem Incident-Response-Team und dem SAP-Owner abgestimmt werden. Löschen Sie die Maschine nicht und tauschen Sie nicht blind jede Zugangsdaten aus, bevor die für die Reichweitenbestimmung notwendigen Beweise gesichert sind. Credential-Rotation, Wiederaufbau und Maßnahmen zur Geschäftskontinuität sollten dem Incident-Prozess der Organisation folgen. ## Was der Hinweis für die einzelnen Teams bedeutet SAP-Basisadministratoren sollten die beiden Security Notes als landschaftsweite Inventarisierungs- und Patchaufgabe behandeln. Das größte Risiko besteht darin, eine Instanz, einen Dispatcher oder eine Wiederherstellungsumgebung zurückzulassen. Außerdem sollte das Basis-Team prüfen, ob der korrigierte Kernel tatsächlich läuft, statt sich allein auf den Status des Deployment-Systems zu verlassen. Netzwerkteams sollten die tatsächlichen Wege zu SAP-Diensten validieren, einschließlich solcher Pfade, die nicht als gewöhnliche Internet-Exposition erscheinen. Zu prüfen sind Sicherheitsgruppen, Load Balancer, VPN-Regeln, Partnerverbindungen und die Segmentierung zwischen Benutzer-, Server-, Entwicklungs- und Verwaltungsnetzen. Eine einzeilige Firewall-Änderung ohne Verständnis für SAP-Cluster- und Client-Kommunikation ist zu vermeiden. Security-Operations-Teams sollten die Überwachung von SAP-Hosts und Betriebssystemkonten um verdächtige Aktivitäten ergänzen. Sie sollten den Zeitpunkt der Veröffentlichung mit der lokalen Telemetrie abgleichen und Beweise sichern, solange die Logs noch verfügbar sind. Ein Schwachstellenticket und ein Incident-Ticket sind unterschiedliche Vorgänge; das eine ersetzt das andere nicht. Identity- und Access-Teams sollten privilegierte SAP- und Betriebssystemkonten überprüfen, sobald Anzeichen einer Ausnutzung vorliegen. Ein Software-Patch macht bereits ausgeführte Befehle, möglicherweise ausgelesene Zugangsdaten oder veränderte Vertrauensbeziehungen nicht rückgängig. Fachliche Owner sollten bei der Entscheidung helfen, welche Systeme eine Notfallwartung benötigen und welcher Datenverkehr tatsächlich erforderlich ist. SAP ist häufig Bestandteil von Finanzwesen, Fertigung, Logistik, Lohnabrechnung, Beschaffung oder Kundenprozessen. Die Reaktion muss schnell erfolgen, aber ein überstürzter Ausfall kann ein eigenes erhebliches Risiko erzeugen. ## Fragen, die vor dem Schließen des Tickets beantwortet sein sollten Ein belastbarer Abschlussnachweis sollte alle folgenden Fragen beantworten können: - Welche SAP-Systeme und Kernel-Familien wurden geprüft? - Welche Instanzen, Web Dispatcher und Message Server gehörten zum Umfang? - Welche exakt laufenden Versionen wurden vor und nach dem Update beobachtet? - Welche Systeme waren aus dem Internet, aus Benutzernetzen, Partnernetzen oder anderen SAP-Systemen erreichbar? - Wurden die Security Notes 3747649 und 3759472 überall eingespielt, wo sie relevant sind? - Wurden alle Cluster-Mitglieder, Standby-Systeme und Disaster-Recovery-Systeme verifiziert? - Welche vorübergehenden Netzwerkkontrollen wurden eingesetzt und wer hat sie genehmigt? - Welche Logs und Telemetriedaten wurden auf mögliche Ausnutzung geprüft? - Fand die Prüfung unerklärte Prozesse, Registrierungen, administrative Aktionen oder ausgehende Verbindungen? - Wer hat ein verbleibendes Risiko akzeptiert und wann wird es erneut bewertet? Lautet die Antwort auf eine dieser Fragen Wir wissen es nicht, ist die Arbeit nicht abgeschlossen. Es kann trotzdem sinnvoll sein, mit dem nächsten operativen Schritt fortzufahren. Die Unsicherheit muss dann aber ausdrücklich dokumentiert werden. ## Ein nüchterner Schluss OVERPASS und S4GET sind ernst, weil sie hohe Auswirkungen mit einer entfernten, unauthentifizierten Erreichbarkeit in gemeinsam genutzter SAP-Infrastruktur verbinden. Sie sind kein Grund anzunehmen, jeder SAP-Kunde sei kompromittiert. Die öffentliche Berichterstattung vom 9. September belegt auch keine breit angelegte Ausnutzung in freier Wildbahn. Sie sind aber ein Grund, Kernel-Patching in SAP nicht länger als eng begrenzte Wartungsaufgabe zu behandeln. Die sinnvolle Reaktion ist diszipliniert: die tatsächliche Landschaft inventarisieren, reale Netzwerkwege abbilden, SAP-Korrekturen installieren, jede betroffene Komponente neu starten und verifizieren, während der Änderung sorgfältig begrenzte Netzwerkkontrollen einsetzen und die Telemetrie auf Hinweise früherer Zugriffe prüfen. So entsteht etwas Belastbareres als Panik oder Beschwichtigung: eine dokumentierte Antwort darauf, was exponiert ist, was behoben wurde und wo noch Handlungsbedarf besteht. ### Quellen und Geltungsbereich Die technischen Fakten dieses Artikels beruhen auf SAPs Security-Patch-Day-Materialien für September 2026, dem Hinweis von CERT-EU zu den beiden Schwachstellen, den Veröffentlichungen der Onapsis Research Labs zur verantwortungsvollen Offenlegung sowie den von CERT-EU referenzierten öffentlichen CVE-Einträgen. Die produktspezifische Behebung sollte nach den aktuellen SAP Security Notes erfolgen, die über das SAP-Supportkonto des Kunden verfügbar sind.