LiteLLM a útok přes oficiální vydání softwaru

21. října 2026 se přes oficiální distribuční kanály rozšířila verze LiteLLM 1.107.0 se škodlivým kódem. Kód hledal přístupové údaje k AI službám, cloudu a dalším účtům. Obsahoval také mechanismus pro stažení a spuštění dalšího kódu. Autoři potvrdili napadení procesu vydávání a zasažené balíčky i kontejnerové obrazy stáhli. Oznámení LiteLLM.

LiteLLM propojuje aplikace s různými modely AI. Firma ho může používat jako společnou bránu, takzvanou AI gateway, přes kterou spravuje přístupy a náklady. Může být ale také součástí jiného nástroje. Uživatel pak zná název své aplikace a o LiteLLM uvnitř vůbec nemusí vědět. Popis projektu.

Proto má smysl zjistit, zda ho některé z vašich řešení používá. Pokud aplikace jen používáte, obraťte se na správce nebo dodavatele. Potřebujete od něj konkrétní odpověď: zda se napadená verze do prostředí dostala a zda se spustila.

Stav k 24. říjnu 2026. Autoři zveřejnili dokončenou rekonstrukci útoku a obnovili vydávání verzí. Rekonstrukce LiteLLM, vydání 1.106.3.

Co si zkontrolovat

Kvůli kontrole nespouštějte Python, pip ani aplikaci v podezřelém prostředí. To platí i pro zjištění verze příkazem pip show. U tohoto útoku se škodlivé soubory mohly načíst už při startu Pythonu. Správce má pracovat se soubory a záznamy z čistého prostředí; podezřelý kontejner kvůli kontrole nestartovat. Vysvětlení mechanismu a postupu.

1. Zjistit, kde LiteLLM máme. Zahrnout společnou AI bránu, jednotlivé aplikace i vývojářské nástroje. LiteLLM se mohlo nainstalovat jako závislost, tedy součást potřebná pro běh jiného programu. Kontrola proto musí jít i za seznam knihoven, které vývojář vybral sám. Patří do ní vývojové počítače, testovací prostředí a stroje, na kterých se software automaticky sestavuje.

2. Dohledat, kterou verzi jsme skutečně převzali. Hledáme především balíčky litellm==1.107.0. U Dockeru je potřeba prověřit obrazy označené v1.107.0, latest, main-latest a main-stable. Obraz je připravený balík aplikace a jejího prostředí, ze kterého se spouští kontejner. U zasažených registrů mohly právě tyto značky v době incidentu ukazovat na škodlivý obsah. Rozsah incidentu.

3. Ověřit historii, ne jen dnešní stav. Škodlivá kopie mohla zůstat ve firemním úložišti, na počítači nebo v mezipaměti pro další sestavení. Spustit se mohla až po odstranění z veřejného registru. Dnešní jiná verze proto sama nedokládá, co na stejném místě běželo včera. Doporučení pro dohledání instalací.

Proč latest není pevně zvolená verze

Zápis končící na :latest může v konfiguraci zůstat měsíce stejný, zatímco obsah pod tímto označením se mění. Při dalším stažení tak můžete dostat jiný obraz. Podobně fungují main-latest a main-stable; ani číselný tag sám o sobě obecně nezaručuje neměnnost. Změna značky v registru ovšem sama nevymění obsah už běžícího kontejneru. Rozhoduje, co se skutečně stáhlo a nasadilo.

Pevné připnutí konkrétního obsahu se dělá pomocí digestu, jeho kontrolního otisku, například odkazem ve tvaru obraz@sha256:…. Změní-li se obsah, změní se i otisk. Digest pomůže určit, který obraz používáte; bezpečnost jeho obsahu musíte posoudit při výběru. I škodlivý obraz má svůj platný digest. Dokumentace Dockeru.

Praktický výsledek kontroly má být konkrétní: odkud obraz pochází, jaký obsah identifikuje jeho digest a kde a kdy běžel. Samotné „máme to připnuté na latest“ tuto odpověď neposkytuje.

Když se napadené prostředí spustilo

