Důvěra v AI nástroje dostává na zadek. Nově směřovaný útok mířil na API klíče i přístupy uživatelů

Dvě falešné verze populárního Python balíčku LiteLLM byly na PyPI živé pouhých 46 minut. Stačilo to k tomu, aby malware začal krást API klíče, cloudové přístupy i SSH klíče.

Zdroj fotografie: Pexels

Callum McMahon si 24. března 2026 spustil v editoru Cursor MCP server pro svůj projekt FutureSearch. Počítač zamrzl. Pak se zhroutil. Když začal pátrat proč, našel v čerstvě stažené závislosti liteLLM kód, který na jeho stroji neměl co dělat, kód, který systematicky sbíral každé tajemství, na které dosáhl, a odesílal je na útočníkem řízenou infrastrukturu. Nešlo o sofistikovaný prompt injection ani o zranitelnost v jazykovém modelu. Šlo o klasický supply-chain útok: někdo se dostal k účtu správce balíčku na PyPI a nahrál dvě otrávené verze, které se tvářily jako běžný update.

Co je LiteLLM a proč na něm záleží

LiteLLM je open-source gateway, který vývojářům umožňuje jednotným rozhraním volat desítky poskytovatelů velkých jazykových modelů, od OpenAI přes Anthropic po Azure a AWS Bedrock. Projekt má na GitHubu přes 40 000 hvězdiček, stojí za ním Y Combinator a používají ho AI agentové frameworky, MCP servery i podnikové orchestrační nástroje. Právě ta šíře adopce z něj udělala atraktivní cíl. Útočník nemusel kompromitovat tisíc projektů zvlášť; stačilo otrávit jednu závislost, kterou si ty projekty samy stáhnou.

Dvě verze, dva různé spouštěče

Kompromitované verze 1.82.7 a 1.82.8 nebyly identické. Rozdíl mezi nimi je klíčový pro pochopení rozsahu ohrožení.

• Verze 1.82.7 obsahovala škodlivý payload vložený do souboru litellm/proxy/proxy_server.py. Spouštěl se při importu proxy modulu, tedy primárně u těch, kdo LiteLLM provozovali jako proxy server.
• Verze 1.82.8 šla dál. Do adresáře site-packages přidala soubor liteLLM_init.pth, který Python automaticky načítá při každém startu. Malware se tak spustil i bez importu LiteLLM, fakticky už během samotné instalace balíčku.

Obě verze obešly standardní GitHub CI/CD pipeline. Podle oficiálního bezpečnostního updatu LiteLLM byly nahrány přímo na PyPI přes kompromitovaný účet maintainera, bez odpovídajícího tagu nebo releasu na GitHubu. Žádný commit v hlavní větvi repozitáře na útok neupozornil.

Co všechno malware sbíral

Seznam exfiltrovaných dat je rozsáhlý a pokrývá prakticky vše, co vývojářský stroj nebo serverové prostředí typicky obsahuje:

• SSH privátní klíče a konfigurace
• soubory .env s API klíči a hesly
• cloudové přístupy pro AWS, GCP a Azure
• Kubernetes tokeny a konfigurace
• databázová hesla a Git credentials
• shell historii, TLS/SSL privátní klíče, Docker konfiguraci
• v některých případech i kryptopeněženky

Data byla před odesláním šifrovaná a putovala na domény models.litellm[.]cloud a checkmarx[.]zone. V Kubernetes prostředích se malware pokoušel o laterální pohyb: vytvářel podezřelé pody node-setup-* v namespace kube-system. Na napadeném hostu si zakládal persistenci přes ~/.config/sysmon/sysmon.py a systemd user service.

Proč to prasklo díky chybě útočníka

Škodlivé verze byly na PyPI živé od 10:39 UTC 24. března 2026. Karanténa přišla v 11:25 UTC, celkem 46 minut. McMahon ve své analýze na blogu FutureSearch popisuje, že malware obsahoval implementační chybu, která ho proměnila ve fork bomb. Právě proto mu zamrzl počítač. Bez té chyby, kterou McMahon označuje za „odbytou, pravděpodobně vibe-coded chybu“, by škodlivý kód tiše běžel na pozadí a sbíral tajemství, aniž by si toho kdokoli všiml.

To je znepokojivý detail. Útok neodhalil žádný bezpečnostní nástroj, žádný automatizovaný guardrail, žádný audit. Odhalila ho nekompetence útočníka. A přitom LiteLLM ve své veřejné dokumentaci deklarovalo certifikace SOC 2 Type I, SOC 2 Type II i ISO 27001. Tyto štítky signalizují popsané a auditované procesy, ale zjevně nepokrývají integritu každého jednotlivého releasu na PyPI. Certifikace není totéž co neprostupnost release kanálu.

Co dělat a jak si ověřit prostředí

Pokud jste 24. března 2026 kdekoli instalovali nebo rebuildovali Python prostředí, které mohlo sáhnout po LiteLLM (přímo nebo transitivně přes jinou závislost), stojí za to provést kontrolu.

• Spusťte pip show litellm a ověřte verzi. Hledáte 1.82.7 nebo 1.82.8.
• Zkontrolujte site-packages na přítomnost souboru liteLLM_init.pth.
• Projděte CI/CD logy, Docker buildy a deployment záznamy z kritického dne.
• Hledejte stopy persistence: ~/.config/sysmon/sysmon.py, systemd user service sysmon.service.
• V Kubernetes zkontrolujte neočekávané pody v kube-system.

LiteLLM zveřejnilo pomocné skripty pro GitHub Actions i GitLab CI. Pokud najdete jakoukoli stopu kompromitace, doporučení je jednoznačné: rotujte veškerá tajemství, která byla na zasaženém hostu přítomná. Nečekejte na forenzní jistotu, zpětně vyloučit exfiltraci prakticky nelze.

Incident kolem LiteLLM není izolovaný. Aqua Security popisuje širší kampaň, která souběžně zasáhla open-source komponenty Trivy a GitHub Action KICS. Bariéra vstupu pro supply-chain útoky na vývojářskou infrastrukturu klesá, a AI tooling s jeho hustou sítí automaticky stahovaných závislostí tu bariéru snižuje ještě víc. Nejslabším článkem dnešního AI stacku není model. Je to pip install bez připnuté verze.