Przycisk "przetestuj połączenie", który uruchamiał dowolne polecenie na serwerze

Tekst odpowiada na trzy pytania. Dlaczego funkcja pomyślana jako niegroźny podgląd ustawień pozwalała uruchomić dowolne polecenie na serwerze. Dlaczego wystarczał do tego klucz najniżej postawionego użytkownika, a nie konto administratora. I dlaczego luka w programie, którego nikt w firmie świadomie nie kupował, mogła trafić do niej razem z zupełnie innym produktem.

Do czego służy funkcja, która okazała się dziurą

LiteLLM to serwer pośredniczący, brama, przez którą aplikacje firmy sięgają do modeli językowych. Poza samym przekazywaniem zapytań umie też podłączać modelowi narzędzia: kalendarz, wyszukiwarkę w dokumentach, bazę zamówień. Robi to zgodnie ze standardem MCP, opisującym, jak model rozmawia z takim narzędziem.

Zanim administrator zapisze konfigurację nowego narzędzia, chce sprawdzić, czy ono w ogóle odpowiada. Do tego służyły dwa punkty w interfejsie programu: POST /mcp-rest/test/connection oraz POST /mcp-rest/test/tools/list. Pierwszy sprawdza, czy da się nawiązać połączenie, drugi wypisuje listę narzędzi, które dany serwer udostępnia.

Kłopot brał się z tego, co te punkty przyjmowały. W ciele żądania szła pełna konfiguracja testowanego serwera, łącznie z polami command, args i env. Te trzy pola opisują tryb pracy nazywany stdio, w którym narzędzie nie stoi pod żadnym adresem sieciowym, tylko jest programem uruchamianym lokalnie. Pole command mówi więc dosłownie, co uruchomić.

Sprawdzanie połączenia było już wykonaniem

Kiedy do jednego z tych punktów trafiała konfiguracja w trybie stdio, program próbował nawiązać połączenie. Nawiązanie połączenia z programem lokalnym polega na tym, że się go uruchamia. Podane polecenie startowało więc jako podproces na maszynie z bramą, z uprawnieniami procesu bramy.

Testowanie i uruchamianie były tu jedną i tą samą czynnością. Wysyłający decydował, co zostanie uruchomione, bo sam wpisywał to w treść żądania. W katalogach słabości taki błąd nosi oznaczenia CWE-77 i CWE-78, czyli wstrzyknięcie polecenia oraz wstrzyknięcie polecenia systemu operacyjnego. Praktyczne znaczenie jest jedno: napastnik przestaje być gościem serwisu, a staje się jego operatorem.

Uprawnienia procesu bramy to zwykle więcej, niż się wydaje. Ten proces ma dostęp do pliku konfiguracyjnego z poświadczeniami do dostawców modeli, do bazy danych z kluczami wewnętrznymi i do sieci, w której maszyna stoi. Wykonanie polecenia na tym poziomie oznacza dostęp do wszystkich trzech rzeczy naraz.

Klucz stażysty wart tyle samo co klucz administratora

Najważniejszy szczegół tej podatności nie dotyczy wykonania polecenia, tylko tego, kto mógł je zlecić. Oba punkty wymagały ważnego klucza, ale nie sprawdzały, jaką rolę ma jego właściciel. Wystarczał zwykły klucz użytkownika wewnętrznego, wydany z najniższymi uprawnieniami.

Czterdziestoosobowa firma handlu internetowego wydaje takie klucze rutynowo. Jeden dostaje aplikacja obsługi zwrotów, drugi zewnętrzny programista pracujący nad wyszukiwarką produktów, trzeci narzędzie do analizy opinii. Każdy z nich, z założenia, może tylko wywoływać model i zużywać przydzielony limit. Tak brzmi decyzja podjęta przy wydawaniu kluczy i tak jest ona zapisana w panelu.

Ta podatność unieważnia tę decyzję. Klucz zewnętrznego programisty, zapisany kiedyś w pliku konfiguracyjnym projektu i wraz z nim wysłany do repozytorium, przestaje być kluczem do wywołania modelu. Staje się kluczem do maszyny. Koszt, gdy ktoś go znajdzie, nie ogranicza się do zużytych limitów: obejmuje wszystkie poświadczenia leżące na tym serwerze i wszystko, do czego one prowadzą.

Wniosek na przyszłość jest niewygodny, ale prosty. Poziom uprawnień przypisany kluczowi jest obietnicą oprogramowania, a nie prawem fizyki, i przestaje obowiązywać w momencie, gdy któryś punkt interfejsu zapomni go sprawdzić. Dlatego klucz wydany na zewnątrz powinien mieć nie tylko niską rolę, ale też krótki termin ważności i osobny adres sieciowy, z którego wolno go używać. Kiedy rola przestaje działać, zostaje wtedy jeszcze data i adres.

Dwie oceny i jedna różnica, która coś zmienia

