SAP heeft een kritieke kwetsbaarheid bekendgemaakt in SAP Cloud SDK Python. De fout (CVE-2026-89111) heeft een CVSS-score van 10.0/10 en kan leiden tot het misbruik van OAuth2 client credentials door een aanvaller die de tenant-identificatie kan beïnvloeden. Het incident is niet gekoppeld aan bekende aanvallen, maar de impact op authenticatie maakt snel ingrijpen verstandig.
De kern van het probleem zit in de manier waarop de SDK tokens aanvraagt voor multi-tenant toepassingen op het SAP Business Technology Platform (BTP). Als een applicatie een tenant subdomein doorgeeft aan de SDK zonder voldoende validatie, kan die waarde worden ingezet om authenticatieverzoeken naar een server van de aanvaller te laten lopen.
Wat is er precies mis met SAP Cloud SDK Python?
Volgens SAP kan de SDK, wanneer een applicatie een tenant subdomein doorgeeft, een URL voor tokenaanvraag construeren. Daarbij wordt een deel van een bestaande token-URL vervangen door het tenant subdomein. In versies zonder de juiste controle gebruikt de SDK vervolgens de OAuth2 client ID en client secret om een toegangstoken aan te vragen bij de aldus opgebouwde bestemming.
Kan een aanvaller het tenant subdomein controleren, dan kan die de bestemming manipuleren. In dat scenario kan de SDK client credentials sturen naar een endpoint die de aanvaller beheert.
CVSS 10.0 en de type kwetsbaarheid: SSRF
SAP classificeert de kwetsbaarheid als server-side request forgery (SSRF). Dat houdt in dat een systeem een verzoek kan doen naar een locatie die het niet bedoeld had—in dit geval veroorzaakt door het tenant subdomein als input.
De fout is alleen relevant wanneer applicaties daadwerkelijk een tenant subdomein aan de SDK doorgeven. Is die route niet aanwezig of is de tenantwaarde correct gevalideerd vóór de SDK, dan is de kans op misbruik kleiner.
Voor welke toepassingen geldt het risico?
De kwetsbaarheid treft multi-tenant applicaties op SAP BTP die gebruikmaken van de SAP Cloud SDK voor Python. Concreet gaat het om toepassingen die met de SDK authentication verwerken voor BTP-diensten.
De advisering benoemt daarbij dat de oplossing eerder een check toevoegde voor invalid tenant subdomeinen, maar dat niet elke latere release die check altijd toepaste.
Welke versies zijn (niet) veilig?
SAP meldt dat de controle om een onjuist tenant subdomein te weigeren is toegevoegd in versie 0.45.2, uitgebracht op 21 augustus. De officiële fix zorgt ervoor dat een tenant subdomein alleen als een “eenvoudige naam” wordt geaccepteerd.
In de praktijk bleek dat sommige daaropvolgende versies de controle niet consequent toepasten. SAP en de ontdekker hebben dit in detail onderzocht.
Wat SAP aanbeveelt als uitgangspunt:
- 0.45.2 tot en met 0.52.2: bevat de controle volgens de advisering.
- 0.55.1 tot en met 0.58.4: bevat de controle volgens de advisering.
- 0.53.0 tot en met 0.55.0: skipte in bepaalde gevallen de check.
- Voor de oudere 0.36-lijn: de checks ontbreken in 0.36.1 en 0.36.2.
Op 13 oktober staat in de advisory geen versie boven 0.45.2 als getroffen. Wel vermeldt SAP dat de advisering geen expliciete duidelijkheid geeft of de “zes” specifieke releases binnen de CVE-scope vallen.
Waarom kon een aanvaller credentials omleiden?
De fix richt zich op het beperken van toegestane tenant subdomeinwaarden. SAP beschrijft dat de check alleen een enkele naam accepteert met letters, cijfers en koppeltekens, met een maximale lengte van 63 tekens.
Als het tenant subdomein daar niet aan voldoet—bijvoorbeeld door URL-delimiters mee te geven—dan moet de SDK volgens de verbeterde logica meteen stoppen met een fout. SAP noemt daarbij dat de aangepaste release een ValueError veroorzaakt in plaats van het “stil” construeren van een onbedoelde URL.
Een belangrijk detail: de onvolledige toepassing van de controle hield verband met een module waar tokenaanvragen via verlopen. SAP noemt dat een wijziging rond de Destination service module ervoor zorgde dat de check niet overal werd meegenomen, tot de herstelrelease op 18 september.
Wat moet je als ontwikkelaar of beheerder nu doen?
De situatie vraagt vooral om gecontroleerde input en snelle dependency-updates. Je kunt grofweg in drie stappen handelen.
1) Upgrade naar de veilige SDK-versies
Werk de SAP Cloud SDK Python dependency bij naar een versie die volgens SAP de tenant-validatie bevat. De advisory noemt expliciet 0.45.2 als fix-startpunt en verder ook de reeksen 0.55.1 tot en met 0.58.4.
2) Controleer waar de tenantwaarde wordt doorgegeven
Het risico bestaat alleen als applicatiecode daadwerkelijk een tenant subdomein aan de SDK doorgeeft. Inventariseer daarom in welke routes of services de tenantparameter wordt opgebouwd en gebruikt, met extra aandacht voor authenticatiegerelateerde flows.
3) Beperk afhankelijkheid van “onvertrouwde” tenant-invoer
Als upgraden nog niet direct lukt, adviseert SAP om het tenant subdomein te vergelijken met een lijst van bij je bekende geregistreerde tenants. Daarmee voorkom je dat een willekeurige of gemanipuleerde waarde in de URL-construtie belandt.
Let op: de advisory geeft niet aan of applicaties die ooit versies zonder de check draaiden hun client credentials moeten vervangen. In de praktijk is het wél verstandig om de authenticatie- en incidenthistorie te bekijken en, waar passend, te beoordelen of heruitgifte van credentials nodig is.
Geen gerapporteerde aanvallen, maar wel een duidelijk leerpunt
SAP meldt dat er in de advisory geen gevallen van misbruik worden genoemd. Het lek is wel al eerder in code aanwezig geweest: SAP geeft aan dat de kwetsbare logica vanaf de eerste release op PyPI in de SDK zat.
De timing—fix in augustus, disclosure in oktober—laat vooral zien hoe belangrijk het is om ook “kleine” validatieverschillen serieus te nemen. Een extra check tegen ongeldige tenantwaarden lijkt technisch, maar kan bij authenticatie sturingsdata worden tot een geloofwaardige route voor SSRF en credential theft.
Vergelijkbare aandachtspunten: supply chain en OAuth-achtige risico’s
Deze kwetsbaarheid onderstreept het grotere thema van software supply chain security: een dependency in je authenticatieketen kan het hele risico-profiel bepalen. Zie ook de waarschuwingen over misbruik in token- of credentialcontext, zoals deze aandacht voor een Docker Hub bug waarbij tokens misbruikt konden worden.
Daarnaast past deze case bij de bredere trend waarbij aanvallers via web- en authenticatie-infrastructuur proberen te escaleren. Als je organisatie werkt met multi-tenant omgevingen of programmatische toegangsdelegatie, is het extra belangrijk om validatie op input-niveau als standaard te behandelen.
Conclusie
SAP Cloud SDK Python heeft een kritieke SSRF-kwetsbaarheid (CVE-2026-89111) waarbij OAuth2 client credentials kunnen worden doorgestuurd naar een server die een aanvaller beheert. SAP voegde de kernfix toe in 0.45.2, maar niet elke release daarna paste de check consequent toe.
De beste volgende stap is: upgrade naar een versie waarin de tenant-subdomeinvalidatie wél klopt, en controleer waar je tenantwaarden aan de SDK doorgeeft. Zo beperk je het risico op OAuth2-credential diefstal via URL-construtie en onbedoelde tokenaanvragen.
Bron: https://thehackernews.com/2026/10/sap-discloses-critical-cvss-10-flaw-in.html
