ハクソク

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

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

8時間前原文(www.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. サイバーセキュリティの衛生状態が悪いことだね。
└
AIを責めるのは、ウェブサイトが壊れたときにDDoSを責めるのと同じくらい無意味だよね。
どういうことなのか、まだよくわからないんだ。彼らが言ってるOAuthトークンって、ユーザーが「Googleでサインイン」を使ったときにもらうやつのこと？それなら、ユーザーがサインインした特定のGoogleアプリのクライアントIDやクライアントシークレットに縛られてるんじゃないの？攻撃者はそこからどうやってコントロールプレーンにアクセスできたの？たとえ攻撃者がユーザーのOAuthトークンやクライアントID、クライアントシークレットを知っていたとしても、Google Driveとかにはアクセスできるけど（それは悪いことだってわかるけど）、そこからどうやってVercelのシステムにログインできたのか全然理解できない。Google Driveの中で認証情報を見つけたのかな？
└
セッショントークンを手に入れたら、つまりOAuthの手続きを終えた後は、APIにリクエストを送れるようになるんだ。それだけのこと。発行されたトークンは、被害者の受信箱にアクセスする権限を持ってた可能性が高いから、攻撃者はそれを利用してメールを読んだり、一時的なパスワードやマジックリンク、その他の重要な情報を取得したんだ。
└
俺もよくわからないんだけど、Context.aiのOAuthアプリが侵害されたの？つまり、脅威を与える側はContext.aiが持ってるのと同じくらい、全てのContext.ai顧客のワークスペースを見えるってこと？なんで一人の社員が責められてるの？このVercelの社員がContext.aiにVercelのワークスペース全体を読むことを許可したの？
└
具体的には言ってないね。俺の予想だと、恥ずかしいことがあったんじゃないかな。それで隠してるのかも。もしかしたら、DriveやGmailのパスワードとか。あるいは、パスワードなしのログインリンク（兄弟が言ってたように）。
なんでこの話が何度も繰り返されるの？大きな話だってのはわかるけど、同じことを説明するN個の記事（N > 1）が必要ってわけじゃないよね。
└
新しい情報だね。たとえば、開示の数ヶ月前から環境の列挙が行われていたなんて知らなかったし、それがHNに来る理由の一部なんだ。Vercelに関しては、読者の10%くらいは何らかの形で関わってるんじゃないかな。
└
この洪水は、「なんで人はVercelを使うの？」っていう絶え間ない質問への反応かもね。「安いし、簡単だから」って。*高いけどね。
└
それがOAuthに関係してるなんて知らなかった。いつここで話題になったの？実際、詳細が少なかったからバーバラは声を温めてたみたい。
> AIによって加速されたトレードクラフト。CEOは攻撃者の異常なスピードをAIの強化に起因すると公に述べた — 2026年のAIによって加速された敵のトレードクラフトに関する議論の中での初期の高プロファイルなデータポイントだね。私が見た限りでは証拠もなく言われてるから、あんまり意味がない。
└
AIがメディアが無批判に繰り返すナンセンスな言い訳の市場を本当に揺るがしてるみたいだね！
これからもっとこういうのが増えると思うよ。ITを活用した経済がAIツールの広範な実験によるリスク債務に追いついてくるから。Vercelのリーダーシップが、ベンダーリスクに関係なく会社全体でAIをインストールしてテストするプレッシャーを受けてるってことだよね。スピード、スピード、スピード。これは、厳格にAIインストールのホワイトリストを適用していない企業が直面する非常に一般的な脆弱性だよ。あなたのローカルやSaaSのAIの範囲内で、ContextのようなAIツールがどれだけインストールされてるか、IT担当者に聞いてみて。多分、かなりの数だと思うよ。これらのツールは…全てにアクセスできるからね！約18〜24ヶ月後にはセキュリティベンダーとRBACメカニズムが存在するようになるだろうし。Vercelはカナリアだよ。ここから面白くなりそうだね。Contextが唯一のターゲットだなんてありえない。これは確立された、無視されがちな脅威のベクトルで、一つが破られると他も始まる。これらの脆弱性が起こり始めると、非常に厳しい6ヶ月が待ってると思う。みんなが今AIのインストールを監査してるから（そうすべきだし）、TAsはアクセスを持ってるうちに発動するだろうね。情報源 - テクノロジーのセキュリティ責任者です。
このレポートのいくつかの詳細、例えば2024-2025年のタイムラインは、あまり広く報じられてないよね？これらの日付の出所を知ってる人いる？例えば、> 2024年後半 - 2025年初頭：攻撃者がContext.aiのOAuthアクセスからVercelの社員のGoogle Workspaceアカウントに移行 -- 確認済み — Rauchの声明 > 2025年初頭 - 中頃：内部のVercelシステムにアクセス；顧客環境変数の列挙が始まる -- 確認済み — Vercelの公報
└
これらは全部作り話で、多分幻覚だね。
Vercelよりも必ずしも安全ってわけじゃないけど、自己ホスティングのものを作ってるんだ。将来的には、こういうクラウド攻撃やコストの影響で、個人用VPSファミリークラウドがもっと一般的になると思うよ。