Компрометация Bitwarden CLI на npm: кража SSH-ключей

По состоянию на 26 апреля 2026 года история с Bitwarden выглядит не как «взломали менеджер паролей целиком», а как показательный удар по цепочке поставки инструментов разработки. Bitwarden подтвердила, что через npm в течение короткого окна распространялся вредоносный @bitwarden/cli@2026.4.0. Ключевая оговорка сразу: компания не видит признаков доступа к пользовательским vault, боевым данным или боевым системам. Проблема была в канале доставки CLI через npm.

Но успокаиваться на этой формулировке рано. Исследователи Socket и JFrog пишут, что вредоносный пакет искал не только SSH-ключи, npm- и GitHub-токены, но и конфигурационные файлы AI-инструментов и MCP. В подтверждённых списках фигурируют, например, ~/.claude.json, ~/.claude/mcp.json и ~/.kiro/settings/mcp.json. Иначе говоря, атака была нацелена не на «Bitwarden как хранилище паролей», а на рабочие машины разработчиков, CI и агентные контуры, где рядом лежат ключи, токены и настройки локальных помощников.

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

Что подтвердил Bitwarden

Официальное заявление Bitwarden появилось 23 апреля 2026 года. В нём компания пишет, что вредоносный пакет распространялся через npm для @bitwarden/cli@2026.4.0 между 5:57 PM и 7:30 PM по восточному времени 22 апреля 2026 года. После обнаружения Bitwarden отозвала скомпрометированный доступ, пометила вредоносный релиз как deprecated и начала восстановительные действия.

Самое важное для точности: Bitwarden отдельно пишет, что не нашла доказательств доступа к пользовательским vault, боевым данным или боевым системам. Компания также подчёркивает, что инцидент не затронул целостность легитимного кодового дерева Bitwarden CLI. Это не взлом всей платформы Bitwarden и не компрометация содержимого хранилища паролей у всех пользователей.

Ограничение по каналу поставки тоже важно. В справке Bitwarden CLI перечислены несколько способов установки: npm, нативные исполняемые файлы, Chocolatey, snap и Flatpak. Из официального заявления следует, что проблема была именно в npm-доставке конкретной версии CLI, а не во всех формах распространения инструмента.

Для пострадавших Bitwarden рекомендует удалить версию 2026.4.0, очистить npm-кэш, временно отключить install scripts, проверить дополнительные индикаторы компрометации и после очистки перейти на Bitwarden CLI 2026.4.1.

Как нормальный CLI превратили в стилер

Дальше начинается самая показательная часть истории. По разбору JFrog, вредоносный пакет сохранял привычные метаданные Bitwarden, но менял точки входа: и preinstall, и бинарник bw были перенаправлены на загрузчик bw_setup.js. Это плохой сценарий именно потому, что со стороны пользователя всё ещё выглядело как установка официального CLI.

Загрузчик проверял, установлен ли Bun. Если нет, он скачивал Bun 1.3.13 с GitHub Releases и уже через него запускал обфусцированный файл bw1.js. Такой ход делает атаку заметно неприятнее обычного постинсталляционного скрипта на Node.js: оператор уводит выполнение в побочный рантайм и получает более гибкую площадку для пейлоуда.

JFrog описывает два канала эксфильтрации. Основной шёл на audit.checkmarx[.]cx, который исследователи связывают с более широкой кампанией. Если этот путь не срабатывал, пейлоуд переключался на GitHub: искал служебные токены, создавал новые публичные репозитории в аккаунте жертвы и складывал туда зашифрованные результаты. Это уже не «скрипт украл пару токенов», а полноценная логика для обхода отказов и продолжения атаки.

Socket дополняет картину важной деталью: у пейлоуда совпадают инфраструктура и часть техники с более ранним инцидентом Checkmarx. В их разборе фигурируют тот же endpoint audit.checkmarx[.]cx/v1/telemetry, та же схема обфускации с __decodeScrambled и тот же общий паттерн: кража секретов, злоупотребление GitHub и попытка размножить компрометацию дальше по цепочке.

