GitHub攻撃「wfx-loot」の概要とユーザー側の確認・対策手順

2026年11月12日から13日にかけて、GitHubアカウントやリポジトリを標的とした大規模な攻撃キャンペーン「wfx-loot」（一部では「WFX Phantom」とも呼ばれます）に関する調査報告が相次ぎ、開発者の間で注目を集めています。

「自分のGitHubアカウントやリポジトリも危険なのでは」と不安に感じた方も多いかもしれませんが、今回の事案はGitHub自体のシステム脆弱性が突かれたものではありません。外部で事前に窃取されていたGitHubの認証情報（Personal Access Token、OAuthトークンなど）を悪用した攻撃であることが報告されています。

この記事では、セキュリティ企業の調査報告で明らかになった「wfx-loot」の概要を整理したうえで、GitHubユーザーが今すぐ落ち着いて確認すべき点検ポイントと、クラウド側の永続化設定を含めた対策手順をわかりやすく解説します。

この記事でわかること
前提条件・対象読者
大規模攻撃キャンペーン「wfx-loot」で何が起きたのか
GitHubユーザーがまず確認すべき5つのポイント
今すぐ見直したいGitHubのセキュリティ対策
万が一不審な痕跡が見つかった場合の対処法
よくある質問
1. 個人利用でプライベートリポジトリしか使っていない場合も確認すべきですか？
2. 2段階認証（2FA）を設定していれば今回の攻撃は防げますか？
まとめ
次に読むおすすめ記事
参考情報

この記事でわかること

攻撃キャンペーン「wfx-loot」で何が起きたのか（原因と4つの注入手口）
自分のGitHubアカウントやリポジトリに影響がないか確認する5つの手順
トークン・Botアカウント・2段階認証（2FA）・GitHub Actionsの推奨対策
万が一、不審な痕跡が見つかった場合のGitHubおよびクラウド側の初動対応

前提条件・対象読者

GitHubの個人アカウント、または組織（Organization）のリポジトリを運用している開発者
GitHub Actionsやクラウドサービス（AWS・Azure・Google Cloudなど）、または npm を利用している方
アカウント設定やログの点検は、GitHubのWebブラウザ画面から特別なツールなしで実施できます

大規模攻撃キャンペーン「wfx-loot」で何が起きたのか

まずは、2026年11月12日にAikido Security、StepSecurity、SafeDepなどのセキュリティ企業から報告され、11月13日に国内でも報じられた「wfx-loot」キャンペーンの事実関係を整理します。

GitHub自体の脆弱性ではなく外部流出トークンの悪用

今回の事案は、GitHubのサーバーや認証基盤の欠陥（ゼロデイ脆弱性など）が直接攻撃されたわけではありません。外部で事前に窃取されていたGitHubの認証情報（Personal Access Token、OAuthトークンなど、4,837アカウント分）が攻撃に悪用されました。

対象となったのは個人の開発者アカウントだけでなく、自動化用のBotアカウントも含まれます（たとえばWebdriverIOプロジェクトのBotアカウントである wdio-bot が悪用された事例も報告されています）。つまり、認証情報の管理が適切で外部に流出していなければ、GitHubを使っているだけで自動的に被害を受けるものではありません。過度にパニックになる必要はありませんが、過去に発行したトークンや連携アプリの権限を見直す良い機会と言えます。

攻撃の流れと4つの不正コード注入パターン

攻撃者は入手した有効な認証情報を使い、2026年11月10日頃から自動化されたスクリプトで以下のような段階的な攻撃を行っていたと報告されています。

1. 書き込み権限の確認（プローブ）

6万1,764リポジトリに対し、無害なドキュメント修正を装った確認用プルリクエスト（タイトル docs: dependency audit notes、ブランチ名 wfx-docs など）を送り、書き込み権限があるリポジトリを特定しました。

2. 不正コードの注入（4パターン）

