Bitwarden CLI、進行中のCheckmarxサプライチェーンキャンペーンで侵害

 (socket.dev)
1 ポイント 投稿者 GN⁺ 6 일 전 | 1件のコメント | WhatsAppで共有
  • npm向けのBitwarden CLIパッケージが、進行中のCheckmarxサプライチェーン攻撃の一部として侵害され、現時点で確認されている影響範囲は @bitwarden/cli 2026.4.0 ビルドに限定される
  • パッケージに含まれる**bw1.js マルウェア**は、audit.checkmarx[.]cx/v1/telemetry のような同一インフラと難読化手法を使用しており、侵害されたGitHub Actionを用いたCI/CD侵害の痕跡とも一致する
  • 収集対象はGitHubトークンだけでなく、AWS、Azure、GCP認証情報、.npmrc、SSHキー、環境変数、Claude/MCP設定ファイルにまで広がっている
  • 窃取した情報は、公開GitHubリポジトリの作成とコミット、npmトークンを使った再配布による拡散、workflow注入へとつながり、~/.bashrc と ~/.zshrc の改変による永続化機能も含まれる
  • Bitwarden CLIを使用した組織は、今回の事案を認証情報漏えいおよびCI/CD侵害として扱うべきであり、CIログの確認と露出した可能性のあるシークレットのローテーションが重要になる

概要

  • Bitwarden CLI npmパッケージが、進行中のCheckmarxサプライチェーン攻撃の一部として侵害され、確認済みの対象バージョンは @bitwarden/cli2026.4.0 である
    • 悪性コードは、パッケージに含まれていた bw1.js に存在していた
    • 攻撃経路は、BitwardenのCI/CDパイプライン内で侵害されたGitHub Actionを利用した痕跡と一致しており、他のリポジトリで確認されたキャンペーンのパターンとも合致する
  • 現時点で確認されている範囲はBitwarden CLIビルドに限定されており、この侵害は、より広範な Checkmarx campaign で特定されたGitHub Actionsサプライチェーンベクターに従っている
    • 関連しているのは npm 向けCLIパッケージのみ
    • Chrome拡張、MCPサーバー、そのほかの正式配布物への影響は現時点では確認されていない
  • 調査は継続中であり、完全な技術分析、影響バージョン、侵害指標、対応ガイダンスは今後追加で公開される予定
  • Bitwarden CLIを利用している場合、CIログの確認と露出した可能性のあるシークレットのローテーションが必要となる

技術分析

  • 悪性ペイロード bw1.js は、前日に分析されたCheckmarxの mcpAddon.js と中核インフラを共有している
    • 同一のC2エンドポイント audit.checkmarx[.]cx/v1/telemetry を使用し、__decodeScrambled とシード 0x3039 によって難読化されている
    • GitHub APIを介したコミットベースの流出と、npmレジストリを通じたトークン窃取および再配布も実行する
  • 埋め込まれたペイロード構造も同系統である
    • gzip+base64構造の中に、GitHub Actions Runner.Worker メモリをスクレイピングしてGitHubトークンを狙うPythonスクリプトが含まれている
    • 再配布用npmパッケージ向けの setup.mjs ローダー、GitHub Actions workflow YAML、ハードコードされたRSA公開鍵、思想的な声明文文字列も含まれる
  • 認証情報の収集範囲は非常に広い
    • GitHubトークンは Runner.Worker メモリスクレイピングと環境変数から収集する
    • AWS認証情報は ~/.aws/ のファイルと環境変数から探索する
    • Azureトークンは azd、GCP認証情報は gcloud config config-helper を通じて収集する
    • .npmrc、SSHキー、環境変数、Claude/MCP設定ファイルも対象に含まれる
  • GitHubを利用した流出手法も具体的に確認されている
    • 被害者アカウント配下に、Duneテーマの命名規則 {word}-{word}-{3digits} に従う公開リポジトリを作成する
    • 暗号化された成果物をコミットし、コミットメッセージには LongLiveTheResistanceAgainstMachines マーカーとともにトークンを挿入する
  • サプライチェーン拡散メカニズムまで含まれている
    • 窃取したnpmトークンで書き込み可能なパッケージを探し、preinstall hook が挿入された状態で再配布する
    • GitHub Actions workflowを注入し、リポジトリのシークレットを追加で収集する
  • ロシアロケールのキルスイッチが存在する
    • システムロケールが "ru" で始まる場合は静かに終了する
    • Intl.DateTimeFormat().resolvedOptions().locale と LC_ALL、LC_MESSAGES、LANGUAGE、LANG 環境変数を確認する
  • ランタイムはBun v1.3.13で、GitHub Releasesから取得される

