本記事の情報は 2026年3月25日 06:00 JST（3月24日 21:00 UTC）時点のものである。
本インシデントは現在も進行中であり、今後新たな情報が判明する可能性がある。
最新の一次情報は Aqua Security公式ブログ および GitHub Discussion #10425 を参照されたい。本ブログの執筆にあたり参照したセキュリティ企業の分析レポート・ニュース記事へのリンクは、本記事末尾のセクション7（参考リンク）にまとめている。
3/22公開の第2レポートはこちらから確認できる。

まず確認すべきこと(Trivyサプライチェーン攻撃の影響確認チェックリスト)

2026年3月19日以降に、以下のいずれかを使用していないか？

• [ ] GitHub Actions で aquasecurity/trivy-action をタグ参照で使用した
• [ ] GitHub Actions で aquasecurity/setup-trivy をタグ参照で使用した
• [ ] Docker Hub から aquasec/trivy の v0.69.4, v0.69.5, v0.69.6, または latest タグを pull した
• [ ] Trivy バイナリ v0.69.4 を GitHub Releases からダウンロードした
• [ ] GitHub Actions で Checkmarx/kics-github-action をタグ参照で使用した
• [ ] GitHub Actions で Checkmarx/ast-github-action をタグ参照で使用した
• [ ] Open VSX から cx-dev-assist v1.7.0 または ast-results v2.53.0 をインストールした
• [ ] npm パッケージ @emilgroup/*, @opengov/*, @teale.io/eslint-config などの CanisterWorm 影響パッケージを使用した
• [ ] PyPI から litellm v1.82.7 または v1.82.8 をインストールした

1つでも該当する場合は、本記事のセクション3（確認方法）とセクション4（対応アクション）を直ちに参照してください。

1. 第2レポート以降の主要イベント

第2レポート（3月22日 14:00 UTC時点）以降も、攻撃者は活動を止めず、Trivy以外のエコシステムにも攻撃範囲を拡大した。以下の時系列は、各セキュリティ企業および公式ソースの公開情報に基づき構成したものである。二次情報の集約であるため、時刻や詳細に誤りが含まれる可能性がある。詳細な影響調査を行う場合は、必ず各行の「情報源」欄に記載された一次ソースを参照されたい。全て UTC で記載する。

影響を受けたバージョン・Exposure Windowの詳細はセクション2を参照。

2. 影響を受けた対象とバージョンの一覧

2.1 GitHub Actions

出典: trivy-action/setup-trivyについては GHSA-69fq-xp46-6x23 および Aqua Security公式ブログ。KICS/astについては Wiz、Sysdig、Checkmarx Security Update。

2.2 Trivyバイナリ/コンテナイメージ

注意: Docker Hub上のv0.69.4は3/19 22:20 UTCに一度削除されたが、latest タグは3/20 03:26 UTCに攻撃者が再び悪意あるコンテンツに紐付けた（Docker公式ブログ）。v0.69.5, v0.69.6は3/22に対応するGitHub Releaseなしで直接プッシュされたものである。

出典: Docker公式ブログ、GHSA-69fq-xp46-6x23。

2.3 npm パッケージ（CanisterWorm）

CanisterWormは、窃取したnpmトークンを使って被害者が管理する他のパッケージにも自動的にマルウェアを拡散する「自己増殖型ワーム」である。ICP（Internet Computer Protocol）ブロックチェーン上のCanisterをC2として利用する点が特徴的である。

出典: Socket（141アーティファクト）、JFrog（追加検出あり）、The Hacker News。パッケージリストは Socket追跡ページ で確認可能。

2.4 PyPI パッケージ

注意: LiteLLMは1日あたり約340万回ダウンロードされるパッケージであり、約3時間の曝露でも影響範囲は大きい（Snyk）。

出典: Endor Labs、Snyk、FutureSearch（発見者）。

2.5 VS Code拡張（Open VSX）

出典: Wiz、Checkmarx Security Update。安全なバージョンはCheckmarx公式で確認。

2.6 CVE情報

※ CVSS v3.0: 9.8はTenableによる評価である。CNA（GitHub）はCVSS v4.0スコアのみを提供しており、NVDは3月25日06:00（JST）時点で「Awaiting Analysis」ステータスのままスコアを割り当てていない。

出典: Tenable、GHSA-69fq-xp46-6x23。CISA KEVカタログは3月25日06:00（JST）時点でCVE-2026-33634を含んでいない（CISA KEV）。

3. 影響を受けたかどうかの確認方法

3.1 GitHub Actions（trivy-action / setup-trivy / kics-github-action / ast-github-action）

Step 1: ワークフローファイルの確認

リポジトリ内の .github/workflows/ ディレクトリで、以下のActionをタグ参照で使用していないか確認する。

    # リポジトリのルートで実行
grep -rn "aquasecurity/trivy-action@" .github/workflows/
grep -rn "aquasecurity/setup-trivy@" .github/workflows/
grep -rn "Checkmarx/kics-github-action@" .github/workflows/
grep -rn "Checkmarx/ast-github-action@" .github/workflows/

SHAピンニング（例: @abcdef1234567890...）ではなくタグ参照（例: @latest, @0.69.4, @v2.1.7）を使っている場合は影響の可能性がある。

Step 2: Exposure Window中の実行確認

ワークフローがExposure Window中に実行されたかどうかを確認する。

    # trivy-action: 3/19 17:43 – 3/20 05:40 UTC
gh run list --workflow=<ワークフロー名>.yml \
  --created "2026-03-19T17:43:00Z..2026-03-20T05:40:00Z" \
  --json createdAt,status,conclusion

     # kics-github-action: 3/23 12:58 – 16:50 UTC
gh run list --workflow=<ワークフロー名>.yml \
  --created "2026-03-23T12:58:00Z..2026-03-23T16:50:00Z" \
  --json createdAt,status,conclusion 

Step 3: 窃取データリポジトリの確認

攻撃のフォールバック窃取メカニズムが発動していた場合、GitHub組織内に tpcp-docs または docs-tpcp という名前のリポジトリが作成されている可能性がある。

     # GitHub CLIで確認
gh repo list <org名> --json name | grep -i "tpcp"

出典: CrowdStrike、Wiz。

3.2 Docker Hub（aquasec/trivy）

    # ローカルに存在するTrivyイメージのバージョン確認
docker images | grep -i trivy

     # イメージのダイジェストを悪意あるダイジェストと照合
docker image inspect aquasec/trivy:<tag> --format ''

以下のダイジェストに一致する場合は侵害されている（GHSA-69fq-xp46-6x23）:

3.3 npm パッケージ（CanisterWorm）

    # node_modules 内の感染痕跡確認
find node_modules -name "deploy.js" -path "*/scripts/*" 2>/dev/null

     # CanisterWormの永続化サービス確認（Linuxのみ）
ls -la ~/.local/share/pgmon/service.py 2>/dev/null
systemctl --user status pgmon.service 2>/dev/null

影響パッケージのリストは Socket追跡ページ で確認できる。

3.4 PyPI パッケージ（LiteLLM）

やってはいけない確認方法

⚠ 重要な注意: LiteLLM v1.82.8 には litellm_init.pth ファイルが含まれている。Pythonの .pth ファイルは Pythonインタープリターが起動するだけで自動実行 される（Snyk）。これは以下を意味する:

• pip show litellm を実行する → pip自体がPythonプロセスを起動 → .pthが発火する
• python -c "import litellm" → 同様に発火する
• IDEのPython言語サーバーが起動 → 同様に発火する

.pth ファイルによる任意コード実行の廃止は CPython Issue #78125 で 2018年から提案されているが、代替メカニズムの設計が未完了であり、任意コード実行機能は現在も有効のままである。なお、隠し .pth ファイルのスキップについては Issue #113659 で起票され、2024年2月にPython 3.12.2で修正済みであるが、これは本件の攻撃手法（非隠しファイルとしての .pth の悪用）とは無関係である。

安全な確認方法

Pythonを起動せず、ファイルシステムを直接確認する:

    # litellmパッケージの存在確認
find /path/to/venv/lib -type d -name "litellm" 2>/dev/null

    # 悪意ある.pthファイルの存在確認
find /path/to/venv/lib -name "litellm_init.pth" 2>/dev/null

    # バージョン確認（METADATAファイルをgrepで読む — Pythonを起動しない）
grep "^Version:" /path/to/venv/lib/python*/site-packages/litellm-*.dist-info/METADATA

    # uvキャッシュの確認
