Rotace, která se nedokončila. Jak z jedné brány k AI vytekly klíče 2 500 firem

Ve středu 12. a čtvrtek 13. srpna zveřejnily dvě bezpečnostní firmy rozbor dat ukradených při útoku na LiteLLM — open-source bránu, přes kterou vývojáři posílají požadavky na jazykové modely. Řeč je o zhruba 2 500 organizacích a stovkách tisíc přístupových klíčů. Samotný útok proběhl už 24. března a všude se o něm píše jako o „čtyřicetiminutovém oknu". Když jsem si otevřel vlastní hlášení LiteLLM, stojí v něm jiné číslo — a je pětkrát delší. Tenhle článek je hlavně o tom, jak si za dvacet minut ověříte, jestli se vás to týká, a proč u většiny českých firem bude odpověď „ne".

Co se stalo

• Napadené verze: podle bezpečnostního hlášení samotného LiteLLM šlo o balíčky litellm==1.82.7 a litellm==1.82.8 nahrané na PyPI 24. března 2026 v 10:39 UTC. Útočník obešel oficiální CI/CD a nahrál je na PyPI přímo — v repozitáři na GitHubu žádný škodlivý kód nebyl.
• Co to dělalo: obě verze obsahovaly zloděje přihlašovacích údajů. Sbíral proměnné prostředí, SSH klíče, přístupové údaje k AWS, GCP a Azure, Kubernetes tokeny a hesla k databázím. Data odesílal zašifrovaně na doménu models.litellm.cloud, která — jak LiteLLM výslovně upozorňuje — není jejich oficiální doména. Verze 1.82.8 navíc přidávala soubor litellm_init.pth, který zajistil spuštění při každém startu Pythonu.
• Odkud to přišlo: ne z LiteLLM. Podle hlášení firmy Aqua Security začalo všechno u skeneru zranitelností Trivy. Koncem února 2026 útočníci zneužili chybnou konfiguraci v jeho GitHub Actions a získali privilegovaný token. LiteLLM měl Trivy automaticky v CI/CD pipeline — otrávený skener si tak přečetl prostředí a odnesl si publikační tokeny k PyPI.
• Co se našlo teď v srpnu: firma Hudson Rock získala a rozebrala archiv o 153 GB se 433 909 soubory a přiřadila 118 829 výpisů z CI runnerů k 2 488 firemním doménám (podrobnosti na Help Net Security). Firma CloudSEK došla z vlastního datasetu k číslu blízko 2 500 organizací. Mezi nimi NVIDIA, Volkswagen, Siemens, Deloitte, FedEx nebo Orange.
• Pozor na slovo „únik": CloudSEK sama zdůrazňuje, že její čísla vyjadřují expozici, ne potvrzené prolomení. To, že se klíč firmy octl v archivu, neznamená, že ho někdo použil.
• Data zatím nekolují veřejně. Alon Gal z Hudson Rock pro Help Net Security uvedl, že archiv „momentálně nikde neunikl a nešíří se" — proto tu disciplínu s rotací dělají teď, dokud je čas.

Co jsem při ověřování našel navíc

Zprávy o tomhle případu se shodly na obrázku „čtyřicet minut, dva a půl tisíce firem". Když jsem sáhl po primárních zdrojích — po hlášení LiteLLM, po hlášení Aqua Security a po samotném PyPI — vyšly najevo čtyři věci, které v přejímkách nejsou.

