技術 約5分で読めます

Context.ai侵害がOAuthチェーンでVercel本体まで到達したセキュリティインシデント

Vercel セキュリティ OAuth Google Workspace インシデント サプライチェーン
いけさん目次

2026年4月19日、Vercelが公式KBで「April 2026 security incident」と題した告知を公開した。内部システムへの不正アクセスが検知され、起点はサードパーティAIツール「Context.ai」のOAuth侵害だった。

このサイトもVercelにデプロイしているので、他人事ではない。 sensitive と明示していない環境変数については全件露出した前提で動いたほうがよく、該当する値を持っているなら今すぐローテーションする話になる。

何が起きたのか

Vercelの従業員が業務で Context.ai（AIコンテキスト共有系のSaaS）を使っており、その Context.ai が Google Workspace の OAuth アプリ権限ごと侵害された。
攻撃者はこの OAuth 権限を踏み台にして、Vercel 従業員の Google Workspace アカウントを乗っ取り、そこから利用できる Vercel 内部環境へアクセスを広げた。

結果として、攻撃者は一部顧客プロジェクトの環境変数（sensitive マークが付いていないもの）を読める状態になった。
Vercel は影響の可能性がある顧客に個別連絡済みとしており、連絡がなかった利用者については「現時点で認証情報やプライベートデータが侵害された理由は見当たらない」と述べている。

攻撃チェーン

flowchart TD
    A[Context.ai 侵害] --> B[Google Workspace<br/>OAuthアプリ権限の奪取]
    B --> C[Vercel従業員の<br/>Google Workspaceアカウント乗っ取り]
    C --> D[Vercel内部システムへの不正アクセス]
    D --> E[一部プロジェクトの環境変数を参照<br/>sensitive未マークのもの]
    D --> F[デプロイ関連リソースの<br/>閲覧の可能性]

1つのサードパーティ OAuth の侵害が、従業員アカウント経由でインフラ中枢まで到達した典型的なサプライチェーン経路（取引先・ツール経由で本体に被害が及ぶ経路）である。

タイムライン

  • 2026年4月19日 11:04 AM PST: Vercel が最初の IOC（侵害指標、Indicator of Compromise）を公開
  • 2026年4月19日 6:01 PM PST: 攻撃起点が Context.ai 経由であったこと、追加推奨事項を公開
  • 2026年4月20日: ページ最終更新

公開されたIOC

Vercel が IOC として公開した OAuth アプリ ID は以下（該当アプリ自体はすでに削除済み）。

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Google Workspace 管理者は、この OAuth アプリ（もしくは Context.ai そのもの）を自社組織で許可していなかったか、監査ログを確認しておく価値がある。

「sensitive」環境変数の有無で影響範囲が変わる

今回の影響範囲は、環境変数に sensitive フラグが立っていたかどうかで分かれた。

  • sensitive マークあり: 作成後は読み取り不可の方式で保存されており、現時点で値を取得された証拠はないとのこと
  • sensitive マークなし: Vercel の管理 UI や API から値を読み戻せる保存方式のため、攻撃者に読まれた可能性がある

この「sensitive」はオプトイン（作成時に明示的に切り替える必要がある）で、デフォルトでは無効になっている。
Hacker News でも「セキュリティはデフォルトで強い方が筋で、オプトインは設計として筋が悪い」という批判が上がっていた。

実務的には、DB の URL や API キーなど、本来 sensitive にしておくべきだったのにフラグを立て忘れていた変数が混ざっている前提で動いたほうが安全。

利用者が今すぐ確認すべきこと

Vercel 側の案内と、実務的に足したほうがよい項目を表にまとめる。

項目内容
環境変数のローテーションsensitive マークなしの変数を全件ローテーション。API キー、DB 接続文字列、外部サービスのトークンなどが対象
アクティビティログの確認Vercel Dashboard の Activity で不審なデプロイや設定変更が混じっていないか確認
最近のデプロイメント検査vercel.json、ビルド設定、環境変数の変更履歴、不審なビルドコマンドや依存の追加がないかを確認
Deployment Protection「Standard 以上」に引き上げ、プレビュー URL を外部から素で叩けない状態にする
Deployment Protection Bypass トークンのローテーション使っている場合は再発行
Google Workspace 監査ログ自社の GWS で Context.ai（もしくは IOC の OAuth アプリ ID）が認可されていなかったか確認
Context.ai の利用棚卸し使っている場合はそちら側の公表・対応状況も追う

サードパーティAIツールのOAuth権限が主要経路になった

本体の守りが堅くても、従業員が業務で使う AI 系 SaaS の OAuth アプリが弱点になりうる。
LLM ブームで「とりあえず試す」系の AI ツールに Google Workspace 認可を気軽に与える流れがあるが、その 1 つが侵害されると、従業員アカウント経由でコア業務システムまで攻撃経路が開通する。

Google Workspace 管理者目線だと、

  • OAuth アプリの許可を管理者承認制にする
  • 使っている AI 系 SaaS のスコープを棚卸しする
  • 不要な OAuth アプリは速やかに取り消す

このあたりを今回のタイミングで見直す価値がある。

Vercel関連の過去記事

最近の Vercel 周りの記事も並べておく。

このサイトは静的生成して Vercel に置いているだけの構成なので、ランタイムで使っている環境変数自体は多くない。 それでも Vercel Analytics のトークンやビルド時に参照している値は一応見直した。DB や API サーバーを同居させているアプリだと影響はもっと大きいはずで、「sensitive」マーク忘れがあった案件ほど厳しい状況になっていると思う。