Ещё одна любопытная деталь из Socket: вредоносный код тихо завершался на системах, где локаль начиналась с ru. Это не меняет практических рекомендаций для защиты, но показывает, что перед нами не примитивный grab-all стилер, а достаточно осознанный операторский код с выбором жертв и механизмами самоконтроля.

Что именно крали и почему в списке оказались AI-конфиги

Если смотреть на список целей, становится ясно, что злоумышленников интересовал не Bitwarden как бренд, а рабочее окружение разработчика. JFrog перечисляет среди мишеней SSH-материалы, .git-credentials, .npmrc, .env, shell history, AWS credentials, GCP credential storage и токены GitHub. Bitwarden в официальном заявлении тоже рекомендует ротировать не только API-токены, но и SSH-ключи.

Отдельно бросается в глаза список AI- и MCP-конфигураций. В разборе JFrog названы ~/.claude.json, .claude.json, ~/.claude/mcp.json, ~/.kiro/settings/mcp.json и их локальные варианты в проекте. Для 2026 года это уже не экзотика. В таких файлах могут лежать адреса MCP-серверов, токены, кастомные настройки доступа, локальные пути и другие куски контекста, которые помогают атакующему понять, как устроен рабочий процесс команды.

Именно поэтому этот инцидент стоит читать рядом с нашей историей про атаки на разработчиков через тестовые задания. Там проблема была в том, что агенту или IDE дают слишком широкий контур доверия. Здесь удар наносится на шаг раньше: компрометируется сам инструмент, который попадает в этот контур.

Socket также пишет, что пейлоуд пытался вытаскивать секреты из GitHub Actions Runner и повторно использовать их для дальнейшего движения по инфраструктуре. Это важный сдвиг. Атака ориентирована не только на ноутбук разработчика, но и на CI-среду, где один удачный токен открывает дорогу к npm-публикации, облачным секретам и другим репозиториям.

Почему это не «взлом Bitwarden», а симптом более широкой болезни

Главная ловушка в обсуждении этого кейса — делать из него новость про то, что «взломали Bitwarden». SEO brief тут справедливо жёсткий: это не та формулировка, которую можно бездумно выносить в H1. Официальное заявление Bitwarden и технические разборы исследователей сходятся в другом: была скомпрометирована доставка конкретной версии CLI через npm, а не весь менеджер паролей и не все пользовательские данные.

Но и в обратную сторону уходить не надо. Формулировка «затронут только npm-канал» звучит успокаивающе, однако для многих команд именно npm-канал и есть рабочая поставка инструмента. Если CLI тянут в CI, во временные сборочные среды, в локальные bootstrap-скрипты и внутренние докер-образы, такой «ограниченный канал» на практике оказывается дорогой к самым чувствительным секретам.

Здесь история напрямую стыкуется с мартовским инцидентом Checkmarx. В официальном апдейте от 23 марта Checkmarx сообщила о вредоносных GitHub Actions и OpenVSX-плагинах, а среди рекомендаций перечислила ротацию GitHub-, AWS-, GCP-, Azure-credential'ов, SSH-ключей и Docker-логинов. Bitwarden в своём заявлении прямо связывает инцидент CLI с более широкой Checkmarx supply chain campaign. Иными словами, для разработчиков это уже не серия случайных эпизодов, а повторяющийся шаблон: атака идёт туда, где пайплайн сам умеет публиковать код и видит секреты.

Ровно поэтому материал стоит перелинковать с кейсом LiteLLM на PyPI. Там злоумышленники тоже охотились не за одним сервисом, а за рабочими окружениями и инфраструктурой вокруг ИИ-инструментов. Разница только в экосистеме: тогда это был Python и PyPI, сейчас — npm и CLI вокруг менеджера паролей.

Что делать, если у вас был установлен @bitwarden/cli@2026.4.0

Практическая часть у этого кейса довольно жёсткая. Если версия 2026.4.0 ставилась из npm в окно атаки, безопаснее считать систему скомпрометированной, а не надеяться, что «в этот раз пронесло».

