24 марта 2026 года в 10:39 UTC на PyPI появились вредоносные версии открытого ИИ-шлюза LiteLLM 1.82.7 и 1.82.8. Примерно через 40 минут площадка поместила их в карантин, но разработчики LiteLLM советуют считать опасными все установки, выполненные с 10:39 до 16:00 UTC. LiteLLM соединяет приложения с разными поставщиками ИИ-моделей, поэтому пакет часто оказывается глубоко внутри агентских фреймворков и средств оркестрации. На 12 августа 2026 года The Hacker News не обнаружил версии 1.82.7 и 1.82.8 в истории релизов PyPI, тогда как соседние 1.82.6 и 1.83.0 оставались доступны.
В LiteLLM 1.82.8 находился файл litellm_init.pth. Python обрабатывает файлы.pth при запуске интерпретатора, из-за чего вредоносный код мог исполниться без импорта LiteLLM и вообще без обращения приложения к пакету. Он собирал переменные окружения, SSH-ключи, статические ключи облачных платформ, токены Kubernetes, пароли баз данных, секреты CI/CD, учётные данные GitHub, токены публикации пакетов и ключи поставщиков моделей, включая OPENAI_API_KEY и ANTHROPIC_API_KEY. Украденное шифровалось и уходило на models.litellm[.]cloud — подконтрольный злоумышленникам домен, никак не связанный с настоящим проектом LiteLLM.
Для заражения не требовалось осознанно выбирать LiteLLM. Незакреплённая транзитивная зависимость могла подтянуть свежий релиз через сторонний инструмент, а временный CI-раннер удалить все следы после завершения задания. Поэтому проверять нужно журналы установок, lock-файлы, кэши пакетных менеджеров, контейнеры, образы сборки, машины разработчиков, CI/CD-задания, агентские фреймворки и оркестраторы. Вопрос «использовали ли мы LiteLLM?» здесь слишком узок; полезнее выяснить, устанавливалось ли что-либо из версий 1.82.7 или 1.82.8 хотя бы на одном узле в окне 24 марта с 10:39 до 16:00 UTC.
CloudSEK получила из конфиденциальных разведывательных источников массив примерно из 434 000 захваченных файлов и событий эксфильтрации. По оценке компании, эти материалы могут относиться более чем к 2500 организациям, хотя в заголовочной оценке фигурировало число свыше 2100. Ни одна из цифр не равна подтверждённому числу жертв. Файлы уже находились у атакующих и не были собраны непосредственно у названных компаний; наличие записи не доказывает, что найденный секрет оставался действительным, применялся злоумышленниками или привёл к полному захвату системы. Один захваченный файл примерно соответствует одному выполнению задания, но 434 000 нельзя автоматически считать числом уникальных конвейеров, заданий, запусков либо пострадавших без дедупликации и отдельной проверки.
CloudSEK открыла поисковый сервис, где данные фильтруются по названию организации, домену и степени уверенности. В записи указываются домен, число раскрытых секретов, количество запусков и оценка High либо Medium. В наборе встречаются NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens и X Corp, но их присутствие само по себе не говорит об использовании украденных учётных данных. Высокая уверенность требует признаков личности хоста, легитимных доменов авторов коммитов, переменных CI и собственного домена организации в собранных материалах. Одного пространства имён репозитория хватает лишь на среднюю оценку.
Атрибуцию CloudSEK проверяет в два прохода. Сначала механизм Index assignment связывает файл с организацией по переменным идентификации CI. Затем Ownership gate заново определяет владельца по извлечённым журналам и при необходимости отменяет первоначальную привязку. Итог получает меньшую из двух оценок уверенности. Компания сформулировала правило коротко: «Если результаты расходятся, отчёт не публикуется». CloudSEK не сообщила, предупреждала ли перечисленные организации до открытия базы и оспаривала ли какая-либо из них своё включение.
Эпизод с LiteLLM относят к более широкой атаке на цепочку поставок TeamPCP; Google отслеживает того же субъекта или кластер активности под обозначением UNC6780. Отправной точкой стал сканер Trivy компании Aqua Security и связанные с ним GitHub Actions. После неполной смены учётных данных атакующие сохранили доступ и 19 марта 2026 года принудительно записали вредоносные коммиты в 76 из 77 тегов trivy-action, во все семь тегов setup-trivy, а затем опубликовали заражённый Trivy 0.69.4. Общий компромисс экосистемы зарегистрирован как CVE-2026-33634; 26 марта 2026 года CISA внесло уязвимость в каталог Known Exploited Vulnerabilities, CISA KEV. На 12 августа запись CVE перечисляла BerriAI LiteLLM 1.82.7, BerriAI LiteLLM 1.82.8 и соответствующие компоненты Trivy.
Описание пути на PyPI поначалу выглядело противоречиво. CloudSEK писала об отравленной сборке, выпустившей скомпрометированные пакеты; отчёт LiteLLM говорил о прямой загрузке в PyPI в обход официального CI/CD; Unit 42 установила, что после взлома Trivy атакующие охотились за токенами публикации PyPI. CloudSEK объяснила расхождение так: «Это разные этапы одной цепочки атаки, а не конкурирующие объяснения». По этой версии, её материалы показывают получение издательского токена, а LiteLLM и Unit 42 описывают дальнейшее применение токена. Python Packaging Authority, PyPA, приводит ту же последовательность: API-токен утёк через скомпрометированную зависимость Trivy, после чего его использовали для загрузки LiteLLM 1.82.7 и 1.82.8. BerriAI к моменту публикации не ответила, какая трактовка подтверждается её собственной экспертизой.
Масштаб CloudSEK пока остаётся оценкой, но последствия кампании подтверждены независимо. Checkmarx сообщила, что украденные через Trivy данные позволили посторонним войти в её репозитории GitHub и опубликовать вредоносные артефакты. Mercor обнаружила у себя заражённые версии LiteLLM и локализовала несанкционированную активность. CERT-EU с высокой уверенностью связала компрометацию AWS-аккаунта Европейской комиссии с атакой через цепочку поставок Trivy; из аккаунта вывели около 91,7 ГБ данных в сжатом виде.
2 июля 2026 года Федеральное бюро расследований выпустило уведомление FLASH-20260702-01. По оценке FBI, связанные с TeamPCP участники способны задействовать похищенные секреты спустя долгое время после первоначального проникновения. Удаление пакета или обновление LiteLLM закрывает вредоносный код, но не отбирает у противника уже скопированные SSH-ключи, статические облачные ключи, токены публикации и учётные данные CI/CD. FBI рекомендует менять либо отзывать все секреты, доступные заражённым системам. FBI и Aqua отдельно советуют уходить от долгоживущих данных доступа к временным учётным данным и короткоживущим токенам.
Среди индикаторов TeamPCP FBI называет репозитории GitHub tpcp-docs и docs-tpcp. В бюллетене Aqua по CVE также указан префикс tpcp-docs-: атакующие создавали репозитории с продолжением после дефиса и загружали добычу в ресурсы релизов с тегами формата data-<timestamp>. Поиск только точного имени tpcp-docs пропустит варианты с добавочным текстом, поэтому внутри GitHub-организаций следует искать точные названия, префикс и связанные релизные теги.
После обнаружения LiteLLM 1.82.7 или 1.82.8 необходимо считать доступными злоумышленникам все секреты, которые мог прочитать соответствующий процесс: облачные ключи, SSH-ключи, токены Kubernetes, пароли баз данных, GitHub-доступ, секреты CI/CD, токены PyPI и других реестров, OPENAI_API_KEY, ANTHROPIC_API_KEY и прочие переменные окружения. Их следует отозвать или заменить без ожидания доказательств фактического применения. Затем проверяются облачные журналы, GitHub-аудит, публикации пакетов, обращения к базам и ИИ-провайдерам, а также репозитории tpcp-docs, docs-tpcp, все имена с tpcp-docs- и ресурсы data-<timestamp>.[/final]
Изображение носит иллюстративный характер
В LiteLLM 1.82.8 находился файл litellm_init.pth. Python обрабатывает файлы.pth при запуске интерпретатора, из-за чего вредоносный код мог исполниться без импорта LiteLLM и вообще без обращения приложения к пакету. Он собирал переменные окружения, SSH-ключи, статические ключи облачных платформ, токены Kubernetes, пароли баз данных, секреты CI/CD, учётные данные GitHub, токены публикации пакетов и ключи поставщиков моделей, включая OPENAI_API_KEY и ANTHROPIC_API_KEY. Украденное шифровалось и уходило на models.litellm[.]cloud — подконтрольный злоумышленникам домен, никак не связанный с настоящим проектом LiteLLM.
Для заражения не требовалось осознанно выбирать LiteLLM. Незакреплённая транзитивная зависимость могла подтянуть свежий релиз через сторонний инструмент, а временный CI-раннер удалить все следы после завершения задания. Поэтому проверять нужно журналы установок, lock-файлы, кэши пакетных менеджеров, контейнеры, образы сборки, машины разработчиков, CI/CD-задания, агентские фреймворки и оркестраторы. Вопрос «использовали ли мы LiteLLM?» здесь слишком узок; полезнее выяснить, устанавливалось ли что-либо из версий 1.82.7 или 1.82.8 хотя бы на одном узле в окне 24 марта с 10:39 до 16:00 UTC.
CloudSEK получила из конфиденциальных разведывательных источников массив примерно из 434 000 захваченных файлов и событий эксфильтрации. По оценке компании, эти материалы могут относиться более чем к 2500 организациям, хотя в заголовочной оценке фигурировало число свыше 2100. Ни одна из цифр не равна подтверждённому числу жертв. Файлы уже находились у атакующих и не были собраны непосредственно у названных компаний; наличие записи не доказывает, что найденный секрет оставался действительным, применялся злоумышленниками или привёл к полному захвату системы. Один захваченный файл примерно соответствует одному выполнению задания, но 434 000 нельзя автоматически считать числом уникальных конвейеров, заданий, запусков либо пострадавших без дедупликации и отдельной проверки.
CloudSEK открыла поисковый сервис, где данные фильтруются по названию организации, домену и степени уверенности. В записи указываются домен, число раскрытых секретов, количество запусков и оценка High либо Medium. В наборе встречаются NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens и X Corp, но их присутствие само по себе не говорит об использовании украденных учётных данных. Высокая уверенность требует признаков личности хоста, легитимных доменов авторов коммитов, переменных CI и собственного домена организации в собранных материалах. Одного пространства имён репозитория хватает лишь на среднюю оценку.
Атрибуцию CloudSEK проверяет в два прохода. Сначала механизм Index assignment связывает файл с организацией по переменным идентификации CI. Затем Ownership gate заново определяет владельца по извлечённым журналам и при необходимости отменяет первоначальную привязку. Итог получает меньшую из двух оценок уверенности. Компания сформулировала правило коротко: «Если результаты расходятся, отчёт не публикуется». CloudSEK не сообщила, предупреждала ли перечисленные организации до открытия базы и оспаривала ли какая-либо из них своё включение.
Эпизод с LiteLLM относят к более широкой атаке на цепочку поставок TeamPCP; Google отслеживает того же субъекта или кластер активности под обозначением UNC6780. Отправной точкой стал сканер Trivy компании Aqua Security и связанные с ним GitHub Actions. После неполной смены учётных данных атакующие сохранили доступ и 19 марта 2026 года принудительно записали вредоносные коммиты в 76 из 77 тегов trivy-action, во все семь тегов setup-trivy, а затем опубликовали заражённый Trivy 0.69.4. Общий компромисс экосистемы зарегистрирован как CVE-2026-33634; 26 марта 2026 года CISA внесло уязвимость в каталог Known Exploited Vulnerabilities, CISA KEV. На 12 августа запись CVE перечисляла BerriAI LiteLLM 1.82.7, BerriAI LiteLLM 1.82.8 и соответствующие компоненты Trivy.
Описание пути на PyPI поначалу выглядело противоречиво. CloudSEK писала об отравленной сборке, выпустившей скомпрометированные пакеты; отчёт LiteLLM говорил о прямой загрузке в PyPI в обход официального CI/CD; Unit 42 установила, что после взлома Trivy атакующие охотились за токенами публикации PyPI. CloudSEK объяснила расхождение так: «Это разные этапы одной цепочки атаки, а не конкурирующие объяснения». По этой версии, её материалы показывают получение издательского токена, а LiteLLM и Unit 42 описывают дальнейшее применение токена. Python Packaging Authority, PyPA, приводит ту же последовательность: API-токен утёк через скомпрометированную зависимость Trivy, после чего его использовали для загрузки LiteLLM 1.82.7 и 1.82.8. BerriAI к моменту публикации не ответила, какая трактовка подтверждается её собственной экспертизой.
Масштаб CloudSEK пока остаётся оценкой, но последствия кампании подтверждены независимо. Checkmarx сообщила, что украденные через Trivy данные позволили посторонним войти в её репозитории GitHub и опубликовать вредоносные артефакты. Mercor обнаружила у себя заражённые версии LiteLLM и локализовала несанкционированную активность. CERT-EU с высокой уверенностью связала компрометацию AWS-аккаунта Европейской комиссии с атакой через цепочку поставок Trivy; из аккаунта вывели около 91,7 ГБ данных в сжатом виде.
2 июля 2026 года Федеральное бюро расследований выпустило уведомление FLASH-20260702-01. По оценке FBI, связанные с TeamPCP участники способны задействовать похищенные секреты спустя долгое время после первоначального проникновения. Удаление пакета или обновление LiteLLM закрывает вредоносный код, но не отбирает у противника уже скопированные SSH-ключи, статические облачные ключи, токены публикации и учётные данные CI/CD. FBI рекомендует менять либо отзывать все секреты, доступные заражённым системам. FBI и Aqua отдельно советуют уходить от долгоживущих данных доступа к временным учётным данным и короткоживущим токенам.
Среди индикаторов TeamPCP FBI называет репозитории GitHub tpcp-docs и docs-tpcp. В бюллетене Aqua по CVE также указан префикс tpcp-docs-: атакующие создавали репозитории с продолжением после дефиса и загружали добычу в ресурсы релизов с тегами формата data-<timestamp>. Поиск только точного имени tpcp-docs пропустит варианты с добавочным текстом, поэтому внутри GitHub-организаций следует искать точные названия, префикс и связанные релизные теги.
После обнаружения LiteLLM 1.82.7 или 1.82.8 необходимо считать доступными злоумышленникам все секреты, которые мог прочитать соответствующий процесс: облачные ключи, SSH-ключи, токены Kubernetes, пароли баз данных, GitHub-доступ, секреты CI/CD, токены PyPI и других реестров, OPENAI_API_KEY, ANTHROPIC_API_KEY и прочие переменные окружения. Их следует отозвать или заменить без ожидания доказательств фактического применения. Затем проверяются облачные журналы, GitHub-аудит, публикации пакетов, обращения к базам и ИИ-провайдерам, а также репозитории tpcp-docs, docs-tpcp, все имена с tpcp-docs- и ресурсы data-<timestamp>.[/final]
