SAP Cloud SDK for Python: SSRF-Lücke mit CVSS 10.0

SAP hat am 13. Oktober 2026 seinen monatlichen Security Patch Day abgehalten. Die offizielle Patch-Day-Seite des Konzerns listet 16 neue Security Notes und 4 GitHub Security Advisories, hinzu kommen zwei Aktualisierungen bestehender Notes. Im Zentrum der Berichterstattung steht eine SSRF-Schwachstelle im SAP Cloud SDK for Python, die das Sicherheitsportal SecurityOnline mit CVSS 10.0 bewertet — dem Höchstwert der Skala. Betroffen sind laut dieser Quelle Multi-Tenant-Anwendungen auf SAP BTP.

SAP Cloud SDK for Python: SSRF mit CVSS 10.0

Die Lücke firmiert unter CVE-2026-89111 und wird als CWE-918 (Server-Side Request Forgery) geführt. Nach der Beschreibung von SecurityOnline genügt die Kontrolle über einen Tenant-Subdomain-Wert, um OAuth2-Token-Requests auf einen Server der eigenen Wahl umzuleiten; die Client-Credentials sollen dabei abfließen. Eine Anmeldung sei für den Angriff nicht erforderlich. Die Fehlerklasse ist bekannt: SSRF tritt überall dort auf, wo eine Anwendung Ziel-URLs aus nicht vertrauenswürdigen Eingaben übernimmt — hier offenbar aus mandantenabhängigen Konfigurationswerten.

Bemerkenswert ist der Weg, über den die Lücke abgewickelt wird: Sie läuft als GitHub Security Advisory und nicht als SAP Note. Damit greift für betroffene Teams nicht der gewohnte Patchday-Workflow über den SAP-Support. Stattdessen muss die Abhängigkeit im eigenen Projekt gehoben werden. Das SAP Cloud SDK for Python ist der offizielle Python-Client für SAP BTP und wird als Bibliothek in eigene Anwendungen eingebunden, inklusive Unterstützung für Agent Gateway, Agent Memory und BTP-Services. Ein Update heißt in der Praxis also: Version prüfen, Abhängigkeit aktualisieren, Anwendung neu bauen und neu ausrollen. Wer mehrere Mandanten auf derselben Instanz betreibt, sollte zusätzlich die OAuth2-Client-Credentials rotieren.

Konkrete Versionsnummern nennt die Quelle nicht. Die exakten betroffenen Releases sollen in den jeweiligen Notes stehen und einen SAP-Support-Login erfordern — im vorliegenden Material sind sie nicht enthalten.

Die weiteren Notizen des Patchdays

Neben dem Python-SDK listet SecurityOnline mehrere Schwachstellen mit hohen und kritischen Scores:

CVE-2026-89110 (CVSS 9.9, CWE-749): SAP NetWeaver Visual Composer — übersprungene Autorisierungsprüfungen in Portal-Funktionen. Ein niedrig privilegierter Angreifer könnte interne Operationen auf einem vorkonfigurierten Remote-System auslösen und damit das entfernte System vollständig übernehmen. SAP Note 3797111.
CVE-2026-89107 (CVSS 9.9, CWE-94): SAP S/4HANA, App „Manage Substitution/Validation Rules" — unzureichend geprüfter Rule-Input wird als ausführbarer ABAP-Code interpretiert. Laut der zitierten SAP-Bewertung ist eine vollständige Kompromittierung des betroffenen Systems möglich. SAP Note 3805589.
CVE-2026-89108 (CVSS 9.1, CWE-862): Manufacturing Integration and Intelligence (MII) — ein MII-Administrator könnte ein erhöhtes Konto auf dem zugrunde liegenden Java-Server anlegen. SAP Note 3798788.
CVE-2026-89113 (CVSS 8.8, CWE-89): SQL-Injection in SAP Commerce Cloud — Datenbankinhalte könnten offengelegt oder verändert werden. SAP Note 3800517.
CVE-2026-89120 (CVSS 7.1): SAP ABAP Platform — eine durch eine API-Änderung ausgelöste Regression führt eine bereits behobene Autorisierungsschwäche wieder ein.
CVE-2026-58249 (CVSS 7.5): Eine nicht authentifizierte Schwachstelle soll SAP-NetWeaver- und SAP-Web-Dispatcher-Prozesse per manipulierter Anfrage zum Absturz bringen.