1. Удалите пакет: npm uninstall -g @bitwarden/cli.
2. Очистите npm-кэш: npm cache clean --force.
3. На время очистки отключите install scripts: npm config set ignore-scripts true.
4. Проверьте рабочие каталоги на артефакты вроде bw_setup.js, bw1.js, скачанного Bun и строк audit.checkmarx.cx, LongLiveTheResistanceAgainstMachines, beautifulcastle.
5. Ротируйте GitHub PAT, npm-токены, SSH-ключи, облачные ключи и секреты из переменных окружения. Для AWS, Azure и GCP стоит отдельно проверить журналы доступа к secret stores.
6. Просмотрите GitHub activity и GitHub Actions: новые ветки, странные workflow runs, неожиданные публичные репозитории и подозрительные артефакты.
7. После очистки переходите на Bitwarden CLI 2026.4.1 или на альтернативный проверенный способ установки из официальной документации.

Если Bitwarden CLI использовался в CI, масштаб ответа должен быть выше. Тут мало переустановить утилиту на одной машине. Безопаснее считать потенциально раскрытыми секреты, к которым runner имел доступ во время установки или исполнения, и проверять, не были ли они уже использованы для публикации других пакетов, создания workflow или доступа к облаку.

Что стоит изменить в процессах после этого инцидента

Первый вывод простой: инструменты безопасности и разработки больше нельзя считать нейтральной инфраструктурой. Если инструмент участвует в публикации пакета, видит токены npm, умеет читать GitHub Actions secrets или стоит в CI рядом с облачными credential'ами, он уже находится в зоне повышенного риска. История с Vercel и сторонним AI-инструментом показывала похожую мысль с другой стороны: вспомогательный сервис быстро превращается во вход в инфраструктуру, если ему дать лишние права.

Второй вывод менее очевиден, но важнее: командам нужно отделять «удобный способ установки» от «доверенный способ поставки» для чувствительных CLI. Это редакционный вывод, а не цитата Bitwarden. Официальная документация сама показывает, что у Bitwarden CLI есть нативные исполняемые файлы без зависимости от Node.js и npm. Для части команд это не универсальное лекарство, но как минимум повод пересмотреть, какие инструменты действительно стоит тянуть из публичного registry в каждый CI-run.

Третий вывод касается агентной разработки. Конфиги Claude, Kiro и MCP-пути попали в список целей не случайно. Если на машине уже живут локальные агенты, их настройки, токены и маршруты к инструментам становятся частью attack surface. В 2026 году секреты лежат не только в .env, но и в файлах, которые вчера ещё считались «просто настройками помощника».

Главный вывод

Кейс Bitwarden стоит запомнить не как сенсацию про «взлом паролей», а как ясный сигнал о новой норме. Популярный CLI может выглядеть легитимно, ставиться из привычного реестра пакетов и при этом в момент установки превращаться в инструмент кражи SSH-ключей, GitHub- и npm-токенов, облачных секретов и AI-конфигов.

Самая опасная часть здесь не бренд Bitwarden. Самая опасная часть — доверие к рабочей цепочке, где package registry, CI, секреты и агентные инструменты живут в одном контуре. Если этот контур скомпрометирован, злоумышленнику уже не нужно «взламывать прод» классическим способом. Достаточно попасть в тот момент, когда разработчик или пайплайн сами ставят нужный пакет.

Читайте также

• Взлом LiteLLM на PyPI: как хакеры превратили ИИ-библиотеку в кражу паролей
• Взлом Vercel: AI-инструмент стал входом в инфраструктуру
• ИИ-агенты атакуют разработчиков через тестовые задания

Источники и проверка фактов

• Bitwarden Community: Bitwarden Statement on Checkmarx Supply Chain Incident, опубликовано 23 апреля 2026 года, проверено 26 апреля 2026 года.
• Bitwarden Help Center: Password Manager CLI, проверено 26 апреля 2026 года.
• JFrog Security Research: TeamPCP Campaign Spreads to npm via a Hijacked Bitwarden CLI, опубликовано 23 апреля 2026 года, проверено 26 апреля 2026 года.
• Socket: Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign, опубликовано 23 апреля 2026 года, проверено 26 апреля 2026 года.
• Checkmarx: Security Update, March 23, обновлено 2 апреля 2026 года, проверено 26 апреля 2026 года.
• BleepingComputer: Bitwarden CLI npm package compromised to steal developer credentials, опубликовано 23 апреля 2026 года, проверено 26 апреля 2026 года.