GhostAction：悪意あるワークフローを数万リポジトリへ

攻撃者はあなたの CI を破る必要はありません。信頼されたアカウントでファイルを 1 つ push すれば済みます。それが GhostAction の手口です。

攻撃の進み方

StepSecurity の分析は 2 つの具体例を示しています。

• まずゲームエンジン pyxel の作者 Takashi Kitao 氏（GitHub で 1.84 万スター）のアカウントが侵害されました。13:20 UTC から、そのアカウントで 27 リポジトリへ悪意あるワークフローが push されました。
• 8 時間後、Uber のオープンソースプロジェクト athenadriver の原作者 Henry Wu 氏（アカウント henrywoo）が侵害されました。21:10 から 21:26 の 16 分間に、同アカウントで 318 リポジトリへ同じワークフローが push されました。

2026 年 10 月 9 日時点で、セキュリティ企業 Socket の監視によれば、10 月 7 日に拡散期へ入って以降、500 を超える GitHub アカウントが数万のリポジトリへこのワークフローをコミットしています。

新しい活動でもありません。GhostAction は 2025 年 9 月に初めて表面化し、当時 327 名のユーザー名義で 817 リポジトリに及び、3325 組の資格情報が窃取されました。

ワークフローの姿

侵害された 2 つのアカウントが push したファイルは次のとおりです。

• security-audit.yml、ワークフロー名 Security Audit
• github_actions_security.yml、ワークフロー名 GitHub Actions Security

名前そのものが偽装です。セキュリティ監査と聞けば、自分から開きたくなるはずです。

発動条件は workflow_dispatch と、フィルタのない push（任意のブランチ、任意のタグ）です。実行されると fetch-depth: 0 で全コードを取得し、Audit という単一ステップで 4 つの処理を行います。

1. 偵察段階で見つけたリポジトリの名前付きシークレットを追加する。
2. 作業ディレクトリを 13 種類の資格情報パターンで走査する。
3. git 履歴全体を同じパターンで走査し、削除されたが履歴に残る資格情報を集める。
4. AWS アクセスキー ID と対応するシークレットキーを自動で組み合わせ、使える資格情報対にする。

外部送信は平文 HTTP で、宛先 IP は 193.32.204.199 です。

なぜ git 履歴が本質か

第 3 段階がチェーンで最も価値のある部分です。

多くの人はシークレットを消すとき、それを取り除いた新しいリビジョンをコミットします。しかし git は古いリビジョンを保持します。履歴を走査すれば、とっくに片付けたと思っていたものが手に入ります。

「削除した」と「存在しない」は git では同じではありません。

GitGuardian が同週に公表した報告はより広い数字を示します。2026 年 8 月 31 日から 9 月 30 日の間に、GhostAction は 373 名のユーザーと組織名義の 772 の公開リポジトリへ同ワークフローを push し、2577 組の資格情報を狙いました。SSH 秘密鍵、Azure 資格情報、コンテナレジストリ、データベース、FTP、Google Cloud と Firebase、GitHub トークン、Telegram・Slack・Discord のボットトークンなどです。

拡散経路：フォーク

Socket は見落としやすい細部を挙げています。henrywoo 名前空間の 279 のフォークがすべてこのワークフローを保持しているという点です。

感染面は元のリポジトリに留まりません。フォークで Actions が有効なら、その後の push が資格情報窃取を発動します。私有フォークと下流ミラーが最も危険です。私有リポジトリには実際に有効な資格情報が置かれがちだからです。

いま何をすべきか

この期間に push があったなら、次の順序を勧めます。

1. 2026 年 8 月 31 日以降のコミットで security-audit.yml と github_actions_security.yml を探す。
2. 見つかれば侵害と判断し、GitHub の資格情報を失効させ、関連する鍵をすべてローテーションする。
3. 悪意あるワークフローをすべてのブランチから削除する。既定ブランチだけでは不十分です。
4. 影響を受けたリポジトリのフォークをすべて確認する。

3 番目は飛ばされがちです。既定ブランチだけを掃除すると、他のブランチにワークフローが残ります。

私の判断

本質は GitHub Actions が安全でないことではありません。アカウントとリポジトリの信頼関係が広すぎることです。

1 つのアカウントが侵害されれば、到達できるすべてのリポジトリへ push できます。ワークフローが一度着地すれば、そのリポジトリのシークレットと git 履歴全体を手にします。攻撃者が本当に破る必要があるのは 1 つ、PAT だけです。

したがって有効な削減は YAML を注意深く読むことではなく、公開権限を細分化することです。ワークフローには最小権限のトークン、本番シークレットはリポジトリシークレットに入れない、既定ブランチに書き込み保護を付ける。どれも新しくはありません。ただ、また価値があると証明されただけです。