• To okno nebylo čtyřicet minut, ale pět a půl hodiny. Tohle je nejdůležitější bod celého článku. V shrnutí LiteLLM opravdu stojí, že balíčky byly živé „asi 40 minut, než je PyPI dalo do karantény". Jenže o pár odstavců níž, v sekci „Koho se to týká", si firma stanovuje vlastní kritérium: postižen můžete být, pokud jste instalovali 24. března mezi 10:39 UTC a 16:00 UTC. Proč se ta dvě čísla liší, hlášení nevysvětluje (nabízí se doběh zrcadel a cache, ale to je moje domněnka, ne jejich údaj). Když si auditujete logy, berte to širší okno. Kdo hledá jen čtyřicet minut kolem 10:39 UTC, může přehlédnout vlastní zásah.
• Kdo jede na oficiálním Dockeru, není zasažený. Tohle se do titulků nedostalo skoro nikde, a přitom to většině čtenářů ušetří práci. LiteLLM uvádí, že zákazníci s oficiálním Docker obrazem proxy (ghcr.io/berriai/litellm) zasažení nejsou, protože ten má závislosti připíchnuté v requirements.txt. Stejně tak nejste zasažení, pokud používáte LiteLLM Cloud, instalovali jste ze zdrojáků z GitHubu, nebo jste na verzi 1.82.6 a starší a v tom okně jste neaktualizovali.
• Ověřil jsem si přímo v PyPI, že obě verze jsou pryč. Nespoléhal jsem na tvrzení a stáhl si rejstřík vydání balíčku litellm. Verze 1.82.7 ani 1.82.8 v něm dnes nejsou vůbec — ne „stažené", ale úplně odstraněné. Poslední čistá verze před útokem, 1.82.6, tam je s datem nahrání 22. března 2026. Aktuální vydání je 1.96.2. Sedí to s tím, co LiteLLM píše.
• Kořen problému nebyla AI, ale nedotažená rotace. Z časové osy Aqua Security plyne nepříjemná věc: incident u Trivy se řešil už 1. března a přihlašovací údaje se tehdy měnily. Jenže rotace nebyla úplná a útočníkovi zbyly platné údaje. S nimi se 19. března vrátil, přepsal 76 ze 77 verzovacích značek v repozitáři trivy-action a vydal škodlivou verzi Trivy. A ještě jednou 22. března, kdy po první nápravě nahrál škodlivé Docker obrazy. Celá kaskáda ke 2 500 firmám tedy stojí na jedné neúplně dokončené rotaci klíčů.

Ještě jedna poznámka k číslům, ať je to poctivé: Help Net Security mluví o archivu velkém 153 GB, zatímco Ars Technica u téhož nálezu píše o souboru o velikosti 195 TB. Ten rozpor jsem nerozhodl a nemám ho z čeho ověřit. Na tom, co máte udělat, ale nic nemění — proto v článku pracuji s počtem souborů a domén, který uvádějí obě firmy shodně.

Proč se to týká i vás

Většina českých firem netrénuje modely a o LiteLLM nikdy vědomě nerozhodla. To ale bohužel není důvod tenhle článek zavřít.

• LiteLLM se k vám mohl dostat, aniž byste si ho vybrali. Sama firma mezi zasažené řadí případ, kdy si závislost přitáhl váš projekt tranzitivně a nepřipíchnutě — typicky přes framework na AI agenty, MCP server nebo nástroj na orchestraci modelů. Máte-li dodavatele, který vám loni nasadil „chatbota nad firemními daty", je to přesně ten případ, kdy se ptáte vy jeho, ne on vás.
• Neteklo z modelu, teklo z pipeline. Ukradené věci nebyly prompty ani firemní dokumenty. Byly to klíče k cloudu, tokeny k repozitářům a hesla k databázím, které se válely v proměnných sestavovacího prostředí. Tohle riziko máte i tehdy, když s AI neděláte vůbec nic — AI byla jen tou nejrychlejší cestou dovnitř, protože se instaluje odvážněji a připíná se méně než zbytek.
• „Už jsme to rotovali" nestačí, dokud to někdo nezkusí. Nezávislý výzkumník Kevin Beaumont podle Ars Techniky ověřil pravost dat a jedna z velkých amerických technologických firem mu řekla, že už všechno vyměnila a nic se neděje. Jejich vlastní pravidla pro hlášení chyb testování údajů dovolovala, tak je zkusil — a fungovaly skoro všechny. To je přesně tatáž chyba, na které v březnu ztroskotalo Trivy.
• Compliance vám tu nepomůže. Tohle není téma na AI Act ani na dokument. Je to provozní bezpečnost a řeší se konfigurací a rotací klíčů. Kdo si na tohle riziko chce koupit papír, kupuje si špatnou věc.

