Неделя, когда всё сломалось сразу: что дайджест уязвимостей говорит о наших инструментах

Двадцать второго октября Саймон Уиллисон дважды сделал ретвит. Первый — длинная сводка инцидентов за одну среду, второй — короткая реплика Армина Ронахера (@mitsuhiko): мы тридцать лет писали плохой софт, и теперь вселенная выставляет счёт. Сводка написана в жанре «паническая лента», и часть деталей нужно перепроверять по первоисточникам. Но одна строка в ней касается нас напрямую: компрометация LiteLLM.

Что именно рассказывает сводка

Автор пересказа перечисляет подряд несколько историй. Две критические уязвимости удалённого выполнения кода в PHP, детали которых утекли до выхода патча. CVSS 10.0 в GitLab, где баг якобы живёт с 2014 года. Приостановленные деплои на Railway после доступа к переменным окружения. Взломанный TiDB Cloud и закрывшаяся Zeabur. И курьёз с удостоверяющим центром, у одного из ключей которого вместо случайного числа в сотню знаков было просто «4».

Масштабы вроде «правительства просят отключить системы» и «упала Википедия» взяты из одного ретвита. Я бы не цитировал их как факт, пока нет подтверждения от CISA, вендоров и самих пострадавших. Зато историю с LiteLLM можно проверить за пять минут: она касается пакета, который стоит в тысячах AI-проектов.

Компрометация LiteLLM: почему это не «ещё один баг»

По сводке, версия 1.107.0 вышла с похитителем учётных данных и трояном удалённого доступа в каждом wheel и в Docker-образах, включая тег latest. Заразиться можно было одной установкой, без единого импорта. Автор добавляет, что это уже второй такой случай за год.

LiteLLM — прокси, через который проекты ходят к десяткам LLM-провайдеров. Значит, в его окружении лежат ключи Anthropic, OpenAI и облачные токены. Это идеальная цель: одна зависимость даёт доступ к платным API и, как правило, к соседним сервисам.

Установка как исполнение кода

Мы привыкли считать опасным запуск чужого скрипта. Но pip install тоже исполняет код, например через хуки сборки. Агенты вроде Claude Code ставят пакеты в песочнице или прямо в рабочем окружении, часто без вашего взгляда на каждую команду. Чем автономнее агент, тем важнее, что ему разрешено ставить.

Что поменять в рабочем процессе

Список короткий и не новый, просто теперь он болезненно актуален:

• фиксируйте версии с хешами (lock-файлы, --require-hashes) и не обновляйтесь в день релиза: свежий пакет — самое рискованное место;
• не храните долгоживущие секреты в окружении, где работает агент; используйте ключи с ограниченными правами и квотами;
• если платформа деплоя признала утечку переменных, ротация нужна всем ключам, которые там лежали, а не только «самым важным»;
• проверьте, откуда ваш конвейер берёт Docker-образы: тег latest — это доверие к чужому решению в момент сборки.

Что скажет «счёт за грехи»

Реплика Ронахера звучит как шутка, но задаёт верный вопрос. AI ускоряет написание кода, а не его проверку. Если мы пишем больше и быстрее, поверхность атаки растёт тем же темпом. Возможно, самая полезная работа для агентов ближайшего года — не новые фичи, а аудит зависимостей, чистка секретов и поиск таких «четвёрок» вместо ключей.

Практический вывод: пока подробности по PHP и GitLab уточняются, проверьте свои lock-файлы на LiteLLM 1.107.0 и сделайте ротацию ключей. Если версия стояла хотя бы на одном сервере или в CI, считайте окружение скомпрометированным.