世界を動かす技術を、日本語で。

Vercelの侵害:OAuth攻撃がプラットフォーム環境変数のリスクを暴露

2026年4月22日原文(trendmicro.com)

概要

  • 2026年4月に公開された VercelのOAuthサプライチェーン侵害 の要点整理
  • 第三者OAuthアプリの侵害 が長期間にわたるプラットフォーム内部アクセスを許容
  • 環境変数の設計と通知遅延 が被害拡大とリスク増大に寄与
  • 攻撃は AI活用による迅速な展開 と指摘される
  • 防御策・検知指針 と今後の対応ポイントを解説

Vercel OAuthサプライチェーン侵害の要点

  • 第三者OAuthアプリ(Context.ai) の侵害が発端
  • OAuthの信頼関係 により従来型防御を回避
  • 内部アクセス権 でVercelの環境変数へ到達
  • 非機密扱いの環境変数 が平文で内部から読める設計
  • 結果として 顧客の機密情報 がプラットフォーム規模で流出リスク

影響と拡大要因

  • OAuthトラストチェーン による横断的な被害拡大
  • 検出から通知までの遅延 が被害を増幅
  • Vercelの設計上の課題 (環境変数の分類と保護)
  • AIによる攻撃速度の高速化 (CEOも公式に言及)
  • 2026年以降増加するサプライチェーン攻撃 (LiteLLM, Axios等も同種事例)

事件の経緯(タイムライン)

  • 2024年6月頃 :Context.aiのGoogle Workspace OAuthアプリ侵害(確認済み)
  • 2024年~2025年 :攻撃者がOAuthトークンで持続的アクセス維持
  • 2025年初頭 :Vercel従業員のGoogle Workspaceアカウントにピボット(確認済み)
  • 2025年初~中旬 :Vercel内部システムから環境変数の列挙開始
  • 2025年2月頃 :ShinyHunters系の攻撃者がBreachForumsでVercelデータ販売を主張(未確認)
  • 2026年4月10日 :OpenAIがVercel顧客にAPIキー漏洩通知(単一報告)
  • 2026年4月19日 :Vercelがセキュリティ速報を公開し、Context.aiを名指し(確認済み)
  • 2026年4月19日以降 :顧客通知・認証情報ローテーション・ダッシュボード更新実施

攻撃チェーンの詳細

  • ステージ1:第三者OAuth侵害
    • Context.aiのOAuthアプリがVercel従業員により認可
    • 攻撃者がこのアプリを侵害し、持続的なアクセストークンを獲得
  • ステージ2:Workspaceアカウント乗っ取り
    • OAuth権限でVercel従業員のGoogle Workspaceアカウントへ移動
    • メール・ドライブ・カレンダー等へのアクセス
  • ステージ3:内部システム侵入
    • WorkspaceアカウントからVercel内部システムへ横移動
    • 詳細な手法は未公開
  • ステージ4:環境変数列挙
    • 内部権限で顧客プロジェクトの環境変数を列挙
    • 非機密指定の変数が平文で取得可能
  • ステージ5:下流サービスへの影響
    • 環境変数に含まれる下流サービス(APIキー等)への認証情報漏洩
    • OpenAIのAPIキー漏洩通知が唯一の外部検知例

通知遅延の問題

  • OpenAIの通知 がVercelの公式発表9日前に発生
  • GDPR等の規制 では侵害認知から72時間以内の通知義務
  • SOC2・ISO 27001監査 でも検知~通知の遅延が審査対象
  • 顧客は 実際の侵害期間が発表日より前 である可能性を考慮
  • APIキー漏洩通知 は今やプラットフォーム侵害の主要な早期警告チャネル

AI活用による攻撃の特徴

  • CEOが AIによる攻撃速度の加速 を公式に指摘
  • 手動を超える列挙・探索速度 が証拠となる可能性
  • LLM活用による スキーマ発見・エンドポイント探索の自動化
  • 認証情報フォーマット認識脆弱性探索 の効率化
  • 攻撃者の行動速度・広範囲な探索 がAIの貢献を示唆

防御策・推奨事項

  • OAuthアプリを第三者ベンダー並みに扱う ガバナンス強化
  • 長寿命プラットフォームシークレットの廃止
  • プロバイダー側侵害を前提とした設計思想
  • 環境変数の機密・非機密判定の再検討
  • OAuth統合の監査・権限最小化・定期的な見直し
  • APIキー等の漏洩検知通知を高優先度で扱う運用体制
  • CI/CDやパッケージレジストリ等、開発者ストア型認証情報の保護強化

今後の展望と注意点

  • Vercelや関係各社による調査が継続中
  • 下流影響範囲や初期アクセス手法、攻撃者特定は今後の情報で変動可能性
  • 新たな技術的詳細やベンダー発表、第三者調査 が出次第、分析を更新予定
  • 組織は現時点で確認された攻撃チェーンに基づく対策を即時実施 推奨

参考リンク:

Hackerたちの意見

