Vercelは2026年4月19日（米国時間）、「内部システムの一部への不正アクセス」を確認したとしてセキュリティ情報を公開しました。翌4月20日には追加アップデートで、侵害の起点が第三者AIツール「Context.ai」のGoogle Workspace OAuthアプリ経由であったこと、IoC（侵害指標）としてOAuth App ID、Mandiantによる対応支援参加などが明らかになっています。本記事では、公式発表・CEO Guillermo Rauch氏のコメント・独立系リサーチ会社の解析を総合し、「何が起きたのか」「何が確定していて、何が未確定か」「利用者側は何を優先すべきか」を整理します。 Vercelが本件を公表したのは、2026年4月19日です。Vercelのナレッジベース（Security Bulletin）では「内部Vercelシステムの一部への不正アクセスを特定した」とし、インシデントレスポンス専門家（後にMandiantと判明）および法執行機関への連絡、影響を受けた顧客への直接連絡、環境変数の見直し推奨などが示されました。翌4月20日にはBulletinが更新され、起点となったのが第三者AIツール「Context.ai」のGoogle Workspace OAuthアプリであったこと、IoCが追加公開されています。 ポイント：4月19日時点の「一部内部システムに不正アクセス／影響は限定的／環境変数の見直し推奨」という軸に加え、4月20日のアップデートで侵害経路（Context.ai経由のOAuth乗っ取り）とIoC（OAuth App ID）が具体化された、というのが現在の情報状況です。一方で、BreachForums上の「ソースコード・内部DB込みで$2M販売」という売り手側の主張は、公式発表と範囲が一致していません。
参照：Vercelが侵害された日：Context.ai起点OAuth侵害で広がったクラウド開発基盤侵害の全貌
侵害が公表された日
公式発表で確認済みの事実
内部システムへの不正アクセス
Vercelは「内部Vercelシステムの一部への不正アクセス」を確認したとしています。調査・封じ込め・復旧のため、Google傘下のMandiantを含む外部のインシデント対応企業および業界ピアを投入し、Context.aiとも直接連携して根本原因の全容を確認中であることが明記されています。サービス自体は稼働中で、Next.js・Turbopackおよびオープンソースプロジェクトは供給網監査の結果「安全」と確認されています。
影響顧客は限定的なサブセット
影響を受けた顧客は「限定的なサブセット」であり、該当顧客には直接連絡済みとされています。これはプラットフォーム全体の一律侵害とは異なるニュアンスで、「連絡を受けていなければ、現時点でVercel資格情報や個人データが侵害された証拠はない」と明言されています。ただし調査継続中のため、追加の侵害が判明した場合は引き続き通知するとしています。
環境変数は「sensitive」のみ保護
最大の実務的ポイントは、環境変数の扱いです。Vercelは全顧客の環境変数を「保管時暗号化（encrypted at rest）」していますが、「sensitive」フラグを立てた環境変数だけは「値を読み戻せない形で保管」される仕様です。攻撃者はsensitiveフラグが付いていない環境変数を列挙・参照できたとされ、sensitive扱いの値にアクセスされた証拠は現時点で「ない」と発表されています。
出典：
侵害経路：Context.ai起点の攻撃チェーン
本件は「OAuthを起点に侵害が広がった」という文脈で語られており、4月20日のアップデートで具体名が明らかになりました。Context.aiは、会議インテリジェンス／ナレッジマネジメント系の業務用AIプラットフォームで、Vercelの一従業員が利用していたとされています。
OAuthは、リソース所有者（ユーザー）に代わって、第三者アプリケーションが限定されたアクセス権を得るための仕組みです。委譲された権限が攻撃者の手に渡ると、本人になりすました操作が可能になります。
参考：
Rauch CEOが説明する攻撃チェーン
VercelのCEO Guillermo Rauch氏がX（旧Twitter）で公表した説明によれば、攻撃の流れは以下の通りです。
- Context.ai側で侵害が発生：Context.aiを顧客として利用していたVercel従業員が、Context.aiの侵害を経由してGoogle Workspaceアカウントを乗っ取られた
- 従業員のGoogle Workspaceアカウント乗っ取り：侵害されたVercelのGoogle Workspaceアカウントを起点に、複数段階のエスカレーション操作が実行された
- Vercel内部環境への水平展開：段階的な操作で従業員のGoogle Workspaceから一部のVercel環境へアクセス権が拡張された
- 非sensitive環境変数の列挙：sensitive指定されていない環境変数が列挙・読み取られ、そこに含まれていたシークレットを足がかりにさらなるアクセス権を得た
Rauch氏は、攻撃者について「極めて洗練されており、Vercelシステムへの深い理解と異常な行動速度から、AIによって大幅に加速されている可能性が高い」と評価しています。
Hudson Rockによる初期感染の分析
独立系の脅威インテリジェンス企業Hudson Rock（InfoStealers.com）は、今回の侵害の初期侵入はContext.ai従業員のマシンに2026年2月に発生したLumma系インフォスティーラー感染である可能性が高いと分析しています。感染経路は当該従業員がゲームのチート（Robloxのオートファームスクリプト／エグゼキューター）を探してダウンロードした過程で踏んだとされ、これによりGoogle Workspace資格情報、Supabase／Datadog／Authkitなどの企業向けツールのキー・ログインが窃取されていたと報告されています。
注意：Hudson Rockの分析は現時点ではVercel／Context.ai側の公式発表と完全に一致してはいません。ただし時系列・侵害対象の整合性は高く、「Context.aiが侵害された」というVercel公式の一次情報と矛盾するものではありません。初期侵入ベクターの詳細は追加発表を待つ必要があります。
参考：
4月20日のBulletin更新で、Vercelは調査支援のためIoCを公開しました。Google Workspace管理者およびGoogleアカウント所有者は、今すぐこのOAuthアプリの利用履歴を確認すべきであるとされています。 公開IoC（OAuth App ID） 本OAuthアプリはContext.aiに紐づくGoogle Workspace連携アプリで、数百ユーザー規模の広範な侵害の対象となった可能性がある、と発表されています。 Google Workspace管理コンソールで、上記OAuth App IDの利用状況を以下の観点で確認してください。
出典：IoC（侵害指標）
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com確認方法（Google Workspace）
4月19日 午前02:02（ET）、BreachForumsに「Vercel Database Access Key & Source Code – 19 Apr 2026」と題する投稿が「ShinyHunters」名義で出現しました。主張された内容は、Vercelの内部データベース、アクセスキー、ソースコード、従業員アカウント、APIキー、NPMトークン、GitHubトークン、Linear（内部プロジェクト管理ツール）データを含む広範なものです。売値は当初$2M（BTCなら$500kから交渉可）とされています。 Vercelの公式Bulletinは、売り手側の主張する範囲を認めていません。具体的には以下の点が異なります。 解釈上の注意：売り手の主張と公式発表の両方が部分的に正しい可能性があります。実務的には「公式が明言した範囲」に沿って対策しつつ、売買主張のスコープ（GitHub・NPMトークン等の広範な資格情報）が仮に本当だった場合に備えた保守的なローテーションを行うのが安全です。
参考：ShinyHuntersによる売買主張との食い違い
公式発表との範囲の違い
影響範囲の整理
影響しうる情報
公式発表とRauch CEOの説明を踏まえると、運用上は以下の観点で棚卸しするのが現実的です。
- sensitive指定されていないVercel環境変数（最重要）
- 環境変数経由で注入している外部サービスのAPIキー（DB、決済、メール配信、分析、監視、認証など）
- Deployment Protection関連のバイパストークン
- GitHub／GitLab連携のOAuthトークン、CIトークン
- （ShinyHunters主張が事実なら）NPMトークン、Linear連携情報
影響の「強弱」
同じ「環境変数」でも、影響の強さは中身で変わります。例えば「公開情報に近い設定値」と「管理者権限のAPIキー」では緊急度が異なります。後者は即時ローテーションが基本です。
| 対象 | 例 | 優先度 | 推奨対応 |
|---|---|---|---|
| 決済・請求 | Stripe secret key、PayPay APIキー | 最高 | 即時ローテーション＋取引ログ監査 |
| DB／ストレージ | Postgres admin、S3 access key、Supabase service_role | 最高 | 即時ローテーション＋権限最小化＋接続元IP確認 |
| 認証・SSO | NextAuth/Auth.js signing key、JWT secret、Authkit key | 最高 | 即時ローテーション＋既存セッション強制無効化 |
| Deployment Protection | Vercelのバイパストークン | 高 | 全トークンローテーション＋Standard以上に設定 |
| CI／リポジトリ連携 | GitHub App token、CI runner token、NPMトークン | 高 | 連携を一度切って再認可＋スコープ最小化 |
| メール送信 | SendGrid／Resend／Postmark APIキー | 中 | ローテーション＋送信レート監視 |
| 監視・分析 | Datadog、Sentry、Plausibleトークン | 中 | ローテーション＋不審な読み取りアクセス確認 |
| 非機微設定 | Feature flag、公開ID、公開URL | 低 | 必要に応じて見直し |
補足として、Vercel側の監査ログ（Audit Logs）は変更イベントや操作の痕跡確認で重要な一次証跡です。
利用者の優先対応（Vercel公式推奨＋実務上の補強）
① 環境変数の棚卸しとローテーション
公式推奨の最優先事項です。Production／Preview／Development、全プロジェクトでsensitive指定されていない環境変数をすべて列挙し、シークレットを含むものはすべて漏えい前提でローテーションしてください。
- 新鍵を発行元（Stripe、AWS、DB、外部SaaS等）で生成
- Vercelの環境変数を更新 → 再デプロイ
- 旧鍵を必ず無効化（発行し直しただけでは不十分）
- ローテーション後は、rotate前期間（保守的には2026年4月初旬から検知時点まで）の利用ログを発行元側で確認
② sensitive環境変数機能への移行
今後新規に登録するシークレットは、Vercelの「sensitive environment variables」機能を使ってください。sensitive扱いの値はダッシュボードから読み戻せない形で保管されるため、同種の侵害が再発しても値そのものの流出リスクを下げられます。Vercelは本件を受けてダッシュボードに環境変数の一覧表示と、sensitive変数のUI改善を追加しています。
③ Deployment Protectionの強化
- Deployment ProtectionをStandard以上に設定
- 既存のバイパストークンはすべてローテーション
④ デプロイ履歴の監査
直近のデプロイを全件確認し、以下のいずれかに該当するものは削除を検討してください。
- 既知のコミット・既知の作者に紐付けられないデプロイ
- ビルドログに想定外の外部通信やBase64ブロブの書き込み／実行
- サーバーレス関数からの想定外のアウトバウンド接続
⑤ Google WorkspaceでIoC確認
前述のOAuth App ID（110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com）の承認履歴を全ユーザー分確認してください。承認していたユーザーは、前節の手順でアクセス取り消しとセッション・資格情報の再発行を行います。
⑥ 連携SaaSの監査ログ確認
Vercelと連携しているGitHub／GitLab／Linearなどで、露出期間中（保守的には2026年4月初旬〜現在）の操作を確認してください。特にLinear等のチケットにはデバッグ時にペーストされたシークレットが残りがちです。AKIA、sk_live_、ghp_、ghs_、npm_、eyJ、----BEGIN などのパターンで全文検索し、見つかったものはすべてローテーションしてください。
# ローテーション作業チェックリスト（コマンドではなくメモ用）
# 1) sensitive指定されていない環境変数を全プロジェクト・全環境で一覧化
# 2) シークレットを含むものを優先度順にグループ分け
# 3) 発行元（Stripe/AWS/DB/Supabase等）で新キー発行
# 4) Vercelの環境変数を「sensitive」で再登録
# 5) 全環境でデプロイ・疎通確認
# 6) 旧キーを無効化
# 7) 発行元のアクセスログで露出期間中の異常アクセスを再確認
# 8) GitHub OAuth/Vercel連携を一度切断 → スコープ最小で再接続
# 9) Deployment Protectionをrotate + Standard以上に設定
# 10) Google Workspaceで該当OAuth App IDをrevoke（全ユーザー）
公式推奨：
現時点で公開されている時系列を整理すると以下の通りです。影響判定の「下限」は、Hudson Rock分析に基づく2026年2月のインフォスティーラー感染まで遡るのが保守的です。 セキュリティインシデントは、稼働障害（ダウン）とは別軸です。「サービスは動いているが内部で不正アクセスがあった」というケースは珍しくありません。Vercelは本件について「サービスは稼働中」と明言しています。 公式情報では「影響は限定的」とされています。一方で、限定的であっても、利用者側の環境変数に高価値のシークレットが含まれていればリスクは高くなります。自社の露出（何を預けているか）で判断してください。 ShinyHuntersのBreachForums投稿は「Vercelのソースコード込み」と主張していますが、Vercelは供給網監査の結果Next.js、Turbopack、オープンソースプロジェクトは安全と明言しています。Next.js等を最新版にロックする対応は現時点の情報では必須ではなく、公式の追加情報を監視する姿勢が適切です。 sensitive環境変数は読み戻しが阻止されるため、本件のような列挙型アクセスには強いですが、デプロイ中のランタイム（`process.env`）や関数ログへの流出までは防げません。最小権限・最小スコープのキー発行と、ログにシークレットを出さない運用がセットで必要です。 実務的な結論：不確実な情報を追うより、「外部キーを預けている前提」でローテーションと監査を先に進める方が、被害を最小化しやすいです。特に、sensitive指定していない環境変数・Deployment Protectionトークン・Google Workspace連携のOAuthアプリ、この3点は今日中の対応対象と考えてください。露出期間とタイムライン
日付
出来事
ソース
2026年2月
Context.ai従業員PCがLumma系インフォスティーラーに感染（推定）
Hudson Rock
2026年4月初旬〜
ShinyHunters系アクターがContext.aiの資格情報を利用開始（保守的な露出期間下限）
公式コミュニティ分析
2026年4月19日 02:02 ET
BreachForumsに「Vercel Database Access Key & Source Code」投稿
BleepingComputer等
2026年4月19日
Vercelが公式Bulletinを公開、Mandiantと連携、影響顧客に通知
Vercel公式
2026年4月20日
Bulletin更新：Context.ai名公開、IoC（OAuth App ID）公開、Rauch CEOがXで詳細共有
Vercel公式、X
よくある誤解
誤解1：Vercelの障害と同一視
誤解2：全ユーザー一律で影響
誤解3：Next.js／Turbopack経由の供給網攻撃
誤解4：「sensitive」にしておけば絶対安全
今後の注視点
まとめ
Vercelが侵害を公表したのは2026年4月19日で、翌20日には侵害経路が「第三者AIツールContext.aiのGoogle Workspace OAuthアプリ経由」であったことと、IoC（OAuth App ID）が公式に開示されました。攻撃チェーンは「Context.ai侵害 → Vercel従業員のGoogle Workspace乗っ取り → Vercel内部環境 → 非sensitive環境変数の列挙」で、Vercelの環境変数のうちsensitive指定されていないものがリスクに晒されています。Mandiantが対応支援に入り、Next.js／Turbopackは供給網監査で安全と確認されています。一方、BreachForumsのShinyHunters名義による$2M売買主張は、ソースコードや内部DB込みのより広範な内容を主張しており、公式発表とスコープが一致していません。
利用者は、①非sensitive環境変数の全数ローテーション、②sensitive機能への移行、③Deployment Protection強化とバイパストークンのローテーション、④Google Workspaceで公開IoC（OAuth App ID）の確認と取り消し、⑤連携SaaS（GitHub、Linear等）の監査ログ確認とシークレット漏れ検索を、それぞれ優先して実施してください。
参考リンク：