Jestli se v prostředí se zasaženou instalací spustil Python, je potřeba s prostředím zacházet jako s napadeným. Aplikace nemusela LiteLLM vůbec použít. Samotné uložení obrazu bez jeho spuštění je jiná situace, ale i tak je potřeba zabránit jeho pozdějšímu nasazení. Technický rozbor Socket.

Při důvodném podezření nečekejte na dokončení celé inventury. Správce nebo bezpečnostní tým má současně řešit tři věci:

• Izolovat prostředí a zachovat důkazy. Omezit další komunikaci a uchovat dostupné záznamy, soubory i informace o běžících procesech.
• Z čistého zařízení odvolat dostupné přístupy. Zahrnout klíče k poskytovatelům AI, hesla k databázím a další údaje, které mohl proces číst. Prověřit také jejich použití v auditních záznamech. Nové klíče nevkládat do podezřelého prostředí.
• Obnovit software z ověřeného čistého základu. Samotná odinstalace LiteLLM nemusí odstranit přidané soubory ani běžící proces. Prověřit také uložené kopie, ze kterých by další sestavení mohlo škodlivou verzi znovu převzít.

Postup obnovy podle Endor Labs, rozsah odvolání přístupů podle Mend.io.

Bezprostředně po incidentu autoři doporučili návrat na 1.106.2. Dne 24. října už vydali 1.106.3, která mimo jiné mění klíč pro ověřování podpisů Docker obrazů a Helm chartů. Před obnovou proto ověřte aktuální pokyny i očekávaný podpisový klíč. Kontroly podpisů kvůli této změně nevypínejte. Původní postup obnovy, pokyny k vydání 1.106.3.

Nový kontejner nezneplatní klíč, jehož kopii už drží útočník. Obnova programu a odvolání přístupů proto patří k sobě.

Proč se k závislostem vracím

V květnovém příspěvku o GSD jsem psal o nástroji pro vývojáře, jehož autor zmizel, zatímco balíček zůstával dostupný. V září jsem se k tématu vrátil v textu Balíček, jehož autor zmizel, se stahuje dál. Řešili jsme údržbu a důvěru v účet, který smí vydat další verzi. Samotné opuštění balíčku neprokazovalo útok.

U LiteLLM je škodlivé oficiální vydání potvrzené. Spojuje je otázka, která se týká každé aplikace složené z cizích součástí: komu svěřujeme možnost dodat další kód do prostředí, kde pracujeme s daty a přístupy.

Závislostí je i knihovna, kterou přinese jiná knihovna. A vedle samotné aplikace stojí nástroje pro vývoj, testování a nasazování. Útok vedený přes některou z těchto součástí se k nám může dostat obvyklou cestou aktualizací. S takovým scénářem bych při návrhu systémů počítal i do budoucna.

Zamrazit všechny aktualizace by znamenalo přestat přijímat také opravy. Smysl dává vědět, co přebíráme, kdo to vydává, jak se nová verze schvaluje a k čemu se po spuštění dostane. Kontrola známých zranitelností je jednou částí této práce. Vedle ní potřebujeme sledovat údržbu balíčků, způsob vydávání a skutečně nasazený obsah.

Podrobnosti pro správce a vývojáře

Následující části rozvádějí kontrolu instalací, průběh útoku a opatření pro provoz vlastní AI brány.

Které distribuce byly zasažené

Časy v tabulce jsou v českém letním čase, SELČ (CEST), UTC+2, dne 21. října 2026. Popisují dostupnost škodlivé distribuce v registrech, nikoli konec možnosti spustit dříve staženou kopii. Oficiální přehled LiteLLM.

Soukromý enterprise registr podle autorů zasažen nebyl. Výjimka se týká tohoto distribučního kanálu; samotná enterprise licence neříká, odkud konkrétní instalace pocházela.

Jak začít kontrolou bez spuštění instalace

Pracujte z důvěryhodného systému. Pokud škodlivý kód mohl běžet na samotném počítači nebo získat přístup k jeho správě, předejte kontrolu bezpečnostnímu týmu. Ten má pracovat s uchovanou kopií dat, pokud možno připojenou pouze pro čtení. Nový kontejner na stejném podezřelém hostiteli tuto hranici nenahradí.

