Представьте: вы скачали программу из официального репозитория. Проверили цифровую подпись. Установили обновление. И собственными руками запустили вредоносный код на сервере.
Это не фантастический сценарий. Именно такую опасность продемонстрировала атака на LiteLLM в октябре 2026 года.
В предыдущем расследовании «Linux без пароля, AI-шлюзы под угрозой. Какие серверы действительно защищены?» мы разбирали уязвимости операционной системы и AI-шлюзов.
Теперь выяснилось нечто ещё интереснее: иногда злоумышленнику вообще не требуется взламывать ваш сервер. Достаточно заставить его принять заражённое обновление за настоящее.
Всё началось с одного забытого ключа
27 мая 2026 года в публичный GitHub-репозиторий разработчиков LiteLLM случайно попал административный ключ внутренней системы.
Ошибку заметили быстро. Файл удалили примерно через три часа.
Но сам ключ не отозвали.
А его копия продолжала храниться в истории GitHub.
Прошло больше четырёх месяцев.
10 октября злоумышленник воспользовался забытым ключом и получил доступ к экспериментальной платформе AI-агентов LiteLLM.
Там обнаружился следующий подарок: GitHub-токен с полномочиями владельца организации.
Один забытый секрет открыл дорогу к целой инфраструктуре разработки.
Как подменили официальный выпуск
Получив доступ к GitHub, атакующий изменил процесс сборки программного обеспечения.
Обычно система должна была собирать LiteLLM из настоящего репозитория BerriAI/litellm.
Но злоумышленник подготовил похожий адрес: Berri-AI/litellm.
Разница почти незаметна.
Затем он изменил настройки сборки так, чтобы вместо настоящего исходного кода использовался его собственный.
Для выпуска потребовалось подтверждение. Атакующий использовал похищенные учётные данные нескольких разработчиков.
21 октября заражённая версия LiteLLM 1.107.0 появилась в официальных каналах распространения PyPI и Docker.
Самое неприятное: скомпрометированные Docker-образы имели действительную подпись прежним ключом проекта.
Подпись подтверждала, что образ прошёл через доверенный механизм выпуска. Но сам механизм уже находился под контролем атакующего.
Что происходило после установки?
В заражённом Python-пакете находились специальные файлы, запускавшие вредоносный код при обычной инициализации Python.
Приложению даже не требовалось напрямую обращаться к LiteLLM.
Достаточно было запустить Python в затронутом окружении.
Вредоносная программа собирала доступные ей секреты: API-ключи нейросетей, облачные учётные данные, SSH-ключи, переменные окружения и сведения из конфигураций.
Для AI-шлюза это особенно опасно.
Через него могут проходить запросы к нескольким поставщикам моделей, а значит, в одной системе сосредоточено множество ценных ключей.
Вредоносные релизы удалили в тот же день. Но удаление заражённого пакета не возвращает уже украденные секреты.
Почему цифровая подпись не спасла?
Здесь скрывается главный урок.
Цифровая подпись отвечает на вопрос: «Кто подписал этот файл?»
Но она не всегда отвечает на другой: «Был ли сам процесс создания файла безопасным?»
Если злоумышленник захватил систему сборки или ключ подписи, внешне правильная подпись может сопровождать вредоносный продукт.
После инцидента LiteLLM заменил ключ подписи контейнеров cosign и начал выпускать образы с новым ключом.
Это означало, что администраторам необходимо не только обновить программу, но и пересмотреть, каким подписям они доверяют.
Ноябрь добавил ещё одну тревожную историю
2 ноября была опубликована информация о CVE-2026-105769, критической уязвимости инструмента сборки контейнеров kaniko.
При определённых условиях специально подготовленный адрес контейнерного реестра мог заставить уязвимую версию kaniko отправить облачный токен Azure на сервер атакующего.
Для этого было достаточно ссылки на внешний образ в Dockerfile. Запускать вредоносную команду внутри собираемого контейнера не требовалось.
Ошибка затрагивает kaniko до версии 1.25.20 при наличии доступной Azure-идентичности и соответствующих условий сборки.
Это отдельная история, не доказанная часть атаки на LiteLLM.
Но обе демонстрируют одну проблему: инфраструктура, которая создаёт и доставляет программы, сама становится целью нападения.
Что делать владельцу сервера?
Проверять нужно не только Linux и открытые порты.
- Не хранить долгоживущие административные ключи в репозиториях. Если секрет раскрыт, его необходимо отозвать, а не просто удалить файл.
- Ограничивать права GitHub-токенов и систем автоматической сборки.
- Фиксировать версии зависимостей и digest контейнеров. Не полагаться исключительно на тег
latest. - Проверять происхождение сборки, а не только наличие цифровой подписи.
- Не предоставлять сборочным контейнерам доступ ко всем облачным секретам.
- После подтверждённой компрометации восстанавливать окружение из доверенного источника и заменять потенциально раскрытые ключи.
Для VPN-серверов это особенно важно: украденные ключи и конфигурации способны превратить защищённый туннель в источник риска.
Для AI-сервисов последствия могут затронуть сразу несколько внешних платформ.
Кто на самом деле управляет вашим сервером?
Можно установить последнюю версию Linux. Настроить firewall, двухфакторную авторизацию и защиту от DDoS.
Но если система автоматически принимает вредоносное обновление, атакующему не придётся преодолевать эти рубежи обычным способом.
Он войдёт через дверь, которую администратор сам открыл для доверенного программного обеспечения.
Настоящая безопасность начинается не с вопроса, где размещён сервер, а с вопроса, кому и почему этот сервер доверяет.
Именно это октябрьская атака на LiteLLM показала особенно наглядно.
Стеклянный мост | 6 ноября 2026 года
Источники:
- LiteLLM, The attack chain behind the v1.107.0 LiteLLM release, 23.10.2026: https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
- LiteLLM, Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised: https://docs.litellm.ai/blog/security-incident-oct-21-2026
- Microsoft Security Research, Inside the LiteLLM 1.107.0 supply chain compromise, 23.10.2026: https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/
- GitHub Security Advisory, CVE-2026-105769: https://github.com/advisories/GHSA-5q7h-w9jf-cx97