find ~/.cache/uv -name "litellm_init.pth" 2>/dev/null

    # 永続化痕跡の確認
ls -la ~/.config/sysmon/sysmon.py 2>/dev/null
ls -la ~/.config/systemd/user/sysmon.service 2>/dev/null
ls -la /tmp/pglog /tmp/.pg_state 2>/dev/null

v1.82.7 または v1.82.8 を動かしていた場合には、その環境を侵害済みとして扱うべきである。

出典: Endor Labs、Snyk。

4. 対応アクション

4.1 即時対応（Exposure Windowに該当する場合）

1. 影響を受けたアーティファクトの即時削除: 悪意あるバージョンのバイナリ、コンテナイメージ、パッケージを全て削除する
2. 全シークレットのローテーション: 該当するCIパイプライン・ランナーがアクセス可能だった全てのシークレットを侵害済みとして扱い、即時ローテーションする。対象には以下が含まれる:
   • クラウドプロバイダー認証情報（AWS, GCP, Azure）
   • GitHub PAT / GITHUB_TOKEN
   • SSH鍵
   • Kubernetes トークン / kubeconfig
   • Docker Hub / レジストリ認証情報
   • データベース認証情報
   • APIキー（Slack Webhook, Discord等を含む）
3. ワークフローの固定: GitHub Actionsのバージョン指定をタグからSHAピンニングに変更する
4. ネットワークログとインフラの確認: 以下のC2ドメイン/IPへの通信がないか確認する。加えて、kube-system namespace内に攻撃者のDaemonSetに対応するPodが作成されていないか確認する。LiteLLMバリアントでは node-setup-*、元のTrivy/KICSバリアントでは host-provisioner-std（標準版）および host-provisioner-iran（ワイパー版）の名前が使用される（ramimac）

