Атака на Axios в 2026 году: почему чистое дерево зависимостей не оправдывает сборочный runner

Что произошло и что добавляет этот анализ

31 марта 2026 года через скомпрометированную учётную запись сопровождающего опубликовали вредоносные версии axios 1.14.1 и 0.30.4. В разборе сопровождающего названа добавленная зависимость plain-crypto-js@4.2.1 и описана доставка вредоносного ПО для нескольких платформ. [1] Анализ Microsoft связывает исполнение с установкой пакетов, а не изменением обычной исходной логики HTTP-клиента. [2]

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

Установка — граница исполнения, даже без импорта

JFrog указывает на хук postinstall; для исполнения импорт из приложения не требовался. [3] Для проверки это означает, что достижимость из исходного кода и достижимость при установке нужно исследовать отдельно. Проверка только того, импортирует ли приложение подозрительную библиотеку, может пропустить этап, на котором машина оказалась под угрозой.

Схема ниже — концептуальная модель переходов доверия, а не утверждение о компрометации всех перечисленных систем. Перечислите установщики, настройки пакетных менеджеров, скрипты, плагины и сборочные инструменты, запускаемые на агентах. Отделите установку от задач с полномочиями развёртывания или подписи. Это важно и для мобильного или настольного продукта, в поставляемом приложении которого вообще нет кода Axios.

registry publication
  -> dependency resolution
  -> package installation
  -> lifecycle-script execution
  -> runner identity and reachable credentials
  -> repositories, signing systems, deployments

The package tree is one evidence source.
The execution history is a different evidence source.

Почему чистое текущее дерево не исключает прошлое вредоносное исполнение

JFrog сообщает об удалении загрузчика и замене его манифеста после исполнения. [3] Следовательно, последующая проверка файлов может дать неполную историческую картину. Это не означает бесполезность всех сканеров: проверка текущего состояния и расследование истории исполнения отвечают на разные вопросы.

До пересборки сохраните журналы установки, ревизии lockfile, хеши кэшированных пакетов, телеметрию runner, сетевые записи и метаданные выпуска. Отсутствие совпадений в сегодняшней рабочей копии не устанавливает, что вчера установил runner. И наоборот: вредоносная версия в lockfile подтверждает разрешение зависимости, но не автоматически успешное исполнение полезной нагрузки или кражу данных. Формулируйте наблюдения на уровне, который допускают доказательства.

Исследуйте полномочия во времени, а не только имена переменных окружения

OpenAI сообщила об исполнении вредоносного Axios в процессе подписи приложений и предупредительной замене сертификата, не обнаружив доказательств компрометации пользовательских данных или изменения ПО. [4] Это показывает, почему подверженность нужно оценивать в точных границах, а не превращать её в необоснованный заголовок об утечке. Расследование должно различать доступные процессу ресурсы и то, чем атакующий действительно воспользовался.

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

Три состояния доказательств вместо бинарного «затронут»

Первое состояние — доказательство разрешения зависимости: вредоносная версия есть в записи установки, lockfile или артефакте пакета. Второе — доказательство исполнения: сработал lifecycle-хук, дочерний процесс или соответствующее сетевое действие. Третье — доступ к полномочиям: исполнение могло получить конкретные учётные данные или выполнить привилегированную операцию. Это предлагаемые состояния триажа, а не официальная классификация инцидента; уверенность по ним в одном расследовании может различаться.

Если журналов нет, сохраняйте значение «неизвестно». Отсутствие телеметрии не доказывает, что скрипт не исполнялся. Доступность учётных данных тоже не доказывает их использование атакующим. Зафиксируйте актив, временной интервал, доказательства и неопределённость, затем поручите ответственному за инцидент выбрать соразмерные меры сдерживания. Это полезнее, чем объявлять всю организацию безопасной или взломанной по одному результату grep.

asset_id | workflow_run | install_time_utc
package_name | package_version | package_digest
script_policy | execution_evidence | network_evidence
identity | credential_scope | credential_lifetime
artifact_digest | downstream_destination
containment | credential_revocation | rebuild_evidence

Восстановление требует доказательств по узлу, идентичностям и артефактам

Microsoft рекомендует исследовать затронутую установочную активность и менять учётные данные, доступные скомпрометированным системам. [2] Удаление зависимости исправляет состояние пакетов; оно не отзывает украденный токен и не устанавливает чистоту runner. Согласуйте сдерживание и сохранение доказательств, отзывайте раскрытый доступ из доверенного окружения и, когда этого требует расследование, пересоздавайте затронутые среды исполнения из доверенной основы.

Проследите выпуски из затронутого workflow до хешей артефактов, событий подписи и точек распространения. Определите результаты, требующие отзыва, проверки или чистой пересборки. Убедитесь, что старые учётные данные не работают, новые обладают ожидаемым объёмом прав, а новая сборка не разрешает вредоносные пакеты. Сохраните доказательства фактического дерева установки и исполненного workflow вместо принятия исправленного package.json за полный отчёт о восстановлении.

Поставьте контроль на каждом переходе доверия

Версионируемый lockfile и неизменяемый режим установки помогают воспроизводить разрешение зависимостей, но не делают доверенным закреплённый вредоносный пакет. Минимальный возраст релиза даёт время для исследования, но не доказывает безопасность старых пакетов. Provenance связывает артефакт с издателем и сборкой, однако авторизованный скомпрометированный workflow всё равно может создать нежелательный артефакт. Используйте каждую меру для конкретной гарантии, не подменяя ею остальные.

Рекомендации Google по цепочкам поставок включают изолированные runner, ограничения lifecycle-скриптов и короткоживущие удостоверения рабочих нагрузок. [5] Проверяйте значения по умолчанию у реально развёрнутой версии пакетного менеджера: версии не обязательно одинаково запускают или блокируют скрипты. Явно разрешайте необходимые сборочные хуки, минимизируйте учётные данные при установке, ограничивайте исходящий трафик и проверяйте, что запрещённый хук действительно не исполняется. Настройка становится границей безопасности только после проверки её поведения.

Какие вопросы о восстановлении должен задать владелец продукта

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

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