2026年4月、Vercelはサードパーティ製AIツール「Context.ai」のOAuth認証情報侵害を起点とするサプライチェーン攻撃を受けました。攻撃者はGoogle Workspaceアカウントを経由して一部のVercel環境・環境変数にアクセスしたことが確認されています。本記事では、インシデントの全容・IOC情報・Vercelが推奨する対応手順・環境変数管理のベストプラクティスについて、Vercelを利用するエンジニアおよびDevOpsエンジニア向けに詳しく解説します。
インシデント概要 Context.aiのOAuth侵害から始まったサプライチェーン攻撃
2026年4月19日、Vercelは自社の内部システムへの不正アクセスを確認し、インシデントレスポンス専門家を招集するとともに法執行機関への通知を行いました。Vercel公式のセキュリティ情報（Knowledge Base Bulletin）によると、このインシデントは以下の経路で発生しています。
「Context.ai」はVercel社員が業務で使用していたサードパーティ製のAIツールです。このContext.aiが攻撃者により侵害され、OAuth認証情報が奪取されました。攻撃者はその認証情報を悪用し、対象社員が使用しているVercel Google Workspaceアカウントを乗っ取ることに成功しました。そしてGoogle Workspaceアカウントに付与されていたアクセス権限を通じて、一部のVercel環境および環境変数への不正アクセスが行われました。
Vercelは「もしVercelからご連絡がなければ、お客様のVercel認証情報や個人データが侵害されたとは考えていません」と声明を出しており、影響を受けた顧客への個別連絡を行っています。今回の攻撃では、Vercelに依存する特定のサプライチェーンが悪用された典型的な事例となりました。
攻撃の流れを追う OAuthトークン奪取からVercel環境変数アクセスまで
今回のインシデントを時系列で整理すると、サプライチェーン攻撃がいかに多段階・巧妙であるかがわかります。
第一段階として、攻撃者はContext.aiというAIツールそのもの、もしくはそのOAuthフロー上の脆弱性を突きました。Context.aiはVercelの開発業務において利用されており、Google WorkspaceのOAuth連携が設定されていたと考えられます。OAuth認証情報（アクセストークンやリフレッシュトークン）が攻撃者の手に渡ることで、被害者本人が気づかないうちに不正アクセスの入り口が開かれました。
第二段階では、奪取したOAuth認証情報を使ってVercel社員のGoogle Workspaceアカウントへの不正ログインが実行されました。Google WorkspaceはVercelの内部業務に広く使われており、ここへのアクセスは一種の「マスターキー」になり得ます。
第三段階として、Google Workspaceアカウントを通じて、攻撃者はVercelの一部環境（プロジェクト環境など）への読み取りアクセスを獲得しました。この段階で環境変数への不正アクセスが発生したとされています。ただし、Vercelの「sensitive（センシティブ）」として設定されていた環境変数については読み取り不可の状態で保護されており、侵害を免れたことがVercelから報告されています。
このように、Context.ai → Google Workspace → Vercel環境という三段階の連鎖がサプライチェーン攻撃の本質です。各段階でのアクセス権限の連鎖が、最終的な被害を拡大させました。
IOC情報と影響範囲の確認方法
Vercelは2026年4月19日 11:04 AM PSTに、コミュニティ調査のためのIOC（Indicators of Compromise：侵害指標）を公開しました。
今回のインシデントで特定された侵害済みGoogle Workspace OAuthアプリIDは以下の通りです。
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.comVercelの発表によれば、このOAuthアプリは「より広範な侵害の対象であり、多数の組織の数百ユーザーに影響している可能性がある」とされています。つまり、Vercel以外の組織・プロダクトも同様の侵害を受けている可能性があります。
影響範囲を自組織で確認するには、以下のアプローチが有効です。まず、Google Workspace管理コンソールにログインし、「セキュリティ」→「OAuth アプリへのアクセス」から上記のクライアントIDを持つアプリが接続されていないかを確認します。次に、Vercelのアクティビティログ（Team Settings > Audit Log）を参照し、不審なアクセスや見覚えのないIPアドレスからの操作がないかをチェックします。さらに、最近デプロイされた内容を確認し、意図しない変更が含まれていないかを検証することも重要です。
Vercelが推奨する6つの対応手順
Vercelは2026年4月19日 6:01 PM PSTに推奨対応策を公開しました。Vercelを利用しているエンジニア・DevOpsエンジニアは、以下の6つの手順を順番に実施することが推奨されています。
最初に行うべきことは、アカウントのアクティビティログの確認です。Vercelの管理画面でAudit Logを確認し、不審なログインや操作の痕跡がないかを調査します。特に、見覚えのないIPアドレスや通常と異なる時間帯のアクセスに注意してください。
次に、非センシティブな環境変数のローテーションを実施します。データベース接続文字列、APIキー、外部サービスのシークレットなど、sensitive設定をしていない環境変数はすべてローテーション（値の更新）を行います。ローテーション後は、依存するサービス側でも新しい値への切り替えを確認します。
三番目の手順として、sensitive環境変数機能の有効化があります。まだ利用していない場合は、Vercelプロジェクトの環境変数設定で「sensitive」フラグを有効にします。sensitive設定された環境変数は暗号化されて保存され、Vercelの管理画面や APIからでも値を読み取ることができなくなります。今回のインシデントでsensitive変数が侵害を免れたことは、この機能の有効性を証明しています。
四番目は、最近のデプロイの調査です。インシデント発生前後にデプロイされたプロジェクトを確認し、意図しないコード変更や設定変更が含まれていないかを検証します。
五番目として、Deployment Protectionの設定強化があります。Vercelの「Deployment Protection」機能をStandard以上に設定することで、不審なデプロイを防ぐ追加の保護レイヤーが有効になります。
最後の手順として、Deployment Protectionトークンのローテーションを行います。既存のDeployment Protectionトークンを無効化し、新しいトークンを発行します。古いトークンが不正に取得されていた場合でも、ローテーションによってそのトークンを無効化できます。
sensitive環境変数とDeployment Protectionの重要性
今回のインシデントで特筆すべきことは、Vercelの「sensitive環境変数」機能が実際に機能し、侵害を防いだという事実です。この機能はVercelが提供するセキュリティ機能の中でも特に重要なものの一つです。
sensitive環境変数として設定された変数は、Vercel側での保存時に暗号化され、Vercelダッシュボード・APIのどちらからも値を平文で取得することができません。デプロイ時にのみ値が展開され、ランタイム環境に注入されます。これにより、攻撃者がVercel環境への読み取りアクセスを取得した場合でも、sensitiveフラグが付いた環境変数の値を直接読み取ることができませんでした。
実際の設定方法としては、Vercelのプロジェクト設定（Settings > Environment Variables）で各環境変数に「Sensitive」トグルを有効にするだけです。データベースパスワード、OAuthクライアントシークレット、外部APIキー、暗号化キーなど、漏洩時の影響が大きいシークレット情報はすべてsensitiveとして設定することを強くおすすめします。
Deployment Protectionについては、Vercelプロジェクトへの不正なデプロイを防ぐための機能です。Standard設定以上にすることで、デプロイ時の認証要件が強化され、不審なデプロイの実行を防止できます。特に本番環境（Production）については、最低でもStandard設定にしておくことが重要です。
サプライチェーン攻撃から学ぶゼロトラスト設計の教訓
今回のVercelインシデントは、現代のクラウドネイティブ開発環境におけるサプライチェーン攻撃の典型例として、多くの教訓を与えてくれます。
第一の教訓は、サードパーティツールへのOAuth権限付与の最小化です。今回の攻撃はContext.aiというツールが持っていたOAuth権限が悪用されました。開発チームが使うSaaSやAIツールは便利ですが、それぞれにOAuth連携を許可する際は、必要最小限の権限のみを付与するべきです。定期的にGoogle Workspace（またはMicrosoft 365）の管理コンソールから接続済みのOAuthアプリを棚卸しし、不要なアプリや過剰な権限を持つアプリは削除・制限します。
第二の教訓は、機密情報のライフサイクル管理です。環境変数のローテーションは「インシデント発生時だけ行うもの」ではなく、定期的なセキュリティ運用の一環として組み込むべきです。CI/CDパイプラインにシークレットローテーションの仕組みを組み込み、例えば90日ごとに自動的に更新するようにすることが理想的です。
第三の教訓は、ゼロトラストアーキテクチャの実践です。「内側のネットワークや認証済みのツールは信頼できる」という前提を捨て、すべてのアクセスを常に検証する設計が求められます。今回のケースでは、Context.aiという信頼されたツールが侵害されたことで、連鎖的な被害が発生しました。どのツール・どのサービスも完全には信頼せず、最小権限の原則（Principle of Least Privilege）を徹底することが重要です。
第四の教訓は、AIツールの拡大に伴うリスクの再評価です。2026年現在、エンジニアの業務環境にはContext.aiをはじめとした多数のAIツールが統合されています。これらのツールは開発生産性を高める一方で、各ツールに付与されたOAuth権限が新たな攻撃ベクトルになり得ます。AI関連リスクが2026年のセキュリティ脅威トップにランクインしたという調査結果とも一致しており、AIツールのセキュリティ評価は今後ますます重要になります。
今回のVercelのインシデント対応は、IOCの早期公開・推奨対応の迅速な発信・透明性の高い情報開示という点で参考になる対応でした。同様のサプライチェーンリスクは他のクラウドサービスにも潜在しており、Vercel利用の有無にかかわらず、OAuthアプリの棚卸し・環境変数のsensitive化・Deployment Protectionの強化という三点は、今すぐ取り組む価値のある対策です。