Auffällig: Die Mengenangaben passen nicht zusammen. SAP nennt 16 neue Notes, die Sekundärquelle schreibt im Teaser von „20 CVEs", listet im Kasten „5 CVEs · 4 Critical · 1 High", führt in der Tabelle aber sechs Einträge plus zwei weitere im Text. Auch die Kategorie „4 Critical" ist nicht aufgelöst — ob die Lücke mit CVSS 9.1 hinzugezählt wird, bleibt offen. Gesichert ist bislang nur die Zahl der Notes von der SAP-Seite.

Kein bestätigter Exploit — aber Handlungsdruck

SAP meldet laut der zitierten Sekundärquelle weder eine Ausnutzung in freier Wildbahn noch einen bestätigten öffentlichen Proof-of-Concept. Der zugrundeliegende RSS-Titel („Angreifer können Systeme übernehmen") beschreibt damit ein potenzielles Szenario, nicht ein eingetretenes Ereignis. Für Betreiber ändert das wenig an der Priorität: Eine SSRF mit CVSS 10.0 in einer Cloud-Bibliothek bleibt unabhängig vom Exploit-Status ein Patch-Kandidat der ersten Stunde. Multi-Tenant-Konstrukte verschärfen das, weil ein einzelner kompromittierter Mandant die Vertrauensgrenze zu anderen überschreiten kann.

Ein zweites Muster zeigt der Patchday selbst: Die Zählungen in den gängigen Aggregatoren weichen regelmäßig von den SAP-Angaben ab. Wer Priorisierung nach Schweregrad betreibt, sollte sich auf die Notes stützen und nicht auf Zusammenfassungen.

Was Admins jetzt tun sollten

Sinnvoll ist eine Reihenfolge, die mit den kritischen Notes beginnt:

Python-SDK aktualisieren — in allen Multi-Tenant-BTP-Anwendungen, anschließend OAuth2-Client-Credentials rotieren.
NetWeaver Visual Composer patchen und bestehende Remote-System-Verbindungen prüfen, ob sie erwartbar konfiguriert sind.
Berechtigungen einschränken — die Rechte für S/4HANA-Ruledefinitionen und für MII-Administratorzugänge reduzieren.
Internet-exponierte Web-Dispatcher-Instanzen patchen, da hier keine Authentifizierung nötig sein soll.

Dass SAP-Patchdays selten Einzelfälle bleiben, ist ein bekanntes Muster: Fehlkonfigurationen, ungepatchte Lücken und übermäßige Benutzerrechte gelten in der Analyse wiederkehrend als die größten SAP-Risiken. Verzögertes Patchen ist dabei kein theoretisches Problem — frühere kritische Lücken wie CVE-2022-22536 (SAP-Hinweis 3123396) oder CVE-2020-6287 (SAP-Hinweis 2934135) zeigen, wie lange exponierte Altsysteme zum Risiko bleiben, wenn Updates liegen bleiben (TJC Group). Im Fall des Python-SDK kommt hinzu, dass der Fix nicht nur eingespielt, sondern durch die eigene Anwendung hindurch bis ins Deployment getragen werden muss.

Ein Hinweis für das Code-Repository

Nicht übertragbar ist das End-of-Life des SAP Cloud SDK Java in den Versionen v3 und v4, für die es keine Security-Fixes mehr gibt. Diese Regelung betrifft das Python-SDK nicht. Teams, die beide Sprachen im Einsatz haben, sollten die Upgrade-Pfade dennoch getrennt prüfen.

Quellen