Níže vyberte postup pro Docker, nebo pro soubory instalace. Příkazy pro macOS a Linux patří do bashe či zsh; varianta PowerShell je pro PowerShell 7, nikoli cmd.exe. Ve WSL použijte linuxovou variantu, která však sama neprověří instalace ve Windows. Pro Docker potřebujete již dostupné CLI a přístup ke správnému serveru.

Kopírujte vždy celý blok, ponechte uvozovky i závorky a potvrďte Enterem. Jméno kontejneru nebo cestu zadávejte až po zobrazení výzvy. Navazující kroky provádějte ve stejném okně. Podezřelý Python, pip ani kontejner kvůli kontrole nespouštějte.

docker context show
docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'
docker info --format 'server={{.Name}} os={{.OSType}} architecture={{.Architecture}}'

docker ps -a --no-trunc --format 'table {{.ID}}\t{{.Names}}\t{{.Image}}\t{{.Status}}'

{
printf 'Jméno nebo ID kontejneru z výpisu: '
IFS= read -r litellm_container

if [ -n "$litellm_container" ] &&
   litellm_image_id=$(docker container inspect --format '{{.Image}}' "$litellm_container")
then
  docker container inspect --format 'reference={{.Config.Image}} image_id={{.Image}} status={{.State.Status}} started={{.State.StartedAt}}' "$litellm_container" &&
  docker image inspect --format 'id={{.Id}} digests={{json .RepoDigests}}' "$litellm_image_id"
else
  printf '%s\n' 'Kontejner nebyl ověřen. Zastavte kontrolu a opravte výběr.'
fi
}

. {
$litellmContainer = Read-Host 'Jméno nebo ID kontejneru z výpisu'
if ([string]::IsNullOrWhiteSpace($litellmContainer)) {
    throw 'Nebyl vybrán kontejner.'
}

$litellmImageId = docker container inspect --format '{{.Image}}' $litellmContainer
if ($LASTEXITCODE -ne 0 -or -not $litellmImageId) {
    throw 'Kontejner nebyl ověřen. Zastavte kontrolu a opravte výběr.'
}
docker container inspect --format 'reference={{.Config.Image}} image_id={{.Image}} status={{.State.Status}} started={{.State.StartedAt}}' $litellmContainer
if ($LASTEXITCODE -ne 0) { throw 'Inspekce kontejneru selhala.' }
docker image inspect --format 'id={{.Id}} digests={{json .RepoDigests}}' $litellmImageId
if ($LASTEXITCODE -ne 0) { throw 'Metadata obrazu nejsou dostupná.' }
}

reference=moje-ai-brana:latest image_id=sha256:… status=created started=0001-01-01T00:00:00Z
id=sha256:… digests=["moje-ai-brana@sha256:…"]

{
printf 'Absolutní cesta ke kopii projektu nebo prostředí: '
IFS= read -r litellm_root

if [ -n "$litellm_root" ] && [ -d "$litellm_root" ]; then
  find "$litellm_root" -type d \( -name .git -o -name node_modules \) -prune -o \
    -type f \( -name '*.lock' -o -name '*.toml' -o -name '*.txt' -o \
    -name '*.yaml' -o -name '*.yml' -o -name '*Dockerfile*' -o -name 'Pipfile*' \) \
    -exec grep -nH -i 'litellm' {} +
else
  printf '%s\n' 'Složka neexistuje nebo nebyla zadána. Nepokračujte.'
fi
}

. {
$litellmRoot = Read-Host 'Absolutní cesta ke kopii projektu nebo prostředí'
if ([string]::IsNullOrWhiteSpace($litellmRoot) -or
    -not (Test-Path -LiteralPath $litellmRoot -PathType Container)) {
    throw 'Složka neexistuje nebo nebyla zadána.'
}
Get-ChildItem -LiteralPath $litellmRoot -Recurse -Force -File -ErrorAction Stop |
    Where-Object {
        $_.FullName -notmatch '[/\\](\.git|node_modules)[/\\]' -and
        ($_.Extension -in '.lock','.toml','.txt','.yaml','.yml' -or
         $_.Name -like '*Dockerfile*' -or $_.Name -like 'Pipfile*')
    } |
    Select-String -Pattern 'litellm' -SimpleMatch -ErrorAction Stop
}