Groźność luk zapisuje się punktacją CVSS, w skali od zera do dziesięciu. Tutaj obie oceny wypadły podobnie: baza NVD dała 8,8 według skali w wersji 3.1, a GitHub, jako podmiot rejestrujący zgłoszenie, 8,7 według nowszej wersji 4.0. Obie mieszczą się w przedziale opisanym jako wysoki. Red Hat, oceniając rzecz na potrzeby własnych produktów, nadał jej wagę ważną, a nie krytyczną, bo do ataku potrzebne jest jednak jakieś konto.

Za niemal identycznymi liczbami stoi jednak różnica warta uwagi. Nowsza skala odnotowała, że skutek sięga poza sam zaatakowany element, na systemy stojące za nim, a jednocześnie uznała powodzenie ataku za zależne od dodatkowych warunków. Starsza skala nie ma miejsca na żadną z tych informacji, więc obie w niej znikają. Dla firmy praktyczny wniosek brzmi tak: ta luka jest wolniejsza od typowego ataku masowego, ale sięga dalej, bo z bramy prowadzi w głąb sieci.

Tomasz Kaczmarek

Mogę Ci jakoś pomóc?

Umów spotkanie +48 888 777 822

lub

biuro@uxu.pl

Potwierdza to osobna ocena CISA, amerykańskiej agencji bezpieczeństwa infrastruktury. Uznaje ona wykorzystywanie tej luki za aktywne, wpływ techniczny za całkowity, ale możliwość zautomatyzowania ataku wprost odrzuca. Automatyzacja odpada dlatego, że napastnik musi najpierw skądś mieć ważny klucz. Skanowanie internetu samo tego nie załatwi, natomiast wyciek repozytorium już tak.

Wersje, poprawki i produkty, które niosły to dalej

Podatne są wydania LiteLLM od 1.74.2 włącznie do wszystkich niższych niż 1.83.7. Poprawka jest w 1.83.7.

Osobno warto prześledzić drogę, jaką ta luka przebyła do firm, które o LiteLLM nigdy nie słyszały. Program jest składnikiem większych produktów, a jednym z nich jest Red Hat OpenShift AI. Red Hat wskazał jako dotknięte wersje 2.25, 3.3 i 3.4 tej platformy i wydał trzy osobne poprawki: erratę RHSA-2026:27784 dla wydania 3.4.1 z 22 czerwca 2026, RHSA-2026:28960 dla wydania 2.25.8 z 24 czerwca 2026 oraz RHSA-2026:30056 dla wydania 3.3.4 z 25 czerwca 2026.

Ten sam mechanizm działa u każdego innego dostawcy pakującego ten składnik. CISA odnotowała to wprost, oznaczając podatność jako dotyczącą powszechnie używanego oprogramowania otwartego i zalecając sprawdzenie stanu łatania u konkretnych dostawców, zamiast poszukiwania jednej uniwersalnej odpowiedzi.

Dla osoby prowadzącej firmę oznacza to konkretne pytanie do zadania dostawcy platformy, na której działa firmowa sztuczna inteligencja. Nie "czy to jest bezpieczne", bo odpowiedź zawsze brzmi tak, tylko "czy wasz produkt zawiera LiteLLM, w jakiej wersji i kiedy została podniesiona". Odpowiedź z numerem wersji da się sprawdzić, odpowiedź ogólna nie.

Terminy, które warto znać jako punkt odniesienia

CISA prowadzi katalog luk potwierdzonych w realnych atakach. Ta trafiła do niego 8 czerwca 2026 pod nazwą BerriAI LiteLLM Command Injection Vulnerability, a termin usunięcia wyznaczono na 22 czerwca 2026, czyli czternaście dni. Wpis nakazuje zastosować środki zaradcze producenta albo zaprzestać używania produktu, jeżeli takich środków nie ma.

Te czternaście dni to termin obowiązujący amerykańskie instytucje federalne, ale dla firmy jest to użyteczny punkt odniesienia. Instytucja z własnym zespołem bezpieczeństwa dostaje dwa tygodnie na podniesienie wersji składnika w produkcie zewnętrznego dostawcy. Firma bez takiego zespołu potrzebuje na to samo więcej czasu, więc harmonogram, w którym aktualizacje przeglądane są raz na kwartał, mija się z tempem tych terminów.

Do tego dochodzi wskaźnik EPSS, opisujący prawdopodobieństwo prób wykorzystania w ciągu trzydziestu dni. Dla tej luki wynosi on 0,83013 przy percentylu 0,9966 według odczytu z 23 sierpnia 2026, czyli wyżej niż ponad 99 procent wszystkich rejestrowanych podatności. Europejska baza ENISA prowadzi ją pod numerem EUVD-2026-28507 i datuje początek wykorzystywania na ten sam 8 czerwca 2026.

• cyberbezpieczeństwo
• sieci
• obsługa incydentów
• łańcuch dostaw
• open source
• zgodność
• nis2
• licencje
• inwentaryzacja
• it

Tomasz Kaczmarek

Mogę Ci jakoś pomóc?

Umów spotkanie +48 888 777 822 lub biuro@uxu.pl

Udostępnij

Twitter LinkedIn Facebook Kopiuj link