SAP npm-пакеты пострадали от Bun-based stealer

Что произошло#

Snyk сообщает, что 29 апреля 2026 года злоумышленники опубликовали вредоносные версии четырех npm-пакетов из экосистемы SAP Cloud Application Programming Model. Среди затронутых пакетов — SAP CAP database service packages в пространстве @cap-js, а также Cloud MTA Build Tool package, который используется для сборки deployment archives для SAP cloud applications.

Скомпрометированные релизы содержали hook, который загружал Bun JavaScript runtime из GitHub Releases. Затем Bun использовался для запуска обфусцированного credential stealer размером около 11,6 MB. Payload идентифицировал себя жестко заданной фразой: “A Mini Shai-Hulud has Appeared.”

Эта фраза была не просто украшением. По данным Snyk, скомпрометированные машины разработчиков создавали публичные GitHub dead-drop repositories под их собственными аккаунтами, и эти репозитории были видны через GitHub search results в реальном времени. Кампания повторно использовала имя Shai-Hulud и схему tagging, замеченные в более ранних npm supply-chain attacks.

Snyk опубликовала advisories для скомпрометированных релизов, включая advisories для @cap-js/db-service, @cap-js/sqlite и @cap-js/postgres. В исходном материале также говорится, что на момент публикации было обнаружено четыре вредоносные версии in wild, а релизы были опубликованы в коротком UTC-окне 29 апреля.

Важное ограничение: в публичном отчете Snyk говорится, что на момент публикации только четыре изначально скомпрометированных пакета были замечены с вредоносным payload. Это не делает инцидент безвредным. Это означает, что наблюдаемое распространение было уже, чем в предыдущих волнах Shai-Hulud на момент публикации статьи.

Почему это важно#

Этот инцидент ударил по developer infrastructure, а не по end-user application. Именно в этом суть.

Затронутые пакеты находятся в цепочке разработки SAP-приложений. Разработчики и CI systems могут устанавливать их в рамках обычной сборки. Если вредоносный релиз запускается во время install или build steps, злоумышленник оказывается рядом с credentials, package tokens, repository access и deployment paths.

Поведение payload, описанное Snyk и другими исследователями, сфокусировано на credentials. Он использует Bun для выполнения крупного обфусцированного stealer. Deobfuscation от StepSecurity, на которую ссылается Snyk, выявила рабочий код npm self-propagation. Payload собирает npm tokens, проверяет их через npm registry token endpoints, проверяет write scope, перечисляет доступные пакеты, встраивает себя в копию tarball и публикует напрямую в npm registry, не вызывая npm CLI.

Именно последняя часть повышает уровень риска. Даже если на момент публикации не было обнаружено пятого зараженного пакета, worm-capable code, по сообщениям, присутствовал и был рабочим. Разница между “capable” и “observed spreading” важна, но защитники не могут считать такую возможность гипотетической, если deobfuscated code показывает путь атаки.

Кампания также показывает, почему безопасность package manager нельзя сводить только к dependency pinning. Первоначальная компрометация, судя по всему, связана с release workflow. Согласно публичному заявлению SAP, процитированному Snyk, unauthorized actor отправил вредоносные commits, которые перехватили release workflow и запустили несанкционированные npm publications. SAP заявила, что злоумышленник смог опубликовать скомпрометированные пакеты, потому что workflow имел publish permissions без manual approval gate.

Это провал release governance. Он превращает CI/CD в машину подписи и публикации для злоумышленника.

Чем это отличается от более ранних волн Shai-Hulud#

Имя Shai-Hulud уже связывали с крупными npm supply-chain incidents. Snyk отмечает более ранние волны в сентябре 2025 года и ноябре 2025 года; поздняя волна затронула сотни пакетов, включая пакеты, связанные с известными компаниями. Kaspersky также публиковала независимый technical analysis этих предыдущих волн.

Этот случай апреля 2026 года заимствует ту же naming convention и dead-drop style, но публичные evidence, описанные Snyk, указывают на меньший observed blast radius на момент публикации.

Разница не в том, что эта кампания безобидна. Разница в том, что пока она выглядит более узкой. Формулировка Snyk осторожна: только четыре изначально скомпрометированных пакета были замечены in wild с payload, тогда как static analysis StepSecurity обнаружил реальную self-publishing capability.

Это различие важно для реагирования. Командам не стоит заявлять о массовом ecosystem-wide spread без появления доказательств. Но им также не стоит игнорировать инцидент только потому, что число наблюдаемых пакетов было небольшим. Worm-capable npm stealer внутри enterprise development tooling — уже достаточная причина для немедленных проверок.

Статус реагирования и устранения#

Snyk сообщает, что SAP отреагировала, опубликовав чистые post-incident versions как минимум для части затронутых пакетов с использованием GitHub Actions OIDC trusted publishing. В исходном материале говорится, что после инцидента SAP поставила npm publication за manual approval environment.

Некоторые вредоносные релизы были удалены или заменены исправленными версиями, но для защитников это не закрывает инцидент автоматически. Если пакет уже был установлен в developer workstation или CI runner, риск связан не только с текущим состоянием npm registry. Риск связан с тем, что payload мог уже выполниться и забрать secrets.

Практический вывод#

Если в вашей организации используются SAP CAP, @cap-js/*, Cloud MTA Build Tool или связанные SAP npm dependencies, проверьте не только lockfiles. Проверьте фактические install/build logs за 29 апреля 2026 года и последующие дни, локальные npm cache, CI artifacts и образы runner’ов. Ищите установки подозрительных версий, загрузки Bun из GitHub Releases, появление фразы “A Mini Shai-Hulud has Appeared” и создание неожиданных публичных GitHub repositories под аккаунтами разработчиков или service accounts.

Минимальный response plan:

1. Найти проекты, где используются затронутые SAP npm-пакеты, особенно @cap-js/db-service, @cap-js/sqlite, @cap-js/postgres и Cloud MTA Build Tool.
2. Сверить установленные версии с Snyk advisories и npm metadata.
3. Пересобрать affected environments из чистого состояния, а не переиспользовать старые CI runners или developer caches.
4. Отозвать и перевыпустить npm tokens, GitHub tokens, CI secrets, cloud deployment credentials и любые credentials, доступные во время install/build.
5. Проверить npm account activity: публикации, token usage, package ownership changes, новые versions и unusual registry traffic.
6. Проверить GitHub audit logs: push events, repository creation, workflow runs, environment approvals, OIDC token issuance и suspicious commits.
7. Включить trusted publishing/OIDC для npm, убрать long-lived publish tokens, ограничить publish permissions и поставить manual approval gate для release workflows.
8. Заблокировать или алертить неожиданные runtime downloads во время package install, особенно загрузку Bun, Node binaries или executables из GitHub Releases.

Главный урок: pinning помогает против случайного обновления, но не спасает, если release workflow сам становится каналом публикации вредоносного пакета. Для npm supply chain нужны короткоживущие credentials, trusted publishing, ручное подтверждение релизов, изоляция CI и мониторинг postinstall/build behavior.