Взлом Bitwarden CLI через npm: 1,5 часа для кражи токенов, SSH‑ключей и конфигов ИИ‑ассистентов
-------------------------------------------------------------------
Если в ночь на 23 апреля вы устанавливали пакет `@bitwarden/cli` версии `2026.4.0` из npm‑реестра, все секреты на этой машине стоит считать скомпрометированными. Речь не о гипотетическом риске: в течение примерно полутора часов в официальном npm‑канале распространялась подменённая сборка Bitwarden CLI с интегрированным трояном.
Заражённая версия не трогала сами хранилища паролей Bitwarden, но массово вытаскивала с системы разработчика GitHub‑ и npm‑токены, SSH‑ключи, облачные креденшлы, секреты CI/CD и данные конфигураций популярных ИИ‑ассистентов для разработчиков.
Когда и что именно произошло
По данным независимых исследователей, 22 апреля 2026 года около 17:57 по времени Нью‑Йорка (00:57 МСК 23 апреля) в npm‑реестр была загружена версия `@bitwarden/cli@2026.4.0`, отличающаяся от легитимных сборок наличием дополнительного файла `bw1.js` и изменённым `package.json`.
В таком виде пакет пролежал в публичном реестре порядка 1 часа 33 минут - до примерно 19:30 по времени Нью‑Йорка (02:30 МСК), после чего был снят с публикации и помечен как небезопасный. Потенциально пострадали только те, кто успел:
1. установить именно версию `2026.4.0` из npm в этом временном окне;
2. запустить установку так, чтобы отработал preinstall‑скрипт.
Bitwarden официально признал инцидент, подчеркнув, что следов доступа к пользовательским хранилищам и продакшн‑инфраструктуре компании не выявлено. Отозваны скомпрометированные токены, вредоносный релиз объявлен устаревшим, для него будет заведён отдельный CVE.
Что крала вредоносная версия Bitwarden CLI
Троян в версии `2026.4.0` был ориентирован не на данные внутри самого Bitwarden, а на всё остальное ценное, что обычно хранится на машине разработчика. В зону риска попадали:
- GitHub‑токены (включая токены с правами на публикацию пакетов, репозитории, Actions и т.д.);
- npm‑токены разработчиков и организаций;
- содержимое директории `.ssh` - приватные SSH‑ключи, конфиги, known_hosts;
- файлы `.env` и аналогичные источники переменных окружения;
- история shell (bash, zsh и др.), которая часто содержит команды с секретами и урезанные токены;
- секреты и токены GitHub Actions;
- креденшлы облачных провайдеров (AWS, GCP, Azure и другие, если их конфиги были доступны);
- конфигурации и ключи ИИ‑ассистентов для разработки.
Отдельный интерес представляли ИИ‑инструменты, такие как Claude, Cursor, Codex CLI, Aider и Kiro: троян умел находить их конфиги и вынимать оттуда API‑ключи OpenAI, Anthropic и другие токены.
Пароли к хранилищу Bitwarden (vault) в этом инциденте не затрагивались: цель атаки - цепочка поставки через npm и окружение разработчика, а не сам менеджер паролей.
Как устроен троян: многоступенчатая схема через preinstall и Bun
Механика атаки была замаскирована под типичный npm‑функционал, но с несколькими важными хитростями.
1. Изменённый package.json
В вредоносной версии пакета в `package.json` был добавлен `preinstall`‑хук. Этот скрипт срабатывает ещё до фактической установки пакета и запуска основного кода, то есть защита, ориентированная на анализ содержимого установленной библиотеки, может даже не успеть вмешаться.
2. Запуск bw_setup.js
В `preinstall` прописан запуск вспомогательного скрипта `bw_setup.js`. Его задача - подготовить среду для исполнения основного вредоносного кода.
3. Подтягивание Bun как альтернативного рантайма
`bw_setup.js` проверяет, установлен ли на машине Bun - альтернативный JS‑рантайм. Если нет, он скачивает и устанавливает его, после чего использует Bun для запуска следующего этапа - обфусцированного загрузчика `bw1.js`.
Этот приём неслучаен. На большинстве рабочих машин разработчиков Bun по умолчанию отсутствует, а средства защиты, особенно корпоративные EDR‑системы, часто хуже профилированы на свежие бинарники, чем на стандартные npm‑скрипты и node.js. В результате подозрительная активность оказывается менее заметной.
4. Обфусцированный загрузчик bw1.js
Основной вредоносный функционал был спрятан в `bw1.js`. Там реализованы:
- сбор секретов и чувствительных файлов;
- шифрование собранных данных;
- их передача на внешние ресурсы;
- логика самораспространения через npm‑пакеты;
- отдельный модуль работы с конфигами ИИ‑ассистентов.
Каналы вывода данных и маскировка под Checkmarx
Собранная на машине жертвы информация перед отправкой шифруется алгоритмом AES‑256‑GCM, что усложняет детальный анализ уже выгруженных записей и делает сетевой трафик похожим на легитимный зашифрованный обмен.
Далее данные уходили по двум основным каналам:
1. Основной канал - псевдо‑телеметрия на домен, похожий на Checkmarx
Троян отправлял POST‑запросы на домен вида `audit.checkmarx.cx` по пути `/v1/telemetry`. Сам домен и путь подобраны так, чтобы напоминать легитимную инфраструктуру популярного security‑вендора. Для большинства инструментов мониторинга такой трафик выглядел как безобидная телеметрия от утилиты аудита к знакомому поставщику решений безопасности.
2. Резервный канал - GitHub‑репозитории жертвы
Если основной канал был недоступен или блокировался, малварь создавал в аккаунте жертвы публичные GitHub‑репозитории и выкладывал туда зашифрованный payload. В названиях репозиториев использовалась строка вида "Shai‑Hulud: The Third Coming" - отсылка к прошлогодней кампании атак на npm.
Такой подход особенно коварен:
- данные становятся доступны не только атакующему, но и любому, кто умеет массово сканировать публичные репозитории на предмет зашифрованных или структурно похожих данных;
- системы корпоративной защиты редко жёстко контролируют исходящий трафик к GitHub, считая его рабочим и необходимым для разработки.
Самораспространение: модуль‑червь для npm‑экосистемы
Собранными токенами дело не ограничивалось. Внутри трояна был реализован модуль, который, получив npm‑токен жертвы, опрашивал список пакетов, к публикации которых этот токен имеет доступ. Далее вредонос автоматически вносил в найденные пакеты изменения, аналогичные подменённому `@bitwarden/cli` - добавляя тот же payload и цепочку preinstall‑скриптов.
Такая техника превращает атаку в своеобразного червя уровня цепочки поставки:
- один скомпрометированный разработчик →
- заражённые его npm‑пакеты →
- следующая волна жертв - пользователи этих пакетов.
Исследователи, анализировавшие нагрузку, назвали этот компонент одним из наиболее полно реализованных supply chain‑пейлоадов для npm на сегодняшний день: он сочетает кражу секретов из разных источников, работу с облачной аутентификацией и функцию самораспространения.
Прицельный удар по ИИ‑ассистентам разработчиков
Отдельный фрагмент кода в трояне был заточен под конфиги ИИ‑ассистентов и инструментов для разработки. Он сканировал файловую систему и домашний каталог на предмет:
- конфигураций Claude, Cursor, Codex CLI;
- токенов Aider;
- параметров Kiro, использующего AWS;
- API‑ключей OpenAI и Anthropic, прописанных напрямую в конфигах или переменных окружения.
Интерес злоумышленников к этим данным объясним:
- Прямой финансовый доступ. Ключи к OpenAI или Anthropic часто привязаны к платёжным картам и аккаунтам с ненулевым балансом. Злоумышленник может расходовать лимиты жертвы для своих нужд.
- Влияние на кодовую базу. Имея валидный токен, атакующий способен инициировать запросы от имени разработчика, подсовывая ИИ‑ассистенту задания на вставку бэкдоров, ослабление проверок или добавление "незаметных" уязвимостей в код.
- Широкий охват. Чем больше разработчиков уже встроили ИИ‑ассистентов в ежедневную работу, тем привлекательнее для атакующих становится контроль над этими инструментами.
Инцидент с Bitwarden CLI - один из первых зафиксированных случаев, когда supply chain‑атака явно содержит отдельный модуль для охоты за "кошельками разработчиков у ИИ".
Почему троян отключается при русской локали
В коде вредоносного пакета заложено условие: если в системе установлена русская локаль, выполнение трояна прекращается без дальнейших действий. Исследователи выдвигают несколько возможных объяснений:
- Юрисдикционные и правовые риски. Создатели могут опасаться внимания правоохранительных органов конкретных стран и стараются исключить пользователей этих регионов из списка жертв.
- Происхождение разработчиков атаки. Часть групп, работающих в определённых странах или говорящих на русском языке, традиционно избегают атак по месту собственного пребывания, чтобы снизить риск локального преследования.
- Идеологические или политические мотивы. Не исключено, что у операторов атаки есть собственные установки, кого следует и не следует атаковать.
Как бы то ни было, наличие фильтра по локали ещё раз подтверждает: мы имеем дело не с автоматической "заливкой" рандомного трояна, а с продуманной и таргетированной операцией.
Что делать, если вы могли установить @bitwarden/cli 2026.4.0
Если существует хоть малейшая вероятность, что на вашей машине ставилась версия `@bitwarden/cli@2026.4.0` в указанное временное окно, следует считать систему скомпрометированной и действовать по максимально жёсткому сценарию.
Минимальный перечень шагов:
1. Немедленная ротация всех токенов и ключей:
- GitHub‑токены, включая токены для Actions и публикации пакетов;
- npm‑токены для личных и организационных аккаунтов;
- все приватные SSH‑ключи, используемые для доступа к репозиториям и серверам;
- ключи и секреты облачных провайдеров (AWS, GCP, Azure и др.), которые хоть как‑то были связаны с этой машиной;
- токены CI/CD (GitHub Actions, GitLab CI, других систем).
2. Перегенерация и отзыв ключей ИИ‑ассистентов:
- сброс и перевыпуск API‑ключей OpenAI, Anthropic и других провайдеров;
- замена токенов и конфигов для Claude, Cursor, Codex CLI, Aider, Kiro;
- проверка проектов и репозиториев, в которые ИИ‑ассистент мог вносить изменения в период после возможного слива токена.
3. Проверка GitHub‑аккаунта:
- поиск странных публичных и приватных репозиториев, которые вы явно не создавали (в том числе с необычными названиями, возможными отсылками к фантастике и т.д.);
- анализ недавних коммитов, особенно если они пришли с неизвестных IP или устройств;
- аудит настроек доступа приложений и OAuth‑интеграций, отозвать всё лишнее.
4. Аудит npm‑публикаций:
- проверить все пакеты, к которым ваш токен имел права публикации, на наличие неожиданных релизов;
- внимательно изучить изменения в `package.json` и дополнительных скриптах (`preinstall`, `postinstall` и т.п.);
- при подозрении - отзывать версии, помечать их как небезопасные и выпускать чистые обновления с прозрачным changelog.
5. Анализ рабочей станции и инфраструктуры:
- провести полное антивирусное и EDR‑сканирование машины;
- при возможности - переустановить систему с нуля и переносить только проверенные данные и ключи;
- проверить логи сетевого трафика на обращения к подозрительным доменным именам, похожим на инфраструктуру безопасности.
Уроки для npm‑экосистемы и цепочки поставок
Этот инцидент стал ещё одним сигналом для всей экосистемы npm и, шире, для практик supply chain‑безопасности:
- Доверие к "trusted publishing" не должно быть слепым.
Даже если используется проверенная схема публикации пакетов, ключи и доступы к ней могут быть скомпрометированы. Нужен независимый контроль содержимого релизов и автоматические проверки аномалий (внезапные `preinstall`‑хуки, появление бинарников, новые сетевые зависимости).
- Preinstall и другие lifecycle‑хуки - критическая зона.
Скрипты, запускающиеся до установки, фактически имеют полный доступ к системе разработчика ещё до того, как он "увидит" пакет в проекте. Компании и индивидуальные разработчики должны осторожнее относиться к установке пакетов, особенно глобально, а инструменты безопасности - уделять повышенное внимание этим хукам.
- Разработчики стали одними из главных целей атак.
Машина разработчика - это концентрат доступа: кода, репозиториев, инфраструктуры, облаков и ИИ‑инструментов. Компрометация одного такого хоста может иметь гораздо более разрушительные последствия, чем взлом отдельного пользовательского аккаунта.
- Инструменты ИИ - новая точка входа.
С ростом популярности ИИ‑ассистентов для программирования, их конфиги и ключи становятся столь же критичными, как и SSH‑ключи или доступы к CI/CD. Их нужно хранить с тем же уровнем защиты, а политики безопасности должны учитывать вероятность целенаправленных атак на эти "кошельки".
- Нужны процессы реагирования именно на supply chain‑инциденты.
Классические playbook'и по утечке пароля или вирусу на машине сотрудника уже недостаточны. Организациям требуются процедуры:
- быстрого отзыва и перевыпуска токенов;
- автоматического анализа всех своих публичных и частных пакетов на предмет подмены;
- уведомления пользователей своих библиотек и клиентов.
Как уменьшить риск повторения для себя и команды
На уровне отдельного разработчика и команды можно внедрить несколько практических мер:
- использовать менеджеры секретов и по максимуму избегать хранения чувствительных данных в `.env`, истории shell и открытых конфигурациях;
- ограничивать область действия токенов (минимально необходимые права, отдельные токены для CI, локальной разработки и публикаций);
- периодически ревокать и перевыпускать ключи, особенно если они долго не обновлялись;
- включить дополнительный контроль npm‑зависимостей: статический анализ, проверку появляющихся хуков, отслеживание нетипичных обновлений;
- держать отдельные окружения для разработки, публикаций и личного пользования, по возможности изолируя кластеры рисков.
***
Инцидент с Bitwarden CLI показал, насколько быстро и незаметно может быть отравлен даже инструмент, напрямую связанный с безопасностью, если атакующий получает доступ к цепочке поставки. Для тех, кто мог установить версию `2026.4.0`, сейчас ключевая задача - не искать оправдания, а максимально жёстко обрубить все возможные последствия: ревокать токены, чинить инфраструктуру и пересматривать собственные практики безопасности в экосистеме npm и инструментов для разработки.
