24 марта 2026 года разработчики, создававшие ИИ-приложения с помощью LiteLLM — Python-пакета с 95 миллионами ежемесячных загрузок, — неосознанно установили вредоносный код. Группа злоумышленников, известная как TeamPCP, скомпрометировала конвейер распространения PyPI и выложила вредоносные версии 1.82.7 и 1.82.8 в индекс пакетов. Вредоносная нагрузка оказалась незаметной: файл .pth — малоизвестный механизм Python, который автоматически выполняет код при каждом запуске интерпретатора. Если вы установили любую из скомпрометированных версий, вредоносный код выполнялся молча — без необходимости явного импорта.
Это уже не исключение. Это закономерность.
Что на самом деле происходит
ReversingLabs сообщает, что число вредоносных пакетов с открытым исходным кодом в 2026 году выросло на 73%. Атака на LiteLLM была частью более широкой кампании TeamPCP, в ходе которой группа систематически компрометировала пользующиеся широким доверием инструменты безопасности с открытым исходным кодом, включая Trivy от Aqua Security и KICS от Checkmarx, прежде чем перейти к библиотекам ИИ-инфраструктуры, размещенным на PyPI.
Цепочка атаки на LiteLLM развивалась по уже привычной схеме. TeamPCP получила учетные данные мейнтейнера для публикации на PyPI, выложила вредоносные версии, практически неотличимые от официального пакета, и внедрила многоэтапную нагрузку, предназначенную для сбора ценных секретов: токенов AWS, GCP и Azure, SSH-ключей и учетных данных облачных аккаунтов. По данным Zscaler ThreatLabz, отравленные пакеты были доступны примерно три часа, прежде чем их поместили в карантин. Трех часов хватило, чтобы достичь десятков тысяч корпоративных сред.
И на этом атаки не прекратились. В конце апреля 2026 года в версиях PyTorch Lightning 2.6.2 и 2.6.3 обнаружили вредоносное ПО, похищающее учетные данные и запускавшееся при импорте. Один вредоносный workflow-файл раскрыл секреты во всех CI/CD-конвейерах.
Почему среды разработки ИИ особенно уязвимы
Большинство атак на цепочку поставок — это плохо. Атаки на цепочку поставок, нацеленные на среды разработки ИИ, — еще хуже.
Среды ИИ и ML объединяют в одном рабочем пространстве разработку, исследования, облачную инфраструктуру, доступ к данным, публикацию моделей и автоматизацию. Скомпрометированный Python-пакет в обычном веб-приложении может украсть учетные данные базы данных. Та же атака в среде разработки ИИ может раскрыть веса моделей, обучающие данные, облачные токены нескольких провайдеров, секреты CI/CD-конвейеров и продакшн-ключи API — одновременно, из одной зараженной зависимости.
Существует второй уровень угрозы, который большинство команд безопасности не учитывают. Когда разработчики используют ИИ-ассистентов для написания кода, те часто предлагают команды pip install и операторы импорта, ссылающиеся на конкретные пакеты. Если разработчик доверяет подсказке и устанавливает указанный пакет, а злоумышленник уже зарегистрировал вредоносный пакет под этим именем, атака достигает цели без какого-либо прямого взаимодействия с разработчиком. Исследователи назвали этот прием slopsquatting — и недавнее исследование показало: в почти 200 000 Python-запросах каждая крупная LLM генерирует вымышленные имена пакетов, которых нет на PyPI, создавая постоянную поверхность атаки, которую не может полностью закрыть ни одно обновление отдельной модели.
Ваши разработчики не делают ничего неправильного. Они используют инструменты, которые делают их продуктивными. Но лежащее в основе этих инструментов предположение о безопасности не работает.
3 меры контроля, которые важны прямо сейчас
1. Зафиксируйте зависимости и проверяйте целостность
Плавающие спецификаторы версий — requests>=2.0 вместо requests==2.31.0 — позволяют менеджерам пакетов незаметно подтягивать обновления, содержащие вредоносный код. Зафиксируйте каждую зависимость в ваших средах разработки ИИ до точной версии и сверяйте контрольные суммы с заведомо корректным хэшем. Уже это ограничило бы радиус поражения атаки на LiteLLM средами, которые явно обновились до скомпрометированных версий, а не любыми окружениями, где запускали pip install litellm без ограничений.
2. Проверяйте пост-установочные хуки в конвейере разработки
Атака на LiteLLM внедрила вредоносную нагрузку через механизм .pth-файлов Python — код, который выполняется автоматически при инициализации интерпретатора, до запуска любого оператора импорта. Пост-установочные хуки и манипуляции с .pth-файлами — задокументированный класс атак, однако контроль в средах разработчиков применяется непоследовательно. Требуйте проверки пакетов, содержащих пост-установочные скрипты, прежде чем они попадут на машины разработчиков. Такие инструменты, как Socket и Sonatype, обеспечивают анализ PyPI-пакетов в реальном времени для выявления вредоносного поведения до установки. Это не опция «приятно иметь». С учетом темпов внедрения ИИ-инструментов это базовый контроль.
3. Немедленно ротируйте облачные учетные данные при любом подозрении на утечку
Нагрузка LiteLLM была нацелена на токены AWS, GCP и Azure именно потому, что эти учетные данные обеспечивают горизонтальное перемещение между облачными средами. Если ваши конвейеры разработки тянули LiteLLM в период уязвимости 24 марта, считайте все облачные учетные данные, доступные из этих сред, потенциально скомпрометированными и ротируйте их. Изучите журналы аудита вашего облачного провайдера на предмет активности, не соответствующей запросам, инициированным разработчиками, — это признак использования украденного токена злоумышленником из другого места.
Что это значит для команд безопасности
Кампания TeamPCP — не конец этой закономерности. Это доказательство концепции того, что ИИ-инфраструктура теперь стала классом целей. LiteLLM, PyTorch Lightning и все инструменты между ними — это пакеты, от которых ваши ИИ-команды зависят каждый день. Атакующие знают об этом. Они знают, что разработчики действуют быстро, что внедрение ИИ-инструментов опережает циклы проверки безопасности и что вредоносный .pth-файл невидим для большинства средств обнаружения на конечных точках.
Перечисленные выше меры контроля не сложны. Они не требуют новых вендоров или новых платформ. Они требуют относиться к установке Python-пакетов в средах разработки ИИ с той же строгостью, с какой вы подходите к продакшн-развертываниям, — потому что в 2026 году расстояние между локальной средой разработчика и вашей продакшн-инфраструктурой короче, чем когда-либо, и злоумышленники это заметили.
Ваши разработчики доверяют своим инструментам. Убедитесь, что это доверие оправдано.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Anjali Gopinadhan Nair
