- 公式GitHub Actionがタグの強制更新によって改ざんされ、悪意あるコードが配布されたサプライチェーン攻撃が発生
- 攻撃者は76個のうち75個のタグを悪意あるコミットに置き換え、約1万件以上のワークフローが影響を受けた
- 改ざんされたスクリプトは機密情報の収集・暗号化・流出の3段階で動作し、TeamPCP Cloud stealerのコードが含まれる
- 感染したタグは依然として有効で、@0.35.0または特定のcommit SHAのみが安全であることが確認されている
- すべての認証情報の交換とcommit SHA固定使用が必須であり、Docker Hubイメージでも同様の汚染が確認された
Trivy GitHub Actionsサプライチェーン攻撃の概要
- Trivyの公式GitHub Action（
aquasecurity/trivy-action）が攻撃者によって**タグの強制更新（force-push）**で改ざんされ、悪意あるコードが配布された事件
- 攻撃者は76個のバージョンタグのうち75個を悪意あるコミットに置き換え、CI/CDパイプラインで自動実行されるよう細工した
- 約10,000件以上のGitHubワークフローファイルがこのアクションを参照しており、被害範囲は広範
- 感染したタグは依然として有効で、@0.35.0のみが唯一安全なバージョンであることが確認されている
- Socketは19:15 UTCからリアルタイムで182件の悪意あるGitHub Actionイベントを検知し、Backdoor、Infostealer、Reconnaissanceタイプに分類した
攻撃の原因と進行方式
- Trivyのメンテナーによれば、今回の攻撃は書き込み権限のある認証情報の窃取によって発生
- 3月初旬に発生した以前の侵害でCI環境の機密が流出し、ローテーションの過程が不完全だったため、新しい認証情報の一部が攻撃者の手元に残った
- 攻撃者はこの認証情報を使い、GitHub自体の脆弱性なしに認証済みタグ更新を実行
- 攻撃者はブランチへのpushやリリース作成ではなく、既存タグを強制的に新しいコミットで上書きした
- 各タグは元のコミットのメタデータ（作者、メール、タイムスタンプ、コミットメッセージ）を複製し、正規に見えるよう偽装された
- ただし元のコミットはGPG署名されていた一方、攻撃者のコミットは署名が欠落しており、親コミットの日付が2026年となる不一致があった
- GitHubのImmutable Release表示があっても、攻撃者が悪意ある状態で公開した後にロックした可能性がある
- したがって“Immutable”バッジに依存せず、**commit SHA固定（pinning）**だけが安全な利用方法となる
タグ改ざんの構造
- 攻撃者は
masterブランチの最新コミット（57a97c7e）を基に新しいコミットを作成
entrypoint.shファイルだけを悪意あるバージョンに置き換え、他のファイルはそのまま維持した- 各タグは元のPR番号、コミットメッセージ、作者情報をそのまま複製して偽装された
- GitHubリリースページで「0 commits to master since this release」と表示される場合、改ざんされたタグの視覚的指標として確認できる
0.35.0タグだけが改ざんされなかった理由は、すでにmaster HEADを指していたため
悪意あるペイロードの構造
- 改ざんされた
entrypoint.shは全204行で、4〜105行にInfostealerコード、その後に通常のTrivyスキャンコードが含まれる
- 悪意あるコードは3段階で構成される
- 第1段階: 収集（Collection） — ランナープロセスのメモリおよびファイルシステムから機密情報を抽出
- 第2段階: 暗号化（Encryption） — AES-256-CBCおよびRSA-4096で収集データを暗号化
- 第3段階: 流出（Exfiltration） — 攻撃者管理ドメインまたは被害者のGitHubアカウントへ送信
-
第1段階: 機密情報の収集
- GitHub Actionsランナープロセス（
Runner.Worker, Runner.Listener, runsvc, run.sh）の環境変数を/proc/<pid>/environから読み取り、env、sshキーワードを含む項目を抽出
- GitHubホスト型ランナーでは、Pythonベースのメモリダンプスクリプトを
sudoで実行し、Runner.Workerプロセスのメモリから"isSecret":trueパターンを検索
- セルフホスト型ランナーでは、TeamPCP Cloud stealerと識別されるファイルシステム認証情報収集ツールを実行
- SSH鍵、AWS/GCP/Azure認証情報、Kubernetesトークン、Docker設定、DBパスワード、環境ファイル、TLS鍵、VPN設定、Webhook URL、ウォレット鍵など広範な対象を含む
-
第2段階: 暗号化
openssl randで32バイトのセッションキーを生成後、AES-256-CBCでデータを暗号化- セッションキーはRSA-4096公開鍵でOAEPパディングを適用して暗号化
- 暗号化されたデータ（
payload.enc）とセッションキー（session.key.enc）をtpcp.tar.gzにまとめる
-
第3段階: データ流出
- 第1チャネル:
https://scan[.]aquasecurtiy[.]orgへHTTPS POSTで送信（aquasecurityを誤記したドメインを使用）
- 第2チャネル: 失敗時には被害者のGitHub Personal Access Tokenを使って
tpcp-docsという公開リポジトリを作成
- リリース資産として
tpcp.tar.gzをアップロード → 攻撃者はGitHub検索でそのリポジトリを見つけてデータを回収
- GitHubインフラを利用してファイアウォール回避を試み、検知回避の可能性が高い
- 最後に一時ファイルを削除し、痕跡を最小化
攻撃者および背後
- 悪意あるコード内のコメントに**「TeamPCP Cloud stealer」**と明記
- TeamPCP（DeadCatx3、PCPcat、ShellForce）はクラウドネイティブ環境を狙う攻撃グループで、Docker API・Kubernetes・Redis・Rayダッシュボードの脆弱性を悪用した事例がある
- 2026年2月にはFlareとThe Hacker Newsでランサムウェア・データ窃取・暗号資産マイニングのキャンペーンとして報告されている
- Solanaバリデーター鍵および暗号資産ウォレット収集機能は、金銭目的と一致する
対応および推奨事項
- すべてのTrivy Actionバージョンタグの使用を中止し、**commit SHA
57a97c7e7821a5776cebc9bb87c984fa69cba8f1またはタグ0.35.0**のみを使用
- 感染したパイプラインは完全な機密流出とみなすべきであり、すべてのクラウド認証情報・SSH鍵・APIトークン・DBパスワード・Dockerトークンの即時交換が必要
- GitHub組織内に
tpcp-docsリポジトリが存在するか確認し、3月19日19:00 UTC以降に実行されたtrivy-actionログの確認を推奨
侵害指標（IOCs）
- ネットワーク指標:
scan[.]aquasecurtiy[.]org
- ファイルハッシュ:
18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a（entrypoint.sh）
- 感染したGitHub Actions:
aquasecurity/trivy-action@0.0.1 ～ @0.34.2の全バージョンを含む（計75個のタグ）
追加アップデート（3月22日）
- Docker Hubでも**Trivyイメージ（
0.69.4, 0.69.5, 0.69.6, latest）**が同一のInfostealerペイロードで汚染されていたことが確認された
latestタグが悪意あるイメージに指定され、露出期間中にユーザーへ配布された- 関連する詳細はSocketの別レポート “Trivy Docker Images Compromised” で確認できる
1件のコメント
Hacker Newsのコメント
GitHub が Actions に イミュータブルなバージョン管理（immutable versioning） を強制しない理由が気になる
セキュリティガイドではコミット SHA で固定（pin）するよう勧めているが、そもそも固定しないと Action を公開できないようにすれば、こうした問題は減らせる気がする
セキュリティチームの立場では固定バージョンのほうが安全だが、同時に セキュリティアップデートの自動反映 がされないと危険でもある
結局は生産性を損なわずに両方を満たす解決策が必要になる
これを「Pinning のパラドックス」と呼びたくなる
それでも、いつかは変える作業を始める必要がある
アップデートを許可したほうが、むしろセキュリティが強化されることもある
これは静的リンク vs 動的リンクの論争に似た問題だ
しかも Trivy Action はどうせ最新バージョンを取得するようになっていた
今回の件は、「サプライチェーンセキュリティ（supply chain security）」製品が、実際には自分たちが守ろうとしているスタックと同じくらい脆弱であり得ることを示す警告だ
とくに「どこでも実行される（run us everywhere）」タイプのセキュリティツールは、一度の攻撃で膨大な数のユーザーを同時に危険にさらせる新たな攻撃ベクターを提供してしまう
最初は Trivy が 認証情報のローテーション（rotation） を適切にしていなかったのかと思った
だが彼らは、「非アトミックな（non-atomic）ローテーション過程で攻撃者が新しいトークンを知った可能性がある」と説明している
GitHub は発行後にトークンを再表示しないが、どの認証方式を使ったかによっては事情が違うかもしれない
新しい GitHub 組織を作った直後に名前を奪われ、GitHub 側に アトミックな作成処理 を依頼する必要があったそうだ
「脆弱性をスキャンすべきであって、脆弱性そのものになってはいけない」という言葉が見事に当てはまる事件だ
関連する出来事として Trivy サプライチェーンの一時的侵害 があった
3月22日、攻撃者は盗まれた認証情報で 悪意のある Trivy v0.69.5、v0.69.6 の DockerHub イメージ を公開した
（セキュリティ告知リンク）
3月19日と22日の2回の事件があり、攻撃者は2度の認証情報ローテーションにもかかわらず継続的にアクセス権を維持していたように見える
「この2週間は最悪だった」
Trivy が侵害されたせいで、膨大な数の セキュリティレポートと会議 に対応しなければならない状況だ
「セキュリティソフトウェアを作っているからといって、必ずしも有能とは限らない」という教訓だ
うちのセキュリティチームも毎月新しいスキャナーを導入しようとするが、彼らが要求する 広範なアクセス権 を許していたら、もう何度もやられていたはずだ
setup-trivyAction はメインブランチをそのまま clone してシェルスクリプトを実行する構造だったつまり、すべての CI ワークフローで任意コード実行が可能だった
Aqua は今月初めに侵害され、2回も 隔離の失敗 をした末に Docker Hub アカウントまで突破された
もう外部の専門家の助けが必要だと思う
その多くは騒がしいレポート生成器にすぎず、攻撃者が内部に入ってきたら何の防御もできない
新しいスキャナーは 隔離されたサンドボックス で読み取り専用データだけにアクセスさせ、十分に検証されるまで本番権限を与えるべきではない
そうしなければ、秘密鍵を pastebin に上げるのと大差ない
「素早く動いてすべてを壊す」セキュリティ文化になってしまっている
そのため、品質の低いセキュリティソフトウェア でもとにかく導入する文化が生まれる
Trivy 自体は悪くないと思うし、うちの会社でも使っている
ただし、うちでは Nix でバージョンを固定 し、Actions ワークフローを自前で書いていたので、今回の侵害の影響は受けなかった
攻撃者は認証済みの状態で タグの強制更新（force-update） を実行できた
GitHub の古い設定である「タグの上書き禁止」さえ有効にしていれば防げた出来事だ
こうした事件が繰り返されるほど、Software Building Code のような標準が必要だという思いが強くなる
2026年にはこの理由があといくつ増えるのか気になる