Eine mandantenfähige Anwendung muss wissen, für welchen Kunden sie arbeitet. Wird diese Zuordnung jedoch ungeprüft in die Adresse eines Authentifizierungsservers eingebaut, kann aus einem Routingparameter ein Abflusskanal für Zugangsdaten werden. Genau dieses Problem beschreibt SAP für sein Cloud SDK für Python. Für Unternehmen geht es deshalb nicht nur um ein Bibliotheksupdate: Sie müssen nachvollziehen, wer Mandantenwerte bestimmen darf und wohin ihre Anwendungen vertrauliche Authentifizierungsanfragen senden. [1]
Die am 13. Oktober 2026 veröffentlichte Sicherheitsmeldung zu CVE-2026-89111 bewertet die Schwachstelle mit CVSS 10,0. Der erste bezeichnete Fix ist allerdings älter. Zusätzlich dokumentieren spätere Release Notes eine weitere Korrektur derselben Eingabegrenze in gemeinsam genutztem Authentifizierungscode. Die praktische Konsequenz: Ein Versionsvergleich allein verdient hier keine Entwarnung. [1–4]
Die Vertrauensgrenze liegt vor der Token-Anfrage
Laut SAP betrifft das Problem mandantenfähige Anwendungen auf der Business Technology Platform, die das Python-Paket sap-cloud-sdk verwenden. Kann ein Angreifer den Parameter tenant_subdomain kontrollieren, lassen sich OAuth2-Token-Anfragen an einen von ihm kontrollierten Server lenken. Dabei können die Client-Zugangsdaten abfließen. Das Advisory klassifiziert die Schwachstelle als Server-Side Request Forgery, kurz SSRF. [1]
Ein Blick in den offiziellen Quellcode erklärt die Grenze: Der Authentifizierungsanbieter liest die konfigurierte Token-Adresse und ersetzt darin die Identitätszone durch den übergebenen Mandantenwert. Anschließend verwendet er die resultierende Adresse für eine Anfrage mit Client-ID und Client-Secret. Im geprüften Stand 0.55.0 fehlt an dieser Stelle eine Prüfung des Mandantenwerts; in 0.55.1 steht sie unmittelbar vor der Ersetzung. Dies ist eine Quellcodeprüfung, kein eigener Exploitnachweis. [5]
Die Ursache liegt damit nicht in einem gebrochenen OAuth-Verfahren. Entscheidend ist, ob unzureichend geprüfte Anwendungsdaten das Ziel einer privilegierten Anfrage verändern dürfen. Ebenso wichtig ist die Voraussetzung: Nicht jede Installation des Pakets ist automatisch von außen ausnutzbar. Unternehmen müssen den tatsächlichen Datenfluss vom Eingang einer Anfrage bis zum SDK-Aufruf untersuchen. [1,5]
Zwei Fix-Zeitpunkte statt einer einfachen Versionsgrenze
SAP nennt im Advisory alle Versionen unter 0.45.2 als betroffen und 0.45.2 als korrigiert. Diese Version wurde laut GitHub-Veröffentlichungszeitpunkt bereits am 21. August 2026 veröffentlicht. Ihre Release Notes beschreiben eine Validierung für Agent Gateway, Destination und Document Management Service. Erlaubt wird ein einzelnes DNS-Label nach RFC-1123-Regeln; unter anderem werden Punkte, Schrägstriche und unzulässige Bindestrichpositionen zurückgewiesen. [1,2]
Für die heutige Prüfung ist jedoch eine zweite Änderung relevant. Version 0.53.0 führte einen gemeinsamen HTTP-Client mit XsuaaAuthProvider ein und stellte das Destination-Modul auf diese Infrastruktur um. Die Release Notes von 0.55.1 dokumentieren anschließend ausdrücklich eine Korrektur der Tenant-Subdomain-URL-Injection in XsuaaAuthProvider._fetch_token. Der GitHub-Zeitstempel datiert diese Veröffentlichung auf 18. September 2026; die Jahreszahl im manuell gepflegten Release-Titel weicht davon ab. [3,4]
Damit sind zwei Aussagen auseinanderzuhalten: Die offizielle CVE-Versionsgrenze lautet weiterhin kleiner als 0.45.2. Die späteren Herstellerunterlagen belegen aber eine zusätzliche sicherheitsrelevante Validierung im neuen Authentifizierungspfad. Es wäre daher irreführend, jede höhere Versionsnummer allein aufgrund des Advisorys als geprüft sicher einzuordnen. Eine vollständige eigene Prüfung aller Zwischenversionen liegt diesem Artikel nicht zugrunde. [1–5]
Warum das für Cloud- und Agentenarchitekturen zählt
Der Fall ist für Enterprise Security interessant, weil die betroffene Bibliothek nicht nur einen isolierten Login-Dialog bedient. Die Herstellerunterlagen nennen sowohl klassische Integrationsmodule als auch Agent Gateway und Agent Memory. In Version 0.53.0 wurde auch der Transport von Agent Memory auf den gemeinsamen HTTP-Client umgestellt. Das belegt eine gemeinsam genutzte Authentifizierungsarchitektur, nicht automatisch die Ausnutzbarkeit jeder dieser Funktionen. [2,3]
Unsere architektonische Schlussfolgerung: Sicherheitsprüfungen sollten sich nicht auf die sichtbare Geschäfts- oder Agentenfunktion beschränken. Eine darüberliegende Freigabe für einen Tool-Aufruf ersetzt keine Kontrolle darüber, an welchen Authentifizierungsdienst die darunterliegende Bibliothek Zugangsdaten sendet. Mandantenidentität, Zieladresse und technische Berechtigung sind getrennte Grenzen und sollten entsprechend getrennt geprüft werden.
Auch der Entwicklungsprozess verdient Aufmerksamkeit. Wenn gemeinsam genutzter Authentifizierungscode eingeführt wird, sollten bestehende Sicherheitseigenschaften als verbindliche Tests mitwandern. Ein Refactoring kann funktional korrekt erscheinen und dennoch eine zuvor vorhandene Eingabeprüfung verlieren. Der Vergleich der veröffentlichten Änderungen ist deshalb ein sinnvoller Anlass, solche Tests in die eigene Integrationspipeline aufzunehmen. [2–5]
Was Unternehmen jetzt konkret prüfen sollten
Die folgenden Maßnahmen sind unsere operativen Empfehlungen, abgeleitet aus der beschriebenen Vertrauensgrenze. Sie sind kein von SAP veröffentlichter Incident-Response-Leitfaden.
Erstens: den laufenden Bestand erfassen. Nicht nur zentrale Anforderungsdateien durchsuchen, sondern installierte Pakete in produktiven Images, Integrationsdiensten und Hintergrundprozessen prüfen. Für jede Fundstelle sollten Version, verantwortliches Team und verwendete SDK-Module feststehen. Ein bereits aktualisiertes Repository sagt noch nichts über ältere, weiterlaufende Container aus.
Zweitens: den Aufrufpfad nachvollziehen. Dokumentieren, woher tenant_subdomain stammt. Kommt der Wert aus einem geprüften Mandantenregister oder mittelbar aus URLs, Headern und Nutzereingaben? Die Untersuchung sollte zeigen, welche Stelle die Zuordnung verbindlich bestätigt. Ein syntaktisch gültiger Mandantenname ist noch kein Nachweis, dass der aktuelle Benutzer für diesen Mandanten berechtigt ist.
Drittens: gezielt aktualisieren und testen. Eine kompatible Version einsetzen, die auch die spätere Korrektur des gemeinsamen Authentifizierungspfads enthält. Die Integrationsprüfung sollte ungültige Mandantenwerte zurückweisen, bevor überhaupt eine Netzwerkanfrage entsteht. Für solche Tests ausschließlich künstliche Zugangsdaten und kontrollierte Testendpunkte verwenden; echte Secrets gehören weder in Testprotokolle noch in Fehlerberichte.
Viertens: den Übergang absichern. SAP empfiehlt als Workaround eine bekannte Positivliste registrierter Mandanten-Subdomains vor jedem entsprechenden SDK-Aufruf. Ergänzend sollten ausgehende Verbindungen zu Authentifizierungsdiensten auf erforderliche Ziele beschränkt werden. Diese zweite Maßnahme ist eine zusätzliche Schutzschicht, kein Ersatz für die Eingabevalidierung. [1]
Fünftens: mögliche frühere Exposition bewerten. Bei einem erreichbaren, ungeprüften Datenpfad verfügbare Proxy-, DNS- und Anwendungsprotokolle nach unerwarteten Authentifizierungszielen untersuchen. Wenn ein Zugangsdatenabfluss plausibel ist, betroffene Client-Secrets kontrolliert ersetzen und vorhandene Token nach den Möglichkeiten des jeweiligen Dienstes widerrufen. Vor Änderungen relevante Belege sichern. Fehlende Protokolle rechtfertigen keine automatische Entwarnung.
Aussagekraft und Grenzen
CVSS 10,0 beschreibt die technische Schwere, nicht die Zahl kompromittierter Unternehmen. Das ausgewertete SAP-Advisory nennt weder bestätigte Opfer noch eine beobachtete Angriffskampagne. Der mögliche Folgeschaden hängt zudem davon ab, welche Rechte die betroffene Client-Identität besitzt und ob Angreifer den relevanten Parameter tatsächlich beeinflussen können. [1,5]
Fazit
Die neue Offenlegung macht aus einer vermeintlichen Eingabeprüfung ein dringendes Thema für Cloud-Identitäten. Der belastbare Abschluss lautet nicht bloß „Version erhöht“, sondern: Mandantenwerte kontrolliert, tatsächlich genutzten Authentifizierungspfad geprüft, Zieladressen begrenzt und mögliche Zugangsdatenexposition bewertet. Gerade bei gemeinsam genutzten SDKs sollten diese Nachweise Bestandteil des Betriebs werden.
Quellen
- SAP: Security Advisory GHSA-4mv3-jxxm-9cx2, veröffentlicht am 13. Oktober 2026
- SAP: Release 0.45.2 und erste Tenant-Subdomain-Validierung
- SAP: Release 0.53.0 und gemeinsamer HTTP-/Auth-Client
- SAP: Release 0.55.1, Tenant-Subdomain-URL-Injection
- SAP-Quellcode, Vergleich von Auth-Modell 0.55.0 und Auth-Modell 0.55.1.