GitHubを狙うサプライチェーン攻撃「GhostAction」の新しい波で、乗っ取られた開発者(メンテナ)のアカウントから、346のリポジトリに偽のワークフローが仕込まれました。セキュリティ会社のSocket、StepSecurity、OpenSourceMalwareが、2026年10月9日前後に相次いで報告しました。
仕込まれたのは、GitHub Actions(ソフトの自動テストや公開に使う仕組み)の設定ファイルです。セキュリティ点検を装っていますが、実際には認証情報を盗んで外部へ送ります。この記事は、各社の報告をもとに、起きたことと、自社や委託先がGitHubを使う場合の点検・対応を整理します。攻撃の手順や中身のコードは扱いません。
何が起きたのか
Socketの報告によると、2026年10月8日、乗っ取られた2つのメンテナのアカウントから、書き込みできるすべてのリポジトリに、.github/workflows/security-audit.yml という1ファイルを加えるコミットが押し込まれました。コミットのメッセージは「Add security audit workflow」などで、一見すると安全のための追加に見えます。
| 項目 |
報告の内容 |
| 時期 |
2026年10月8日 |
| 仕込まれた数 |
346のリポジトリ(Socket)。StepSecurityは345とする |
| 使われたアカウント |
著名なオープンソースの開発者2名のアカウント(乗っ取り) |
| 含まれた著名なプロジェクト |
ゲームエンジンpyxel(1万8千スター超)、Uberのathenadriverなど |
| 送信先 |
攻撃者のサーバー(ハードコードされた1つのIPアドレス)へ、平文(暗号化なし)のHTTPで送信 |
| 広がり |
Socketは10月9日の追記で、10月7日以降、500を超えるアカウントが数万のリポジトリに同じワークフローを入れたとしている。OpenSourceMalwareは10月9日時点で790の公開リポジトリを確認 |
攻撃者がどうやってアカウントの認証情報を手に入れたかは、報告でも分かっていません。athenadriverは、元の作者が今も書き込み権限を持っていたため、主要なブランチに直接ワークフローが追加されました。
GhostActionは、2025年9月にGitGuardianが最初に報告したサプライチェーン攻撃です。手口(盗んだメンテナの認証情報で、それらしい名前のワークフローを仕込む)は同じですが、盗む対象が広がりました。
今回の特徴: 過去のコミット履歴まで探す
これまでのGhostActionは、GitHub Actionsに登録された秘密情報(Secrets)だけを盗んでいました。今回のワークフローは、それに加えて、リポジトリの中身と、過去の全コミット履歴を正規表現で走査し、クラウドやAIのサービス(AWS、GitHub、OpenAIなど)の鍵やトークンを探します。AWSの鍵の近くのコードも一緒に取り込みます。
重要なのは、いま使っているコードから鍵を消していても、過去のコミットに残っていれば見つかる、という点です。「消したから大丈夫」とは言えません。
StepSecurityは、athenadriverの実行記録を調べ、ワークフローの実行から4秒後に攻撃者のサーバーが受信を返したことを確認したとしています。ただし、有効な認証情報がどれだけ流出したかは、確認できていません。Socketは、この活動に由来する不正なパッケージがPyPIやcrates.ioに公開されたのは、報告の時点では見ていないとしています。
自社は関係あるか
- 自社でGitHubを使ってソフトを開発・公開している会社。GitHub Actionsを使っていれば、今回の手口の対象になり得ます。
- 開発を外部に委託している会社。委託先のGitHubのアカウントやリポジトリが対象になり得ます。
- 自社が、オープンソースのソフトやパッケージを取り込んで使っている会社。取り込み元が汚染されると、影響が及ぶおそれがあります。
- GitHubをまったく使っていない会社は、この手口の直接の対象ではありません。ただし、同じ考え方は、ほかのコード管理サービスや自動化の仕組みにも当てはまります。
点検の手がかり(各社が公表した指標)
各社は、感染を探す手がかり(IoC)を公表しています。守る側が点検に使うものです。
- ファイル名: 各リポジトリの
.github/workflows/ に security-audit.yml という身に覚えのないファイルがないか
- コミットの仕方: デフォルトのブランチに、PR(プルリクエスト)を経ずに、メンテナの名前で直接ワークフローが追加されていないか
- 送信先のIPアドレス:
193.32.204[.]199。コードや実行記録、通信ログにこのアドレスが出ていないか
- 目印の文字列: StepSecurityは、ワークフローに含まれる
AKIA_CTX_START や c=monami などの文字列を、点検の目印として挙げています
StepSecurityは、GitHubのコード検索や組織のログで、これらの目印を探す方法を公表しています。見つかれば、感染したリポジトリか、感染したものを複製(フォーク)したリポジトリの疑いがあります。
情シス・開発チームが今日やること
- 開発者のアカウントを守る。 GitHubのアカウントに二要素認証やパスキーを有効にします。アクセストークンや、連携しているアプリの権限を見直し、不要なものは消します。アカウントの乗っ取りが、今回の起点です。
- ワークフローを点検する。 自社と委託先のリポジトリの
.github/workflows/ に、身に覚えのないファイル(security-audit.yml など)がないかを確かめます。上の「点検の手がかり」の目印も使います。
- デフォルトブランチへの直接の追加を確かめる。 PRを経ずに、ワークフローが直接追加されたコミットがないかを、監査ログで見ます。
- 鍵とトークンを失効・再発行する。 感染の疑いがあれば、GitHubのトークン、クラウド・AI・SaaSの鍵、パッケージ公開用の認証情報を、失効して作り直します。ワークフローを消すだけでは、すでに盗まれた鍵は無効になりません。
- 過去の履歴の鍵も見直す。 過去にコミットして消した鍵が、履歴に残っていないかを確かめ、残っていれば作り直します。
- 公開物とデプロイを監査する。 攻撃の期間に公開したパッケージや、デプロイしたシステムに、不正な変更がないかを確かめます。委託先にも、同じ点検を依頼します。
書かれていないこと
- GitHub社自身の公表。2026年10月13日に確認した範囲では、今回の波についてのGitHubの公式の発表は見当たりませんでした
- 攻撃者がメンテナのアカウントの認証情報を、どうやって手に入れたか
- 流出した有効な認証情報の数と、それによる二次被害の範囲
- 日本の開発者や企業の被害
攻撃の手順や、ワークフローの中身のコードは、この記事では扱いません。点検は、各社が公表した手がかりをもとに、社内の開発担当や委託先、専門の事業者と進めてください。
2026年10月13日時点の内容です。
