Wenn ein deutscher Mittelständler heute seine Finanzplanung, Konzernkonsolidierung oder das Reporting an die Bundesbank mit SAP betreibt, läuft das in vielen Fällen auf SAP Business Warehouse (BW) oder SAP Business Planning and Consolidation (BPC). Genau diese beiden Komponenten stehen seit dem April-Patch-Day von SAP im Zentrum einer Sicherheitslücke, die das Bundesamt für Sicherheit in der Informationstechnik in dieser Woche zu einer der dringlichsten Schwachstellen des Monats erklärt: CVE-2026-27681, CVSS-Score 9.9, behoben in Security Note 3719353.

Die Kombination aus „authentifiziert, aber niedrig privilegiert“ und „beliebige SQL-Statements direkt auf der HANA- oder MS-SQL-Datenbank“ ist das, was diesen Fehler so gefährlich macht. Wer es ernst meint mit Datenintegrität, Bilanzwahrheit und einem zukunftsfesten Informationssicherheits-Programm, hat zwischen dem 14. April und heute keine zwei Wochen verloren – sondern zwei Wochen geschenkt bekommen, in denen weder ein öffentlicher Exploit noch eine breite Angriffswelle bekannt geworden ist. Dieses Zeitfenster schließt sich gerade.

Was genau steckt hinter CVE-2026-27681?

Im Kern ist es eine klassische, aber spektakulär ungeschickt platzierte SQL-Injection. Ein ABAP-Programm im Umfeld der Konsolidierungs- und Planungsfunktionen nimmt eine vom Anwender hochgeladene Datei entgegen und übergibt deren Inhalt – unter bestimmten Bedingungen – ohne ausreichende Berechtigungsprüfung an die Datenbank. Das bedeutet: Ein Anwender, der lediglich über das SAP-GUI-Berechtigungsobjekt S_GUI mit Aktivität 60 (Upload) verfügt, kann eine Datei mit beliebigem SQL hochladen. Das Programm liest die Datei und führt das SQL aus.

Damit fällt die übliche Schutzschicht aus – nämlich die Annahme, dass „nur ein normaler Fachanwender“ keine direkten Datenbankrechte hat. Die ABAP-Schicht wird zur Brücke, über die ein Buchhalter, ein Controller oder ein Praktikant im Reporting plötzlich zum De-facto-Datenbankadministrator wird. Auf Microsoft-SQL-Server-Backends, die in vielen BPC-Installationen Version 10.1 und 11.0 noch im Einsatz sind, ist die Wirkung besonders unangenehm: xp_cmdshell, gespeicherte Prozeduren und Cross-Database-Queries warten dort als Verstärker, sobald jemand SQL ausführen kann.

Welche Versionen sind betroffen?

SAP nennt im Patch-Hinweis eine ungewöhnlich breite Liste:

SAP Business Warehouse: SAP_BW 750, 752, 753, 754, 755, 756, 757, 758 und 816. Damit sind praktisch alle gepflegten BW-Releases der letzten Dekade enthalten.

SAP Business Planning and Consolidation: HANABPC 810, BPC4HANA 300, BPC 10.1 und BPC 11.0 – mit besonderem Augenmerk auf die Komponenten, die an Microsoft-SQL-Server-Backends angebunden sind.

Wer in den letzten Jahren ein Greenfield-Migration auf S/4HANA und BW/4HANA durchgezogen hat, ist nicht zwingend aus dem Schneider: Auch BW/4HANA-Stränge mit BW-Bridge oder Side-by-Side-Architekturen können die anfälligen ABAP-Reports geerbt haben, wenn sie aus älteren Installationen übernommen wurden.

Warum CVSS 9.9 hier nicht übertrieben ist

Ein Score von 9.9 bedeutet bei diesem Fall in der Praxis: Ein Angreifer, der nur über minimale Rechte in einem produktiven SAP-System verfügt, kann die vollständige Vertraulichkeit, Integrität und Verfügbarkeit der angeschlossenen Datenbank kompromittieren. In einem typischen BPC-Szenario heißt das übersetzt:

