Для кого: разработчики и операторы, которые используют LiteLLM — инструмент с открытым исходным кодом для вызова множества API LLM (больших языковых моделей) через один интерфейс, либо как библиотеку Python, либо как прокси (LLM-шлюз), работающий в Docker.
Статья основана на официальном уведомлении BerriAI, компании-разработчика LiteLLM, и обновлениях статуса, опубликованных ею на GitHub. Она не охватывает методы атаки, содержимое вредоносного ПО и конкретные индикаторы компрометации (IoC). Имена файлов и дайджесты образов смотрите на странице уведомления компании.
Ситуация развивается: статья будет обновляться по мере новых публикаций организации
По состоянию на 11:00 UTC, 24 октября 2026 года (20:00 JST)Пока неизвестно
- Меры по предотвращению повторения (компания говорит, что поделится ими на следующей неделе)
- Число затронутых пользователей или сред
- Использованы ли похищенные данные
23 октября (UTC) компания сообщила, что завершила расследование цепочки атаки, и опубликовала анализ первопричины. Она признаёт, что некоторые предположения в обновлениях статуса, опубликованных во время расследования, были «неточными или неполными», и что этот анализ является основным источником. Первое сообщение об инциденте оставлено в исходном виде.
То, что нужно сделать пользователям (затронутые версии и окно, очистка, какие ключи заменить), со времени первого сообщения не изменилось. 24 октября (UTC) компания опубликовала 1.103.8, 1.104.6, 1.105.4 и 1.106.3, и последней версией на PyPI теперь является 1.106.3. Начиная с этих релизов ключ cosign, которым подписываются образы Docker и Helm-чарты, изменился (шаг 3 ниже).
Что пользователям LiteLLM нужно сделать сегодня
Шаг 1 нужен всем. Следующие шаги соответствуют рекомендациям компании для сред, где была установлена или запущена затронутая версия или образ.
Проверьте, затронуты ли вы: когда вы устанавливали и какой тег использовали
Компания перечисляет следующие затронутые артефакты. Все времена относятся к 21 октября 2026 года.
| Канал | Затронуто | Окно (UTC) |
|---|---|---|
| PyPI | litellm==1.107.0 (все семь wheel-пакетов) | с 11:39 до 13:23 |
| Docker Hub | v1.107.0, latest, main-latest, main-stable | с 11:46 до 14:20 |
| GHCR (реестр контейнеров GitHub) | Те же четыре тега (litellm, litellm-database, litellm-non_root) | с 11:46 до снятия к 13:51 |
Компания сообщает, что вы затронуты, если в течение окна установили LiteLLM через pip без закрепления версии или запустили контейнер из одного из этих тегов. Если CI выполняет pip install litellm при каждой сборке или ваш Dockerfile собирается FROM тега latest, затронутая версия могла быть установлена без каких-либо действий с вашей стороны.
- Если среда могла быть затронута, не запускайте Python или pip для проверки версии. Сначала изолируйте её, затем просмотрите записи о развёртываниях или дайджесты образов с отдельной чистой машины. Если исключить воздействие нельзя, считайте среду затронутой и переходите к пересборке и замене учётных данных ниже (примечание этого сайта). Команда компании для проверки версии тоже запускает Python, поэтому не выполняйте её до очистки
- Компания опубликовала имена файлов, которые нужно искать, и дайджесты образов. Их обнаружение подтверждает воздействие, но их отсутствие не доказывает, что среда чиста
- Если вы явно закрепили 1.106.2 или более раннюю версию либо 1.107.0rc1 или rc2, вы не затронуты (компания говорит, что более ранние версии вне этой компрометации)
- Клиенты, загружавшие пакеты из приватного корпоративного реестра, затронуты не были (компания)
Если пакет был установлен: не начинайте с pip install в этой среде
Согласно анализу автора сообщения, процитированному в уведомлении компании, вредоносное ПО устанавливается в виде файлов, которые Python загружает автоматически при каждом запуске. Оно запускается снова в любом процессе Python, включая те, что никогда не импортируют litellm, и сам pip.
Порядок очистки, который указывает компания (имена файлов и расположение — на странице её уведомления):
- Не запуская Python, удалите из оболочки названные компанией вредоносные файлы (и их файлы кэша) из каждого затронутого каталога site-packages
- Остановите процесс Python, оставшийся работать в фоне
- Только после этого переустановите пакет, закрепив
litellm==1.106.2. Компания говорит, что лучше пересобрать образы и виртуальные среды с нуля
Если вы запускали пакет в контейнерах, обычно быстрее всего остановить контейнеры, созданные из затронутого образа, и создать их заново из образа с закреплённой чистой версией (примечание этого сайта).
Закрепите версию и проверяйте новым ключом подписи
В первом сообщении компания просила закрепить 1.106.2 или любую явную версию, опубликованную до этого инцидента. 24 октября (UTC) она опубликовала 1.103.8, 1.104.6, 1.105.4 и 1.106.3. Последняя версия на PyPI — 1.106.3, а 1.107.0 по-прежнему удалён. Согласно примечаниям к релизам, эти версии удаляют корневой центр сертификации eMudhra из всех пакетов сертификатов, которым доверяют SDK, прокси и образы Docker. О проблеме eMudhra рассказано в материале что пользователям Python нужно сделать в связи с ключами промежуточного ЦС eMudhra.
В Docker ссылайтесь на образы по тегу версии или, лучше, по дайджесту (значению, вычисляемому из содержимого образа), а не по тегам вроде latest или main-stable, содержимое которых меняется. Тогда изменение того, на что указывает тег, вас не затронет.
Согласно примечаниям к релизам, начиная с релизов от 24 октября образы Docker и Helm-чарты подписываются новым ключом cosign (cosign — инструмент для подписи и проверки образов контейнеров), а проверка прежним ключом не проходит. Если вы закрепили старый cosign.pub в скриптах cosign verify, проверках CI или политиках Kubernetes, проверяющих подписи (например, Kyverno), замените его новым ключом из коммита, указанного в примечаниях к релизу. В примечаниях к релизу также указан SHA-256 нового ключа, поэтому перед переключением сравните с ним загруженный ключ (примечание этого сайта).
Замените ключи: всё, до чего могла дотянуться среда
Компания говорит, что если 1.107.0 когда-либо был установлен на хосте с исходящим доступом в интернет, следует исходить из того, что похищенные данные были успешно отправлены. В частности, она называет:
- Облачную роль, назначенную серверу или контейнеру (например, роль IAM экземпляра или задачи AWS)
- Все ключи провайдеров LLM, хранящиеся в базе данных прокси LiteLLM
- Мастер-ключ прокси и все выданные вами виртуальные ключи
- Пароль в строке подключения к базе данных (DATABASE_URL)
- Все секреты, находившиеся в окружении любого процесса, работавшего на хосте
Согласно анализу автора сообщения, вредоносное ПО было также рассчитано на сбор ключей SSH, учётных данных Git и публикации пакетов, токенов Kubernetes, паролей, сохранённых в браузерах, и настроек ИИ-помощников для программирования. Если вы запускали 1.107.0 на ноутбуке разработчика, учётные данные на этом ноутбуке тоже нужно заменить.
Выпустите новый ключ в панели каждого сервиса и отзовите старый (примечание этого сайта: сначала задайте новый ключ, затем отзовите старый, чтобы избежать простоя). Об обращении с ключами API рассказано в материале чем опасны файлы .env и ключи API.
Проверьте на злоупотребления: журналы аудита облака и использование LLM
Компания просит проверить журнал аудита AWS (CloudTrail) на вызов проверки идентичности (GetCallerIdentity), выполненный с ролью экземпляра примерно во время установки, а затем на любое использование учётных данных этой роли извне вашей собственной инфраструктуры.
В качестве примечания от этого сайта: также проверьте в панелях ваших провайдеров LLM, нет ли неожиданного роста использования или расходов с 11:39 UTC 21 октября (вечер в Японии). Использование похищенного ключа LLM может проявиться в статистике и счетах. О том, что происходит с похищенными ключами, рассказано в материале как похищенные ключи API приводят к блокировке аккаунтов.
Установили 1.107.0 или запустили затронутый тег в течение окна
Считать скомпрометированным
↓→
1. Очистить, не запуская Python
Лучше: пересобрать образы и виртуальные среды
У хоста был исходящий доступ в интернет
Исходить из того, что данные были отправлены
↓→
2. Заменить все ключи, до которых он мог дотянуться
Облачные роли, ключи провайдеров, мастер-ключ, база данных
Явно закрепили 1.106.2 или более раннюю версию
Компания говорит, что более ранние версии вне этой компрометации
↓→
3. Сохранить закрепление; проверять подписи новых версий
В Docker использовать тег версии или дайджест. Новый ключ cosign с релизов от 24 октября
Если вы используете прокси LiteLLM
В базе данных прокси хранятся ключи всех подключённых вами провайдеров LLM. Согласно анализу автора сообщения, при заданном DATABASE_URL вредоносное ПО было рассчитано на чтение таблиц с ключами провайдеров и настройками моделей. Если ваш прокси запускался на 1.107.0, планируйте заменить все ключи провайдеров, зарегистрированные в нём, и составьте их список до начала работы. Выданные вами виртуальные ключи тоже придётся выпустить заново, поэтому заранее подготовленное сообщение для их пользователей уменьшит путаницу.
Что произошло (по данным BerriAI)
Ниже изложено на основе публикации в блоге BerriAI «Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised» (опубликована 21 октября 2026 года, обновлена в тот же день в 20:30 UTC), её анализа первопричины от 23 октября «The attack chain behind the v1.107.0 LiteLLM release» и обновлений статуса, опубликованных её директором по безопасности в задаче на GitHub. Все времена — UTC 21 октября, если не указано иное. Значения индикаторов, такие как адреса и имена, использованные злоумышленником, не приводятся.
27 мая
Файл конфигурации с мастер-ключом внутренней платформы агентов ошибочно закоммичен в публичный репозиторий. Коммит быстро перезаписан, но мастер-ключ не отозван (анализ первопричины).10 октября
Злоумышленник использует мастер-ключ для вызова API платформы и получает токен GitHub CLI владельца организации, настроенный там. Примерно через 45 минут с помощью этого токена злоумышленник запускает CI в репозиториях компании и выводит секреты CI, получая токены двух других мейнтейнеров (анализ первопричины).12 октября
С помощью токена владельца злоумышленник запускает CI в нескольких приватных репозиториях и повторно выводит секреты: малочувствительные секреты и ключи провайдеров LLM с минимальным балансом, использовавшиеся в тестировании CI. Компания говорит, что они не участвовали в пути к отравленным артефактам, а задействованные токены она заменила и проверила журналы безопасности (анализ первопричины).10:08
Защита веток отклоняет изменение приватного рабочего процесса выпуска. Через пять секунд учётные данные привилегированной учётной записи разработчика используются, чтобы обойти защиту и применить изменение.10:46
Изменённый рабочий процесс запускает промежуточную сборку из похожего репозитория, контролируемого злоумышленником.11:11
Злоумышленник с помощью других похищенных учётных данных добивается одобрения и публикации изменённого релиза.11:39 – 11:40
На PyPI загружены семь вредоносных wheel-пакетов 1.107.0.11:46
Опубликованы образы Docker того же релиза.12:06
Внешний исследователь сообщает о проблеме в задаче на GitHub.12:09 – 12:24
Злоумышленник удаляет следы изменения рабочего процесса (анализ первопричины; журнал аудита организации сохранил запись).13:02
Компания начинает реагирование на инцидент (анализ первопричины).К 13:23
PyPI удалил 1.107.0.14:20
Все затронутые теги Docker Hub удалены или перенаправлены на чистые образы.20:30
Компания обновляет уведомление, сообщая, что, по её мнению, определила цепочку атаки.23:37
Компания сообщает, что выявляет все токены аутентификации в организации и отзывает или заменяет каждый из них. Реестры остаются закрытыми для новых релизов, регулярные релизы приостановлены.02:19 22 октября (11:19 JST)
Компания сообщает об отсутствии существенных изменений с прошлого обновления. Реестры остаются закрытыми, регулярные релизы приостановлены. Она переходит от обновлений каждые два часа к обновлениям при значимых событиях.Примерно с 21:00 до 21:50 23 октября (примерно с 06:00 до 06:50 JST 24 октября)
Около 21:00 компания публикует анализ первопричины и говорит, что некоторые её прежние предположения были неточными или неполными. Обновление в 21:50 (06:50 JST) к первому сообщению указывает на анализ как на основную запись.Примерно с 07:56 до 09:15 24 октября (примерно с 16:56 до 18:15 JST)
Компания публикует на PyPI 1.103.8, 1.104.6, 1.105.4 и 1.106.3. Они удаляют корневой центр сертификации eMudhra из доверенных пакетов, а образы Docker и Helm-чарты переходят на новый ключ подписи cosign (примечания к релизам).
- Затронуто
- litellm==1.107.0 на PyPI (все семь wheel-пакетов). Теги v1.107.0, latest, main-latest и main-stable на Docker Hub и GHCR (на GHCR: образы litellm, litellm-database и litellm-non_root)
- Что произошло
- Конвейер выпуска был скомпрометирован, и был опубликован 1.107.0 с вредоносным ПО. Официальный тег v1.107.0 на GitHub не содержит вредоносных файлов; артефакты были собраны из похожего репозитория, контролируемого злоумышленником
- Что делает вредоносное ПО (по раскрытым данным)
- Скомпилированное вредоносное ПО, которое похищает учётные данные и загружает инструменты удалённого выполнения кода. Оно запускается при каждом старте Python и оставляет работающий в фоне процесс
- Версии вне этой компрометации
- Все более ранние версии вне этой компрометации. Пока закрепите 1.106.2 или другую явную версию
- Причина (анализ первопричины от 23 октября)
- Неотозванный мастер-ключ внутренней платформы агентов, ошибочно закоммиченный в публичный репозиторий, был использован для получения OAuth-токена GitHub CLI владельца организации. Этот токен не был привязан к сервисной учётной записи и не был ограничен по правам. С ним злоумышленник вывел секреты CI и получил токены двух мейнтейнеров. Токен владельца использовался, чтобы отключить защиту веток и изменить рабочий процесс, а остальные похищенные токены — чтобы провести изменённый релиз через одобрение
- Одобрение релиза (анализ первопричины)
- Обычно релиз должен был одобрять специальная учётная запись, привязанная к физическому устройству в офисе компании. Ранее на той же неделе это ограничение смягчили, разрешив любым двум инженерам запускать и одобрять релиз, чтобы поддержать более частые релизы с исправлениями
- Исправление первого объяснения
- В первом сообщении предполагалось, что токены были взяты из логов внутреннего развёртывания LiteLLM. Анализ говорит, что первый токен был получен из другого сервиса
- Прочие похищенные учётные данные
- Были также похищены токены нескольких других внутренних систем, а активность злоумышленника была сосредоточена в основном на ключах API вышестоящего инференса (ключах провайдеров LLM). 12 октября из нескольких приватных репозиториев были выведены малочувствительные тестовые секреты CI и ключи провайдеров с минимальным балансом; компания говорит, что они не участвовали в пути к отравленным артефактам. Компания отзывает все токены всех внутренних систем и платформ поставщиков
- Реакция компании
- Удалила артефакты с PyPI, Docker Hub и GHCR. Отозвала задействованные токены, сократила свою организацию GitHub до одного незатронутого участника, убрала доверенные связи своих публичных реестров с организацией и отзывает или заменяет все токены. 24 октября (UTC) опубликовала 1.103.8, 1.104.6, 1.105.4 и 1.106.3 с новым ключом подписи
- Числа и злоупотребления
- Не раскрыты
Что известно и что неизвестно
Это состояние на 24 октября 2026 года. При появлении новых сведений столбец статуса будет обновлён.
| Пункт | Что говорится в уведомлении | Статус |
|---|---|---|
| Затронутая версия (PyPI) | litellm==1.107.0, все семь wheel-пакетов | Подтверждено (компанией) |
| Затронутые образы и теги | v1.107.0, latest, main-latest, main-stable на Docker Hub и GHCR | Подтверждено (компанией) |
| Временное окно | PyPI с 11:39 до 13:23 UTC; Docker Hub с 11:46 до 14:20 UTC; GHCR недоступен к 13:51 UTC | Подтверждено (компанией) |
| Вредоносное ПО в релизе | Похищает учётные данные и загружает инструменты удалённого выполнения кода | Подтверждено (компанией) |
| Учётные данные на затронутых хостах | Если у хоста был исходящий доступ, исходить из того, что данные были отправлены | Возможно (компания) |
| Более ранние версии | Вне этой компрометации | Не затронуты (компания) |
| Приватный корпоративный реестр | Не затронут | Не затронут (компания) |
| Официальный исходный тег на GitHub | Не содержит вредоносных файлов | Не затронут (компания) |
| Как были взяты токены | Неотозванный мастер-ключ, ошибочно закоммиченный в публичный репозиторий, был использован, чтобы взять токен владельца, хранившийся во внутренней платформе агентов (анализ первопричины от 23 октября) | Подтверждено (компанией) |
| Объяснение «взято из логов» из первого сообщения | Исправлено в анализе: первый токен был получен из другого сервиса | Исправлено (компанией) |
| Повторный вывод данных 12 октября | Тестовые секреты CI и ключи провайдеров с минимальным балансом из приватных репозиториев; не участвовали в пути к отравленным артефактам | Подтверждено (компанией) |
| Исправленные релизы и ключ подписи | 1.103.8, 1.104.6, 1.105.4 и 1.106.3 опубликованы 24 октября; образы Docker и Helm-чарты подписаны новым ключом cosign | Подтверждено (компанией) |
| Меры по предотвращению повторения | Будут опубликованы на следующей неделе | Запланировано (компанией) |
| Число затронутых пользователей или сред | В уведомлении не указано | Не указано |
| Использование похищенных данных | В уведомлении не указано | Не указано |
Как это понимать: хотя окно было коротким, решающим является то, устанавливали ли вы или запускали пакет
Релиз был доступен на PyPI около двух часов, но установки без закрепления версии в CI или автоматические пересборки могли получить его за это время. Этот сайт не гадает о числах. Определяйте, затронуты ли вы, по тому, устанавливали ли вы 1.107.0 или запускали затронутый тег в течение окна.
В уведомлении и анализе компании названы исследователь, обнаруживший проблему, компания в сфере информационной безопасности, проводившая независимое расследование, и инструмент для разработчиков, упомянутый в первом сообщении. В соответствии с политикой этого сайта называется только организация, раскрывшая инцидент; остальные описаны по роли.
Что может произойти, если релиз содержит вредоносное ПО
Нижеследующее носит общий характер и не означает, что в данном случае это происходило. Что компания раскрыла об этом вредоносном ПО, указано выше в разделе «Что произошло».
Пакет Python выполняется с правами того, кто его устанавливает. На сервере или в контейнере он может получить доступ к переменным окружения этого хоста, файлам и любой облачной роли, назначенной хосту. LLM-шлюз существует для того, чтобы хранить в одном месте ключи нескольких провайдеров LLM, поэтому при его компрометации под угрозой сразу оказываются ключи всех подключённых провайдеров.
Отличие от тайпсквоттинга или эксплуатации уязвимости старой версии в том, что вредоносный код пришёл из официального канала, под официальным именем и номером версии. К инцидентам того же рода относятся компрометация цепочки поставок Trivy, инциденты с TanStack и Nx Console и вредоносное ПО в Rank Math PRO, плагине WordPress.
Что пользователям LiteLLM стоит пересмотреть: выводы из раскрытых фактов
Этот раздел не оценивает действия компании. В нём выбраны пункты из уведомления и анализа первопричины, на основе которых пользователи могут подготовиться к следующему инциденту.
Перестаньте использовать ссылки, содержимое которых меняется: закрепляйте версии и используйте дайджесты
Затронутыми оказались среды, где пакет устанавливался через pip без закреплённой версии или использовались теги вроде latest, main-latest и main-stable, содержимое которых меняется. Среды, закрепившие 1.106.2 и ссылавшиеся на образы Docker по дайджесту, не были затронуты, даже если их пересобирали в течение окна.
В качестве первого шага закрепите зависимости, используемые в продакшене и CI, с помощью lock-файла с хешами (pip install --require-hashes или lock-файлы uv либо Poetry). Настройка, исключающая совсем недавно опубликованные версии (например, exclude-newer в uv, которая игнорирует всё опубликованное после заданного момента), также помогает против релизов, которые отзывают в течение нескольких часов. Подход описан в материале аудит зависимостей с помощью OSV-Scanner.
Разделите ключи, которые вы даёте LLM-шлюзу, исходя из того, что их придётся заменять
В базе данных прокси хранятся ключи всех подключённых провайдеров. Когда их нужно заменять, как сейчас, незнание того, какой ключ относится к какой среде, оставляет выбор между риском что-то пропустить и остановкой всего.
Использование отдельных ключей провайдеров для разработки, тестирования и продакшена, а также лимиты расходов и оповещения на стороне провайдера уменьшают объём замены и помогают быстрее заметить злоупотребление. Что делать при утечке ключа, описано в материале ключ API, утёкший из кода, написанного ИИ.
Отзывайте раскрытый ключ, даже после перезаписи коммита
Согласно анализу первопричины, отправной точкой стал мастер-ключ, ошибочно закоммиченный в публичный репозиторий в мае. Коммит быстро перезаписали, а раскрытые ключи определили как требующие отзыва, но мастер-ключ не отозвали, и он был использован примерно через четыре с половиной месяца. Компания говорит, что этот инцидент наглядно показывает риск незамены потенциально раскрытого ключа.
Если вы отправили секрет в публичный репозиторий, сначала отзовите и замените ключ, а потом занимайтесь историей. После замены сверьтесь со списком заменённых ключей и убедитесь, что ни один не пропущен (примечание этого сайта). Проблема описана в материале утёкшие учётные данные, которые остаются действительными.
Не давайте инструментам автоматизации личный токен владельца
Согласно анализу, первый похищенный токен был настроен в платформе агентов, чтобы она могла открывать pull request'ы. Он не был привязан к сервисной учётной записи и не был ограничен по правам: это был личный токен GitHub CLI владельца организации. Компания отмечает, что токены GitHub CLI выдаются после двухфакторной аутентификации и на них не распространяется повторная аутентификация, которую GitHub запрашивает перед чувствительными действиями.
Выдавайте агентам и ботам отдельный токен, ограниченный только их задачей (GitHub App или fine-grained токен), и разделяйте права владельца и учётные записи для повседневной работы (примечание этого сайта). Если секреты CI доступны только тем рабочим процессам и средам, которым они нужны, это тоже ограничивает охват похищенного токена (примечание этого сайта). Защита учётной записи GitHub описана в материале настройка двухфакторной аутентификации GitHub.
Не выставляйте журналы и интерфейс администратора шлюза в интернет
Как выяснилось, это не было причиной, но в первом сообщении компании отмечалось, что в определённых ситуациях ИИ-помощник для программирования может встроить токен GitHub CLI пользователя в тело ответа, и там, где тела ответов записываются в журнал, эти токены могут появляться в логах LiteLLM.
Для шлюза, который вы запускаете сами, проверьте три вещи: интерфейс администратора и API недоступны напрямую из интернета, настройки журналирования, сохраняющие тела ответов, пересмотрены, а если вы их сохраняете, срок хранения короткий. Защита учётной записи GitHub описана в материале настройка двухфакторной аутентификации GitHub.
Источники (публичные данные)
Факты в этой статье взяты из следующей публичной информации. Содержимое вредоносного ПО, адреса, с которыми оно связывается, и конкретные значения индикаторов не приводятся.
- BerriAI (LiteLLM), «Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised» (опубликовано 21 октября 2026 года, обновлено в тот же день в 20:30 UTC) — docs.litellm.ai
- BerriAI (LiteLLM), «The attack chain behind the v1.107.0 LiteLLM release» (анализ первопричины, опубликован 23 октября 2026 года) — docs.litellm.ai
- Задача BerriAI/litellm на GitHub № 47826 (сообщение внешнего исследователя и обновления статуса компании, проверено до обновления в 21:15 UTC 23 октября) — github.com
- Страница проекта litellm на PyPI (проверена в 11:00 UTC 24 октября; последняя версия — 1.106.3, 1.107.0 в списке нет) — pypi.org
- Релизы BerriAI/litellm на GitHub (v1.103.8, v1.104.6, v1.105.4 и v1.106.3, опубликованы 24 октября 2026 года: смена ключа подписи и удаление корневого ЦС eMudhra) — github.com
История обновлений
2026-10-24 (11:00 UTC): Учтена публикация компанией 24 октября (UTC) версий 1.103.8, 1.104.6, 1.105.4 и 1.106.3 вместо утверждения, что последней версией на PyPI остаётся 1.106.2. В шаг 3 и FAQ добавлено, что образы Docker и Helm-чарты этих релизов подписаны новым ключом (прежний ключ их больше не проверяет), а также удаление корневого ЦС eMudhra. Из анализа первопричины добавлен повторный вывод данных 12 октября (по данным компании, не участвовал в пути к отравленным артефактам).
2026-10-24: Учтён анализ первопричины, опубликованный компанией 23 октября. Переписано описание того, как были взяты токены: вместо предположения из первого сообщения (логи внутреннего развёртывания LiteLLM) — мастер-ключ, ошибочно закоммиченный в публичный репозиторий и не отозванный, затем токен владельца, хранившийся во внутренней платформе агентов, затем секреты CI. Обновлены хронология, FAQ, таблица и раздел для пользователей. В сообщениях 22 и 23 октября описывалось первоначальное предположение (утечка токенов через журналы ИИ-инструмента или шлюза), которое компания впоследствии исправила. То, что нужно сделать пользователям, не изменилось. Значения индикаторов (IP-адреса, имена, коммиты) не включены.
2026-10-22 (13:30 JST): Добавлено обновление на GitHub в 02:19 UTC 22 октября (существенных изменений нет; обновления теперь только при значимых событиях). Уведомление по-прежнему в версии от 20:30 UTC. Уточнено, какие образы затронуты на GHCR, и формулировка проверки на злоупотребления.
2026-10-22: Первая версия на основе уведомления BerriAI в редакции от 20:30 UTC 21 октября и обновления на GitHub в 23:37 UTC того же дня. Будет обновлена, когда будут опубликованы путь проникновения или числа.
Читайте также
- Связанное: Переменные окружения Railway, возможно, раскрыты (октябрь 2026)
- Инциденты того же рода: Что делать, если вы используете Trivy в CI после компрометации цепочки поставок / Цепочка TanStack, Nx Console и GitHub
- Порядок отзыва похищенных токенов: Защита от червей в цепочке поставок npm
- Где хранятся секреты: Чем опасны файлы .env и ключи API / Утёкшие учётные данные, которые остаются действительными
- Термины: Что такое бэкдор / Что такое вредоносное ПО
- Другие инциденты 2026 года: Утечки данных и кибератаки 2026 года