Gheist｜盗難GitHubトークンでActionsを悪用しprivateリポのシークレットを流出させる進行中攻撃

GitHub Actions シークレット流出を規模で狙う進行中の攻撃キャンペーン「Gheist」が確認された。盗んだ GitHub トークンで Actions ワークフローを仕込み、private リポジトリのシークレットを実行ログ経由で持ち出す手口だ。クラウドセキュリティ企業 Wiz Research が 2026年9月15日から追跡しており、攻撃ツールが GitHub API に送る User-Agent 文字列「gheist」から名づけた。この記事は、Wiz の報告と複数の独立報道で裏が取れた事実だけを、防御側の打ち手（検知・ローテーション・予防）を軸に整理する。

依存関係やプラットフォームの権限を足がかりにする攻撃の全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。

GitHub Actions シークレット流出の時系列——2026年9月から進行中

Gheist は単発の脆弱性ではなく、盗んだ資格情報を規模で濫用する進行中のキャンペーンだ。Wiz の報告をもとに、確認できた時系列（タイムライン）を整理する。GitHub Actions シークレット流出がどの範囲で起き、どこで止まったかを押さえる出発点になる。

何が確定していて、何が未確認か

確定しているのは、Wiz が報告した手口・命名の由来・規模の数値・保護の範囲だ。一方で、実際にシークレットが露出した組織の数は Wiz が公表していない。850 超・13,500 超という数字は「侵害の試みがどれだけ広がったか」であって、「何組織で露出が成功したか」ではない。本記事はこの線引きを保ったまま進める。

何が起きたか——盗難トークンから「ログに符号化」まで

手口はシンプルで、だからこそ数で効く。Wiz の報告によれば、攻撃者はまず書き込み権限のある盗難トークンを使う（高い権限は要らない）。そのトークンでアクセスできる各リポジトリに、ci-sync- に続く 6 桁のランダムな文字のブランチを作り、CI 風のワークフロー（例: sync-check.yml、on: [push]）を push する。ワークフローが走ると、設定されたシークレットを符号化してログに出力し、攻撃ツールがそのログを GitHub API でダウンロードしたうえで、実行(run)を数秒後に削除する。

データが GitHub 自身の API を通って出ていくため、防御側がブロックすべき外部ドメインや外向き通信が無いのがこの攻撃の厄介な点だ。FV の図がこの「トークン入手 → ブランチ生成 → ログに符号化 → 痕跡を消す」という流れを表している。

なぜ GitHub のログマスキングが効かないのか

GitHub Actions は、シークレットに設定した生の値がログに現れると自動で伏せる（マスキング）。だが、マスキングが照合するのは登録された文字列そのものだ。シークレットを base32 などで符号化してから出力すると、伏せ字の対象と一致せず、そのままログに残る——これがマスキング回避の原理である。防御の観点では「ログに秘密情報を出さない」「ログを閲覧・ダウンロードできる範囲を絞る」ことが要点になり、符号化そのものを完全に塞ぐのは難しい。

トークンはどこから来たか

Wiz は悪用されたトークンの出所として、インフォスティーラー（情報窃取型マルウェア）のログと過去のサプライチェーン攻撃で露出したトークンを挙げている。つまり Gheist は「新しい侵入口」を開けたのではなく、すでに世に出てしまった資格情報を自動化して刈り取ったキャンペーンだ。言い換えれば、流出済みの鍵を束で試す GitHub トークン 悪用 の自動化版であり、だからこそ鍵の失効と入れ替えという基本動作が効く。盗まれたトークンで GitHub 環境が実際に侵害された例は、Grafana Labs GitHubへの不正アクセス全容が詳しい。

この手口が特別な脆弱性を必要としない点は見落としやすい。書き込み権限のあるトークンと、ワークフローを実行できる標準の GitHub Actions の仕組みだけで成立する。CI のブランチ名を装った ci-sync- は、流れてくる通知やブランチ一覧の中では見過ごされやすい。日々 CI が走る環境ほど、1 本増えた「同期チェック」が紛れ込む余地がある。GitHub Actions の設定そのものを突く別型の攻撃は、GitHub Actions pull_request_target の設計ミスで解説している。

対策——ブランチ削除では終わらない

最初に押さえるべきは、ブランチを消しても露出は取り消せないという点だ。ログは取得済みで、盗まれた値は攻撃者の手元に残る。Wiz が推奨する対応を、やることと効果で並べる。

予防は多層で効かせる。基本となる GitHub Actions セキュリティの観点で、次を順に敷いていく。

・最小権限・短命のトークン：fine-grained PAT でリポジトリと権限を限定し、有効期限を短くする。長期トークンの使い回しをやめる
・private でも実行に承認を要求：公開リポと同じワークフロー承認を自組織にも敷き、未知のブランチが勝手に走らないようにする
・クラウド認証情報は secrets に置かない：AWS のアクセスキー等の長期資格情報を避け、OIDC で短命な資格情報を実行時に発行する。これが効けば、ログが抜かれても AWS Secrets Manager の列挙まで届きにくい
・想定外のワークフロー・ブランチを監視：.github/workflows/ への追加や見慣れないブランチの増加を検知し、secret scanning を有効にしておく

このうち OIDC への移行は Gheist のように「ログに出た値がそのまま使える」攻撃の実害を最も小さくする。盗まれて困る長期の鍵を、そもそも secrets に置かない構成に寄せることが最も効く対策だ。トークンが盗まれた後の被害を層で抑える考え方は、トークン窃取を多層で止める防御パターンにまとめている。

自システムの確認——痕跡を探す

まずローカルのリモート参照を更新し、ci-sync- で始まるブランチが無いかを見る。これは痕跡の探索であって、侵害の有無を確定する判定ではない。

# リモートの参照を取り直す
git fetch --all --prune

# ci-sync- で始まるリモートブランチを列挙する
git ls-remote --heads origin 'ci-sync-*'

次に、組織・リポジトリの監査ログで以下の観点を確認する。GitHub の監査ログ（UI またはログの API）で、User-Agent 文字列「gheist」からの API アクセス、ci-sync- ブランチの作成、そして作成直後に削除されたワークフロー実行の組み合わせを探す。

影響範囲——GitHub Actions シークレット流出は公開リポで止まり、private が本丸

GitHub は 2026年7月28日以降、公開リポジトリで不審なワークフロー実行を保留する保護を入れている。Wiz が確認した公開リポの Gheist のワークフローは、すべて実行されなかった。攻撃が「つまずいた（stumbles）」と評されるのはこのためだ。

問題は、この保護が private リポジトリと GitHub Enterprise Server（GHES）を対象外としていることだ。Wiz はそこで実際にワークフローが実行され、シークレットが持ち出されたと報告している。企業環境では後続活動として、流出したクラウド認証情報で AWS Secrets Manager を列挙する動きも観測された。公開リポで止まったという事実は安心材料ではなく、守りが手薄な private こそが本丸だという警告として読むべきだ。

なお、冒頭でも触れたとおり、実際に何組織でシークレットが露出したかは Wiz が公表していない。規模の数値（850 超・13,500 超）は侵害の試みの広がりを示すもので、成功した露出の件数とは別物である。

参照ソース

• Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles（Wiz Research）
• Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs（The Hacker News）