Vertraulichkeit: Quartals- und Jahresabschlussdaten, Forecasts, Margenstrukturen, Mitarbeiterzahlen, Kostenstellenpläne – alles steht zur Auslese bereit.

Integrität: Buchungen lassen sich nachträglich verändern, Konsolidierungspositionen umverteilen, Reports manipulieren, ohne dass eine reguläre Buchungsspur entsteht. Für Konzerne, die nach IFRS oder HGB testieren lassen, ist das ein Albtraumszenario – auch ohne Datenabfluss.

Verfügbarkeit: Ein Angreifer, der will, kann die zugrundeliegenden Datenbanktabellen mit wenigen Statements unbrauchbar machen. In Verbindung mit Ransomware-affinen Akteuren ist das eine Erpressungsoption mit unmittelbar bezifferbarem Stillstandsschaden.

Die unangenehme Frage: Wer hat eigentlich S_GUI mit Aktivität 60?

In gewachsenen SAP-Berechtigungslandschaften ist die Antwort selten beruhigend. S_GUI wird in vielen Häusern weitgehend pauschal vergeben, weil es für legitime Upload-Funktionen in unzähligen Standardtransaktionen benötigt wird. Wer nie eine systematische Berechtigungsprüfung gemacht oder kein SAP-IDM oder GRC im produktiven Betrieb hat, muss davon ausgehen, dass eine dreistellige Zahl von Konten in jedem mittelgroßen Unternehmen die Voraussetzungen für eine Ausnutzung erfüllt – inklusive technischer Service-Accounts und Schnittstellen-User mit zu weiten Profilen.

SAPs Fix: ein bemerkenswert harter Schnitt

Security Note 3719353 wählt einen Weg, der für SAP-Verhältnisse ungewöhnlich kompromisslos ist: Der Patch deaktiviert den ausführbaren Code im betroffenen ABAP-Programm vollständig. Das Programm bleibt zwar als Hülle vorhanden, kann aber nach dem Einspielen nicht mehr ausgeführt werden. SAP geht hier offenbar davon aus, dass die Funktion in der bisherigen Form nicht mehr sicher betreibbar ist und priorisiert Schutz vor Komfort.

Für Betriebe heißt das: Wer das Programm im Standard nicht aktiv genutzt hat, merkt nach dem Patch nichts. Wer ABAP-Erweiterungen, Z-Reports oder kundeneigene Custom-Aufrufe darum herum gebaut hat, sollte vor dem Einspielen testen, ob Abhängigkeiten brechen. Diese Prüfung ist überschaubar, kostet aber Zeit – und genau diese Zeit ist der Grund, warum viele Häuser SAP-Patches in der Praxis aufschieben. Genau das ist hier die falsche Entscheidung.

Workaround statt Patch?

SAP nennt einen temporären Workaround: das Berechtigungsobjekt S_GUI mit Aktivität 60 systemweit zu entziehen. Das ist nur in Ausnahmefällen praktikabel. Wer in einer hochregulierten Branche arbeitet (Banken, Versicherungen, Energieversorger im NIS2-Anwendungsbereich), sollte den Workaround als Brücke sehen – nicht als Lösung –, weil zahllose Standard- und Custom-Transaktionen Upload-Funktionen mit demselben Objekt nutzen.

Konkrete Handlungsempfehlungen für die nächsten 72 Stunden

1. Inventur machen. Welche SAP-BW- und BPC-Systeme gibt es im Konzern? Auch Entwicklungs- und Qualitätssicherungssysteme zählen, weil ein kompromittiertes DEV-System mit produktivem Datenbestand denselben Schaden verursachen kann. Eine Tabelle aus SAP Solution Manager, Focused Run oder einer eigenen CMDB ist dafür ausreichend.