C2ドメイン/IP一覧:

Kubernetes確認コマンド:

    kubectl get pods -n kube-system | grep -E "node-setup|host-provisioner"

4.2 安全なバージョンへの移行

出典: GHSA-69fq-xp46-6x23、Aqua Security公式ブログ、Checkmarx Security Update。

4.3 GitHub Actionsのピンニング

Gitタグはforce-push可能であり、今回の攻撃はまさにその仕組みを悪用したものである。タグ参照を廃止し、イミュータブルなコミットSHAで固定すべきである。

    # ❌ タグ参照（force-pushにより、悪意あるコミットを指すリスクがある）
- uses: aquasecurity/trivy-action@latest
- uses: aquasecurity/trivy-action@0.34.2

    # ✅ SHA固定（イミュータブル、変更不可）
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1  # v0.35.0

上記のSHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 は、今回の攻撃で唯一改ざんされなかったv0.35.0の安全なコミットである（ramimac）。GitHubのImmutable Releases機能によって保護されていた。

加えて、CI/CDランナーからの想定外のアウトバウンド通信を検知する仕組み（Egress制御）を導入することも有効である。今回の攻撃では、ペイロードがC2ドメインへのHTTPS POSTで窃取データを送信していた。Egress Policyを設定し、許可リスト外のドメインへの通信をブロックしていれば、窃取を阻止できた可能性がある。

5. クレデンシャルローテーションに関する警告

本インシデントは、クレデンシャルローテーションの手順に不備があれば、ローテーションの効果が大幅に減殺されることを示した。対応にあたるユーザは、自組織のローテーションにおいても同様の問題が生じないよう留意する必要がある。

5.1 対応するユーザへの警告

今回のインシデントでExposure Windowに該当し、シークレットのローテーションを実施する場合は、以下の4点を満たさなければローテーションの効果が失われるリスクがある。

1. 全クレデンシャルの棚卸し

まず「何が存在するか」を把握する。見落とされやすいものとして以下がある:

