Популярный ИИ-шлюз LiteLLM заражали дважды за год: почему подписи не спасли
Популярный ИИ-шлюз LiteLLM заражали дважды за год: почему подписи не спасли 21 октября 2026 года на PyPI — официальном складе Python-пакетов — вышел LiteLLM версии 1.107.0 с вором паролей внутри, а те же заражённые версии попали и в Docker-образы. LiteLLM — популярный открытый «шлюз» к моделям ИИ: через него команды ходят к OpenAI, Anthropic и другим вендорам, и он хранит их ключи. Для проекта это уже второй инцидент за год: в марте 2026 заражали версии 1.82.7 и 1.82.8. Автор разбора сам использует другой шлюз, KTMS, и не пострадал — он разбирает случай по отчётам BerriAI, StepSecurity, Wiz и Socket. Самое поучительное, по его словам, не вредонос, а то, что тот прошёл через конвейер выпуска релизов, специально укреплённый после мартовского инцидента. Атака заняла полтора часа. За день до неё двум инженерам временно расширили права на публикацию бэкпортов. У атакующего были украденные токены (то есть цифровые ключи доступа) трёх разработчиков GitHub: одним он запустил правку релизного процесса, вторым прошёл шаг ручного одобрения, третьим стёр следы. Защита веток первую попытку отклонила — но через пять секунд токеном владельца организации её просто отключили. Затем сборку направили в репозиторий-двойник Berri-AI/litellm, отличающийся от настоящего одним дефисом. Заражённый пакет провисел на PyPI около 1 часа 45 минут, заражённые Docker-образы под плавающими тегами latest и другие — около 2 часов 30 минут. Достаточно было установить пакет — даже не импортировать его: вредоносные файлы Python подхватывает при каждом старте, и даже команда проверки «pip show» снова запускала стилер. По разбору StepSecurity, он собирал пароли и cookies браузеров, SSH- и облачные ключи, секреты CI, переменные окружения процессов и токены более 20 ИИ-инструментов. А при заданной переменной DATABASE_URL — всю базу прокси LiteLLM: ключи вендоров моделей и мастер-ключ. Данные шифровались и уходили на домен litellm.dev, зарегистрированный за восемь дней до атаки. Подпись образов, которая должна была подтверждать подлинность, сработала против защиты: конвейер честно подписал и заражённые артефакты. Подпись доказывает, что артефакт собрал конкретный конвейер, — но не то, что конвейер не захвачен. Ручное одобрение тоже не помогло: «два ключа» бессмысленны, когда украдены оба. По версии BerriAI, точкой входа стал внутренний деплой LiteLLM, открытый в интернет, вероятно через недавно закрытую уязвимость: он писал в логи тела ответов, где могли оказаться токены разработчиков. Как именно атакующий попал внутрь и откуда взялись токены — BerriAI на момент отчёта ещё не подтвердила; расследование продолжается. Затронуты те, кто ставил litellm==1.107.0 (в том числе без указания версии) в окно 11:39–13:23 UTC или скачивал образы v1.107.0, latest, main-latest, main-stable с 11:46 до 14:20 UTC. Чистыми названы версии 1.106.x и ранее и два release-кандидата. BerriAI рекомендует пересобрать окружения с нуля, закрепить версию 1.106.2 и — если заражённый пакет работал на машине с выходом в сеть — считать данные утёкшими и сменить всё, до чего машина могла дотянуться, включая ключи вендоров моделей. Для бизнеса на ИИ выводы автора конкретны: деплоить не по тегу latest, а по точному хэшу образа; не ставить релиз в день выхода; ограничить шлюзу исходящий доступ адресами вендоров; считать логи с телами запросов секретом. Шлюз — особенно ценная цель: он стоит на пути каждого запроса и хранит ключи ко всем вендорам сразу, а компрометация раскрывает ещё и содержимое промптов. Автор подчёркивает: настоящая защита — контроль над тем, кто может менять релизный процесс, а не криптография. Источник: https://habr.com/ru/articles/1099402/