…/requirements.txt:2:litellm==1.107.0
…/compose.yaml:4:    image: example.invalid/litellm:latest

if [ -n "$litellm_root" ] && [ -d "$litellm_root" ]; then
  find "$litellm_root" -type f -path '*/litellm-*.dist-info/METADATA' \
    -print -exec sed -n -e '/^Name: /p' -e '/^Version: /p' {} \;
else
  printf '%s\n' 'Nejprve zvolte platnou složku v předchozím kroku.'
fi

if ([string]::IsNullOrWhiteSpace($litellmRoot) -or
    -not (Test-Path -LiteralPath $litellmRoot -PathType Container)) {
    throw 'Nejprve zvolte platnou složku v předchozím kroku.'
}
Get-ChildItem -LiteralPath $litellmRoot -Recurse -Force -File -Filter METADATA -ErrorAction Stop |
    Where-Object { $_.Directory.Name -like 'litellm-*.dist-info' } |
    ForEach-Object {
        $_.FullName
        Get-Content -LiteralPath $_.FullName -ErrorAction Stop |
            Where-Object { $_ -match '^(Name|Version): ' }
    }

…/.venv/lib/python3.14/site-packages/litellm-1.107.0.dist-info/METADATA
Name: litellm
Version: 1.107.0

Výsledek spojte s historií sestavení, stažení a nasazení. Zapište kontrolovaný server a složky, jméno kontejneru, celé otisky, nalezené verze a doložené časy běhu. Připojte i to, co se nepodařilo zjistit. Prázdný výsledek nebo dnešní jiná verze samy bezpečnost prostředí nepotvrzují.

Jak útočník ovládl vydávání

Útok začal klíčem k experimentální platformě pro řízení agentů. Dne 27. května se omylem dostal do veřejného repozitáře LiteLLM-Labs/lite-harness. Záznam byl odstraněn, klíč ale zůstal platný. Útočník ho 10. října použil k získání GitHub tokenu vlastníka organizace. Další dva tokeny pak odcizil přes automatizované úlohy v repozitářích. Dokončená rekonstrukce LiteLLM.

Oprávnění vlastníka mu umožnilo vypnout ochrany větví a změnit postup vydávání. Další odcizený účet posloužil ke schválení produkčního vydání. Smazání zveřejněného klíče tedy nestačilo: dokud nebyl odvolán, dál otevíral cestu k dalším přístupům. Rekonstrukce oprávnění a vydání.

Sestavovalo se z podvrženého repozitáře Berri-AI/litellm. Oficiální organizace má název BerriAI, bez pomlčky. Rozdíl byl vidět i v záznamu o původu sestavení, který prozkoumal Socket. Analýza Socket.

Autoři 24. října také upřesnili, že oficiální zdrojový tag v1.107.0 vůbec nevznikl. Číslo na distribuovaném balíčku proto nelze zaměňovat za ověřený původ jeho kódu. Upřesnění autorů.

Zdrojový archiv sdist na PyPI byl jiný případ: podle Endor Labs obsahoval změněnou konfiguraci balení, přestože samotné škodlivé soubory v něm chyběly. Nelze proto všechny zdrojové distribuce označit za čisté. Porovnání zdrojů a balíčků.

Autoři po březnovém incidentu přidali ochrany vydávání včetně podepisování kontejnerových obrazů. Říjnový útok ovládl proces, který obrazy sestavoval, podepisoval a publikoval. Podpis umožňuje ověřit podepisující identitu a vazbu na soubor; bezpečnost obsahu tím prokázaná není. Také záznam o původu sestavení, označovaný jako provenance, je potřeba porovnat s povoleným repozitářem, revizí a workflow. Nestačí ověřit, že nějaký záznam existuje. Popis opatření LiteLLM, doporučení Endor Labs.

Proč mohl malware spustit i kontrolní příkaz

