LiteLLM под 1.83.9: обичен корисник може да го преземе целиот gateway

20 октомври 2026 г., во 11:00|Автор: Уредувачки тим на QUASA|5 мин. читање

На 13 октомври 2026 година анализата на Check Point Research опиша како најавен корисник со ограничени права можел да преземе администраторска контрола врз LiteLLM Proxy и како одделна ранливост можела да изложи провајдерски API-клучеви. Истражувањето било спроведено врз верзијата 1.77.7, а верзијата 1.83.9 ги содржи поправките за двете опишани патеки. Наодите се однесуваат на gateway што посредува меѓу апликациите и AI-провајдерите, а не на секое користење на LiteLLM како библиотека.

Во известувањето на IT Pro од 15 октомври 2026 година, ризиците се поврзани со CVE-2026-35029 и CVE-2026-59823. За администраторот се важни активната верзија и тоа кој имал пристап до gateway: првата ранливост барала валидна најава, а втората можела да испрати барање со провајдерски клуч на адреса под контрола на напаѓач. Октомврискиот повод е деталната анализа на претходно поправени пропусти, а не нова поправка објавена во октомври.

Како ограничен корисник добивал администраторски пристап

Кај CVE-2026-35029, административната патека POST /config/update прифаќала измени на конфигурацијата додека LiteLLM Proxy работи, но не проверувала дали повикувачот има администраторска улога. Истовремено, проверката за сесиите од корисничкиот интерфејс ја третирала патеката /config/update како дозволена бидејќи почнува со /config. Затоа најавен корисник со ограничена улога можел да смени поставки што требало да бидат под контрола на администратор.

Една последица била читање локални датотеки достапни за процесот LiteLLM. Со промена на UI_LOGO_PATH, напаѓачот можел да зададе датотека што gateway потоа ја враќа преку /get_image; истражувачите го покажале тоа со системска датотека. Пристапот до датотеките бил ограничен со правата на самиот процес, но меѓу достапните датотеки можеле да бидат конфигурации и тајни.

Истата можност за промена на конфигурацијата дозволувала да се заменат UI_USERNAME и UI_PASSWORD за вградената администраторска најава. По таква промена, корисникот можел да се најави со администраторски права и да управува со gateway. Друга патека минувала низ функцијата за пренасочување кон надворешни услуги: таа можела да вчита Python-модул од далечинско складиште и да го изврши неговиот код со правата на процесот LiteLLM. Тоа се различни последици од истиот пропуст во контролата на пристапот.

Како барањето можело да го изложи провајдерскиот клуч

CVE-2026-59823 се однесува на насочувањето на барањата, а не на администраторската улога. Параметарот user_config во барање кон LiteLLM Proxy можел да зададе сопствен список на модели и сопствена адреса api_base. Gateway потоа создавал нова конфигурација за насочување и го испраќал барањето на таа адреса. За оваа патека напаѓачот исто така морал да има валиден пристап до gateway.

Проверката што ограничувала директно зададени адреси и клучеви во барањето не го опфаќала истиот избор кога бил сместен во user_config. Ако напаѓачот зададел адреса што ја контролира, таму можело да пристигне целото барање, вклучувајќи провајдерски API-клуч додаден од gateway. Тоа е суштинската разлика меѓу виртуелниот клуч со кој корисникот пристапува до LiteLLM и тајниот клуч со кој организацијата плаќа услуги кај AI-провајдерот.

Изложен провајдерски клуч може да овозможи неовластени повици и трошоци на сметката на неговиот сопственик. Ранлива инсталација сама по себе не докажува дека некој го презел клучот: за таков заклучок се потребни записи за излезните барања и проверка на активноста кај провајдерот. Истиот механизам на пренасочување можел да се употреби и за испитување адреси во внатрешната мрежа, зависно од мрежниот пристап на gateway.

Верзијата ја одредува точната изложеност

Во безбедносната објава на LiteLLM од 3 април 2026 година стои дека CVE-2026-35029 е поправена во 1.83.0 со задолжителна администраторска улога за /config/update. Објавата го припишува првичниот наод на Lakera и потврдува дека за нападот бил потребен валиден клуч за proxy. Поправката за одделното пренасочување преку user_config е во 1.83.9, која затоа ги опфаќа двете ранливости.

Разликата е важна при процената на ризикот. Инсталациите пред 1.83.0 треба да се разгледаат за двете патеки. Кај верзиите од 1.83.0 до 1.83.8, опишаниот пропуст во /config/update веќе е поправен, но останува патеката што може да го изложи провајдерскиот клуч. Надградбата на 1.83.9 или понова верзија ги затвора двете патеки опишани во октомвриската анализа.

Што треба да се провери во засегната инсталација

Проверете која верзија навистина работи на секоја активна инстанција на LiteLLM Proxy, вклучително и ако gateway е вграден во друга платформа или се стартува од контејнер. Верзијата запишана во списокот со зависности не ја докажува верзијата на активниот процес. По надградбата, потврдете дека новата верзија е стартувана на сите инстанции што примаат барања.

За инстанции што работеле со верзија пред 1.83.0, прегледајте повици кон /config/update, промени во конфигурацијата и неочекувани администраторски најави. Побарајте и промени на дестинациите за пренасочување или вчитување надворешни модули.
За инстанции што работеле со верзија пред 1.83.9, проверете дали барања со user_config биле испраќани кон адреси надвор од одобрените AI-провајдери. Споредете ги достапните записи на gateway со активноста што ја прикажува провајдерот.
Ако записите покажуваат дека провајдерски клуч бил испратен на неовластена адреса, ротирајте го кај соодветниот провајдер и проверете дали имало неочекувана употреба. Ако има знаци за преземена администраторска сметка или извршување код, проверете ги и другите тајни достапни за процесот LiteLLM.

Надградбата спречува нова злоупотреба на овие патеки, но не ја менува можната претходна изложеност. Затоа одлуката за ротација зависи од тоа кои клучеви биле достапни за засегнатата инстанција и што покажуваат записите од периодот кога таа работела со ранлива верзија.

Прочитајте и:

Сподели: