Vercel 2026年4月インシデント対応ガイド

最終更新: 2026年4月20日 12:07 PM AEST/ブリスベン - (v2 — Vercel CEO 2026年4月20日更新を反映)

重要: これは法的なアドバイスや公式見解ではありません。侵害を受けたと思われる場合は、インシデント対応パートナーに連絡してください。この情報は、OpenSourceMalware チームによる誠意として提供されるものです。インシデント対応企業への紹介が必要な場合は、これまでに協力したことのある企業をいくつかご紹介できます。

何が起こったのか？

Vercel は2026年4月19日、攻撃者が内部システムへの不正アクセスを取得したことを公表しました。公式発表はこちら: 発表

Vercel セキュリティ発表

4月20日、Vercel CEO の Guillermo Rauch 氏は詳細なアップデートを公開し、初期アクセス経路を確認しました。Vercel の従業員が Context.ai という AI プラットフォームを使用しており、それが侵害されていました。そこから攻撃者は従業員の Google Workspace アカウントに移動し、Vercel 環境へと権限昇格しました。環境変数は保存時に暗号化されていますが、攻撃者は「機密」とフラグが立てられていない変数を列挙できました。Vercel は攻撃者を高度に洗練されており、AI による加速が大きい可能性があると特徴づけています。Google Mandiant が対応に関与しています。Vercel は Next.js、Turbopack、およびオープンソースプロジェクトは安全であると述べています。

以下は、そのセキュリティアドバイザリからの侵害指標セクションです:

Vercel IOC 情報

詳細はかなり乏しいです。その唯一の Google IOC をどこで確認すればよいかさえ教えていません。Vercel の顧客として、この詳細レベルの低さにはかなり失望しています。何を探すべきか理解できるようにしてください！侵害されたかどうかを知るためにどこに行けばいいのか教えてください！

Vercel からの詳細がないため、このドキュメントを作成しました

Vercel でワークロードを実行している場合、以下のことが証明されるまで仮定してください:

露出期間中の Vercel プロジェクトで「機密」フラグが立てられていない環境変数は、読み取り可能だった可能性があります。
ダッシュボードまたは vercel env CLI を介して Vercel にプッシュされ、ローテーションされていない資格情報はすべて、存続する負債です。
Vercel ↔ GitHub および Vercel ↔ Linear の統合パス内のトークンは、アクセス可能だった可能性があります。
「影響あり/なし」の明確なシグナルはすぐには得られません。まずローテーションし、その後調査してください。

既知の事実 vs. 主張されていること: ブリーフィングではこれらを分けて扱ってください

この区別は、エグゼクティブコミュニケーションや過剰対応（または過小対応）を防ぐために重要です。

Vercel により確認済み (速報 + 4月20日のCEOアップデート)

Vercel の特定の内部システムへの不正アクセス。
初期アクセス経路: Context.ai — Vercel 従業員が使用していた AI プラットフォームが侵害されました。攻撃者はその足がかりを使って従業員の Vercel Google Workspace アカウントを侵害し、そこから Vercel 環境へと権限昇格しました。
顧客の環境変数は保存時に暗号化されています。しかし、「非機密」と指定された変数は、攻撃者が内部に入った後で列挙可能でした。
顧客への影響は「かなり限定的」とされています。Vercel は懸念がある顧客に直接連絡済みです。
Next.js、Turbopack、Vercel のオープンソースプロジェクトは分析され、安全であると考えられています（つまり、Vercel の4月20日時点の声明では、これらのプロジェクトのリリースパスに悪意のある成果物はありません）。
攻撃者は高度に洗練されており、AI による加速が大きい可能性があると特徴づけられています。
対応パートナー: Google Mandiant が積極的に関与しており、外部の IR 企業、業界の同業他社、法執行機関も関与しています。
Vercel は Context.ai に連絡を取り、全容の把握に協力しています。
Vercel は UI の改善をリリースしました: 環境変数概要ページ、機密性の高い環境変数の管理改善。

