はじめに

GitHubのリポジトリに、ある日「Add security audit workflow」というコミットが入っていたら、それは攻撃かもしれません。

歯車のパイプラインから幽霊のような影が鍵を抜き取り、遠くのサーバーへ運ぶイラスト

2025年9月に見つかった GitHub Actions を悪用する認証情報窃取キャンペーン GhostAction が、2026年8月末から再び活発になっています。盗んだメンテナーのアカウントで「セキュリティ監査」を装ったワークフローを仕込み、リポジトリに設定されたシークレットや、コード内のAWS・AIサービスのAPIキーを外部のサーバーへ送るという手口です。10月8日の新しい波では、全ブランチ・タグの履歴を対象に、過去に削除した鍵も探す機能が加わりました（公開された実装には処理量の上限があります）。

この記事では、何が起きたのか、どれくらいの規模か、自分のリポジトリをどう確認し、どう守るかをまとめます。内容は2026年10月12日に確認した GitGuardianの報告（10月7日、9日追記）、StepSecurityの分析（10月9日）、Socketの分析（10月9日）、The Hacker Newsの報道（10月9日）にもとづきます。件数は各社の集計時点のもので、今後変わる可能性があります。本記事で攻撃を再現・検証したものではありません。

GhostActionの手口

StepSecurityとGitGuardianの説明を合わせると、流れは次のとおりです。

  1. アカウントの乗っ取り: メンテナーのGitHub認証情報を入手する。StepSecurityは、情報窃取マルウェア（インフォスティーラー）のログなどから流出した個人アクセストークン（PAT）である可能性が最も高いとしています
  2. 下調べ: 既存のワークフローに書かれた ${{ secrets.名前 }} を読み、そのリポジトリが使っているシークレットの名前を把握する
  3. 仕込み: 「Security Audit」（security-audit.yml）や「Github Actions Security」（github_actions_security.yml）という名前のワークフローを、本人の名義で既定ブランチに直接コミットする
  4. 送信: ワークフローが動くと、シークレットの値などを暗号化されていないHTTPで攻撃者のサーバー（IPアドレス直指定）へ送る

本人のアカウントで普通にコミットされるため、監査ログを見ても、ワークフローの中身を確認しない限り異常に気づきにくいとStepSecurityは指摘しています。

2026年の被害規模

8月31日〜9月30日の波（GitGuardian）

  • 772の公開リポジトリ（373のユーザー・組織）に悪性ワークフローが入れられ、狙われたシークレットは 2,577件。SSH秘密鍵、Azure、コンテナレジストリ、データベース、AWSなどの認証情報が多い
  • ただし、GitHubが多くの実行を承認待ちで止めており、集めた3,669件の実行記録のうち実際に動いたのは32リポジトリでの499件。成功した336件で、13リポジトリから26件のシークレットが持ち出されたとしています
  • 10月5日までに公開履歴上で悪性ワークフローを取り除いたと確認できたのは、124リポジトリ（16%）にとどまりました

10月8日の波（StepSecurity・Socket）

  • 人気ゲームエンジン pyxel の作者のアカウントで27リポジトリ（10月8日 13:20 UTC＝日本時間22:20から）、Uberの athenadriver の作者のアカウントで318リポジトリ（うち279はフォーク、10月8日 21:10〜21:26 UTC＝日本時間10月9日 6:10〜6:26）に、同じワークフローが入れられました。合計はStepSecurityの集計で345、Socketの集計で346リポジトリです
  • athenadriverでは、ワークフロー開始の4秒後に攻撃者のサーバーが受信を返しており、送信の成功が確認されています
  • Socketは10月9日の追記で、10月7日以降、500を超えるGitHubアカウントから数万のリポジトリへ同じワークフローがコミットされていると報告しました
  • 10月9日付のStepSecurity・Socketの報告では、盗まれた公開用の認証情報による悪意あるパッケージの公開は確認されていません（本記事で10月12日まで独自に確認したものではありません）。ただしStepSecurityは「悪用が見られないことは安全の証拠ではない」とも述べています

10月の新型は何が違うのか

StepSecurityによると、10月の「Security Audit」ワークフローは次の4つを行います。

  • リポジトリに設定された名前付きシークレットの値を集める（従来どおり）
  • 作業ツリーから、AWSのアクセスキー、Anthropic・OpenAI・OpenRouterのAPIキー、GitHub・GitLabのトークン、Google/Firebase、Slack、SendGrid など13種類の認証情報のパターンを探す
  • git log -p --all で全ブランチ・タグの履歴を対象に同じパターンで探す。昔コミットしてすぐ消した鍵も対象になる。ただしSocketが掲載したコードでは、履歴の差分は先頭20万行まで、履歴から抜き出す結果は300行までといった処理上限があり、どんな履歴でも走査し終えるわけではない
  • AWSのアクセスキーIDの前後の行も取り込み、対応するシークレットキーとの組み合わせを狙う

上限があっても、どの鍵が読まれたかは外から判断できません。このためStepSecurityは、「Actionsのシークレットを入れ替えるだけでは足りない。リポジトリに一度でもコミットされた認証情報は、すべて漏れたものとして扱うべきだ」としています。