Checkmarx事案との相違点

  • bw1.js には、Checkmarx事案の文書にはなかった追加の侵害指標が含まれている
    • ハードコードされたロックファイル /tmp/tmp.987654321.lock で同時実行を防止する
    • ~/.bashrc と ~/.zshrc にペイロードを注入してシェルプロファイル永続化を確保する
    • リポジトリ説明を Shai-Hulud: The Third Coming に設定し、デバッグ文字列に "Would be executing butlerian jihad!" を含めるなど、明示的なブランディングを使用している
  • 共有ツール群は同一のマルウェア生態系との強い関連を示唆する一方で、運用上のシグネチャは帰属判断をより難しくしている
    • Checkmarx攻撃は発見後、TeamPCPが @pcpcats ソーシャルアカウントを通じて自らの犯行だと主張した
    • 当該マルウェアは正常に見える説明で偽装しようとしていた
  • 今回のペイロードは公開的な態度が異なる
    • Shai-Huludリポジトリ名、"Butlerian Jihad" 声明文、機械への抵抗を掲げるコミットメッセージのように、思想的な印がマルウェア内に直接含まれている
    • 同じインフラを使う別オペレーター、より強い思想性を持つ分派、またはキャンペーンの公開姿勢の変化といった複数の可能性が残されている

推奨事項

  • 悪性のBitwarden npmパッケージをインストールした組織は、今回の事案を認証情報漏えいおよびCI/CD侵害インシデントとして扱うべきである
  • 開発者システムとビルド環境から影響パッケージを直ちに削除し、当該環境で露出した可能性のある認証情報をすべてローテーションすべきである
    • GitHubトークン、npmトークン、クラウド認証情報、SSHキー、CI/CDシークレットが含まれる
  • GitHubでは、未承認のリポジトリ作成と異常なworkflowを点検すべきである
    • .github/workflows/ 配下の予期しないファイル、不審なworkflow実行、artifactダウンロード、Duneテーマの命名パターン {word}-{word}-{3digits} に従う公開リポジトリを確認する必要がある
    • 影響の可能性がある場合は、新たに公開されたリポジトリで以下のキーワードを確認すべきである
      • atreides
      • cogitor
      • fedaykin
      • fremen
      • futar
      • gesserit
      • ghola
      • harkonnen
      • heighliner
      • kanly
      • kralizec
      • lasgun
      • laza
      • melange
      • mentat
      • navigator
      • ornithopter
      • phibian
      • powindah
      • prana
      • prescient
      • sandworm
      • sardaukar
      • sayyadina
      • sietch
      • siridar
      • slig
      • stillsuit
      • thumper
      • tleilaxu
  • npmでは未承認の配布が行われていないか監査すべきである
    • 未承認の publish、バージョン変更、新たに追加されたインストールフックを確認する必要がある
  • クラウド環境ではアクセスログを再確認すべきである
    • 異常なシークレットアクセス、トークン使用、新たに発行された認証情報を追跡する必要がある
  • エンドポイントとランナーでは、観測された流出インフラとファイルアクセスの痕跡を追跡すべきである
    • audit[.]checkmarx[.]cx への外部接続を探す必要がある
    • 普段使わない環境でBunの実行があったか確認すべきである
    • .npmrc、.git-credentials、.env、クラウド認証情報ストア、gcloud、az、azd へのアクセス痕跡を調べる必要がある
    • /tmp/tmp.987654321.lock の存在有無と ~/.bashrc、~/.zshrc の変更有無も確認すべきである
  • GitHub Actionsでは未承認のworkflow作成有無を確認すべきである
    • 一時ブランチ上でworkflowが作成されたか確認が必要である
    • format-results.txt のようなartifactが生成またはダウンロードされていたかも点検すべきである
  • 長期的には、今後のサプライチェーン事案における被害半径の縮小が必要である
    • トークン権限のスコープを狭め、可能であれば短命な認証情報を利用すべきである
    • パッケージ作成および配布権限を制限し、GitHub Actions権限を強化すべきである
    • 不要なartifactアクセスを無効化し、通常のリリース手順外で発生した公開リポジトリやworkflow変更を監視すべきである

