OVHcloud CLIのリリースがGitHubアカウントの侵害により乗っ取られ、秘密情報を窃取

10月19日の月曜日、攻撃者はコントリビューターのGitHubアカウントを侵害し、既存の5つのOVHcloudコマンドラインインターフェース（CLI）リリースのダウンロードアーカイブを置き換えました。ローカルディスクから秘密情報を窃取するよう設計された悪意あるバイナリは、クラウドプロバイダーがそれらを削除し、変更不可なクリーンなリリースを発行するまで、94分間GitHub上に公開されていました。

何が起きたのか

このインシデントは、4月14日から9月16日にかけて公開されたOVHcloud CLIのバージョンv0.11.0からv0.15.0を対象としていました。UTCで12:47から14:21の間、コントリビューターアカウントへのアクセス権を持つ攻撃者が元のアーカイブファイルを削除し、マルウェアを含む新しいファイルをアップロードしました。攻撃者はさらにchecksums.txtファイルも置き換え、公開されたハッシュ値が悪意あるバイナリと一致するように操作しました。これにより、提供されたチェックサムのみを頼りにする基本的な整合性チェックが回避されました。

OVHcloud創業者のOctave Klaba氏は、ソースコード、リリースタグ、および内部ビルドパイプラインは無傷のままだったことを確認しました。悪意あるファイルは、後のコミットに対する単純なGoビルドであり、GitHubのリリースページに直接アップロードされたものでした。同社は対応として、置き換えられたアーカイブを削除し、リリースアセットのさらなる変更を防ぐGitHubの機能である「変更不可（immutable）」リリースとしてバージョンv0.16.0を公開しました。侵害されたコントリビューターはドキュメントリポジトリへのマージ作業を行っていましたが、組織の公開メンバーではありませんでした。

仕組み

この攻撃は、変更不可設定が有効になっていない場合、書き込み権限を持つユーザーが既存のGitHubリリースを変更できるという特性を悪用したものです。この設定は2025年10月に一般公開されましたが、リリースファイルとタグをロックするのは有効化後に作成されたリリースのみを保護します。OVHcloudは影響を受けたリリースに対してこのオプションを有効にしていなかったため、攻撃者はCI/CDパイプラインのチェックやワークフローの実行をトリガーすることなくバイナリを差し替えることができました。

マルウェア自体は、~/.ovh.confや環境変数などに格納されている認証情報など、ディスク上の秘密情報を狙うスティーラー（窃取ツール）でした。OpenSourceMalwareの研究チームは、侵害されたアカウントをGlassWormキャンペーンに関連付けています。これは不可見Unicode文字にコードを隠蔽することで知られるキャンペーンです。10月のバイナリの複製は公開分析されていませんが、当該アカウントに関連する4つの個人リポジトリでは、3月にGlassWormの戦術と一致するローダーを含む強制プッシュ（force-push）が発生していたことが確認されています。

主要な詳細

• 侵害されたバージョン: v0.11.0、v0.12.0、v0.13.0、v0.14.0、およびv0.15.0は侵害されたとみなされます。v0.10.0は安全です。
• 影響を受けたプラットフォーム: macOS (x86_64, arm64)、Linux (x86_64, arm64)、Windows (x86_64)。Linux i386、Windows i386、Windows arm64、およびWebAssemblyビルドは影響を受けていません。
• 露出期間: 2026年10月19日 UTC 12:47 から 14:21 まで。
• 検知方法: 悪意あるバイナリには v0.15.1-0.20261013083505-5ead8ef9b43d+dirty のような擬似バージョンが表示され、-ldflags="-s -w" を含みます。一方、正規のリリースにはタグ番号が表示され、ldflags行は含まれません。
• 安全なインストール経路: Homebrewユーザーは、caskが元のSHA-256ハッシュを固定（pinning）していたため保護されており、不一致のダウンロードは失敗していました。Dockerイメージおよび go install メソッドも影響を受けませんでした。
• 悪意あるハッシュ: 置き換えられたv0.15.0 Linux arm64アーカイブのSHA-256は 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb です。

なぜ重要なのか

このインシデントは、リリースの変更不可性が強制されない場合のサプライチェーンセキュリティの脆弱性を浮き彫りにしています。多くの開発者は、暗号署名の検証やハッシュの固定を行うことなく、インストールスクリプトやGitHubリリースからの直接ダウンロードに依存しています。例えば、公式のOVHcloudインストールスクリプトはハッシュを確認せずに最新のアーカイブをダウンロードするため、94分間のウィンドウ中にこれを実行したすべてのユーザーが危険にさらされました。同様に、固定されたハッシュなしでアーカイブを取得するCIジョブも、悪意あるバージョンを静かにインストールしてしまっていた可能性があります。

エンジニアリングチームにとって、これはリポジトリのコントリビューターへの信頼を技術的なセーフガードとバランスさせる必要があるという重要な教訓となります。ビルドパイプラインが安全であっても、リリースアセットの直接操作によってこれを完全に回避できてしまいます。Homebrewユーザーが保護されていた事実は、ハッシュ固定を強制するパッケージマネージャーの価値を示しており、手動インストールやカスタムスクリプトを使用していたユーザーはより高いリスクに直面していました。マルウェアはホストマシンから読み取り可能なすべての秘密情報を流出させた可能性が高いため、侵害されたバイナリを実行した可能性があるすべての人は、今すぐ秘密情報のローテーション（更新）を実施することが必須です。

対処法

• 侵害されたCLIを実行した可能性のあるマシンに保存されているすべての秘密情報を、別のクリーンなマシンを使用してローテーションしてください。
• 現在のOVHcloud CLIバイナリを削除し、証明書を伴う変更不可リリースとして公開されているバージョンv0.16.0をインストールしてください。
• GitHub CLIコマンド gh release verify-asset v0.16.0 FILE を使用してダウンロードしたアーカイブを検証し、整合性を確認してください。
• 自分のGitHubリポジトリでリリースの変更不可性を有効にし、既存のリリースアセットへの不正な変更を防いでください。
• CI/CDパイプラインやインストールスクリプトでは、動的な最新タグや未検証のダウンロードに依存するのではなく、SHA-256ハッシュを固定してください。
• コントリビューターのアクセスレベルを監査し、多要素認証（MFA）を適用して、アカウント侵害のリスクを低減してください。