書き込み権限が確認されたリポジトリでは、少なくとも1,800以上のリポジトリで情報窃取用コードが実行された可能性が報告されています。StepSecurityの調査では、主に次の4パターンの注入手法が確認されています。

攻撃手法	具体的な内容
既存ワークフローへの注入	既存のGitHub Actions用YAMLファイルに不正な処理を追加する
シェルスクリプトへの注入	CIが実行する既存の `.sh` ファイルに不正コードを追加する
新規ワークフロー作成	新たなワークフローファイル（`security-audit.yml` 等）を追加する
npmフックへの注入	`.ci-*.sh` 等のスクリプトを追加し、`package.json` から実行する

特に注意したいのが、2番目の「シェルスクリプトへの注入」と4番目の「npmフックへの注入」です。既存のワークフローYAMLに変更がなくても、CIから呼び出される .sh ファイルが書き換えられていれば攻撃が成立します。また、npm のインストールフック（postinstall など）を使う手口では、CI環境だけでなく、攻撃期間中に該当コミットを取得して npm install を実行した開発者のローカルPCも影響を受ける可能性があります。

3. 痕跡の隠蔽

情報窃取の実行後、数分以内に悪意あるコミットを自動で取り消し（リバート）、GitHub Actionsの実行履歴やログごと削除して証拠を隠す手口が確認されています。コードの差分や最新のActions画面を見ただけでは気づきにくい点が特徴です。

窃取対象となった主な情報とクラウドへの永続化

対象カテゴリ	具体的に狙われた情報の例
GitHub関連	GitHubトークン、リポジトリのSecrets、CI/CD実行時の環境変数
クラウド認証情報	AWS、Azure、Google CloudのアクセスキーやOIDCトークン
パッケージレジストリ	npm、PyPI、crates.ioなどの公開用トークン
AIサービス関連	OpenAI、Anthropic、Cursor、GitHub CopilotなどのAPIキー

また、単に既存の認証情報を盗むだけでなく、窃取したクラウド権限を使ってAWSの長期アクセスキーを作成したり、AWS IAMロールの信頼ポリシーを変更したり、Azureのアプリ登録に wfx-ci-* という名前のフェデレーション資格情報を追加したりして、Secretsを更新しても侵入経路が残る「永続化」を試みる挙動も報告されています。

GitHubユーザーがまず確認すべき5つのポイント

自分のアカウントや管理しているリポジトリに不審な動きがないか、以下の5つのポイントを順番に確認しましょう。特に、攻撃開始時期とされる2026年11月10日以降の履歴を重点的にチェックします。

手順1：セキュリティログとセッションで不審な動きを確認する

はじめに、自分のGitHubアカウント自体に身に覚えのない操作やログインセッションが残っていないかを確認します。

GitHubにログインし、画面右上のプロフィールアイコンから Settings を開きます。
左側サイドバーの Archives 等にある Security log をクリックします。
過去90日以内の履歴から、2026年11月10日以降に身に覚えのない認証、トークン発行、SSH鍵追加、アプリ認可などがないか確認します。
続けて左サイドバーの Access セクションにある Sessions を開き、身に覚えのないWebセッションやGitHub Mobileセッションがあれば Revoke で終了させます。

組織（Organization）を管理している場合は、組織設定の Audit log もあわせて確認してください。なお、個人アカウントの Security log に異常が見当たらなくても、それだけで完全に侵害されていない証明にはならないため、以下のリポジトリ側の点検も必ず実施してください。

手順2：リポジトリのPR・ブランチ・コミット履歴を確認する

次に、自分が管理または書き込み権限を持っているリポジトリに、不審な動きがなかったか確認します。今回の攻撃ではPRや不正ブランチ自体が削除される場合もあるため、現在残っているPRやブランチの一覧だけでなく、コミット履歴や Audit log も含めて確認することが重要です。

