Уязвимост в Cloud SDK за Python на SAP може да изпрати клиентските идентификационни данни за OAuth2 на дадено приложение към сървър под контрола на атакуващ, съобщи SAP в бюлетин за сигурност на 13 октомври. Дефектът засяга мултитенантни (multi-tenant) приложения на SAP Business Technology Platform (BTP), които използват SDK — официалния Python клиент на SAP за услуги на BTP. За да се възползва, атакуващият трябва да има възможност да контролира поддомейна на наемателя (tenant subdomain) — името, което такова приложение подава към SDK, за да посочи за кой наемател се отнася дадена заявка.
Уязвимостта се проследява като CVE-2026-89111 и има максимална оценка по CVSS от SAP от 10.0 от 10 възможни. В бюлетина като коригираща версия се посочва 0.45.2, публикувана на 21 август.
SDK управлява автентикацията за тези услуги чрез клиентските идентификационни данни на приложението — client ID и client secret. Версия 0.45.2 добави проверка, която отхвърля всеки поддомейн на наемател, който не представлява просто име.
Шест по-късни версии обаче не прилагат тази проверка във всички случаи, установи The Hacker News. Версии от 0.53.0 до 0.55.0, публикувани между 10 и 18 септември, я пропускат, когато дадено приложение извиква модула Destination service на SDK.
Версия 0.53.0 премести този модул към нов споделен код за заявяване на токени, като този код не включваше проверката. Версия 0.55.1 я добави там на 18 септември.
Подаването на поддомейн на наемател, съдържащ разделители за URL адреси, „вече незабавно предизвиква ValueError, вместо мълчаливо да пренасочва идентификационните данни към крайна точка под контрола на атакуващ“, се посочва в бележките по версия 0.55.1.
На 13 октомври The Hacker News изпълни собствените тестове на SAP за проверката спрямо изходния код на всяко издание от 0.45.1 до 0.58.4, както и за трите версии от линията 0.36. Шестте издания се провалиха на 9 от 11-те теста, които SAP добави с версия 0.55.1. Тази версия и последващите 11 издания преминаха успешно всички 11 теста.
Към 13 октомври в бюлетина не е посочена версия над 0.45.2 като засегната. Нито в него, нито в бележките към версиите се уточнява дали тези шест издания попадат в обхвата на CVE-2026-89111.
Две версии от по-старата линия 0.36 също нямат проверката. Версии 0.36.1 и 0.36.2 бяха публикувани съответно на 4 и 10 септември, след корекцията за сигурност от август, и се провалиха на тестовете, написани от SAP. И двете попадат в посочения в бюлетина диапазон от версии под 0.45.2.
| Издания | Проверка на поддомейн на наемател | Основание |
|---|---|---|
| Под 0.45.2, включително 0.36.1 и 0.36.2 | Липсва | Бюлетин за сигурност на SAP. Тест на The Hacker News за 0.36.0, 0.36.1, 0.36.2 и 0.45.1. |
| 0.45.2 до 0.52.2 | Налична | Тест на The Hacker News за всички 18 издания. |
| 0.53.0 до 0.55.0 | Липсва при извиквания на Destination. Липсва и при извиквания на Document Management Service във версия 0.55.0. | Бележки към версия 0.55.1 на SAP. Тест на The Hacker News за всички 6 издания. |
| 0.55.1 до 0.58.4 | Налична | Тест на The Hacker News за всички 12 издания. |
Какво да направите
Версии от 0.45.2 до 0.52.2 и от 0.55.1 до 0.58.4 съдържат защитната проверка. Версия 0.58.4 беше най-новото издание в PyPI (индекса на пакети за Python) към 13 октомври.
Обновяването в рамките на линията 0.36 не добавя проверката. Никое от трите ѝ издания не я съдържа.
Приложения, които все още не могат да преминат към по-нова версия, могат да сравняват всеки поддомейн на наемател със списък на регистрираните си наематели, преди да го подадат към SDK, съветва SAP в бюлетина.
Уязвимостта има значение само когато приложение подава поддомейн на наемател към SDK. Корекцията за сигурност от август обхвана три модула: Agent Gateway, Destination и Document Management Service.
В бюлетина не се посочва дали организациите, чиито приложения са използвали версия без проверката, трябва да сменят своите клиентски идентификационни данни.
Как работи уязвимостта
Когато дадено приложение подаде поддомейн на наемател, SDK заявява токен за достъп за съответния наемател. За да направи това, библиотеката взема URL адреса за токени от конфигурацията на приложението и замества част от него с поддомейна на наемателя.
Версиите без проверка използваха каквато и да е подадена стойност. След това SDK изпращаше клиентския идентификатор (client ID) и тайната на клиента (client secret) на приложението към генерирания URL адрес, за да заяви токена.
Атакуващ, който контролира поддомейна на наемателя, може да насочи тази заявка към собствен сървър, според SAP.
Проверката приема само единично име, състоящо се от букви, цифри и тирета, с дължина до 63 знака. Всяка друга стойност прекъсва изпълнението на заявката с грешка.
SAP определя уязвимостта като фалшифициране на заявки от страна на сървъра (SSRF — Server-Side Request Forgery) — слабост, при която сървър може да бъде подведен да изпрати заявка към непредвидена дестинация.
Какви действия би могъл да извърши атакуващият с придобитите идентификационни данни зависи от правата, с които разполага клиентът на приложението. В бюлетина липсват подробности по този въпрос.
Коригирана през август, оповестена през октомври
Непровереният код е присъствал в SDK още от първото му публикуване в PyPI на 16 март.
В бележките към августовското издание промяната е описана в раздел „Bug Fixes“ без каквото и да е споменаване на сигурността. „Преди това невалидни стойности се използваха без предупреждение за конструиране на неправилно форматиран URL адрес“, гласят бележките.
Официалният бюлетин последва 53 дни по-късно. В него се отдава признание на потребител в GitHub с псевдоним SunandM за докладването на дефекта, като не се съобщава за реално извършени атаки.