2. Patch-Status prüfen. Die Note 3719353 ist seit dem 14. April über den Standardweg verfügbar. SAP-Basis-Teams sollten den aktuellen Status für jedes betroffene System eindeutig dokumentieren: nicht eingespielt, getestet, in Produktion eingespielt.

3. Berechtigungsanalyse zu S_GUI. Welche Rollen tragen das Objekt mit Aktivität 60? Gibt es technische Konten oder Service-User, die das Recht ohne erkennbaren Bedarf besitzen? Eine Bereinigung dieser Rechte ist auch unabhängig von dieser CVE eine sinnvolle Hygienemaßnahme.

4. Logging schärfen. SAP Security Audit Log und HANA Audit Trail so konfigurieren, dass Programmaufrufe und kritische SQL-Operationen aufgezeichnet werden. Wer SIEM-seitig Sysmon, Splunk oder Sentinel im Einsatz hat, sollte gezielt nach ABAP-Aufrufen mit File-Upload-Pattern und ungewöhnlichen DB-Operationen filtern.

5. Notfallpfad definieren. Wenn der Patch wegen Tests oder Change-Freeze nicht sofort produktiv eingespielt werden kann, muss ein klarer Mitigationspfad existieren: temporäre Sperre des Programms über SE38, Custom-Berechtigungsprüfung im User-Exit oder, im Härtefall, restriktiver Entzug von S_GUI bis zur Patch-Einspielung.

6. Externe Anbindungen prüfen. Wer SAP-Systeme über RFC-Schnittstellen, Web Services oder OData-Endpunkte mit Drittsystemen integriert hat, muss prüfen, ob diese Schnittstellen Wege zur Triggerung des betroffenen Reports anbieten. Auch reine API-Aufrufe können das Programm aktivieren, wenn die Berechtigungen passen.

Einordnung: ein Symptom, kein Einzelfall

CVE-2026-27681 ist nicht der erste Fall einer kritischen SAP-Schwachstelle in einem ABAP-Standardreport, und er wird nicht der letzte sein. Was diesen Fall besonders macht, ist die Kombination aus niedriger Einstiegshürde, hoher Wirkung und einer Komponente, die in jeder konsolidierungspflichtigen Konzerntochter mitläuft. Die Realität in vielen Häusern ist: SAP-Patching ist ein zäher Prozess, der zwischen SAP-Basis, Fachbereich und externem Dienstleister abgestimmt werden muss. Genau diese Trägheit ist es, die Angreifer zunehmend zu ihrem Vorteil nutzen.

Für IT-Verantwortliche im deutschen Mittelstand bedeutet das: Eine reine „Patch-it-when-the-window-opens“-Strategie reicht für ABAP-Schwachstellen mit CVSS jenseits von 9 nicht mehr. Wer den Schutz seiner SAP-Landschaft ernst nimmt, etabliert für solche Fälle einen Fast-Lane-Prozess, der zwischen erstem Hinweis und produktiver Einspielung idealerweise unter sieben Tagen bleibt – ohne Reuetests zu opfern. Das ist organisatorisch anspruchsvoll, aber machbar, und die Erfahrung zeigt, dass Häuser, die diese Disziplin entwickelt haben, im Ernstfall um Größenordnungen widerstandsfähiger sind als solche, die jeden Patch wie ein Großprojekt behandeln.

Was pleXtec empfiehlt

Wenn Sie Unterstützung bei der Bewertung Ihrer SAP-Landschaft, der Berechtigungsanalyse oder dem Aufbau eines belastbaren Patch- und Notfallprozesses suchen, hilft das Team von pleXtec gerne weiter. Unsere Erfahrung mit Mittelstands-SAP-Landschaften reicht von der reinen Schwachstellenbewertung bis zur Begleitung kompletter Informationssicherheits-Programme. Sprechen Sie uns über das Kontaktformular an – idealerweise, bevor der erste öffentliche Exploit zu CVE-2026-27681 zirkuliert.

Bis dahin gilt: Note 3719353 einspielen. Heute, nicht nächste Woche.