Атака на цепочку поставок npm в Keyv затронула 2 млрд установок

Злоумышленник во вторник взломал учетную запись GitHub разработчика, поддерживающего keyv — небольшую библиотеку хранилища «ключ-значение», которую npm обслуживает примерно 127 миллионов раз в неделю. Всего за несколько часов на npm появились скомпрометированные версии keyv и связанных с ней кэширующих пакетов, содержащие червя для кражи учетных данных. К полудню охранная фирма Aikido насчитала не менее 868 скомпрометированных пакетов в 1381 версии, суммарно генерирующих более двух миллиардов загрузок в месяц, и этот показатель продолжает расти. Компания JFrog независимо друг от друга отследила эту кампанию более чем по 400 пакетам и 1700 скомпрометированным версиям.

Больше всего каждую службу безопасности должно беспокоить вовсе не количество загрузок. Дело в документации. Первые зараженные релизы поставлялись с действительными цифровыми подписями происхождения (provenance) — криптографическими подтверждениями, которые индустрия создала для доказательства того, что пакет поступает из заявленного источника. Червь не подделывал эту подпись. Он заслужил ее так же, как это делает легитимный релиз.

Днем ранее компания CrowdStrike опубликовала свой отчет об охоте на угрозы за 2026 год (2026 Threat Hunting Report), в котором предсказала именно такой формат атаки. В разделе под названием «Эволюция атак на цепочку поставок программного обеспечения» («Software Supply Chain Attacks Evolve») в качестве основных целей, по которым злоумышленники теперь бьют напрямую, названа сама экосистема разработчиков: реестры пакетов, конвейеры непрерывной интеграции, реестры контейнеров и расширения, загружаемые разработчиками в свои редакторы кода. В отчете пакеты npm ставятся в центр этого сдвига — с ними связано 87% угроз в реестрах вредоносного ПО, отслеживаемых CrowdStrike в первой половине года. Червь в keyv превратил этот вывод в реальный инцидент менее чем за 24 часа.

Для директоров по информационной безопасности (CISO) и архитекторов безопасности эти два события звучат как одно предупреждение. Сигналы доверия, встроенные в цепочку поставок ПО, могут быть удовлетворены злоумышленником, владеющим правильной учетной записью, а временной интервал между обнаружением и эксплуатацией сократился настолько, что ежемесячное устранение уязвимостей уже не помогает.

Как червь заслужил свое происхождение

Если проанализировать механизм атаки, становится понятно, почему подписи происхождения не помогли. Согласно анализу Aikido, злоумышленник отправил вредоносные файлы прямо в основную ветку каждого репозитория, контролируемого мейнтейнером, а затем немедленно выпустил новый релиз. Поскольку релиз запускался через собственный рабочий процесс (workflow) GitHub Actions мейнтейнера, npm сгенерировал для него легитимную аттестацию происхождения. Для любого проверяющего целостность цепочки поставок скомпрометированная сборка выглядела подлинной. Компания Wiz независимо подтвердила путь выпуска, а по одному из целевых путей, задокументированному JFrog, червь пошел еще дальше. В рамках выполнения GitHub Actions, привязанного к opensearch-js, он запросил OIDC-токен, обменял его на токен публикации и создал комплект Sigstore через Fulcio и Rekor, благодаря чему вредоносный архив нес происхождение, сгенерированное из контекста доверенного рабочего процесса.

Превращению взлома одной учетной записи в масштабный инцидент во всем реестре способствовало быстрое распространение. Как только зараженный пакет попадал в среду разработчика или на сборочный сервер (build runner), его полезная нагрузка собирала все доступные учетные данные, а затем использовала найденные токены публикации npm для внедрения бэкдоров в другие пакеты, контролируемые жертвой. Каждый скомпрометированный мейнтейнер становился невольным узлом распространения: специалисты Aikido наблюдали, как каждые несколько минут появлялись десятки новых зараженных пакетов. Вредоносное ПО передавало украденные секреты в публичные репозитории GitHub с меткой «Shai-Hulud: Here We Go Again» — это подпись, давшая название всей кампании.