Wheely přidávaly do kořene site-packages soubory cook.pth, cook.py a sitecustomize.py. cook.pth obsahoval instrukci pro import škodlivého modulu. Python při běžném startu zpracovává spustitelné řádky v souborech .pth a pokouší se načíst sitecustomize. Útočník tak dostal kód do běhu bez toho, aby aplikace importovala LiteLLM. Rozbor AISLE, dokumentace Pythonu.

Proto může škodlivý kód aktivovat i pip, který sám používá Python. Samotné čtení obsahu archivu jako dat není spuštění tohoto prostředí. Rozbor Socket.

Oficiální oznámení na jednom místě uvádí kontrolu přes pip show, zároveň ale před spuštěním Pythonu a pipu varuje. Kvůli popsanému mechanismu zde doporučuji kontrolu bez podezřelého interpretu. Oznámení LiteLLM.

Při návrhu čistého runtime je také potřeba rozlišovat přepínače Pythonu. -P omezuje přidávání potenciálně nebezpečné cesty do sys.path; -I zapíná izolovaný režim, ale nevypíná všechny startovací mechanismy instalace. Nejsou náhradou za kontrolu toho, co se při startu načítá. U podezřelé instalace zůstává vhodným začátkem statická kontrola z čistého prostředí. Dokumentace přepínačů Pythonu.

Co malware hledal a co bylo pozorováno

Sběr mířil na cloudové přihlašovací údaje, Kubernetes tokeny, privátní klíče, údaje vývojářských nástrojů, proměnné prostředí i uložená hesla prohlížečů. Data malware šifroval a posílal na podvrženou doménu litellm[.]dev. Skutečný rozsah závisel na oprávněních procesu. Analýza AISLE.

Další část se zaměřila na databázi LiteLLM. Pokud k ní měla přístup, pokoušela se získat uložené klíče k poskytovatelům a konfiguraci modelů. Brána tak mohla zpřístupnit údaje pro více služeb využívaných dalšími týmy. Rozbor Mend.io.

Druhá komponenta připravovala kanál pro stažení a spuštění dalšího Python kódu. Při analýze Wiz nebyl cílový zdroj aktivovaný a technická omezení bránila běhu této části na Windows. To nevylučovalo krádež údajů přes cook.py. Schopnost spouštět další kód tak neznamená, že se tato fáze prokazatelně spustila u každé oběti. Analýza Wiz.

Wiz zároveň zaznamenal použití odcizených cloudových údajů přibližně 4,5 hodiny po jejich odcizení: ověřování AWS identit, zjišťování dostupných AI modelů a v některých prostředích další průzkum oprávnění. Jde o pozorování v prostředích sledovaných Wiz. Popis následného zneužití.

Co změnit v provozu vlastní AI brány

Bránu bych provozoval odděleně od prostředí, ve kterém agent pracuje se zdrojovým kódem a spouští nástroje. Krátkodobé klíče uživatelů a rozpočtové limity přitom neodstraňují riziko pro klíče k poskytovatelům, které drží sama brána. Pokud tato pravidla vynucuje jen její vlastní kód, při jeho napadení se na ně nelze spolehnout.

Původní hypotéza o získání GitHub tokenů z logů při práci s Claude Code se nepotvrdila. Autoři výslovně uvedli, že touto cestou útočník tokeny nezískal. Upřesnění z 24. října.

Pro návrh systému je užitečné počítat s tím, že i výstup nástroje může obsahovat tajný údaj. Úklid logu až po doběhu úlohy nechává do té doby citlivý obsah uložený; při pádu se úklid nemusí dokončit. Maskování zároveň nevezme zpět údaj, který už odešel k modelu. Proto je vedle maskování potřeba omezit i sběr a odesílání.

Každá ochrana pokrývá jinou část problému. SSO řídí přihlášení lidí, lidské schválení změn rozhoduje o jejich přijetí a síťová omezení zužují možnosti komunikace. Úniku údajů během práce nástroje samo schválení jeho výsledku nezabrání.

Začněte jedním konkrétním řešením: zjistěte, jaké součásti používá, odkud dostává aktualizace a ke kterým přístupům se dostanou při běhu. U každého přístupu má být jasný důvod, vlastník a postup odvolání. Právě taková kontrola pomůže omezit škody i u příštího napadeného balíčku.