Co s tím

Postup níž je zadarmo a zvládne ho váš vývojář nebo dodavatel během jednoho odpoledne. Seřazeno podle toho, co dává největší smysl udělat první.

• 1. Zjistěte, jestli se vás to vůbec týká — patnáct minut. Nechte projít historii sestavení a nasazení z 24. března 2026 v okně 10:39–16:00 UTC (tedy 11:39–18:00 našeho času) a hledejte, jestli se někde instaloval litellm bez připíchnuté verze. Když jedete na oficiálním Docker obrazu proxy, LiteLLM Cloudu nebo na verzi 1.82.6 a starší, tady končíte a nic dalšího řešit nemusíte.
• 2. Prohledejte stroje na stopu. LiteLLM zveřejnil konkrétní indikátory: soubor litellm_init.pth v adresáři site-packages a odchozí komunikaci na domény models.litellm[.]cloud a checkmarx[.]zone. Ani jedna k LiteLLM nepatří. Historii DNS a odchozích spojení máte většinou zpětně i za březen — tohle je nejrychlejší způsob, jak si potvrdit, že se nic nedělo.
• 3. Když nález je, rotujte všechno v dosahu, a dotáhněte to. Ne jen ten klíč, který v datech vidíte. Klíče do cloudu, tokeny do GitHubu a GitLabu, servisní účty Kubernetes, hesla k databázím a API klíče poskytovatelů modelů. A hlavně: staré údaje aktivně zneplatněte, nestačí vydat nové. Přesně tenhle krok chyběl u Trivy i u té velké americké firmy — v obou případech proto, že rotace skončila u vydání nových klíčů a nikdo neověřil, že ty staré přestaly fungovat.
• 4. Připíchněte verze závislostí. Celý tenhle případ je reklama na jednu nudnou věc: kdo měl v requirements.txt konkrétní verzi místo otevřeného pip install litellm, ten se nenakazil, i kdyby instaloval přesně v tu chvíli. Platí to pro všechny balíčky, nejen pro AI.
• 5. Zeptejte se dodavatele písemně. Pokud vám AI řešení někdo dodal, pošlete mu dvě otázky: jestli u vás v březnu jelo LiteLLM ve verzi 1.82.7 nebo 1.82.8, a jestli po incidentu rotoval údaje, ke kterým měl ve vašem prostředí přístup. Odpověď „to se nás netýká" bez čísla verze není odpověď.

Za zmínku stojí, že LiteLLM se k tomu postavil slušně: přizval forenzní tým Mandiant, vyměnil údaje správců, postavil novou sestavovací pipeline, od verze 1.83.0 podepisuje Docker obrazy přes cosign a ke všem vydáním mezi 1.78.0 a 1.82.6 dodatečně zveřejnil kontrolní součty SHA-256, aby si je šlo ověřit. To je víc, než po podobném incidentu udělá většina projektů.

Kde to řeším s klienty

Řeknu to na rovinu: jestli je vaše odpověď na krok 1 „jedeme na oficiálním Docker obrazu" nebo „LiteLLM u nás nikdo nikdy neinstaloval", nepotřebujete ode mě nic. Zavřete tenhle článek a jděte dělat něco užitečnějšího. A i kdyby nález byl, celý postup výše je veřejný a váš vývojář ho zvládne sám.

Kde se ozvat dává smysl, je situace, kdy vám na otázku „co všechno máme z AI nasazené a čí klíče to vidí" nikdo ve firmě neumí odpovědět — protože pak nedokážete odpovědět ani u příštího takového incidentu, a ten přijde. To je přesně obsah AI Agent Governance Checkupu: soupis toho, co u vás běží, jaká oprávnění to má a kam dosáhne. Když si nejste jistí, jestli se vás dnešní téma týká, napište si o AI Risk Scan zdarma — na otázku ohledně března 2026 se dá odpovědět za dvacet minut. A na příbuzný vzorec, kdy problém nezpůsobí model, ale to, co všechno kolem sebe vidí, jsme se dívali v článku Zablokovaný požadavek unesl AI agenta.