Атака на цепочку поставок npm похитила облачные и CI-учётные данные
4 августа 2026 года экосистема npm столкнулась с одной из самых масштабных атак на цепочку поставок за последнее время. Вредоносный код был обнаружен как минимум в десяти пакетах из пространств имён keyv и cacheable, совокупно набиравших миллионы еженедельных загрузок. Злоумышленник получил контроль над учётными записями мейнтейнеров и использовал доверенные механизмы публикации npm для распространения троянизированных версий, нацеленных на сбор конфиденциальных учётных данных.
Как работала двухэтапная вредоносная схема
Техническая архитектура атаки опиралась на двухступенчатый payload. Первый этап внедрялся через хук preinstall (файл setup.mjs), который автоматически запускался при установке любого заражённого пакета. Загрузчик определял платформу, скачивал автономную среду выполнения Bun и готовил систему ко второму этапу.
Второй этап — обфусцированный скрипт Math_Symbol.js — применял сложные техники кодирования, чтобы скрыть своё истинное назначение. После расшифровки payload активно опрашивал окружение и собирал секреты из целого ряда источников:
- метаданные облачных инстансов;
- учётные данные AWS, Azure, GCP;
- токены OIDC для GitHub Actions;
- данные других CI-систем и переменных окружения.
Для эксфильтрации злоумышленник использовал специально созданные репозитории GitHub, а также адреса, разрешаемые через DNS, — это позволяло избежать фиксированных серверов управления и усложняло блокировку трафика.
Самораспространение и контроль над инфраструктурой
Скомпрометированные учётные записи давали атакующему возможность манипулировать историей пакетов в реальном времени. Вскоре после первоначальной компрометации ключевых пакетов были выявлены дополнительные затронутые модули, выходящие за пределы keyv и cacheable. Злоумышленник переупаковывал другие npm-пакеты, обеспечивая самораспространение через полностью легитимный процесс публикации, что делало атаку особенно трудно обнаруживаемой.
Рекомендации для разработчиков и служб безопасности
Для минимизации последствий специалисты рекомендуют незамедлительно выполнить следующие шаги:
- Зафиксировать версии пакетов. Откатить зависимости npm до проверенных версий, предшествующих компрометации, и запретить автоматическое обновление из поражённых учётных записей — конвейер npm не гарантирует целостность исходного кода, если источник уже троянизирован.
- Ротировать все учётные данные. Отозвать и сменить любые секреты, которые могли быть доступны с хостов, где устанавливались заражённые пакеты.
- Провести аудит учётных записей. Проверить аккаунты npm и GitHub на предмет несанкционированного доступа, подозрительной активности и неожиданных репозиториев.
- Искать артефакты атаки. Мониторить подозрительные версии пакетов, аномальное поведение при доступе к файлам и метаданным, специфичные для данного инцидента индикаторы компрометации.
Уроки для цепочек поставок: почему provenance — не просто модное слово
Инцидент наглядно показал, что доверие к имени пакета и репутации мейнтейнера больше не может быть единственной линией защиты. Тщательная проверка происхождения (provenance) каждой сборки и внедрение механизмов верификации целостности на уровне реестра — критически важные условия для снижения постоянных рисков, связанных с уязвимостями в цепочке поставок. Пока злоумышленники продолжают эксплуатировать человеческий фактор и автоматизированные конвейеры публикации, индустрия должна двигаться к моделям нулевого доверия на всех этапах жизненного цикла зависимостей.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.