GhostActionの流れの図。1 流出したトークンなどでアカウントを乗っ取る、2 既存ワークフローからシークレット名を調べる、3 偽のSecurity Auditワークフローを既定ブランチへ直接コミット、4 シークレットと、作業ツリー・全ブランチとタグの履歴（処理上限あり）から探した鍵をHTTPで外部へ送信。止めどころとして、トークンの最小権限と期限・2要素認証、ワークフロー変更にレビュー必須、ワークフロー実行の承認（何に適用されるかを確認）、送信先の制限、鍵をコミットしないことを示す
図：GhostActionの流れと、各段階での止めどころ（StepSecurity・GitGuardianの報告をもとに作成。図を選ぶと大きく表示できます）。

自分のリポジトリを確認する

StepSecurityは、次のような確認を勧めています。

  • .github/workflows/ に security-audit.yml、github_actions_security.yml、security-check.yml が身に覚えなく追加されていないか（既定ブランチ以外も含めて）
  • コミットメッセージ「Add security audit workflow」「Add Github Actions Security workflow」「Trigger security scan」などがないか
  • GitHubのコード検索で、自分のアカウントや組織に絞って "193.32.204.199" path:.github/workflows などを検索する（ただし検索に出ないことだけで安全と判断しない。既定ブランチ以外や削除済みの実行は検索に出ないことがあります）
  • 2026年8月31日以降のActionsの実行履歴に、「Security Audit」「Github Actions Security」の実行がないか

該当するワークフローが入っていた場合、StepSecurityは侵害が確定したものとして扱うよう求めています。

見つかった場合の対応

StepSecurity・GitGuardianの推奨をまとめると、次のとおりです。

  1. 入口になったGitHubの認証情報を特定して無効化する: GitGuardianは、同じ流出トークンが複数の攻撃者に使い回されている形跡があるとして、シークレットの入れ替えだけでは別の攻撃者に再び使われると警告しています
  2. シークレットと、履歴にある鍵をすべて入れ替える: Actionsのシークレットに加え、過去に一度でもコミットした認証情報も対象
  3. 悪性ワークフローを全ブランチから削除し、フォークも確認する
  4. 後片付けが済むまでリリースしない: PyPI・npm・crates.io・コンテナレジストリの公開用トークンがあった場合、攻撃者が本人名義で公開できる前提で動く

個人開発者がふだんからできる対策

  • トークンは最小権限・期限付きに: 使っていない個人アクセストークンは削除し、必要なものもリポジトリと権限を絞る。GitHubアカウントには2要素認証（できればパスキー）を設定する。ただし、すでに盗まれたトークンは2要素認証を後から追加しても使えてしまうため、無効化が別に必要です
  • 端末をインフォスティーラーから守る: 入口は流出したトークンとみられています。出所不明のツールや「便利スクリプト」を開発用PCで実行しない
  • ワークフローの変更にレビューを必須にする: StepSecurityは、ブランチ保護で .github/workflows/ の変更をプルリクエストのレビュー必須にするよう勧めています
  • ワークフロー実行の承認を活用する: 9月の波ではGitHubが多くの実行を承認待ちで止め、10月7日の事例でも、ワークフロー実行に承認が必要な設定のリポジトリ（1件）では送信が実行されませんでした。StepSecurityは、今週この攻撃の送信を止めたと確認できた唯一の対策が承認だったとしています。ただし、フォークからのプルリクエストの実行承認は、メンテナーによる直接pushまで一律に止めるわけではありません。Environment（環境）の承認は、その環境を参照するジョブとシークレットに適用されます。実行者やイベントを制限する設定もあるので、使う承認・実行制限が何に適用されるかを確認してください
  • 鍵をリポジトリに置かない: .env や設定ファイルにAPIキーを書いてコミットしない。過去の履歴も、シークレットスキャンのツールで一度確認しておくと安心です

AIエージェントに渡した権限が狙われる例は AIエージェントが乗っ取られる3つの経路 でも扱っています。

まとめ

  • GhostActionは、乗っ取ったメンテナーのアカウントで偽の「セキュリティ監査」ワークフローを仕込み、シークレットやAPIキーを外部へ送る攻撃。2026年8月31日〜9月30日に772リポジトリが狙われ（GitGuardian）、10月8日にも約345のリポジトリへ一斉に仕込まれた（StepSecurity）
  • 10月の新型は、全ブランチ・タグの履歴を対象に削除済みの鍵も探す（公開実装には処理上限あり）。シークレットの入れ替えに加え、入口となったGitHubの認証情報の無効化が必要
  • 10月9日付のStepSecurity・Socketの報告では、盗まれた公開用の認証情報による悪意あるパッケージの公開は確認されていない
  • 対策は、トークンの最小権限化と2要素認証、ワークフロー変更のレビュー必須化、実行の承認（適用対象を確認したうえで）、鍵をコミットしないこと

「セキュリティ」という名前のコミットほど、中身を確かめる価値があります。