GitHub上の開発用アカウントを足がかりに、自動テストやデプロイの仕組みを改変し、クラウドなどの認証情報を盗む攻撃が報告されています。セキュリティ企業のAikidoとSafeDepが2026年11月12日に分析を公表しました。
注意したいのは、攻撃者が不正な処理を実行した後、コードを元に戻したり、実行履歴を削除したりする動きです。現在のファイルに問題が見当たらなくても、それまでに外へ出た認証情報が安全に戻るわけではありません。
GitHub Actionsで自社サービスをテスト・公開している企業は、開発担当者や委託先に、コードだけでなく、実行履歴と接続先のクラウドも確認してもらう必要があります。
狙われたのは、開発の自動処理に渡す「鍵」
GitHub Actionsは、コードの変更をきっかけにテストや公開作業を自動で行う機能です。本番環境への反映や外部APIへの接続のために、クラウドや各種サービスの認証情報を使うことがあります。
今回の調査では、盗まれたGitHubの認証情報でアクセスできるリポジトリに対し、書き込み権限を探る変更や、不正な自動処理の追加が確認されています。ワークフローと呼ばれる処理手順の改変だけでなく、パッケージのインストール時に動く処理を使った手口も報告されました。Aikidoの調査
狙いは、実行環境から取得できる認証情報です。そこからアクセスできるクラウド、AIサービスなどへ影響が広がるおそれがあります。GitHubを使っていれば全社が被害を受けるという話ではなく、侵害されたアカウントの権限と、改変された処理から何にアクセスできたかが判断のポイントです。
「いま正常に見える」だけでは終われない
SafeDepは、悪意ある処理を実行してから変更を戻す動きや、実行記録の削除を含む攻撃を分析しています。また、得られた権限を使い、クラウド側に追加のアクセス経路を作ろうとする処理も報告しました。SafeDepの分析
ここでは、二つの状態を分けて考える必要があります。
- リポジトリのコードやワークフローを、正常な内容に戻すこと。
- 外に出た認証情報を失効させ、接続先に追加された不正な権限がないか調べること。
たとえば、クラウドを操作する鍵が盗まれ、その鍵で別の鍵や信頼設定を追加できる権限まであった場合、元の鍵だけを交換しても十分とは限りません。これは今回報告された処理から考える確認事項であり、すべての被害環境で追加のアクセスが成立したと確認されたわけではありません。
自社や開発会社に確認するなら、この順番
この攻撃の影響を調べるときは、GitHubだけを見て終わらせず、自動処理が接続する先まで範囲を広げます。
まず、不審な変更と実行の有無を確認する
11月10日以降の変更・実行履歴を重点的に確認します。調査報告に挙がったブランチ名「wfx-docs」や、PRの題名「docs: dependency audit notes」は手がかりの一つですが、同じ名前があるだけで被害確定とはせず、ないだけで安全とも判断しません。
依頼していないワークフローの変更、見覚えのない自動処理、短時間で戻された変更、不自然な履歴の欠落を、アカウントの操作記録と合わせて調べます。詳細な判別材料は、Aikido・SafeDepの原文を開発担当者と共有してください。
不審な動きがあれば、証拠を残して止める
疑わしい処理を止め、取得できる監査ログや変更・実行記録を保全します。先にすべて削除すると、どの認証情報が利用可能だったかを判断しにくくなります。
侵害の疑いがあるアカウントのトークンや接続許可を点検し、流出した可能性のある認証情報を失効・交換します。交換前後の順序やサービスへの影響は、開発・運用担当者とそろえて進めます。
クラウド側と実行環境も点検する
自動処理から接続できたAWS・Azureなどで、不審な認証情報の作成、権限や信頼設定の変更がないか確認します。AIサービスや外部APIの利用量、請求の急増も調べる対象です。
自社で用意した実行用サーバーを使っている場合は、そのサーバーに保存された他の認証情報や作業領域も範囲に入れます。リポジトリの修正だけで、実行環境まで安全になったとは扱わないことが大切です。
再発防止は「自動処理に何を渡すか」から
GitHubの公式ガイドは、自動処理が使う認証情報の権限を必要最小限にすることや、環境用の秘密情報へのアクセスにレビューを要求する方法を案内しています。長期間使う鍵を置く代わりに、OIDCという仕組みで必要なときにクラウドへ認証する方法もあります。GitHubの安全な利用ガイド
ただし、認証方式だけ変えれば解決するわけではありません。誰がワークフローを変更できるか、どのリポジトリ・処理に本番の権限を渡すかも、一緒に見直す必要があります。
事業者として開発会社に聞きたいのは、**「不正なコードは消しましたか」だけでなく、「その処理が使えた鍵と接続先は、どこまで確認しましたか」**です。コードの修復とアクセス権の点検を、復旧の別々の完了条件として扱ってください。
現時点で分かっていないこと
本記事で確認したのは、セキュリティ企業による攻撃の観測・分析です。最初のGitHub認証情報が盗まれた経路や、個々の企業の被害範囲は確定していません。GitHubの基盤そのものの脆弱性が原因だと示されたものでもありません。
調査に出てくる「アクセスを試されたリポジトリ」「悪意ある変更が入ったリポジトリ」「処理が実行された環境」は異なるため、これらの件数をまとめて被害数とは扱っていません。
※2026年11月12日時点の調査報告に基づきます。確認対象は、自社の権限・実行履歴・接続先に応じて判断してください。