対象リポジトリの Pull requests タブを開き、Closed も含めて docs: dependency audit notes のような見覚えのないPRがないか確認します。
Branches 一覧を開き、wfx-docs のような見知らぬブランチが残っていないか確認します。
ローカルにリポジトリがある場合は、ターミナルでリモート情報を最新化したうえで、全ブランチ・全参照を対象に直近のコミット履歴を確認します。

git fetch --all --prune
git log --all --since="2026-11-10" --oneline --decorate

必要に応じて git reflog --all でローカル環境の参照変更履歴を確認することもできますが、reflog はあくまでローカルPC上の記録であり、GitHubリモート上のすべての操作を復元できるわけではない点に留意してください。

手順3：GitHub Actionsの実行番号の抜け（欠損）を確認する

今回の攻撃では、不正なワークフローを実行したあとに「実行履歴そのものを削除する」という隠蔽工作が行われます。GitHub Actionsの実行番号（run_number）はワークフローごとに採番され、削除された実行の番号が再利用されるわけではありません。そのため、攻撃者が実行履歴を削除すると、前後の実行番号に欠番が残る場合があります。

リポジトリの Actions タブを開きます。
左側の一覧から、確認したいワークフローを1つずつ選択します（リポジトリ全体ではなく、必ず同じワークフロー内で番号を比較します）。
実行履歴の番号が連続しているかを確認し、2026年11月10日以降の時間帯で不自然な番号の抜けがないかチェックします。

ただし、通常の運用で管理者が手動削除した場合などにも欠番は生じるため、欠番だけで不正実行を断定することはできません。不審なコミットやPRの履歴と時間的な一致があるかを照合して判断してください。

手順4：発行済みのPAT・連携アプリ・CLI・SSH鍵を棚卸しする

外部に漏洩すると悪用されやすい認証情報を、Settings 画面からすべて点検しましょう。

Personal Access Token（PAT）の確認

左サイドバーの Developer settings を開き、Personal access tokens 配下の Fine-grained tokens と Tokens (classic) の両方を確認します。使っていない古いトークンや用途が不明なトークンがあれば、Delete（または Revoke）で無効化してください。

連携アプリ・GitHub CLIのOAuthトークン確認

左サイドバーの Applications（Integrationsセクション）を開き、Authorized GitHub Apps および Authorized OAuth Apps のタブを確認します。以前試しただけの外部サービスや、GitHub CLIなどで過去に認証したまま使っていないOAuthトークンに強い権限が残っていれば、Revoke で連携を解除します。

SSH鍵・デプロイキーの確認

左サイドバーの SSH and GPG keys を開き、現在使っていないPCの古いSSH鍵が残っていないか確認します。リポジトリ単位で登録する Deploy keys（リポジトリの Settings → Deploy keys）もあわせて見直しておくと安心です。

手順5：Botアカウントの権限とnpm利用環境を確認する

個人用アカウントだけでなく、CI/CDや自動リリース用に運用しているBotアカウントがある場合は、そのBotアカウントが保持しているPATやOAuth認証も必ず棚卸ししてください。特に、ブランチ保護ルールをバイパスできる権限を持つBotアカウントは最小限に絞っておくことが推奨されます。

また、GitHub Actionsを利用していなくても、攻撃対象となった公開リポジトリを2026年11月10日以降にローカルへ取得し、悪意ある postinstall フック等が含まれた状態で npm install を実行していた場合は注意が必要です。該当する場合は、使用していたPCのマルウェア調査に加え、その端末上で扱っていたGitHubやクラウドサービスの認証情報も漏洩した可能性を考慮してください。

今すぐ見直したいGitHubのセキュリティ対策

点検の結果、問題がなかった場合でも、設定の甘さを突かれないために以下の対策を取り入れておくことをおすすめします。

Classic PATからFine-grained PATへ移行・最小権限化する

従来の Tokens (classic) は、一度発行するとアカウント内の全リポジトリに対して広い権限を持ってしまうケースが多く、万が一漏洩した際の影響範囲が大きくなりがちです。

GitHubが推奨している Fine-grained personal access tokens を使えば、以下の制限をかけられます。

