Injective LabsのGitHubが侵害され、ウォレットキーを盗むnpmパッケージが公開される
Injective LabsのSDKプロジェクトのGitHubリポジトリが侵害され、悪意のあるnpmパッケージが公開されました。このパッケージは、暗号通貨ウォレットのプライベートキーやニーモニックシードフレーズを盗むために設計されています。侵害されたバージョンは、@injectivelabs/sdk-ts@1.20.21で、偽のテレメトリ機能が埋め込まれており、暗号通貨ウォレットからデータを抽出します。攻撃者は、信頼された開発者のアカウントを利用して悪意のあるコミットを行い、他の17のパッケージにも影響を及ぼしました。ユーザーは、悪意のあるバージョンをインストールした場合、プライベートキーやニーモニックフレーズを更新することが推奨されています。
メトリクス
このニュースのスケール度合い
インパクト
予想外またはユニーク度
脅威に備える準備が必要な期間が時間的にどれだけ近いか
このニュースで行動が起きる/起こすべき度合い
主なポイント
- ✓ Injective LabsのGitHubリポジトリが侵害され、悪意のあるnpmパッケージが公開されました。このパッケージは、暗号通貨ウォレットのプライベートキーを盗むために設計されています。
- ✓ 攻撃者は、信頼された開発者のアカウントを利用して悪意のあるコミットを行い、他の17のパッケージにも影響を及ぼしました。
社会的影響
- ! この事件は、オープンソースソフトウェアの信頼性に対する懸念を引き起こし、開発者や企業が使用するライブラリのセキュリティを再評価する必要性を示しています。
- ! ユーザーがプライベートキーやニーモニックフレーズを適切に管理しない場合、資産の盗難や情報漏洩のリスクが高まります。
編集長の意見
解説
Injective LabsのSDKリポジトリが侵害。npmの正規更新に見せかけた“テレメトリ”でウォレット鍵を窃取する手口が露見です。
今日の深掘りポイント
- 信頼された開発者アカウントの乗っ取り→正規リポジトリから悪性バージョンがリリース、という供給網攻撃の王道パターンです。対象は@injectivelabs/sdk-ts 1.20.21で、他17パッケージにも波及しています。
- 偽装テレメトリが鍵素材(プライベートキー/ニーモニック)を収集・外送する設計で、ウォレットを扱う開発・運用環境の被害半径が極めて大きいです。npmからは削除済みでも、GitHubから入手可能な点が二次感染リスクです。
- いま必要なのは依存関係の可視化と封じ込め、そして鍵の即時ローテーションです。CI/CDのpostinstall抑止、公開鍵署名・プロビナンス検証の徹底、発行者アカウントの強化という“3本柱”で再発防止に踏み込むべきです。
はじめに
サプライチェーン攻撃の焦点は、近年「メンテナの信用」をどう突くかに収斂しています。今回のInjective Labs事案は、まさにその盲点を衝きました。信頼済みアカウントから正規のSDKに悪性改変が混入し、しかも“テレメトリ”というもっとも疑われにくい外送口に偽装して、ウォレットの重要秘密を抜き取りにいく——。暗号資産の運用現場にとって、技術的には単純でも、運用上の脅威は最大級です。即応の手順と、中長期のガードレールをこの機に見直すべき局面です。
本稿は報道と提供データに基づく深掘りで、確定事実と仮説を明確に分けて論じます。一次情報の追加検証ができていない部分については推測である旨を明示します。
深掘り詳細
いま分かっている事実
- 侵害対象と混入ポイント
- Injective LabsのGitHubリポジトリが侵害され、信頼された開発者アカウントから悪性コミットが行われました。
- npmに公開された悪性バージョンは@injectivelabs/sdk-ts 1.20.21です。他に17のパッケージへの影響が報告されています。
- 悪性コードの挙動
- “テレメトリ”機能を装い、暗号資産ウォレットのプライベートキーやニーモニックを収集し外部に送信する設計です。
- タイムラインと流通
- 悪性版は2026年7月8日に公開。npmレジストリからは削除済みですが、GitHubからは依然ダウンロード可能です。
- 推奨される一次対応
- 悪性版を取得・インストールした可能性がある場合、ウォレットのプライベートキーやニーモニックのローテーションが推奨されています。
編集部の視点(仮説とインサイト)
- 供給網攻撃の“いま”を示す三層の偽装です。
- アカウントの信頼(正規メンテナの名義)、リリースの信頼(通常のパッチ版リリースに見せる)、機能の信頼(テレメトリと称する)という三層の煙幕で審査と運用監視をすり抜けています。これは近年のサプライチェーン事案の定番パターンで、開発者とCI/CDの双方に刺さる構造です。
- CI/CD経由の“静かなる漏洩”が最悪シナリオです。
- 本件は開発端末だけでなく、CI/CDや自動化Botに保存されているシードや鍵(たとえば自動マーケットメイクや決済署名用)に直撃する可能性があります。CIは監査ログとネットワーク制限が甘いケースが多く、気づかれず外送されやすいです。
- 「npmから削除済み、でもGitHubには居残る」二重流通リスクです。
- 依存性をGitHubのtarballやcommit SHAにピン留めしている組織や、キャッシュ型社内レジストリを運用している環境では、レジストリ削除の効果が届きません。封じ込めの難しさがここにあります。
- メトリクスの示唆を読み解くと、「即応優先・実行可能」が鍵です。
- 編集部の評価指標から総合すると、新規性と即時性が高く、組織が今すぐ取り得る具体策も明確です。一方で“ポジティブ材料”は少なく、被害抑止は時間との勝負です。意思決定の遅延コストがそのまま資産流出リスクに転化します。
脅威シナリオと影響
以下は報道と一般的な挙動に基づく仮説です。実際のIoCやコード詳細は一次情報確認が必要です。
- シナリオA:開発端末の漏洩
- 依存更新時に悪性版を取得、インストールフックやimport時に秘密情報を収集し、HTTPSで外送。
- 影響:個人開発者のウォレット、テスト用とはいえ実資産を含むケースで即時流出に直結します。
- シナリオB:CI/CDの機密吸い上げ
- ビルド・デプロイ時の環境変数やキーストアからシード/鍵を収集。postinstallや初期化コードの“テレメトリ”として外送。
- 影響:署名用鍵や自動執行Botの鍵が奪取され、継続的な資産移転・後続侵害に利用されます。
- シナリオC:本番サービスの運用鍵窃取
- ノードサービスが当該SDKをロードするたびに外送ロジックが実行。運用鍵が抜かれ、即時に不正送金が発生。
- 影響:DEXやカストディのホットウォレット、マーケットメイク用資金の即時枯渇リスクです。
- 二次被害の可能性
- 盗難資産のミキシング、同組織の他サービスへの横展開、取引所アカウント乗っ取りなどが連鎖します。
ATT&CKに沿った仮説マッピング(高レベル)
- 初期侵入
- Supply Chain Compromise(サプライチェーン妥協)/Valid Accounts(正規アカウント悪用)です。
- 実行
- JavaScript/Nodeによるスクリプト実行(import時・postinstallなど)です。
- 認証情報アクセス
- Private Keys/Unsecured Credentials(ファイル・環境変数・キーストア中の秘密情報取得)です。
- 偽装・回避
- Masquerading(テレメトリ装い)、Obfuscated/Compressed Files and Information(難読化)です。
- 指揮管制・外送
- WebプロトコルによるC2/外送(通常のテレメトリに偽装したHTTP(S)通信)です。
資産・業務インパクト
- 金銭被害:ホットウォレット主体に即時・不可逆の流出です。
- 信用・コンプライアンス:カストディや交換業の顧客資産保護義務、インシデント報告要件への影響です。
- 開発生産性:依存性凍結・検証強化に伴うデリバリ遅延です。
セキュリティ担当者のアクション
“止血・封じ込め・再発防止”の3段で整理します。
-
- トリアージ(本日中)
- 資産棚卸し:Monorepo/サービス/CIで@injectivelabs/sdk-ts利用有無とバージョンを列挙します。package-lock.jsonやpnpm-lock.yaml、yarn.lockを機械検索し、1.20.21の痕跡を洗い出します。
- 取得経路の確認:npm公式レジストリか、GitHub tarball/commit SHAか、社内キャッシュかを特定します。GitHub由来のピン留めは特に注意です。
-
- 止血(即時)
- 鍵ローテーション:該当期間に当SDKを取得・実行した可能性が1%でもあれば、該当ウォレットのプライベートキー/ニーモニックを全面的に交換します。資産は新アドレスへ速やかに退避します。
- ネットワーク封じ込め:ビルドとランタイムのアウトバウンドをデフォルト拒否し、必要先のみ許可に切り替えます。テレメトリ送信先のドメイン情報が得られ次第、ブロックルールに追加します。
- レジストリ隔離:社内npmプロキシ/キャッシュから当該版を隔離・削除し、再解決を強制します。
-
- 検知・フォレンジック(48時間以内)
- ログレビュー:該当期間のNodeプロセスからの外向きHTTP(S)通信を洗い出し、異常な宛先とペイロード長の分布を比較します。CI/CDランナーのネットワークフローを優先します。
- アーティファクト再現:当該期間にビルドされたコンテナやLambdaレイヤを再構築し、差分(npm ci --ignore-scriptsを用いたクリーンビルド)で改変有無を検証します。
- ソース監査:偽装テレメトリの導線(init/constructorでの送信、env.MNEMONIC/PRIVATE_KEY参照等)を静的解析ルールでスキャンします。
-
- 運用ガードレール(今週中)
- CIのpostinstall抑止:npm ci / yarn installの--ignore-scriptsをデフォルトにし、必要プロジェクトだけ例外申請制にします。
- 発行者・パイプラインの強化:GitHub・npmの強制2FA、SSO必須化、細粒度PAT、署名付きコミット必須、保護ブランチ、リリースタグ署名を組織ポリシーにします。
- プロビナンス検証:GitHub Actions由来のnpmパッケージ・コンテナについて、ビルド署名とプロビナンス(Sigstore/SLSA相当)を検証し、未署名/出所不明のアーティファクトを拒否します。
- 依存性管理:SemVerの自動マイナ・パッチ更新を停止し、許可制の“カーブアウト”に移行します。lockfileの厳格ピン留めとSBOM自動生成を合わせます。
- 最小権限の鍵運用:本番署名用鍵はオフライン/HSMに、Bot/ホット鍵は用途別・少額・短期ローテーションに分離します。
-
- 経営・法務連携
- 事象の重大性を踏まえ、資産流出可能性と対応状況を経営・法務へ即時報告します。必要に応じて当局・パートナー取引所との連絡線を開きます。
最後に——本件は「テレメトリ」という善意の名札が、どれほど強力な隠れ蓑になりうるかを示しました。テレメトリの送信先ドメインをホワイトリストで厳格管理し、コードレビューでも“なぜそれを収集し、どこへ送るのか”の説明責任を徹底することが、供給網時代の新しい衛生要件です。今日の一手が、明日の資産を守ります。
参考情報
背景情報
- i ソフトウェア供給チェーンのセキュリティは、近年ますます重要視されています。特に、オープンソースプロジェクトでは、信頼できる開発者のアカウントが悪用されることで、悪意のあるコードが混入するリスクが高まります。
- i 今回の攻撃では、悪意のあるパッケージがテレメトリ機能を装ってユーザーのプライベートキーを盗む仕組みが採用されており、開発者が気づかないうちに情報が外部に送信される可能性があります。