Троянизация решений Trivy, Checkmarx и LiteLLM | Блог Касперского

Как решения Trivy и CheckMarx для защиты open source стали началом массовой атаки TeamPCP на популярные приложения и что делать организациям, их использующим.

Миллионы автоматизированных конвейеров разработки полагаются на встроенные в процесс сборки инструменты безопасности, такие как Trivy и Checkmarx AST. Именно эти доверенные решения недавно стали точкой входа для одной из наиболее масштабных и опасных атак на цепочку поставок в современной истории. Рассказываем, как можно проверить свои автоматизированные рабочие процессы и защитить свою облачную инфраструктуру.

Хронология атаки и известные последствия

19 марта была осуществлена целенаправленная и эффективная атака на цепочку поставок через Trivy, инструмент для сканирования уязвимостей с открытым исходным кодом, широко используемый в CI/CD-конвейерах. Нападающим, группировке TeamPCP, удалось внедрить вредоносное ПО в официальные рабочие процессы GitHub Actions и образы Docker, относящиеся к Trivy. В результате каждый автоматизированный скан конвейера запускал вредоносное ПО, осуществляющее кражу ключей SSH, облачных токенов доступа, криптовалютных кошельков и других ценных данных из пораженных систем. Учитывая критический характер инцидента, ему был присвоен идентификатор CVE-2026-33634 с почти максимальным баллом: CVSS4B 9.4.

Позже в тот же день команда Trivy зафиксировала факт компрометации и удалила вредоносные артефакты из каналов распространения, остановив эту фазу атаки. Но злоумышленники уже получили доступ к средам многих пользователей Trivy.

23 марта была обнаружена аналогичная компрометация в другом инструменте безопасности приложений: GitHub Action для Checkmarx KICS, а также Checkmarx AST. Три часа спустя вредоносный код был удален и здесь. Также TeamPCP смогли скомпрометировать расширения Open VSX, поддерживаемые Checkmarx: cx-dev-assist 1.7.0 и ast-results. Данные о том, когда эта часть инцидента была завершена, разнятся.

24 марта был скомпрометирован популярный проект, использующий сканирование кода от Trivy — универсальная библиотека для вызова ИИ-систем LiteLLM AI Gateway. Скомпрометированы версии 1.82.7 и 1.82.8, выложенные в PyPI. Эти версии были публично доступны около 5 часов.

Но тот факт, что атака продолжалась всего несколько часов, — не повод относиться к ней с пренебрежением. С учетом популярности затронутых проектов вредоносный код мог быть запущен тысячи раз, в том числе в инфраструктуре очень крупных компаний.

Этот доступ позволил злоумышленникам развернуть устойчивые бэкдоры в кластерах Kubernetes, а также запустить саморазмножающегося червя CanisterWorm по экосистеме JavaScript npm.

Код злоумышленников обладает деструктивными возможностями, которые уничтожают кластер Kubernetes и все его узлы, если обнаруживают в пораженной системе основной язык фарси или временную зону Тегерана. Только в других регионах проводится кража данных с помощью CanisterWorm.

По оценкам экспертов, более 20 000 репозиториев оцениваются как потенциально уязвимые. Нападающие заявляют, что они украли сотни гигабайт данных и более 500 000 учетных записей.

Как атаковали Trivy

Для компрометации Trivy атакующие воспользовались доступами, украденными ранее. Предыдущий инцидент с компрометацией Trivy, произошедший в конце февраля, вероятно, был локализован не полностью, и атакующие, группировка TeamPCP, вернулись с новой атакой. Разработчики Trivy, компания Aqua Security, предполагают, что из-за постепенной замены учетных данных после предыдущего инцидента злоумышленники смогли выпустить себе новые токены доступа, пока некоторые старые еще не были отозваны.

В результате TeamPCP смогла скомпрометировать рабочие процессы GitHub (GitHub Actions), используемые в CI/CD-конвейерах. Используя учетные данные с правом записи тегов, злоумышленники принудительно перезаписали 76 из 77 тегов версий в aquasecurity/trivy-action и все 7 тегов в aquasecurity/setup-trivy, перенаправив существующие доверенные версии на вредоносные коммиты. Это напоминает тактики, наблюдаемые в кампании Shai-Hulud 2.0. В результате по всей цепочке рабочие процессы начали исполнять код атакующих, при этом в метаданных релиза не было каких-либо видимых изменений.

Параллельно злоумышленники опубликовали зараженный бинарный файл Trivy (v0.69.4) в официальные каналы распространения, включая GitHub Releases и реестры контейнеров.

Компрометация LiteLLM

Популярный инструмент вызова языковых моделей LiteLLM может сам по себе породить крупную волну атак по цепочке проектов, его использующих. Атака состоялась 24 марта 2026 года, когда TeamPCP напрямую опубликовали на PyPI вредоносные версии библиотеки (1.82.7 и 1.82.8). В период с 10:39 UTC до 16:00 UTC эти скомпрометированные пакеты содержали ВПО, проводящее кражу учетных данных. Оно было встроено в файл proxy_server.py, а версия 1.82.8 также содержала вредоносный файл litellm_init. Данные извлекались на сервер models.litellm[.]cloud.