アクセスを許可するリポジトリを特定のものだけに限定する（Only select repositories）
必要な権限（Contentsの読み取りのみ、など）だけを細かく指定する
必ず有効期限（Expiration）を設定し、無期限のトークンを作らない

ローカルPCにトークンを平文ファイルで保存したり、.env やスクリプト内に直書きしたりする運用も避け、認証情報マネージャーやシークレット管理ツールを適切に利用してください。

2段階認証（2FA）の維持とパスキー・認証アプリの活用

Settings → Password and authentication を開き、認証方式としてSMSではなく認証アプリ（TOTP）やパスキー（Passkeys）、ハードウェアセキュリティキーが設定されているか、またリカバリコード（Recovery codes）が安全なオフライン環境に保管されているかを確認しましょう。

ただし、2FAを有効にしていても、すでに発行済みのPATやOAuthトークン、SSH鍵が外部に漏洩すればリポジトリへアクセスされてしまいます。2FAとトークンの定期的な棚卸しはセットで運用してください。

GitHub Actionsとクラウド連携（OIDC活用）の強化

GitHub Actionsを使ってAWS・Azure・Google Cloudなどへデプロイしている場合、長期間有効なアクセスキーをリポジトリのSecretsに保存していると、流出時の被害が大きくなります。

可能であればOpenID Connect（OIDC）を利用した一時的な認証情報の発行へ切り替えることで、静的なクラウド認証情報をSecretsに保存せずに済みます。また、ワークフローファイル内で GITHUB_TOKEN の権限をデフォルトで読み取り専用など最小限に絞っておくことも、GitHub公式ドキュメントで推奨されている有効な対策です。

万が一不審な痕跡が見つかった場合の対処法

確認の結果、不審なPRやActionsの実行番号の抜け、身に覚えのないセキュリティログが見つかった場合は、以下の手順で速やかに対処してください。

侵害が疑われるGitHubアカウント（およびBotアカウント）のパスワード変更、全PAT・OAuthトークンの無効化（Revoke）、不審なSSH鍵・アクティブセッションの削除を行います。
リポジトリの Secrets に登録していたAPIキー（OpenAI・Anthropic・npm・PyPIなど）をすべて再発行・無効化します。
クラウド環境（AWS・Azure・Google Cloud）の認証情報を連携していた場合は、GitHub側のSecretsを更新するだけでは不十分です。各クラウドの管理画面へログインし、少なくとも以下の永続化設定が仕込まれていないか必ず監査してください。

クラウド環境	確認すべき不審な変更
AWS	見覚えのないIAMアクセスキーが新規作成されていないか
AWS	IAMロールの信頼ポリシーが不審な外部アカウント等へ変更されていないか
Azure	`wfx-ci-*` という名前のフェデレーション資格情報が追加されていないか
Azure	アプリ登録に身に覚えのないフェデレーション資格情報が追加されていないか

開発者のローカルPC上で悪意ある npm フック等を実行した可能性がある場合は、端末のウイルススキャンやOSのクリーンインストールも検討してください。

よくある質問

個人利用でプライベートリポジトリしか使っていない場合も確認すべきですか？

はい、確認しておくことをおすすめします。攻撃者は外部で入手した認証情報を使って機械的にアクセスを試みるため、パブリックかプライベートかを問わず、そのトークンがアクセス権を持つすべてのリポジトリが対象になり得ます。特にローカルPCに古いPATを保存したままにしている場合は、一度棚卸ししておくと安心です。

2段階認証（2FA）を設定していれば今回の攻撃は防げますか？

ブラウザなどからの通常ログイン時の不正アクセスは2FAで防げますが、一度発行されたPATやOAuthトークン自体が外部に流出した場合、トークンを使ったAPIやGit操作には2FAの都度入力が求められません。そのため、2FAの維持に加えて「不要なトークンの削除」「Fine-grained PATによる最小権限化・期限設定」が重要になります。