Установлен вредоносный пакет: остановите выполнение кода до замены учётных данных

Цель

Состояние на 25 октября 2026 года. Остановить выполнение вредоносного пакета и восстановить безопасность учётных записей и артефактов, которые он мог затронуть. Этот предлагаемый протокол опирается на документацию GitHub и npm по реагированию, бюллетень Tensorlake, опубликованный 8 октября, и запись OSV о LiteLLM, изменённую 21 октября в 22:01:01 UTC. Перед действиями повторно проверьте предупреждения для конкретного пакета и обновлённые индикаторы.

Предварительные условия

Чистая машина для администрирования; полномочия на изоляцию затронутых систем и приостановку выпусков; доступ к управлению реестром, репозиторием и сервисами, выдающими учётные данные; защищённое хранилище свидетельств. Назначьте ответственного за инцидент и фиксируйте действия по UTC. Исследуйте подозрительные файлы доверенными инструментами, не запуская установочные хуки, код запуска интерпретатора или задачи проекта.

Шаги

1. Остановите выполнение и распространение. Изолируйте затронутые рабочие станции и раннеры, отмените связанные с инцидентом задания и приостановите публикацию. До очистки сохраните доступные журналы, метаданные пакетов, lock-файлы, дайджесты артефактов и значимые свидетельства из файловой системы. Используйте средства администрирования за пределами подозрительного окружения. Не помещайте новые учётные данные на машину, которую всё ещё проверяют в рамках расследования.
2. Немедленно проверьте наличие разрушительных механизмов закрепления. Для Tensorlake 0.5.144 требуется отключить gh-token-monitor до отзыва GitHub-токенов. Инструкция для Linux начинается с systemctl --user disable --now gh-token-monitor.service, выполняемой в сеансе затронутого пользователя; полностью выполните процедуру очистки из бюллетеня для вашей платформы. Если остановить угрозу не удаётся, выключите затронутую машину и исследуйте её накопители офлайн, прежде чем продолжать. В случае LiteLLM 1.107.0 запуск Python может выполнить вредоносные файлы: не запускайте Python или pip для исследования этого окружения.
3. Отзовите раскрытые учётные данные с чистой машины. Сначала займитесь правами публикации и записи в репозитории, затем охватите все остальные доступные секреты и сеансы через соответствующие сервисы, которые их выдали. Для npm выполните npm token list, определите ID затронутого токена и используйте npm token delete TOKEN_ID, заменив заполнитель этим ID. Снова выведите список токенов. В документации npm указана возможная задержка отзыва, поэтому сохраняйте меры изоляции, пока проверяете состояние у сервиса, выдавшего токен. Выдавайте замену только восстановленным потребителям.
4. Определите полный охват компрометации. Зафиксируйте каждую затронутую машину, время установки, доступную учётную запись и созданный после этого артефакт. Руководство GitHub по реагированию рекомендует составить перечень затронутых рабочих процессов и учётных данных и пересматривать меры локализации при появлении новых свидетельств. Проверьте кэши CI и реестра как возможные источники последующих повторных установок.
5. Проверьте доступ и механизмы закрепления. Изучите изменения рабочих процессов, одобрения выпусков, новые раннеры и незнакомые исполняемые файлы. Руководство GitHub по безопасности аккаунтов также предписывает проверять ключи развёртывания, SSH-ключи, разрешения приложений, вебхуки, участников с доступом и последние коммиты. Сравните результаты с одобренным состоянием до инцидента. Проверьте релизы, выпущенные от имени скомпрометированных издателей, и согласуйте с реестром изъятие подтверждённых вредоносных артефактов.
6. Пересоздайте окружения и проверьте результат. Замените затронутые окружения, используя доверенные образы, проверенный исходный код и одобренный набор зависимостей; не используйте повторно подозрительные кэши или исполняемые файлы. Зафиксируйте идентификационные данные новых артефактов и протестируйте приложение. Подтвердите отзыв учётных данных и правомерность доступа, затем поэтапно возобновляйте работу сервиса, наблюдая за журналами репозитория, публикации, доступа к облачным ресурсам и конечных устройств.

Ожидаемый результат

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

Ограничения и основание проверки

Это предложение по реагированию, составленное на основе источников, а не процедура восстановления, проверенная на практике. Отсутствие индикаторов не доказывает, что кражи или выполнения дополнительного кода не было. Одно удаление пакета не восстанавливает доверие. Меры против разрушительных механизмов закрепления зависят от конкретного инцидента; следуйте актуальным инструкциям разработчика, продолжая срочную локализацию с помощью чистых средств администрирования.