侵害指標

関連記事

1件のコメント

 
GN⁺ 6 일 전
Hacker Newsのコメント

  • 最小リリース待機期間を設けることよりも、もっと良い防御策があるのか気になる
    .npmrc に min-release-age=7 を入れておくだけでも、約 19時間前 に公開されて後に悪意あるものと判明した @bitwarden/cli 2026.4.0 を取得した334人は避けられたはず
    同様に axios、ua-parser-js、node-ipc の事例にもかなり有効で、event-stream のように長く潜伏したケースには効かなくても、たいていの急性のサプライチェーン攻撃には効果がありそう
    設定例として npm/pnpm/bun/uv それぞれに待機時間を入れる方法があり、ワンクリックで点検・適用するツールがなかったので自分で https://depsguard.com を作った
    同じようなアイデアの https://cooldowns.dev も今見つけた

    • Aikido safe-chain を使っている
      最小リリース待機期間を設けるだけでなく、npm/uv などを包むラッパーとして、インストール前に各依存関係を商用の 脆弱性データベース と照合し、既知の問題や疑わしいシグナルを検査してくれる
    • クールダウン のアイデアは良いが、誰もすぐ更新しなかった場合、この攻撃が本当に検出されたのかも気になる
      現実には常に誰かが即座に更新するだろうが、こうした事故が表面化する過程自体が、素早く更新するユーザーに依存している面がありそう
    • backend や CLI ツールを NPM に置かないことから始める方がよいと思う
    • 新規インストール時はともかく、既存の依存関係は patch バージョンで pin して sha を固定 すればいいのではと思う
    • この種の攻撃はたいてい upstream source までは入り込まないので、https://www.chainguard.dev/libraries のように ソースからビルド する方式なら、おおよそ98%は防げる
      レジストリのバイナリをそのまま引っ張ってこなければならないなら、クールダウンでリスクを少し下げられる
      GitHub 側まで侵入した裾の長いケースでは、コミット・メンテナーのヒューリスティクスと AIベースのコード変更分析 を回し、異常兆候があれば人がレビューする組み合わせが必要に見える
      ちなみにそこで働いている

  • 今回の事故は ビルドパイプラインが乗っ取られ、汚染されたパッケージが配布されたのが核心
    それでも業務上重要なものを npm に載せているなら、依存関係は必ず pinning した方がいいと思う
    多くの開発者は lockfile で十分だと考えるが、^ の範囲が残っていれば、lockfile 更新時に自分が明示的に選んでいない新しいバージョンを引き上げてしまう
    会社の存続に影響し得るシステムなら、この程度の手間は払う価値がある

    • 逆に言えば、後のバージョンで セキュリティ脆弱性が修正 されたときは、システムがそれを自動で受け取って適用してくれるのが理想でもある

  • https://github.com/doy/rbw は Bitwarden CLI の Rust 製代替
    Rust エコシステムも次第に npm のような大きく深い依存ツリーに向かっている感じはあるが、それでも JavaScript でよくあるケースより信頼しなければならない作者の数はずっと少ない

    • https://github.com/doy/rbw/blob/main/Cargo.toml#L16 を見ると、ここも 依存関係はかなり多い
      それでも少なくともバージョンは pin されている
    • Firefox 内蔵パスワードマネージャー を使うことに欠点があるのか気になる
    • みんな Rust をより安全だと見なす一方で、依存関係を通じてマルウェアを引き込むリスク が大きく増えたことをあまりにも軽視しているように思う
    • rbw + vaultwarden の組み合わせなら、self-hostable な Rust 版 Bitwarden のように動くのでかなり良い
    • こういうことがあると、もっと多くのソフトウェアが .Net のようにサードパーティ依存なしでも大半を解決できるスタック に向かうかもしれない
      逆に、言語の標準ライブラリにもっと機能を入れる方向に進む可能性もある

  • Bitwarden の CLI 体験は非常にひどかった
    bw list を実行したらパスワード名だけが出ると思っていたのに、実際には パスワードと現在の TOTP コードまで全部 表示された
    さらに恐ろしかったのは、サーバーに ssh で入り tmux 内の weechat を開くと、bw コマンドの全内容に weechat の入力履歴 からアクセスできたこと
    なぜそうなったのかまったく分からず、tmux と weechat のセッションを越えて残り続け、サーバーを再起動して初めて消えた
    その後 bw CLI はすぐ削除し、再インストールするつもりもない
    ちなみにターミナルは ghostty を使っている

    • これは本題とは関係ない、愚痴に近い
    • CLI を使ってみようとしたが、JavaScript ベース なのを見てやめた
    • 本当に奇妙な出来事だ
      weechat に bwcli 拡張でもあるのか気になるし、Bitwarden に CLI があること自体今回初めて知った
      自分はローカルで keepass を使っている

  • CLI は使ったことがないが、ブラウザプラグイン は使っている
    これが破られたら本当に大惨事だが、何をすれば防げるのか分からない
    検証済みの 旧バージョン を使い続けるのが答えなのか考えてしまう
    自分の人生のかなりの部分が、これらの秘密が秘密のままであることにかかっているのだと改めて思うと妙な気分になる

    • 統合ポイント が増えるほど攻撃面も広がる
      だからパスワードマネージャーの ブラウザ拡張 はそもそも使わない
      以前ブラウザ連携でセキュリティ問題があった製品を見てから完全に避けるようになり、iOS 統合は比較的まだ信用するが、それでも警戒している
    • クールダウン はデフォルトでどこにでも入るべきだと思う
      開発用パッケージマネージャー、OS パッケージマネージャー、ブラウザ拡張、単体アプリの自動更新まで全部含めての話
      Socket のような会社が悪性アップデートを検出する時間を稼ぐ必要があるのに、みんなが公開から数分でダウンロードしてしまえば、そうした検出自体が無意味になる
    • 自分のデジタル資産の中で最も大事な メールと Bitwarden アカウント は、常に身につけている Yubikey 1本と、別の場所に置いたバックアップキー1本で保護している
      この構成を強く勧める
      タイトルを見て少し肝を冷やしたが、偏執的になるほどではなく、合理的にできることは全部やっていると感じている
    • ブラウザプラグイン の代わりに、デスクトップアプリや Web vault を直接使えばよい
    • 防ぐ方法は簡単に言えばこの2つ
      https://cooldowns.dev
      https://depsguard.com
      2つ目は自分が管理していて、1つ目を先に知っていたらわざわざ作らなかったかもしれない
      どちらもほぼ同じことをしていて、自分の方は Rust を使っているので少しやり過ぎ気味だ

  • ここで最も重要なのは、npm install だけで十分だった という事実
    侵害ポイントが preinstall なら、インストール後に検査しようという通念はすぐ崩れる
    その時点でペイロードはすでに実行の機会を得ているからだ
    これは エージェント、CI、ephemeral sandbox 環境でさらに興味深い。露出時間が短くても、インストールが自動で繰り返されれば十分にやられ得る
    さらに注目すべきなのは、このペイロードが秘密情報だけでなく AI ツール群の設定 まで狙っていた点だ
    シェルプロファイルの改変が、次のコーディングアシスタントが読み取るコンテキストを汚染する経路になり得るという見方もかなり現実的だ
    この観点は AgentSH の作業とあわせて https://www.canyonroad.ai/blog/the-install-was-the-attack/ にさらに詳しく書いた

    • インストール後にパッケージを検査する人は実際ほとんどおらず、npm install スクリプト だけを特別視するのは何度も反論されてきた主張だと思う
      どうせ最終的には実際のバイナリを実行することになる
      そして厳密に言えば、インストール前にパッケージを直接取得して検査することもできるのだから、インストーラの挙動保証と範囲を深く理解しないまま、悪意あるコードをダウンロードして展開する過程を半端に信頼する方がむしろ奇妙だ

  • ロシアロケール kill switch とは、大胆でありながら臆病にも見える

    • さらに悪いのは、それが本当の痕跡なのか、それとも false flag なのかすら分からないことだ
    • Discretion is the better part of valor のような、いろいろな格言が思い浮かぶ
      要するに、自分の足は撃たない という態度に見える
    • それ自体で 決定的証拠 にはならない
      Vault7 の流出でも、NSA や CIA が出所を曖昧にするためにこうした痕跡をわざと残すという話があり、他の国家主体でも十分使いそうな手法だ
    • 他国による 脅迫的工作 のようにも見える
    • npm publish の GitHub CI ジョブで、わざわざロケールをそう合わせるだろうか
      あまりに露骨な ミスリード用の痕跡 に見えるが、同時に国家主体が関与したという印象を強く与える

  • KeePass ユーザーとして生きる方が、こうしたストレスはずっと少ない
    過去5年だけ見ても、ローカルインフラで KeePass を使っていたおかげで複数のセキュリティ事故を避けられた

    • 今回は vault 自体ではなくアクセスツール が問題だった
      KeePass 用のアクセスツールだからといってこうした問題が起きないわけでもなく、何が違うのかよく分からない
    • パスワードを インフラと携帯電話の両方からアクセス したいのだが、KeePass でそれをどう解決するのか気になる
      無理だと思っていたが、正直そこまで深く調べてはいない
    • 自前のインフラを回せる人には良いだろうが、stress free という表現を一般的なユーザーにまで当てはめるのは難しい
    • 単一ファイル方式なのは分かるが、現実的に 同期と競合解決 をどうするのか気になる
      2台のデバイスがオフラインのままそれぞれパスワードを追加し、その後オンラインに戻ったらどう処理するのだろうと思う
    • KeePass でまだしっくり来ないのは クラウドバックアップ だ
      バックアップを暗号化したら、そのパスワードはどこに保存し、さらにクラウドプロバイダーのパスワードはどこに保存するのかという話になる

  • 今回の攻撃で特に印象的なのは、攻撃者たちが GitHub が落ちていないタイミング と正確に合わせる必要があった点だ

  • だから自分は サードパーティのパスワードマネージャー をそもそも使わない
    セキュリティ、アップデート、バックアップなどをちゃんとやってくれると信じ続けなければならないからだ
    自分で stateless パスワード生成器 を作っており、そのおかげでデバイス間のデータバックアップや同期は一切不要
    非常に長く強力なマスターパスワードとサービス名、ユーザー名を入力すると、適切なパラメータの scrypt ハッシュ を計算して総当たりを事実上不可能にする方式
    重要なアカウントには 2FA も併用している