Масштаб поражения вышел далеко за рамки малоизвестных утилит. Поскольку keyv выступает в качестве транзитивной зависимости для многих популярных инструментов, червь проник по этим цепочкам в пакеты из корпоративных областей имен (scopes) npm. Среди подтвержденных жертв оказались релизы, связанные с Deliveroo, Qlik и Picsart. Разработчики в этих компаниях никогда не устанавливали keyv специально. Они зависели лишь от компонента, который, в свою очередь, зависел от него на много уровней ниже в дереве зависимостей, которое никто не проверяет вручную.

Извлекатели учетных данных внутри полезной нагрузки показывают, за чем именно охотились злоумышленники, и это явно были не библиотеки кэширования. Компания JFrog, отслеживавшая взлом keyv и cacheable, а также Wiz зафиксировали сбор вредоносным ПО ключей облачного доступа, секретов CI и токенов для аутентификации в производственной инфраструктуре. Компрометация пакетов была лишь средством передвижения, а конечной целью всегда оставалось облако. По данным CrowdStrike, в первой половине 2026 года преступная активность, нацеленная на облачные среды, выросла на 171%, и компрометация цепочки поставок — один из путей, подпитывающих этот рост.

Целью стали собственные инструменты разработчика

Простой кражей дело не ограничилось: червь также закрепился на рабочих местах разработчиков. Специалисты Wiz выяснили, что вредоносное ПО сбрасывает полезные нагрузки для сохранения доступа (persistence payloads) в два каталога на зараженных машинах: один предназначен для Visual Studio Code, а второй называется .claude (рабочий каталог ИИ-агента Claude Code от Anthropic). Файлы настройки, размещенные там, позволяют полезной нагрузке запускаться не только в момент установки, но и когда разработчик открывает зараженный проект в своем редакторе или начинает сеанс работы с ИИ-помощником. Это именно та экосистема разработчиков, о которой говорила CrowdStrike: удар пришелся точно по редактору и ИИ-помощнику, которым разработчик доверяет больше всего и которые проверяет реже всего.

Исправление не стоит ничего

Один элемент контроля мог бы смягчить удар червя, и он не стоит ничего. Адам Мейерс (Adam Meyers), возглавляющий операции по противодействию противникам в CrowdStrike, изложил это в предварительном интервью под эмбарго. «Обеспечьте безопасность цепочки поставок программного обеспечения, — сказал он. — Простые вещи, такие как запрет любому вашему инструменту подтягивать самые свежие зависимости; лучше использовать зависимости недельной давности». Задержка здесь — ключевой момент. «У вас все равно будут достаточно актуальные компоненты, но вы избежите риска скачать то, что было обновлено несколько минут назад и во что уже зашили какую-то вредоносную утилиту». Релиз, задержанный на неделю, дает экспертному сообществу время обнаружить заражение, которое в противном случае дошло бы до каждой подчиненной сборки за считанные минуты.

Эта рекомендация не гипотетична. В феврале 2026 года npm выпустила версию CLI 11.10.0 с функцией под названием min-release-age. Пакетный менеджер pnpm реализовал это на пять месяцев раньше под названием minimumReleaseAge. Любая из этих функций позволяет команде отклонять любые версии пакетов, опубликованные позже заданного порога. Червь в keyv — главный аргумент в пользу их включения.

Мейерс дополняет период ожидания (cooldown) второй дисциплиной: исправляйте в первую очередь то, что эксплуатируют злоумышленники. «Вам нужно сосредоточить устранение уязвимостей и патчинг вокруг эксплойтов, которые уже известны атакующим», — заявил он в интервью VentureBeat. Он указал на ресурс, который большинство команд недоиспользует. «CISA здесь, в Соединенных Штатах, выпускает каталог известных эксплуатируемых уязвимостей (Known Exploited Vulnerability Catalog)», который еженедельно обновляется за счет брешей, подтвержденных в ходе активных атак, поддерживается государством и предоставляется бесплатно. «Если вы в первую очередь устраните эти уязвимости, вы, вероятно, будете в большей безопасности».

Мейерс привел точные цифры, отражающие проблему скорости — эти данные не вошли в опубликованный отчёт. За весь 2025 год в качестве CVE было зарегистрировано около 48 200 уязвимостей. Когда он проверял статистику за неделю до брифинга, в 2026 году этот показатель уже достиг 43 000.