第三者および攻撃者によって報告/主張されている（Vercel 未確認）

Linear および GitHub の統合が不均衡に影響を受けた（コミュニティの報告、特に Theo Browne 氏の X でのポスト）。
BreachForums で販売されているデータ: 内部 DB、従業員アカウント、GitHub トークン、npm トークン、ソースコード断片、アクティビティタイムスタンプ — 約 200 万ドルで提供。
攻撃者は自らを ShinyHunters と名乗っている。過去にその名称に関連する他の攻撃者は関与を否定しています。
Vercel が顧客と直接確認した範囲を超えた特定の顧客データクラスが流出。

未確認の報告は、もっともらしく、自身のトリアージには実行可能 として扱ってください。ただし、Vercel が裏付けを取るか、独立した証拠を得るまでは、顧客や規制当局へのコミュニケーションで事実として引用しないでください。「列挙可能な環境変数」（Rauch 氏確認）と「BreachForums で販売されている npm + GitHub トークン」（攻撃者の主張）の間のギャップは、サプライチェーンリスクにとって最も重要なギャップです — ローテーションの目的では最悪を想定し、コミュニケーションでは確認済みのバージョンに固執してください。

スコーピング: このプレイブックを実行すべき対象

最高の緊急性 — Vercel から直接連絡があった場合、または以下のいずれかに該当する場合:

Vercel ↔ GitHub 統合があり、リポジトリへの書き込みスコープがある（またはあった）。
Vercel ↔ Linear 統合がある（またはあった）。
Vercel 環境変数として暗号化されていないシークレット（機密フラグなし）を保存している。
Vercel インフラ上または経由で実行される CI/CD から npm パッケージを公開している。

標準的な緊急性 — アクティブな Vercel プロジェクトを持つすべてのチーム（マーケティングサイトも含む）。マーケティングサイトには、CMS API キー、分析トークン、フォームハンドラーのウェブフックが含まれていることが多く、これらはより機密性の高いシステムにピボットする可能性があります。

それでも実施 — インシデント前にプロジェクトを削除した場合でも。問題は、シークレットが読み取り可能な形で Vercel に存在したかどうかであり、プロジェクトがまだあるかどうかではありません。

副次的な質問: 組織は Context.ai に直接露出していますか？

4月20日のアップデートでは、侵害された上流ベンダーとして Context.ai が指名されています。組織内の誰かが Vercel インシデントとは独立して Context.ai を使用している場合（ミーティングインテリジェンス、ナレッジマネジメント、CRM エンリッチメント、その他のワークフロー）、Vercel インシデントとは別に、独自の直接的な露出期間がある可能性があります。

これらのチェックを並行して実行してください:

SSO / IdP（Okta、Entra、Google Workspace）で、Context.ai または Context 関連の OAuth アプリに認証したユーザーをクエリします。
Google Workspace 管理コンソール → セキュリティ → OAuth アプリアクセスログで context.ai または関連アプリ ID を検索します。
企業の経費 / SaaS 支出管理ツールで Context.ai のサブスクリプションを確認します。
付与された OAuth スコープを確認します — Gmail 読み取り、カレンダー、Drive、Workspace ディレクトリスコープは影響が大きいです。

環境内で Context.ai の使用が見つかった場合、OAuth 許可を取り消し、Context.ai ワークフローを通過した資格情報をローテーションし、影響を受けたユーザーの Google Workspace アカウントで Vercel が従業員のアカウントで確認したものと同じ侵害指標を監視してください。自身のインシデント詳細については Context.ai に直接連絡してください。Vercel は、他の影響を受ける組織を支援するために Context と調整していると公表しています。

フェーズ 0: 出血を止める（最初の60分）

2つの目標: 新たな被害を防ぎ、証拠を保全する。

デプロイを凍結する。 プロダクションブランチでの自動デプロイを一時停止します。攻撃者によって改変されたビルドが本番に出荷されるのを防ぎ、監査ログの増加を止めます。
Vercel の GitHub App を無効化する。 Vercel GitHub App がインストールされている場合（新しいコードを GitHub にプッシュしたときに Vercel への自動デプロイを行っている場合に該当）、無効化します。インストールされている GitHub アプリは https://github.com/organizations/<GitHub-Organization>/settings/installations で確認できます。
GitHub App が持っているアクセス権を特定する。 上記の設定ボタンをクリックし、Vercel アプリがアクセス権を持っていたリポジトリを監査します。これにより、今すぐ何に焦点を当てるべきかがわかります。GitHub → Organization → Settings → GitHub Apps → Vercel に移動して確認:
- リポジトリアクセス（全リポジトリか選択済みか）
- 付与された権限
- インストール日と誰がインストールしたか

GitHub リポジトリアクセス

Vercel 監査ログのスナップショットを取得する チームのログをエクスポートまたはスクリーンキャプチャします。保持期間は限られており、UI ですべてが公開されているわけではありません。ログを汚染する変更を加える前に取得してください。 https://vercel.com/activity-log で確認できます。
「Observability Plus」を有効にする。 これは Vercel の有料追加機能であり、有効にして支払うことを提案するのは残念ですが、インシデント対応中はこれが最善の方法だと思います。決して嬉しいことではありませんが、デフォルトでは非常に短い監査ログの保存期間を延長するために、私は有効にしました。
露出の広がりを棚卸しする。 管理下にあるすべての Vercel チーム/アカウントについて、以下をリストアップ:
- プロジェクトとそれにリンクされた Git リポジトリ
- 接続されている統合（GitHub App、Linear、Slack、マーケットプレイス統合）
- チームメンバーとその役割
- チームの下で発行された個人アクセストークン / API トークン
- デプロイフック
GitHub Organization の監査ログを確認する。 露出期間（控えめに見て2026年4月1日〜15日から現在まで）を探します。以下でフィルタリング:
- repo.add_member, repo.add_topic
- org.invite_member, org.add_member
- integration_installation, integration_installation.repositories_added
- protected_branch.destroy, protected_branch.update
- git.ref.force_push またはプッシュイベントの force-push フラグ
- 新しいデプロイキー、新しいウェブフック、新しい Actions シークレットまたは変数
- 組織メンバーによって作成された新しい PAT、新しいファイングレインドトークン
- oauth_access.create, oauth_authorization.create
「最重要」環境変数を特定する。 攻撃者がピボットを可能にするもの（決済プロセッサキー、DB URL、認証シークレット、クラウドプロバイダキー（AWS/GCP/Azure）、サードパーティ SaaS の管理 API キー）にフラグを立てます。
トラッキングチケット / インシデントチャネルを開く。 影響を受けていないことが判明しても、プレイブックを実行したという証跡は価値があります。

現時点では、発表やシークレットのローテーションは行わないでください。まずスナップショットが必要です。

フェーズ 1: 侵害指標（IOC）の確認

Vercel の発表からの詳細はかなり乏しいです:

Vercel IOC リスト

判明している限りでは、Google Workspace 管理コンソールに移動して、この googleusercontent.com アプリを探すことを提案しているようです。コンソールでこれを見つける方法は以下の通りです:

Workspace 管理コンソールで セキュリティ > アクセスとデータ制御 > API 制御 に移動し、アクセス済みおよび保留中のアプリを見つけます。
次に、さまざまなリストで IOC を探します。これは oauth アプリのようです: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
見つけた場合は直ちに削除し、インシデント対応パートナーに相談してください。これは私の能力を超えています。

フェーズ 2: 資格情報のローテーション

ローテーションは最も価値の高い単一のアクションです。優先順位順に実行し、中断された場合でも最も危険なものが処理されるようにします。

何をローテーションするかは、GitHub および Vercel 環境で何が露出しているかに依存します。GitHub PAT などから始めて、このガイドに従って外側に向かって進めてください。

優先順位ティア

ティア 0 — 今日中に、他の何よりも先にローテーション:

vercel-april2026-incident-response

人気