• GitHub PAT（複数アカウント、組織間ブリッジ用ボットを含む）
• Docker Hub / コンテナレジストリの認証情報
• npm / PyPI の公開トークン
• GPG署名鍵
• CI/CDプラットフォームのサービスアカウント
• Slack / Twitter / Discord のBot Token
• SSH鍵
• クラウドプロバイダーのIAMクレデンシャル

2. アトミックな無効化と再発行

逐次的なローテーション（1つずつ無効化→再発行）では、新旧のクレデンシャルが共存する時間帯が生まれる。CVE-2026-33634の公式説明が示すとおり、全てのクレデンシャルを同時に無効化し、その後に新しいクレデンシャルを発行すべきである。

3. ローテーション前の環境クリーン化

侵害されたサーバー、ランナー、開発端末の上で新しいクレデンシャルを発行すれば、攻撃者はそのクレデンシャルを窃取できる。本攻撃のペイロードは、プロセスメモリの読み取り（/proc/<pid>/mem）、ファイルシステムの走査、環境変数の収集を行っていた。ローテーション前に、まず環境をクリーンな状態に復元するか、新しい環境を構築してからローテーションを実施すべきである。

4. ローテーション後の検証

ローテーションが完了した後、旧クレデンシャルが確実に無効化されていることを検証する。具体的には:

• 旧トークンを使用したAPI呼び出しが 401 Unauthorized を返すことの確認
• 旧SSH鍵による接続が拒否されることの確認
• CI/CDパイプラインが新しいクレデンシャルで正常に動作することの確認
• 監査ログで旧クレデンシャルの使用が検出された場合のアラート設定

6. 攻撃者に関する情報

3月25日06:00（JST）時点で、本攻撃の実行者は調査継続中である。MandiantもCyberScoopの取材において攻撃者の正式な名称付けを行っていない（"The attackers, which the incident response firm has yet to name"）。

一方、攻撃ペイロードに自己署名文字列「TeamPCP Cloud stealer」が埋め込まれていることから、複数のセキュリティ企業（Wiz、Endor Labs、Sysdig、Cyble）はTeamPCPとして追跡している。

ただし、Socketは「自己ラベルは偽旗の可能性もあるが、過去のTeamPCPツールとの技術的重複から、真正な帰属が妥当である」と指摘しており、帰属は確定的ではなく「高い確信度」での評価である点に留意する必要がある。

Mandiantによれば、本攻撃の背後にいるグループは主に米国、カナダ、英国に拠点を置く複数の脅威グループと連携しており、「非常に積極的な恐喝」で知られるとのことである。

7. 参考リンク

一次情報

セキュリティ企業分析レポート

タイムライン・IOC・脅威アクタープロファイル

ニュースサイト

本記事は今後の情報に基づき更新される可能性がある。最新情報は本ブログおよび上記の公式ソースを参照されたい。

執筆者プロフィール

フューチャー株式会社

Cyber Security Innovation Group　エンジニア

棚井龍之介（たない りゅうのすけ）

役割

セキュリティ領域を専門とするエンジニア（クラウドインフラ領域、バックエンド開発 ）として業務に従事。同社が展開する脆弱性管理ツール「FutureVuls」に深く携わっており、OSSの脆弱性スキャナ（TrivyやVuls）のエンジン検証、SBOMの取り込み、サプライチェーン攻撃の調査・安全性の検証レポートなどを担当。

略歴

フューチャー株式会社の公式技術ブログ「Future Tech Blog」や「FutureVuls Blog」で継続的に技術発信を行っており、クラウドインフラからサイバーセキュリティまで幅広い技術領域で活躍。

• サイバーセキュリティ: 脆弱性管理（CPE名の検索最適化など）、サプライチェーンセキュリティの監視、セキュリティ製品の実装・運用

• クラウド・インフラストラクチャ: AWS（DynamoDB等のサーバレス技術）、Terraformを用いたInfrastructure as Code（IaC）の推進、LocalStackを利用したローカルテスト環境の構築。

• 業務自動化とプログラミング: 主な使用言語はGo言語やRuby。GAS（Google Apps Script）やSlack Botを利用した業務効率化、Seleniumを利用したUI操作の自動化。

棚井龍之介の他の記事を見る