Такой объем разрушает месячные циклы установки патчей. «Они не могут работать в рамках 30-дневных окон исправления, — сказал он VentureBeat. — Как только уязвимость обнаруживается, нужно сразу переходить к патчингу или минимизации этой конкретной проблемы». Отчет CrowdStrike связывает эту тенденцию с выводом о том, что 88% зафиксированных атак на уязвимости с общедоступными доказательствами концепции (PoC) происходили в течение 48 часов после публикации кода.

GitHub защитил половину проблемы

Компания GitHub, владеющая npm, прошлый год потратила на укрепление безопасности реестра именно против этого класса атак. Платформа сделала двухфакторную аутентификацию обязательной для публикации, аннулировала старые бессрочные токены доступа и добавила функцию доверенной публикации (trusted publishing), позволяющую сборочным системам выполнять развертывание без хранения учетных данных. Затем в npm версии 12, выпущенной в середине 2026 года, было изменено самое важное значение по умолчанию. Хуки preinstall, install и postinstall, на которые полагается большинство вредоносных программ из реестров для выполнения кода в момент попадания пакета в систему, теперь требуют явного подтверждения.

Это изменение имеет прямое отношение к данной ситуации, поскольку червь keyv запускается через preinstall-скрипт, и npm 12 работает в обе стороны. Компания JFrog подтвердила, что в npm 12 или более новых версиях, где хуки установки по умолчанию отключены, вредоносное ПО не запускается во время установки. При этом каждая организация, все еще использующая старые версии npm (а большинство предприятий обновляются медленно), осталась уязвимой.

Меры защиты GitHub укрепили не ту половину атаки: стало сложнее выполнять вредоносный пакет после его попадания в систему, но при этом сделано меньше для того, чтобы помешать злоумышленнику получить право на публикацию. Первопричиной остается захват учетных записей. Киран Радж (Kiran Raj), инженер по безопасности в компании Endor Labs, отметил, что наблюдал ту же закономерность — украденный и повторно использованный токен публикации npm. В большинстве случаев это был CI-токен или токен служебной учетной записи, похищенный со сборочного сервера, который сам по себе установил зараженную зависимость. Червю не нужно было обходить систему проверки происхождения. Ему требовался всего один набор действительных учетных данных, а остальное сделала собственная автоматизация публикации npm.

Аттестация происхождения отвечает на вопрос, поступил ли пакет из заявленного конвейера. Но она не отвечает на вопрос, должен ли был человек или токен, запустивший этот конвейер, иметь на это право. Управление идентификацией (кто может публиковать и к чему имеют доступ их учетные данные) остается более слабым звеном. CrowdStrike называет злоупотребление легитимными учетными записями разработчиков главной точкой входа для компрометации цепочки поставок. Мейерс выразился предельно ясно: «Они заходят под своими учетными записями, а не взламывают систему», — сказал он. Учетная запись мейнтейнера keyv была именно такой личиной, а механизм доверенной публикации сделал остальное за злоумышленника.

Почему совет директоров — на очереди

Давление с требованием исправить эту ситуацию будет исходить не только из отчетов об угрозах. Оно скоро придет через контракты. Кейн Макгладри (Kayne McGladrey), старший член IEEE, сообщил VentureBeat в эксклюзивном интервью, что предприятия начинают перекладывать обязательства по безопасности программного обеспечения на вендоров и мейнтейнеров в своих цепочках поставок. «Мы начнем видеть, как компании пытаются юридически переложить ответственность на другие стороны в своей цепочке поставок, — сказал он VentureBeat. — Мы используем ваши технологии, но мы хотим, чтобы вы отвечали за их безопасность».

Он сравнил это с тем, как Министерство обороны США заставило своих поставщиков повысить уровень кибербезопасности с помощью программы сертификации CMMC. «Добейтесь лучших результатов в области кибербезопасности, если хотите продавать нам свою продукцию». Для любой компании, выпускающей программное обеспечение на базе зависимостей с открытым исходным кодом, это превращает происхождение, идентификацию и дисциплину патчинга в юридические риски.

Что делать в понедельник утром

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

Количество пакетов отражает данные мониторинга Aikido и JFrog по состоянию на 4 августа и продолжало расти на момент сдачи материала в печать.

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