Дзве дзіркі LiteLLM аддавалі ключы API і кантроль адміністратара

13 кастрычніка 2026 года тэхнічнае раскрыццё Check Point Research апісала дзве ўжо выпраўленыя ўразлівасці шлюза LiteLLM. CVE-2026-35029 дазваляла карыстальніку з абмежаванымі правамі змяняць адміністрацыйную канфігурацыю, а CVE-2026-59823 — перанакіраваць запыт на старонні сервер і атрымаць ключ пастаўшчыка мадэляў. Даследчыкі паказалі гэтыя наступствы ў кантраляваным тэставанні; агульная бяспечная мяжа для абедзвюх памылак — версія 1.83.9.

У публікацыі TechRadar ад 14 кастрычніка прыведзеныя словы даследчыкаў пра ключы шлюза: «no further authentication required». Ключ, які пакінуў шлюз, можа даць доступ да платнага API без асобнага ўзлому пастаўшчыка. Адміністратарам трэба адрозніць абнаўленне праграмы ад праверкі раней захаваных сакрэтаў: выпраўленне закрывае шлях атакі, але не адклікае ключ, які ўжо мог быць раскрыты.

Пачатковы доступ і наступства кожнай CVE

Абедзве ўразлівасці патрабавалі доступу да LiteLLM, але выкарыстоўвалі розныя паўнамоцтвы і закраналі розныя часткі шлюза. Таму рэагаванне залежыць ад таго, хто меў уліковы запіс або віртуальны ключ, якія функцыі былі адкрыты і якія даныя пра запыты захаваліся.

• CVE-2026-35029. Пачатковы доступ — сеанс аўтэнтыфікаванага карыстальніка інтэрфейсу, у тым ліку з нізкай роляй. Магчымасць — выклік POST /config/update без належнай праверкі ролі і змена налад шлюза. Наступства — чытанне файлаў, даступных працэсу LiteLLM, падмена ўліковых даных адміністратара або выкананне кода праз падключаны модуль. Дзеянне — абнавіць уразлівыя асобнікі і праверыць выклікі гэтага маршруту, змены канфігурацыі ды адміністрацыйныя ўваходы.
• CVE-2026-59823. Пачатковы доступ — сапраўдны віртуальны ключ для запытаў да шлюза. Магчымасць — перадаць user_config з уласным api_base і прымусіць LiteLLM адправіць запыт на выбраны хост. Наступства — перадача ключа пастаўшчыка ў загалоўках перанакіраванага запыту, як у паказаным даследчыкамі сцэнары. Дзеянне — абнавіць шлюз, шукаць нетыповыя адрасы выходных запытаў і ацаніць неабходнасць замены ключоў.

Для першай памылкі істотная камбінацыя дзвюх праверак: сеанс карыстальніка інтэрфейсу трапляў у дазволены прэфікс /config, а сам POST /config/update не патрабаваў ролі адміністратара. Праз гэта карыстальнік, які мог толькі ўвайсці ў сістэму, атрымліваў доступ да налад асяроддзя. Змена UI_USERNAME і UI_PASSWORD адкрывала ўваход у адміністрацыйны ўліковы запіс; шлях праз UI_LOGO_PATH і /get_image дазваляў атрымаць файл, які мог прачытаць працэс шлюза.

У другім выпадку звычайная забарона на перадачу api_base на верхнім узроўні запыту не ахоплівала ўкладзены user_config. LiteLLM ствараў маршрутызатар з перададзеных параметраў і адпраўляў выклік да чужога вузла. Гэта асобны шлях да ключа пастаўшчыка: атрымліваць права адміністратара для яго не патрабавалася.

Чаму розніца ў версіях важная

Бюлетэнь LiteLLM пазначае для CVE-2026-35029 ацэнку 8,7 паводле CVSS, уразлівыя версіі ніжэй за 1.83.0 і выпраўленне ў 1.83.0. Для CVE-2026-59823 мяжа іншая: выпраўленне ўвайшло ў 1.83.9. Значыць, прамежкавая версія магла ўжо закрываць доступ да адміністрацыйнай канфігурацыі, але ўсё яшчэ дазваляць перанакіраванне запыту.

