対象：GitHubでリポジトリを管理・開発している個人と組織、GitHub Actionsやクラウドの認証情報（OIDC連携を含む）を使っている人。本記事は調査したセキュリティ企業の公開記事と関係する事業者の告知にもとづく解説で、攻撃の手順は扱いません。
続報待ち：この記事は公式発表に合わせて更新します
- 対象者
GitHubでリポジトリを管理・開発している個人と組織、GitHub Actionsやクラウドの認証情報（OIDC連携を含む）を使っている人。
- 影響が確認された範囲表で見る ↓
- 約4,800アカウントの不正利用
- 61,764のリポジトリへの確認用プルリクエスト
- 悪意ある変更を受けたリポジトリ
さらに3件
- 不正なコードの実行と認証情報の外部送信
- 秘密情報とクラウド認証情報の窃取
- 公開されたパッケージへの混入
可能性があるとされた項目
- クラウド側の仕掛け（入れ替えても残る設定）
- 未確認事項
- 被害アカウントとリポジトリの確定数（調査した企業ごとに数え方が違う）
- 最初にトークンが盗まれた経路（クラウド事業者の件を除き、全体としては確認されていない）
- GitHubの公式の発表（11月14日に確認した範囲では記載なし）
さらに2件
- 同じ攻撃者による10月の別の事案との関係（企業AとCは同一と断定していない）
- クラウド事業者のトークンの失効の完了（同事業者が、途中で止まったと追記している）
- 今やること手順を見る ↓
- 見覚えのないプルリクエスト・ブランチ・Actionsの実行がないか確かめる
- 侵害されたアカウントのトークン・許可・セッションを失効させる
- 不正な変更が入った疑いがあれば、そのリポジトリで読める秘密情報とクラウドの権限を入れ替える
さらに3件
- クラウド側に、入れ替えても残る変更がないか点検する
- トークンと第三者アプリの棚卸しをする
- 自分のアプリが、バージョン管理のフォルダを公開していないか確認する
- 最終確認日時
- 2026年11月14日時点
発表の続報予定と確認の記録
調査した企業の記事はいずれも11月12日の公表で、数字は更新される可能性があると読める書き方です。2026年11月14日に確認した範囲では、GitHubのブログ、更新履歴、障害情報にこの件の記載は見当たりませんでした。
リポジトリの管理者・開発者が今日やること
見覚えのないプルリクエスト・ブランチ・Actionsの実行がないか確かめる
自分のアカウントが書き込めるすべてのリポジトリ（協力者として入っている組織のものも）で、11月10日以降の次の3つを確かめます。企業Aによれば、確認用のプルリクエスト61,839件のうち10,431件は、そのアカウントの持ち物ではない、協力者や組織の権限で届くリポジトリに送られていました。
- プルリクエスト一覧に、自分も同僚も出していないものがないか。タイトルが文書の更新のような無害な内容でも、同じ形のものが多数のリポジトリにあれば要注意
- ブランチ一覧に、心当たりのない短命なブランチや、作って消された形跡がないか
- Actionsの実行履歴に、見覚えのない実行や、実行番号の飛び（欠け）がないか。企業AとCは、攻撃者が実行とログを短時間で消すため、番号の欠けが手がかりになると書いています。組織の監査ログも見てください
見つかったら、次の手順に進みます。企業Aは、実行されなかった場合も含め、確認用のプルリクエストがあればそのアカウントは侵害されていると書いています。
侵害されたアカウントのトークン・許可・セッションを失効させる
企業Bと企業Cの案内にもとづく順序です。
- 個人アクセストークン、第三者アプリ（OAuthアプリ・GitHubアプリ）への許可、SSH鍵、ログイン中のセッションをすべて取り消し、必要なものを作り直す
- 2段階認証を有効にする。ただし、すでに盗まれたトークンは2段階認証を通らずに使えるため、トークンの失効が先です（当サイトの見解）
- 見つかった確認用のプルリクエストを閉じ、心当たりのないブランチを消す。消す前に、どのアカウントの名前で作られたかを記録しておく
不正な変更が入った疑いがあれば、そのリポジトリで読める秘密情報とクラウドの権限を入れ替える
企業AとBは、悪意ある変更が実行された場合、そのワークフローが読めた秘密情報とクラウドの権限は、すべて盗まれたものとして扱うよう書いています。
- Actionsのシークレットと変数（リポジトリ、環境、組織の各レベル）、公開用のトークン（パッケージの公開を含む）、デプロイ用の鍵を新しく発行し、古いものを無効にする
- OIDCでクラウドに入る設定がある場合、そのクラウドの権限も対象にする（次の手順）
- 変更が入った疑いのあるリポジトリを開発端末でビルドした場合は、その端末も、読めた認証情報（SSH鍵、クラウドの認証情報、パッケージ公開のトークンなど）を入れ替える対象にする。企業BとCは、変更の中に、パッケージのインストール時に動く形のものがあったと報告しています
- 11月10日以降にパッケージを公開したリポジトリは、公開された版が悪意ある変更を含んでいないか確認し、含むなら取り下げて、きれいな状態から再公開する
クラウド側に、入れ替えても残る変更がないか点検する
企業Aは、秘密情報を入れ替えても残る変更として、AWSのロールの信頼ポリシーの書き換えと、Azureの認証連携の追加を挙げています（企業BはAWSのアクセスキーが残る点も指摘）。次の2か所を、監査ログと現在の設定の両方で確認します。
- AWS：新しいアクセスキーの作成、ロールの信頼ポリシーの変更（意図しないアカウントや条件に広がっていないか）
- Azure（Entra ID）：アプリケーションに追加された、リポジトリと連携する認証（フェデレーション認証）
これとは別に、盗んだ認証情報で権限を広げる操作（権限昇格）の点検として、次も見ます。Google Cloudはサービスアカウントの不審な利用やトークン発行の呼び出し、Vault・KubernetesはGitHubのOIDCでの心当たりのないログインです。
見つからなくても、OIDCの信頼条件を、リポジトリ・ブランチ・環境まで絞っているかを確認します（次の「見直すこと」）。
トークンと第三者アプリの棚卸しをする
GitHubの設定で、次を一覧にして、不要・心当たりなしのものを消します。
- 個人アクセストークン：使っていないものは消し、残すものは範囲（リポジトリと権限）と期限を絞る
- 連携を許可したOAuthアプリ・GitHubアプリ：ホスティングやCIなど、デプロイのために連携したものを含む。使っていないものは許可を外す
- SSH鍵とデプロイキー：使っていない鍵と、持ち主のいない鍵を消す
- ボットや自動化用のアカウントの権限：保護されたブランチの規則を迂回できるものがないか
あるクラウド事業者のアプリは、同事業者の告知によれば、再連携が必要になっています。使っている人は、同事業者の案内に従ってください。
自分のアプリが、バージョン管理のフォルダを公開していないか確認する
同じ事業者は、GitHub経由でデプロイしたアプリのうち一部が、ビルド用のディレクトリごとを公開していたため、そこに残ったトークンを取られたと説明しています。自分のアプリの公開URLから、バージョン管理のフォルダ（.git）の中身が取れないかを確かめ、取れる場合はイメージに含めない設定にして再デプロイし、そこに入っていた認証情報を入れ替えます。使っているデプロイ基盤が、同じ仕組みを使っていないかも見ます。
何が起きたのか（調査した企業と関係する事業者の発表より）
以下は、セキュリティ企業A・B・Cの公開記事（いずれも2026年11月12日の公表）と、あるクラウド事業者の告知（11月12日の夜に把握、13日に追記）にもとづきます。いずれも当事者や調査者自身の説明で、GitHubによる確認ではありません。時刻は特記がなければ協定世界時（UTC）です。
11月10日 12:45ごろ
企業Aによれば、攻撃者が、盗んだトークンを使って、トークンが書き込めるリポジトリで活動を始めた。リポジトリごとに、まず確認用のプルリクエストを送り、次に悪意ある変更を加え、1分ほどで元に戻し、実行とログを消した。企業Bも、悪意ある変更の最初の時刻を12:46と数えている。11月11日 15:00
企業Aが数えた確認用のプルリクエスト61,839件の期間の終わり。11月12日 04:36
企業Bが数えた、悪意ある変更を受けた公開リポジトリ8,093件の期間の終わり。11月12日 07:40
企業Cが、確認用のプルリクエストを63,000件以上と数えた時刻。同日、企業A・B・Cが記事を公表した。11月12日 22時（時間帯の記載なし）
あるクラウド事業者が、同社のGitHubアプリが発行したトークンが第三者によって顧客のリポジトリに使われたと把握したとして、告知を投稿した（同事業者の告知。把握は11月12日、時刻の記載なし）。11月13日 15時54分
同事業者が、全ユーザーのトークンの失効が途中で止まり、GitHubが調べていると追記した（同事業者の告知）。
盗まれた有効なトークン
書き込める権限があるかを、確認用のプルリクエストで試す
↓→
悪意ある変更
CIの秘密情報とクラウドの認証情報を集めて外部へ送る
↓→
痕跡の消去
変更を元に戻し、実行とログを削除。クラウド側に残る設定も
調査した企業ごとの数字（足し合わせない）
| 出所（役割） | 数えたもの | 数字 | 注意 |
|---|---|---|---|
| 企業A（最初に報告） | 確認用のプルリクエストを送ったアカウント／受けたリポジトリ | 4,837アカウント／61,764リポジトリ | 約92%が未対応のまま開いている（分母は、アカウントの持ち物でないリポジトリに送られた10,431件） |
| 企業A | 不正なコードが実行され、認証情報が外部へ送られたリポジトリ | 1,835以上（別の箇所では1,806） | 記事の中で2つの数字があり、下限の可能性があるとしている |
| 企業A | パッケージを公開できるアカウント | 少なくとも50 | npm、Go、PyPI、Packagist、cratesの公開権限と見られる |
| 企業B | 悪意ある変更を受けた公開リポジトリ（11月10日12:46〜12日04:36） | 8,093 | 実行された数ではない。内訳の合計は8,096で、差は説明されていない |
| 企業B | 確認用のプルリクエスト | 61,879件／4,833アカウント／61,734リポジトリ | 上の8,093には含まれない |
| 企業C | 確認用のプルリクエスト（11月12日7:40時点） | 63,000件以上 | 約90%が開いている。そのうち173件（19アカウント）が、あるクラウド事業者のGitHubアプリのトークン経由 |
| クラウド事業者（自社の告知） | 影響を受けた顧客のアカウントで見つけた確認用のプルリクエスト | 250件以上 | 影響を受けたのは少数としている |
企業Bは、数字はGitHubの検索にもとづき、公開リポジトリの既定ブランチだけを対象にするため、実際はもっと多い可能性が高いと書いています。
- 盗まれたもの
- GitHub Actionsのシークレットと変数、ワークフローのトークン、クラウド（AWS、Azure、Google Cloud）の認証情報、開発者とAIサービスの認証情報（企業A）
- 原因（調査した企業の説明）
- GitHub Actionsの不具合ではなく、盗まれた有効なトークンの悪用（企業C）。コミットは本人名義で、署名がなく、盗まれたトークンを指すと企業Bは書いている（企業Bの推論）
- トークンの入手経路
- 全体としては確認されていない。企業Cも、クラウド事業者のアプリ経由の分について、入手経路は確認できず、同事業者の基盤が侵害された証拠もないと書いた
- クラウド事業者の説明
- 自社の基盤は侵害されていない。GitHub経由のデプロイで、トークンがビルド用のディレクトリの設定ファイルに残り、一部のアプリがそのディレクトリごと公開していたため取り出された。影響を受けた顧客は少数で、個別に連絡した。アプリが発行した全ユーザーのトークンの失効を始め、デプロイの仕組みを変更した。同事業者のコマンドラインツール経由のデプロイとAPIトークン、稼働中のアプリは影響を受けないとしている
- パッケージへの影響
- 企業Bは、悪意ある変更を受けたリポジトリを元にしたnpm・Go・Packagistの218パッケージを調べ、悪意ある変更の入った版があったのは3パッケージ（Packagist1、Go2）で、同社の一覧では版は計5つ。ほかには見つからなかったと書いた。PyPIなどは調べていない。企業Aも、攻撃者の狙いはCIの秘密情報で、パッケージへの混入は自動公開の副作用と見ている
- 10月の別の事案との関係
- 企業Aは、10月の別のキャンペーンに被害を受けたアカウントが、今回も被害を受けやすかったと書く一方、両者は別の攻撃者による別の活動と見ている。企業Cも、重なりがあっても同一の攻撃者を示すものではないとする（盗まれたトークンは共有・売買されるため）
- GitHubの公式の発表
- 記載なし（2026年11月14日にブログ、更新履歴、障害情報を確認）
分かっていること・分かっていないこと
2026年11月14日時点の状態です。続報が出たら、この表の状態欄を書き換えます。
| 項目 | 発表の内容 | 状態 |
|---|---|---|
| 約4,800アカウントの不正利用 | 盗まれた有効なトークンで、確認用のプルリクエストを送った | 確認済み（企業A・B） |
| 61,764のリポジトリへの確認用プルリクエスト | 変更の有無とは別の数 | 確認済み（企業A。企業Bは61,734） |
| 悪意ある変更を受けたリポジトリ | 公開リポジトリで8,093 | 確認済み（企業B。公開・既定ブランチのみの数） |
| 不正なコードの実行と認証情報の外部送信 | 少なくとも1,835のリポジトリ | 確認済み（企業A。1,806とも書く） |
| 秘密情報とクラウド認証情報の窃取 | 実行されたリポジトリで | 確認済み（企業A・B） |
| クラウド側の仕掛け（入れ替えても残る設定） | AWSのロールの信頼ポリシーの書き換えとAzureの認証連携の追加（企業A）。AWSのアクセスキーが残る点も企業Bが指摘 | 可能性（企業A・B） |
| GitHub Actionsの不具合の悪用 | 使われていない | 含まれない（企業C） |
| 公開されたパッケージへの混入 | 3パッケージ（Packagist1、Go2）、版は計5つ（ほかには見つからず） | 確認済み（企業B。PyPIなどは未調査） |
| クラウド事業者の基盤の侵害 | 証拠なし（企業C）。事業者も侵害を否定 | 確認されていない（企業C・同事業者） |
| 最初にトークンが盗まれた経路 | クラウド事業者のアプリ経由の一部は説明されているが、全体は不明 | 調査中 |
| 同じ攻撃者による10月の別の事案との関係 | 企業Aは別の活動と見る。企業Cは断定しない | 調査中 |
| GitHubの公式の発表 | 見当たらない | 記載なし |
| 被害を受けた組織の確定した一覧 | 公表されていない | 記載なし |
読み方の注意：数字は出所ごとに数え方が違い、公表から2日で動いている
企業Aの1,835は実行の見積もり、企業Bの8,093は変更を受けた公開リポジトリの数、企業Cの63,000は確認用のプルリクエストの数で、同じものを数えていません。確認用のプルリクエストだけを受けた多くのリポジトリは、変更や窃取を受けていない可能性があります。ただし企業Aによれば、確認用のプルリクエストが送られたアカウントは、変更が加わらなくても侵害されたものとして扱うべきです。
盗まれた有効なトークンが使われると、何が起きうるか
以下は一般に言えることで、今回これらが起きたという意味ではありません。今回起きたと調査した企業が報告しているのは、上の「何が起きたのか」の範囲です。
トークンが有効なら、攻撃者は正規の利用者として書き込めます。GitHubの機能の弱点を突く必要がなく、ソフトウェアの更新では止められません。リポジトリに書き込めるアカウントがCIのワークフローを書き換えられると、そのワークフローが読める秘密情報とクラウドの権限が、まとめて狙われます。クラウドにOIDCで入る設定が緩い（どのブランチ・ワークフローでも入れる）と、保存された秘密がなくても、一時的な認証情報が発行されえます。自分のアカウントが協力先の組織に入っていれば、被害は自分の持ち物の外にも及びます。
CIとクラウドの権限を見直すこと
本節は被害を受けた側の評価ではありません。調査した企業が報告した経過から、当サイトの見解として、自分の構成で確かめる点に絞ります。
トークンを「長く、広く」持たない
今回は、盗まれた有効なトークンが使われました。個人アクセストークンは、リポジトリと権限を絞り、期限を短くして、使わなくなったら消します（細かく範囲を指定できる形式を使う）。第三者のアプリには、必要な範囲だけを許可します（当サイトの見解）。
ワークフローの権限と、クラウドへ入れる条件を絞る
ワークフローの既定の権限は読み取りだけにして、書き込みが必要なものにだけ許可します。クラウドへのOIDCの信頼設定は、リポジトリ、ブランチ、環境まで条件を絞り、どのワークフローからでも入れる形にしません。環境ごとのシークレットに承認者を置くと、書き換えられたワークフローが、そのまま本番の秘密を読めなくなります（当サイトの見解）。
ブランチ保護は、レビューの承認で固める
企業Aは、ブランチ保護を通り抜けようとする仕組みがコードにあったと書いています。チェックの名前だけに頼らず、コードオーナーによる承認のレビューを必須にし、ボットのアカウントにも例外を作らないようにします（当サイトの見解）。
Actionsの実行番号の欠けと、クラウドの設定変更を検知する
今回は、実行とログが消され、番号の欠けが手がかりでした。組織の監査ログを残し、ワークフローの変更と、クラウドのアクセスキー作成・信頼ポリシー変更・認証連携の追加を通知する設定にします。CIからの外向きの通信を許可リストに絞る方法も、企業Cが勧めています。
秘密情報をリポジトリに置かない
CIの秘密情報とは別に、コードの履歴に認証情報が入っていると、読める人のトークンが盗まれたときに一緒に取られます。コミット前に検出する方法は gitleaksでコミット前に秘密を止める に、失効の順序は GitHubに公開された認証情報54万件が今も有効 にあります。
出典（公開記録）
本記事の事実関係は以下の公開情報にもとづきます。GitHubの公式の発表は、この件について記載なしです（11月14日に確認）。攻撃の手順の詳細は扱っていません。
- GitHub「Changelog」「Security」（公式のブログ・更新履歴。この件の記載なし。11月14日に確認） — github.blog ／ github.blog
- GitHub Status（公式の障害情報。この件の記載なし。11月14日に確認） — githubstatus.com
- あるクラウド事業者の告知「Security: GitHub tokens exposed by apps deployed from GitHub」（公式のコミュニティ掲示板。英語。2026年11月12日に把握、13日に追記。11月14日に確認） — community.fly.io
- 企業A（セキュリティ企業。最初に報告）「wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories」（英語。2026年11月12日。11月14日に確認） — aikido.dev
- 企業B（セキュリティ企業）「wfx: GitHub Actions Credential Stealer Hits 8,000 Repos」（英語。2026年11月12日。11月14日に確認） — safedep.io
- 企業C（セキュリティ企業）「WFX Phantom: The GitHub Actions Secret Stealer That Deletes Its Tracks」（英語。2026年11月12日。11月14日に確認） — stepsecurity.io
- 報道：BleepingComputer「Hackers compromise 4,800 GitHub accounts to steal cloud credentials」（11月に確認。企業Aの記事の紹介） — bleepingcomputer.com
更新履歴
2026-11-14：初版。調査した3つのセキュリティ企業の公開記事（いずれも11月12日）と、あるクラウド事業者の告知にもとづく。GitHubの公式の発表は記載なし。報道との比較は、各社の原文を正本とした。続報が出たら更新する。
次に読む
- 公開された認証情報が失効されずに残る問題：GitHubに公開された認証情報54万件が今も有効
- GitHub上の開発の仕組みが狙われた別の事案：TanStack・Nxのサプライチェーン攻撃
- 失効の順序と、パッケージ経由の被害：npmサプライチェーン攻撃の守り方
- アカウントの守り：GitHubの2段階認証 ／ .envとAPIキーは何が危ないのか
- 正規の認証情報で起きる事案：2026年の情報漏えいは「正規の認証情報」で起きている
- 2026年の他の事案：情報漏えい・サイバー攻撃の一覧（国内・海外）