効果的な防御にはアーキテクチャの変更が必要だね。OAuthアプリをサードパーティのベンダーとして扱ったり、長期間有効なプラットフォームの秘密を排除したり、プロバイダー側の侵害を想定して設計することが求められる。でも、プロバイダー側の侵害を想定して設計するのはすごく難しいんだよね、だって信頼の根本的な部分だから…。

SaaSでOAuthアプリについて考えてるけど、ほんとに難しいよね。どこかのマーケットプレイスがいいアプローチを持ってるのかな?Cloudflareは、Salesloftの問題の後に、すべてのサードパーティのOAuthやAPIトラフィックをプロキシ経由で通すことを提案してたけど、それって別の脅威ベクターに変えるだけな気がする。狭いスコープや短い有効期限、OAuthクライアントシークレットのローテーションみたいな標準的な良いプラクティス以外に、何ができるか分からないな。特定のクライアントに関連するリクエストが来るIPアドレスをホワイトリストにするのもありかも?

ゼロトラストが今までほとんどマーケティングの戯言だったってことを裏付けてるね。セキュリティを設計するっていうのは、サプライチェーン攻撃で上流のプロバイダーが完全に乗っ取られないとは限らないっていう考え方を取り入れることを意味するんだ。

Vercelが環境変数のUIを導入したときに、「センシティブ」オプションがなかったって話、まだ見たことないな。https://github.com/vercel/vercel/discussions/4558#discussion... それが導入されるまでに約2年かそれ以上かかったみたい。https://vercel.com/changelog/sensitive-environment-variables...

「センシティブ」だからといって、読めないわけじゃないよ。ただ、UIを通しては露出してないだけ。アクション関数やルートからちょっと多めにプロップスを返すと、簡単に漏れちゃうことがある。こういう問題に対抗する唯一の方法は、自分のキーで環境を暗号化することだね。秘密情報はソースに埋め込むことになるかもしれないけど、他に分ける手段がないから。攻撃者は環境を読むだけじゃなく、コンパイルされた関数をダウンロードして復号化キーを見つける必要がある。理想的ではないけど、ワークアラウンドとしては機能するかもしれない。

UIレイヤーの敏感なフラグは、実際にはランタイムを変えないんだよね。ビルド中にprocess.envに入っちゃうと、それをgrepする依存関係は何でもできるから。問題はチェックボックスがないことじゃなくて、まだ全ての秘密を一つのenvバッグに詰め込んで、ビルドツールにそのバッグを渡しちゃってることなんだ。CloudflareのスコープバインディングやFlyはもう分けてるけど、他のプラットフォームは遅れてるだけ。

みんなが困るのは、Vercelの環境変数をローテーションしても、古いデプロイが無効にならないことだよね。前のデプロイは古い認証情報で動き続けるから、再デプロイや削除をしない限り、侵害された値がまだ生きてることになる。あと、Google WorkspaceのOAuth認証も確認しておくといいよ。Admin Console > セキュリティ > APIコントロール > サードパーティアプリのアクセス。2年前にデモ用に承認したアプリが、まだフルのメールやドライブアクセスを持ってる可能性があるから。

ローテーションするときは、古い変数を無効にするのが普通だよね。

普通、認証情報をローテーションするときは、前のものを無効にするもんだよね。古いものをアクティブに保ったまま新しいものを作るなんて聞いたことないな。

認証情報の変更で再デプロイしないのは、設計上の欠陥に見えるね。たとえば、Renderは環境変数の変更で再デプロイするし。

人を困らせるのは、Vercelの環境変数を回転させても古いデプロイが無効にならないこと。以前のデプロイは、再デプロイや削除するまで古い認証情報で動き続けるから。だから、掲示後にキーを回転させたけど、全てを再デプロイしなかったら、侵害された値はまだ生きてるってこと。このレポートのその部分は本当に混乱する;論理的じゃないし、LLMが生成した感じがする。古い環境変数を使った古いデプロイは、認証情報がまだ有効かどうかを制御することには何の影響もない。この問題は可用性に影響を与えるもので、機密性には影響しないって言われてる。レポートの別のセクションも混乱する、「環境変数の列挙(ステージ4)」。環境変数へのアクセスのメカニズムが奇妙に感じる - > ユーザーアカウントからの環境変数アクセスや、通常はアクセスされないプロジェクトとのインタラクションがないアカウントからのアクセスに特に注意を払ってください。本当に人々は他のシステムで使うためにVercelの環境変数から認証情報を読み取ってるの?

OAuthの信頼関係がプラットフォーム全体の露出につながった > CEOは攻撃者の異常な速さをAIに起因すると公に述べた > プラットフォームの侵害における検出から開示までの遅延に関する疑問 典型的だね!私が考える主な失敗は、1. 権限がありすぎるユーザーアカウント - 同じようなアカウントがたくさんある可能性がある 2. 2FAがないか、限られた2FA、またはゼロトラストアーキテクチャがない 3. サイバーセキュリティの衛生状態が悪いことだね。

Hacker Newsで議論の続きを見る