Агульная рэкамендацыя ўсталяваць 1.83.9 або навейшы выпуск тычыцца закрыцця абедзвюх памылак, а не азначае, што кожны ранейшы выпуск меў абедзве. Правяраць трэба версію фактычна запушчанага працэсу, а не толькі запіс у файле залежнасцяў. Улічваць варта і асобнікі ў складзе іншых платформаў: калі ўнутраная праграма падключае LiteLLM як кампанент, яе копія шлюза таксама патрабуе праверкі.

Чаму адзін шлюз пашырае наступствы

LiteLLM прымае запыты ад праграм, выбірае мадэль і перадае выклік пастаўшчыку з патрэбным ключом. У такой схеме адно месца аб'ядноўвае маршруты, правы карыстальнікаў, сакрэты і ўлік выкарыстання. Калі праз шлюз ідуць выклікі да розных пастаўшчыкоў, скампраметаваная канфігурацыя ўплывае на больш чым адну праграму; абсяг залежыць ад таго, якія менавіта ключы і правы былі ў канкрэтнай усталёўцы.

Адміністрацыйны кантроль дае магчымасць змяніць маршруты або прачытаць файлы шлюза, у якіх могуць знаходзіцца сакрэты. Перанакіраванне запыту па другой CVE працуе інакш: шлюз сам дасылае ўліковыя даныя разам з выклікам на старонні адрас. Калі ключ апынуўся ў чужых руках, яго ўладальнік рызыкуе атрымаць несанкцыянаваныя выклікі і выдаткі ў адпаведнага пастаўшчыка.

Абнаўленне, журналы і ратацыя ключоў

Спачатку варта скласці пералік асобнікаў шлюза: асноўных, рэзервовых і ўбудаваных у іншыя сэрвісы. Для кожнага патрэбныя запушчаная версія, спосаб доступу карыстальнікаў, пералік пастаўшчыкоў і месцы захоўвання іх ключоў. Перад заменай зборкі карысна захаваць наяўныя журналы і бягучую канфігурацыю для аналізу інцыдэнту, а пасля абнаўлення пацвердзіць, што сапраўды працуе выпраўлены выпуск.

Пры праверцы першай CVE важныя звароты да POST /config/update ад карыстальнікаў без адміністрацыйнай ролі, нечаканыя змены налад, уліковых даных і падключаных модуляў. Для другой — запыты з user_config, калі яны фіксуюцца, і выходныя злучэнні да адрасоў па-за звычайным спісам пастаўшчыкоў. Калі журнал не змяшчае цела запыту, дапамагчы могуць час выкліку, ідэнтыфікатар карыстальніка, сеткавы адрас атрымальніка і гісторыя выкарыстання ключоў у пастаўшчыка.

Пры прыкметах несанкцыянаванага доступу ключы пастаўшчыкоў, якія захоўваліся ў закранутай усталёўцы, трэба замяніць і адклікаць старыя. Ратацыя ахоплівае кожны такі ўліковы запіс асобна: новы ключ трэба ўсталяваць у шлюзе і залежных праграмах, затым пераканацца, што запыты працуюць і стары ключ больш не прымаецца. Калі падрабязных журналаў няма, адсутнасць падазроных запісаў не дазваляе ўпэўнена выключыць вывад ключа; рашэнне аб яго замене прымаюць з улікам гэтага прабелу і абсягу доступу да шлюза.

Пасля абнаўлення застаецца супаставіць звесткі шлюза з выкарыстаннем і выдаткамі ў кабінетах пастаўшчыкоў. Незвычайны рост выклікаў можа паказаць, дзе патрэбна глыбейшая праверка і які ключ варта адклікаць першым, нават калі сам LiteLLM ужо працуе на выпраўленай версіі.

Чытайце таксама:

• Дзве дзіркі NetScaler ужо атакуюць: стандартная канфігурацыя не ратуе
• MLflow ці Weights & Biases: прыватнасць даных аплачваецца адміністраваннем
• Basecamp ці ClickUp: гнуткасць можа запатрабаваць асобнага адміністратара