Wprowadzenie do problemu / definicja
SAP ujawnił krytyczną podatność w bibliotece Cloud SDK for Python wykorzystywanej w środowisku SAP Business Technology Platform. Luka dotyczy obsługi subdomen tenantów w aplikacjach wielodzierżawnych i może prowadzić do nieuprawnionego przesłania poświadczeń OAuth2 do serwera kontrolowanego przez atakującego.
Z uwagi na ocenę CVSS 10.0 problem należy traktować jako incydent najwyższego priorytetu. W praktyce oznacza to ryzyko wycieku danych uwierzytelniających aplikacji oraz potencjalnego dalszego dostępu do zasobów chmurowych powiązanych z danym klientem OAuth2.
W skrócie
Podatność została oznaczona jako CVE-2026-89111 i dotyczy SAP Cloud SDK for Python. W określonych scenariuszach biblioteka mogła wykorzystać niezweryfikowaną wartość tenant subdomain do zbudowania adresu żądania tokenu OAuth2.
- zagrożone są aplikacje wielodzierżawne działające na SAP BTP,
- możliwy jest wyciek client_id oraz client_secret do zewnętrznego hosta,
- pierwszą poprawkę wprowadzono w wersji 0.45.2,
- wersje 0.53.0–0.55.0 nadal zawierały niespójną walidację w części modułów,
- pełniejsze zabezpieczenie wdrożono ponownie w wersji 0.55.1.
Kontekst / historia
Problem dotyczy aplikacji korzystających z SAP Cloud SDK for Python do komunikacji z usługami SAP BTP. W architekturze wielodzierżawnej aplikacja może przekazywać do SDK nazwę subdomeny konkretnego tenanta, aby pobrać token dostępu właściwy dla danego środowiska.
Według ujawnionych informacji podatny mechanizm był obecny od pierwszych wydań pakietu. W sierpniu 2026 roku opublikowano poprawkę ograniczającą możliwość nadużycia, jednak początkowo została ona opisana jako zwykła poprawka błędu, a nie kwestia bezpieczeństwa. Formalne ujawnienie luki nastąpiło 13 października 2026 roku, a dalsza analiza wykazała, że część nowszych wersji nadal nie stosowała walidacji konsekwentnie we wszystkich ścieżkach kodu.
Analiza techniczna
Źródłem problemu jest niewłaściwa walidacja parametru tenant subdomain używanego podczas konstruowania endpointu do pobierania tokenu OAuth2. Biblioteka korzysta z bazowego adresu tokenu z konfiguracji aplikacji, a następnie modyfikuje go zgodnie z przekazaną subdomeną tenanta.
Jeżeli wartość ta może być kontrolowana przez atakującego i nie zostanie poprawnie zweryfikowana, możliwe staje się utworzenie adresu prowadzącego do infrastruktury przeciwnika. W takiej sytuacji żądanie pobrania tokenu trafia do nieautoryzowanego hosta razem z poświadczeniami klienta OAuth2.
SAP klasyfikuje ten scenariusz jako odmianę SSRF, ponieważ aplikacja serwerowa wykonuje żądanie do niezamierzonego celu. Jednak skutki są poważniejsze niż w typowym SSRF, ponieważ konsekwencją może być bezpośredni wyciek client_id i client_secret.
Mechanizm naprawczy opiera się na ścisłej walidacji subdomeny tenanta. Akceptowane powinny być wyłącznie proste, dozwolone nazwy zawierające litery, cyfry i myślniki, o kontrolowanej długości. Wartości zawierające separatory URL lub inne niedozwolone znaki powinny powodować natychmiastowe przerwanie operacji bez wykonania połączenia sieciowego.
- wersje poniżej 0.45.2 są podatne,
- wersje 0.45.2–0.52.2 zawierają mechanizm walidacji,
- wersje 0.53.0–0.55.0 nie stosują tej kontroli konsekwentnie w części modułów,
- wersja 0.55.1 i nowsze ponownie wdrażają wymagane sprawdzenia.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności jest ujawnienie poświadczeń OAuth2 aplikacji. Jeśli przechwycony klient ma szerokie uprawnienia, atakujący może uzyskać dostęp do danych, integracji, konfiguracji połączeń oraz innych usług zależnych od nadanych ról i zakresów uprawnień.
Ryzyko jest szczególnie wysokie w środowiskach, które dynamicznie przekazują subdomenę tenanta, wykorzystują podatne wersje SDK i obsługują integracje z usługami takimi jak Destination service czy Document Management. W praktyce incydent może prowadzić do kompromitacji sekretów aplikacyjnych, a następnie do przejęcia elementów integracji chmurowej.
Rekomendacje
Organizacje korzystające z SAP Cloud SDK for Python powinny niezwłocznie przeprowadzić inwentaryzację wersji bibliotek we wszystkich aplikacjach działających na SAP BTP. Kluczowe jest ustalenie, czy wykorzystywane są wersje starsze niż 0.45.2 lub wydania z zakresu 0.53.0–0.55.0.
- zaktualizować SDK do wersji zawierającej pełną walidację, najlepiej do najnowszego bezpiecznego wydania,
- nie pozostawać na starszych gałęziach, które nie usuwają problemu,
- wdrożyć własną walidację tenant subdomain po stronie aplikacji,
- dopuszczać wyłącznie subdomeny z jawnej listy zarejestrowanych tenantów,
- monitorować ruch wychodzący do endpointów tokenów i wykrywać anomalie DNS,
- przeanalizować logi pod kątem nietypowych wartości subdomen zawierających elementy składni URL,
- rozważyć rotację client_secret i innych powiązanych sekretów, jeśli aplikacja działała w podatnym środowisku produkcyjnym,
- ograniczyć uprawnienia klientów OAuth2 zgodnie z zasadą najmniejszych uprawnień.
Z perspektywy bezpieczeństwa to również sygnał, aby przejrzeć biblioteki odpowiedzialne za budowanie adresów URL, obsługę tenantów i logikę uwierzytelniania. Błędy walidacji danych wejściowych w warstwie integracyjnej często prowadzą do skutków wykraczających poza pojedynczy komponent.
Podsumowanie
CVE-2026-89111 pokazuje, jak pozornie niewielki błąd walidacji może doprowadzić do krytycznego naruszenia poufności w środowisku chmurowym. Dla organizacji korzystających z SAP BTP priorytetem powinny być szybka identyfikacja podatnych wdrożeń, aktualizacja SDK, dodatkowa walidacja danych wejściowych oraz ocena, czy nie doszło do ekspozycji sekretów OAuth2.