Клиенты, использующие LiteLLM Cloud или официальный Docker‑образ LiteLLM Proxy, не пострадали благодаря жесткой фиксации зависимостей, тогда как разработчики и downstream‑проекты, которые устанавливали не закрепленные версии через pip в указанный временной интервал, оказались под ударом.

В течение 3 часов вредоносные пакеты были удалены с PyPI, а команда LiteLLM приостановила новые релизы, провела ротацию учетных данных и привлекла внешнюю команду реагирования. Пользователям рекомендовано немедленно искать индикатор компрометации litellm_init.pth и в плановом порядке ротировать все потенциально скомпрометированные секреты.

Функции вредоносного ПО TeamPCP Cloud stealer

В GitHub Actions и исполнимый файл Trivy была добавлена новая логика с сохранением оригинальной функциональности. Благодаря этому результаты сканирования уязвимостей через Trivy выглядели как обычно, но одновременно происходили поиск и извлечение ценных данных. В их числе:

• разведка (сбор данных сети и переменных окружения);
• поиск токенов и учетных данных для доступа к облачным средам AWS и GCP;
• сканирование памяти (/proc/*/mem) для извлечения секретов, хранящихся в памяти процессов Runner.Worker и Runner.Listener;
• извлечение секретов Kubernetes (/run/secrets/kubernetes.io/serviceaccount);
• сбор данных для подключения к серверам баз данных (MySQL, PostgreSQL, MongoDB, Redis, Vault);
• сбор любых других ключей API и секретов в файлах окружения и настройках сред CI/CD (файлы .env, .json, .yml);
• поиск связей (webhook) для чатов Slack и Discord;
• поиск данных, связанных с криптокошельками (переменные, связанные с блокчейном Solana, а также данные rpcuser, rpcpassword).

Собранные данные шифровались и выгружались на сервер с похожим по звучанию названием (scan.aquasecurtiy[.]org). В качестве резервного механизма злоумышленники предусмотрели выгрузку в репозиторий с именем docs-tpcp.

В атаке на CheckMarx и LiteLLM использовалась похожая тактика с тайпсквоттинг-доменами: models.litellm[.]cloud и checkmarx[.]zone.

Реагирование и стратегии защиты от CVE-2026-33634

Существующие сигнатурные проверки и сканирование зависимостей в публичных реестрах больше не являются достаточными, так как вредоносный код был внедрен напрямую в доверенные подписанные действия и ускользнул от обнаружения, пока не был применен поведенческий мониторинг. CI/CD-конвейеры стали «новым периметром» безопасности.

Немедленные действия. Убедитесь, что все рабочие процессы используют безопасные версии (Trivy binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).

Администраторы конвейеров CI/CD и команды ИБ должны немедленно проверить свои ссылки на решения Checkmarx (kics-github-action, ast-github-action) и Trivy (setup-trivy и trivy-action). Если ваши рабочие процессы ссылались на тег версии, а не на конкретный SHA-хеш, тщательно проверьте ваши журналы исполнения рабочих процессов в период уязвимости.

Также необходимо проверить сетевые журналы на наличие трафика к доменам scan.aquasecurtiy[.]org, checkmarx[.]zone и models.litellm[.]cloud. Его наличие свидетельствует об успешной эксфильтрации конфиденциальных данных.

Если в вашей организации на GitHub появился репозиторий с именем docs-tpcp, это также может указывать на успешную кражу данных.

В любом случае необходимо провести проактивный поиск угроз (threat hunting), предполагая успешную компрометацию и быстрое продвижение злоумышленников в затронутых системах.

Рекомендовано восстановить затронутые окружения из проверенных архивов.

Фиксация зависимостей и управление секретами. Убедитесь, что точные версии зависимостей закреплены с помощью криптографических хешей во всех конвейерах и Dockerfile. Переходите от долгоживущих токенов к краткосрочным учетным данным, используя для этого менеджер секретов, а также применяя интеграции OIDC там, где это поддерживается. Минимизируйте инъектирование секретов в окружение запущенных процессов — делайте это только с необходимыми секретами. Убедитесь, что секреты не сохраняются на диск и во временные файлы, а также не используются повторно в различных процессах.

Другие меры защиты. Разрешайте запуск GitHub Actions только из закрытого списка, одобренного в организации, блокируйте новые и непроверенные процессы. Настройте GITHUB_TOKEN и другие ключи доступа с соблюдением принципа наименьших привилегий. Не давайте разрешений на запись, если в этом нет прямой необходимости.

Для повышения безопасности GitHub Actions существует несколько инструментов с открытым исходным кодом:

• zizmor — инструмент статического анализа и поиска ошибок конфигурации в GitHub Actions;
• gato и Gato-X — две версии инструмента, помогающего выявлять структурно уязвимые конвейеры;
• allstar — приложение GitHub, разработанное OpenSSF для настройки и внедрения политик безопасности в организациях и репозиториях GitHub.

26.03.2026

Kaspersky для школ по специальной цене