OVHcloud CLI配布チャネル乗っ取り攻撃：コードはクリーン、バイナリはマルウェア｜ブログ(ほぼこもセキュリティニュース)

2026年10月19日、大手クラウドプロバイダーOVHcloudの公式GitHubリポジトリ（ovh/cli）において、既存のリリースページに掲載されていたバイナリファイルが、認証情報（シークレット）を窃取するマルウェアへと差し替えられるサプライチェーン攻撃が発生しました。
本攻撃は、GitHubアカウントの乗っ取りを介して既知の過去リリース（v0.11.0 〜 v0.15.0）のバイナリおよびチェックサムファイル（checksums.txt）を直接書き換える手法で実施されました。
開発者エコシステムを標的とする脅威アクティビティ「GlassWorm」による関与が強く疑われています。
約93分間（12:47〜14:21 UTC）にわたり不審なバイナリが公開状態にありましたが、ユーザ側のCI/CDパイプラインによるハッシュ不一致検知をきっかけに発覚し、問題のバイナリの削除を経て、現在は修正版（v0.16.0）の公開とリリース管理体制の強化により収束しています。
本インシデントには、従来のサプライチェーン攻撃（Typosquattingやビルドパイプライン侵入など）とは異なる際立った特徴がいくつか存在します。
特徴的な部分をみてみましょう。

ソースコードやCI/CDパイプラインを迂回した「リリースアセットの直接差し替え」
- 内容
  攻撃者はソースコードのリポジトリ、git tag、CI/CDビルドパイプライン（GitHub Actions等）には一切触れず、GitHub Releases APIを通じて既存の公開済みリリースバイナリのみをローカルで手動ビルドした悪意あるバイナリに直接差し替えました。
- 過去の脅威との違い
  SolarWinds型やCodecov型のような「ビルド工程（CI/CD）の汚染」や「悪意あるコミットの注入」とは異なり、ソースコードもCI/CDログも完全にクリーンなままでした。
  そのため、ソースコード監査やパイプライン上の脆弱性スキャン（CVEチェック）では検知できない盲点をついた攻撃です。
チェックサムファイル（checksums.txt）の同時改ざん
- 内容
  攻撃者は悪意あるバイナリへ置換するのと同時に、同じリリースページに配置されているハッシュ値一覧ファイル（checksums.txt）も手動ビルドした悪意あるバイナリのSHA-256値に書き換えました。
- 過去の脅威との違い
  通常、「配布元から提供されているハッシュ値ファイルと照合する」ことが公式な検証手順とされますが、配布元のハッシュファイル自体が攻撃者によって一括更新されていたため、公式ページからハッシュを取得して検証する一般的な整合性チェックを無効化（回避）させました。
「イミュータブル（不可変）設定」の欠如を突いた過去リリースの改ざん
- 内容
  GitHubのリリース機能において、過去にリリースされたアセット（バイナリ等）の上書き防止設定（Immutable Release）が有効化されていなかったため、数か月前にリリースされた安定版（v0.11.0等）のアセットまで一括して悪意あるファイルへ更新可能でした。
- 過去の脅威との違い
  従来の攻撃の多くは「新バージョン（最新版）のリリース」として悪意あるコードを配布しますが、本件では「すでに信用されている過去のバージョン」を後から書き換える手法が使われました。
  固定した旧バージョンを指定してダウンロード（ピン留め）していた環境もリスクに晒される結果となりました。
ベンダーではなく「エンドユーザーのハッシュピン留め（CI/CD）」による検知
- 内容
  本件の第一発見者はOVHcloud公式の監視システムではなく、該当CLIツールを利用していた顧客（ユーザ）でした。
  顧客がCIパイプライン側で独自に事前保持していた「正規のSHA-256ハッシュ値」と、ダウンロードされたファイルのハッシュ値が一致しなかったことで異常を検知し、GitHub Issue（#300）へ手動報告したことで事件が発覚しました。
- 過去の脅威との違い
  一般的なインシデントではベンダー内部のEDRや開発者通知で検知されますが、本件は「ユーザ側が事前にハッシュをハードコードして検証する強固なパイプラインを構築していたこと」が早期発見につながる唯一のトリガーとなりました。

今回のOVHcloud CLIサプライチェーン攻撃は、「ソースコードやビルドパイプラインがクリーンであっても、最終的な配布チャネル（Release Assets）の権限管理や不可変性が不十分であれば、マルウェアの配布元になり得る」というセキュリティ上の盲点を明白に示しました。

推奨される対策は次のようなものです。

暗号学的ハッシュの独自ピン留め
公式から提示された checksums.txt をその場でダウンロードして信頼するのではなく、事前に検証済みのSHA-256ハッシュ値を組織のビルドスクリプト側に固着（ピン留め）して比較検証を行う。
リリースアセットの保護と権限の最小化（リリースタグの変更保護や、アセット上書きを防ぐワークフローの構築）
リポジトリ管理者は、一度作成したリリースアセットやタグの再アップロード・上書きを技術的に不可とする設定を適用する。
認証情報の回転（ローテーション）
該当時間帯（2026年10月19日 12:47〜14:21 UTC）に対象バイナリを取得・実行した可能性がある端末および自動実行環境においては、アクセス可能なすべてのAPIキー、クラウド認証情報、シークレットを直ちに無効化・再発行（ローテーション）する。

攻撃側と防御側としてみると、防御側が後れを感じるイタチごっこになることが多いように感じますが、こういう例もあるのですね。

OVHcloud CLI supply chain compromise: release assets replaced through a GlassWorm-hijacked contributor account
https://opensourcemalware.com/blog/glassworm-hacks-ovh-clouds-cli-tool