Vercel OAuth サプライチェーン侵害事例分析

主要な結論

• 侵害されたサードパーティの OAuth アプリケーションにより、Vercel の内部システムへの長期にわたるパスワード非依存アクセスが可能になり、従来の境界防御を回避するための OAuth の信頼関係の脆弱性が浮き彫りになりました。
• Vercel の環境変数モデルがこの影響を拡大させました。明示的に機密としてマークされていない認証情報は、内部アクセスを持つ攻撃者によって平文として読み取ることができ、プラットフォーム規模で顧客の機密情報が漏洩しました。
• 公的告知前の公開された漏洩認証情報に関するアラートは、プラットフォーム侵害における「検出から通知までの遅延（Detection-to-notification latency）」が重要なリスク要因であることを示しています。
• この事例は、2026 年のより広い収束パターン（LiteLLM, Axios など）に適合しており、攻撃者が CI/CD、パッケージレジストリ、OAuth インテグレーション、デプロイメントプラットフォームなど、開発者が保存する認証情報を一貫して標的にしていることが確認されています。
• 効果的な防御にはアーキテクチャの変更が必要です：OAuth アプリをサードパーティベンダーとして扱う、長期にわたるプラットフォーム機密の排除、およびプロバイダ側の侵害が前提となる設計への移行です。

状況説明（最終更新：2026 年 4 月 20 日 月曜日）

本分析は、本件発行時点において公知事実として広く知られている Vercel OAuth サプライチェーン侵害事象に基づいています。Vercel と関連当事者により調査が継続中であり、下流への影響の全範囲、初期アクセスベクトルの正確な内容、および帰属先などの主要詳細は、追加情報が入手するにつれて変化することがあります。情報ギャップについては推測を行うのではなく明示的に記載しました。防御上の勧告や検出ガイダンスは、確認された攻撃チェーンと確立されたサプライチェーン侵害パターンに基づいています。組織は完全な状況が判明するのを待たず、これらに即して行動するべきです。新しい技術的な詳細、ベンダーからの公式発表、または第三者による研究が明らかになるにつれて、この分析を更新していく予定です。

約 2024 年 6 月に開始された侵入活動が 2026 年 4 月に公表されました。攻撃者は、Context.ai の Google Workspace OAuth アプリケーションの侵害を悪用し、Vercel の内部システムへの足場（フットホールド）を得て、特定されないが一部限定とされる顧客プロジェクトの環境変数を暴露しました。Vercel は、フロントエンドおよびサーバーレスアプリケーションに広く使用されているクラウドデプロイメントおよびホスティングプラットフォームです。

2026 年 4 月 19 日、Vercel はセキュリティブリーフィングを発表し、CEO の Guillermo Rauch（以下、「ラウシュ」）氏は X（旧 Twitter）上で詳細な投稿を行い、攻撃チェーンを確認するとともに、侵害されたサードパーティとして Context.ai を特定しました。この事象は重要であり、その理由は 2 つあります。第一に、OAuth のサプライチェーンにおける信頼関係が従来の境界防御を回避する横方向移動（レテラル・ムーブメント）の経路を生み出すことを示している点です。第二に、Vercel の環境変数の感度モデルにより、機密と明示的にマークされていない認証情報は静かに暗号化されておらず、内部アクセスを持つ攻撃者が容易に読み取れる状態にあった点です。

本分析は攻撃チェーンを検討し、爆発半径を拡大させたプラットフォームの設計上の意思決定を評価し、 rising wave（高まり続ける波）としてのサプライチェーン侵害事例（LiteLLM, Axios, Codecov, CircleCI など）との文脈を整理し、Vercel および類似の PaaS プラットフォームを利用する組織向けの実行可能な検出および強化ガイダンスを提供します。

今回の事象が明らかにしたこと

今回の事象が目新しさを持っているのはその洗練された手法ではなく、主に以下の 3 つのより広い示唆意義によるものです：

1. **OAuth の増幅効果:**単一の OAuth の信頼関係が、侵害ベンダーとの直接的な関係のない下流の顧客まで影響を与えるプラットフォーム全体の暴露事象へと拡大しました。
2. AI に加速された戦術（AI-Accelerated Tradecraft）: CEO が公開的に攻撃者の異常な迅速さを AI の拡張によるものだと归属し、2026 年の「AI に加速された敵対者戦術」に関する議論において、早期かつ高プロファイルなデータポイントとなりました。
3. **検出から公表までの遅延:**少なくとも一つの公的顧客報告により、Vercel の公表（4 月 19 日）から 9 日前、すでに「野生で（外部に）」認証情報が漏洩として検出されていたことが示されており、プラットフォーム侵害における検出から公表までの遅延に関する疑問を提起しています。

事象のタイムライン

攻撃は OAuth 侵害からの初期アクセスと Vercel の公的発表までの期間におよそ 22 ヶ月に及びました。この「駐在時間（dwell time）」は、合法なアプリケーション権限を活用して標準的な検出制御をトリガーしにくい OAuth ベースの侵入に見られるものであり、典型的です。

図 1. 事象のタイムライン（約 22 ヶ月間の驻在時間を示す）

表 1. キーイベントのサマリーと確認ステータス

タイムラインから得られる重要な観測点は、初期 OAuth 侵害から公的発表に至るまでの驻在時間が約 22 ヶ月であったことです。高度な侵入において長期化は珍しくありません（Codecov の侵害で約 2 ヶ月、CircleCI では数週間の検出漏れが報告されています）が、合法的なアプリケーション権限を活用する OAuth ベースの横方向移動を検出するのが難しいことを示しています。

この課題を悪化させているのは、Google Workspace の OAuth オーディットログが多くのサブスクリプションプランにおいてデフォルトで 6 ヶ月間保持されていることです。調査官が捜査を開始する前に、最初期の侵害活動に関するフォレンジックな可視性が失われていた可能性があります。

攻撃チェーン

この攻撃は、現代的な SaaS 環境に内在的な信頼連鎖を悪用しました：第三者的な OAuth アプリケーションが企業向け Google Workspace アカウントへのアクセス権限を得ていたこと。

図 2. Vercel 侵害の攻撃チェーン

ステージ 1: サードパーティ OAuth 侵害（T1199）

AI アナリティクスツールを提供する Context.ai は、Vercel の従業員が認証した Google Workspace OAuth アプリケーションを持っていました。攻撃者はこの OAuth アプリケーションを侵害しました（Context.ai が侵害された正確なメカニズムは公開されていません）。ラウシュ氏の X での投稿には、「Vercel はインシデントの全規模を理解するのを支援するために Context に連絡を取った」とあり、これは Context.ai 自身も侵害を検出していなかった可能性を示唆しています。

これは重要な初期アクセスベクトルです。認証された OAuth アプリケーションは、以下の特性を持ちながら永続的なアクセストークンを維持します：

• ユーザーのパスワードが不要
• パスワードの変更（ローテーション）後も生存する
• 広範なスコープを持つことが多い（メール、ドライブ、カレンダーへのアクセスなど）
• 初期認証以降は稀に監査される

ステージ 2: ワークスペースアカウント取得（T1550.001）

侵害された OAuth アプリケーションのアクセス権を利用し、攻撃者は Vercel の従業員の Google Workspace アカウントへとピボットしました。これにより、メールへのアクセス（さらなる認証情報の収集の可能性）、Google Drive 経由での内部ドキュメントへのアクセス、会議および関連リソースへのカレンダー情報の閲覧、そして他の OAuth 接続サービスの潜在的なアクセスが可能になります。

ステージ 3: 内部システムへのアクセス（T1078）

侵害された Workspace アカウントから、攻撃者は Vercel の内部システムへとピボットしました。ラウシュ氏はエスカレーションを「同僚の侵害された Vercel Google Workspace アカウントからの一連の manoeuvres」と説明しています。具体的な横方向移動技術（SSO フェデレーション、メール/ドライブから収集した認証情報の利用、または他の OAuth 接続内部ツールの使用など）は公開されていません。

ステージ 4: 環境変数の列挙（T1552.001）

攻撃者は、顧客プロジェクトの環境変数を列挙する十分な権限を持つ Vercel の内部システムにアクセスしました。ラウシュ氏の公的声明によると：Vercel はすべての顧客環境変数を完全に暗号化して保存していますが、プラットフォームは変数を「非機密（non-sensitive）」として指定する機能を提供しています。この非機密変数の列挙を通じて、攻撃者はさらにのアクセス権を得ました。

ステージ 5: 潜在的な下流への悪用（T1078.004）

暴露された環境変数は通常、下流サービスの認証情報を含みます。Andrey Zagoruiko 氏による一つの公的顧客報告（2026 年 4 月 19 日）では、同氏は 4 月 10 日に OpenAI の漏洩キー通知を受信したと述べています。この報告によれば、その API キーは Vercel にのみ存在していたため、少なくとも一つの暴露された認証情報が Vercel の公表以前に「野生で」検出されていた可能性を示唆しています。

この報告は、検出から公表までの異常（anomaly）を導入しており、後続のセクションでより詳しく検討されます。

公表タイムラインの異常点

Guillermo Rauch 氏の 2026 年 4 月 19 日の X 投稿に対する公的返信には、独立した注意を払うべきタイムラインの詳細が浮き彫りになりました。Vercel の顧客である Andrey Zagoruiko 氏は、2026 年 4 月 10 日に OpenAI から API キーの漏洩通知を受けたと報告しました。同氏の証言では、そのキーは Vercel 以外には存在しなかったとされています。

OpenAI の漏洩認証情報検出システムは、通常、API キーが出現すべきではない公有場所（GitHub, パスツ サイトなど）で見つかった際にトリガーされます。Vercel の環境変数から OpenAI への通知に至る経路は容易には説明できません。特に重要なのは、この日付が生み出した「暴露の最初の公的証拠」と Vercel の公表との間の 9 日間のギャップです。

図 3. 公表タイムラインの異常（認証情報暴露と公的通知の間に生じた 9 日のギャップを示す）

「9 日のギャップ」が意味するものと意味しないこと

この事実は、単一の公的報告でありフォレンジックな発見ではないことに注意する必要があります。これは Vercel が 4 月 10 日に侵害について知っていたことを証明するものとして解釈されるべきではありません。しかしながら、これは少なくとも一つの認証情報が顧客が正式に機密をローテーションするよう通知される前に「野生で」検出されていた証拠です。この区別は以下の 3 つの観衆にとって重要です：

• 規制当局: GDPR では、コントローラーが侵害発生の事実を知った時点で 72 時間のブリーフィング時計が始まります。Vercel がいつ事実を認知したかは現在公にされています。
• 監査人: SOC 2 および ISO 27001 の評価者は、継続的なモニタリング証拠の一部として検出から通知までの遅延を審査します。
• 顧客: 認証情報が暴露されている可能性のある組織は、4 月 19 日を暴露ウィンドウの終了とみなしてはいけません。それが能動的に悪用され始めたのはその前にである可能性があります。

インシデントレスポンス計画の観点から、このデータポイントは実用的なポイントを裏付けるものでもあります：OpenAI、Anthropic、GitHub、AWS、Stripe などからの不意打ちの漏洩認証情報通知は、現在、プラットフォーム侵害を早期に警告する主要なチャネルの一つとなっています。セキュリティチームはこれらを通常のノイズではなく、高優先度のシグナルとして扱うべきです。

AI に加速された戦術（CEO の評価）

2026 年 4 月 19 日の X 投稿で Vercel CEO の Guillermo Rauch は明確に声明しました：「攻撃団体が非常に洗練されており、私には強く信じているのですが、AI に著しく加速されていると考えられています。彼らは驚くべき速度と、Vercel に対する深い理解を持って行動しました。」

これは影響を受けたプラットフォームの CEO による記録に残る声明であり、慎重に評価する必要があります。「速度」に基づく帰属は本質的に解釈的ですが、いくつかの理由から注視する価値があります（以下のセクションで議論します）。

証拠において「AI に加速された」様子がどのように見られるか

ラウシュ氏の評価が事後的な合理化ではなく何か現実を反映している場合、背後にあるフォレンジックシグナルには少なくとも以下の一つが含まれている可能性があります：

1. 人手作業を上回る列挙速度: スクリプト化だけでこれらの一部は説明できますが、LLM 駆動の偵察はスキーマ発見、エンドポイントプローブ、認証情報形式の認識などを並列化して行い、手動クエリの構築よりも速く実行できます。
2. 文脈を考慮したクエリ構築: Vercel に特有の用語（プロジェクトスラグ、デプロイターゲット名、env var の命名規則など）に気づいているように見えるクエリでありながら、明らかな事前偵察なしで行われたもの。
3. エラーへの適応行動: API エラーやレート制限からの回復において、静的スクリプトよりも LLM を支援する攻撃者がより流暢に振る舞い、戦術を即座にシフトします。
4. プロンプト工学による社会的アーティファクト: ファイッシングルアー、コミットメッセージ、またはサポートチケットなどがローカルに本物のように読まれるのではなく、翻訳されたものやテンプレート化されたように見えるものではなく、むしろ「本物」のように読まれるものです。

Vercel 事象を超えてなぜこれが重要か

ラウシュ氏の評価が公式のフォレンジック審査を踏んで成立するかどうかは別として、そのカテゴリー自体である「AI で拡張された敵対者オペレーション」はもはや単なる推測ではありません。Microsoft が 2026 年 4 月に発表した「AI により支援されたデバイスコードファイッシング（Storm-2372 サークル活動の継承）」に関する出版物では、生成 AI を動的コード生成、ハイパーパーソナライズされたルアー、バックエンド自動化オーケストレーションのために生きている脅威アクターが利用していることが記録されています。その示唆は、人間のペースに較準されたテロメトリベースラインを持つ場合、AI に加速されたオペレーターに対して偽のネガティブ（false negative）を生成する可能性があることです。

検出工学への示唆: AI に加速された攻撃者が列挙と横方向移動のタイムラインを圧縮する場合、旧いインシデントデータに基づいて調整された驻在時間および速度閾値にチューニングされた検出ルールは低警报（under-alert）する可能性があります。特に、チームは以下の閾値を見直すことを検討すべきです：セッションあたりのユニークリソース列挙率、エラー対成功の比率回復曲線、短いウィンドウ内のクエリパターンの多様性など。

環境変数の設計上の問題

この侵害で最も重大な側面は、初期アクセスベクトルではなく、Vercel の環境変数の感度モデルです。OAuth 侵害は既知で研究されたリスクですが、顧客機密をデフォルトで不安全な構成を作成した点にありました。

図 4. 環境変数の設計上の問題：デフォルト不安全なシークレットマネージャモデルとセキュア・バイ・デフォルトのアプローチの比較

侵害時の Vercel 環境変数の動作

Vercel プロジェクトは、サーバーレス関数やビルドプロセスに設定および機密を注入するために環境変数を使用します。これらの変数は「機密（sensitive）」フラグを持ち、アクセス制限を制御します（表 2 を参照）。

表 2. 感度フラグに基づいた Vercel 環境変数の取扱い比較

重要な設計判断点：「機密」フラグはデフォルトでオフです。開発者が明示的にこのフラグをトグルしなかった DATABASE_URL、API_KEY、STRIPE_SECRET_KEY、または AWS_SECRET_ACCESS_KEY のようなすべての変数は、Vercel の内部アクセスモデルにおいて未暗号化で静かに保存されました。

個々の機密について明確なオプトインが必要であり、ガードレールやデフォルトがないセキュリティ制御は、実際の採用率が低いでしょう。

Vercel の対応

ラウシュ氏は、Vercel がすでにダッシュボードの変更をロールアウトしたと確認しました：環境変数の概要ページ、および機密変数の作成および管理のための改善された UI です。これらの変更は検索可能性（discoverability）を向上させますが、執筆時点ではデフォルトを変更していません。各変数について開発者がオプトインする必要があります。Vercel がデフォルトを変更するかどうかは未解決の問題であり、顧客が追及すべき事項です。

業界の他社との比較: 業界のトレンドは、感度ティアを持つ環境変数ストアではなく、Vault、AWS Secrets Manager、Doppler、Infisical などの専用シークレットストレージへ移行することです。この侵害はそのアーキテクチャ的選択を裏付けました。

表 3. Vercel の環境変数ベースのシークレット取扱いと、専用秘密管理システムを採用する業界他社プラットフォームの比較

認証情報のファンアウト：下流リスクの定量化

「認証情報のファンアウト」という用語は、単一のプラットフォーム侵害がそのプラットフォーム上で保存された認証情報で認証されるすべての下流サービスへの暴露へと拡大することを表します。

図 5. 認証情報のファンアウトと、一つのプラットフォーム侵害が多数の侵害に転じる様子の説明

この特定のケースについて、表 4 に Vercel プロジェクトの環境変数に含まれる典型的な内容及びその下流影響をサマリーしました。

表 4. Vercel プロジェクトで通常保存される環境変数と暴露された場合の潜在的な下流影響

単一の Vercel プロジェクトは通常、10〜30 つの環境変数を含みます。組織規模では、50 プロジェクトポートフォリオの場合、プラットフォーム内に 500〜1,500 の認証情報が存在することになります。各認証情報は、独自の爆発半径を持つ全く別のシステムへの潜在的なピボットポイントです。

これが、プラットフォーム侵害を機密事象からソフトウェアサプライチェーン全体への潜在的なカスケードへと引き上げる倍増因子（multiplier）です。

なぜ OAuth の信頼関係が境界防御を回避するか

この攻撃が約 22 ヶ月にわたって成功した根本的な理由は、OAuth ベースの侵入が従来の認証情報ベースの攻撃を検出またはブロックするものの大半を回避していたことです。左列にあるすべての防御制御は、セキュリティチームがアカウント侵害を検出またはブロックするために依存しています。しかし、それらの制御すべては、OAuth アプリの侵害経路では無関係か、すでに満たされています。この非対称性が、OAuth ガバナンスがアイデンティティとアクセス管理とは別に、独立したセキュリティ規律として台頭する理由です。

図 6. 従来の認証情報ベースの攻撃経路と OAuth アプリケーション侵害の比較：OAuth の信頼関係が境界セキュリティ制御を回避し、サイレントな横方向移動を可能にする様子を示す

OAuth ガバナンスをベンダーリスク機能として捉える

多くの組織は OAuth グラントを開発者のセルフサービス問題として扱っています：各従業員が必要とするツールの権限を与え、中央でのレビューは最小限です。今回のインシデントは、OAuth グラントをサードパーティのリスク管理として扱うべきであることを示唆しています。つまり、認証されたすべての OAuth アプリは効果的に企業のデータへの永続的なアクセスを持つベンダーであり、ベンダーレビューを受け、定期的に見直し、異常な使用を追跡する必要があります。

脅威アクターの主張と帰属

地下フォーラムでの脅威アクターの主張は本質的に信頼できません。以下は認識と脅威追跡のためのドキュメント化であり、確認された事実としてではありません。インシデントにおける帰属は notoriously difficult（困難）であり、フォーラムの主張はしばしば誇張され、偽造されており、または事件に関連する当事者によって行われます。

ShinyHunters 関連の主張

ShinyHunters グループとの関係を主張する脅威アクターが BreachForums で Vercel データの保有を主張しました。

表 5. 主張されるデータとその数量のサマリー（すべて未検証）

ShinyHunters 関連のアクターに帰属するこのインシデントを複雑にしている要素は以下の通りです：

• 既知の ShinyHunters メンバーが BleepingComputer に公開的に関与を否定しました。
• 200 万ドルのランサムデマンドは Telegram を介して伝えられたと主張されています（合法的および偽造された侵害主張の両方で一般的な収益化パターン）。
• ShinyHunters のブランドは、グループが最初に活動した以来、複数の潜在的に関連のないアクターによって使用されてきました。
• Vercel のセキュリティブリーフィングはこれらの主張を言及しておらず、ラウシュ氏の投稿は攻撃チェーンには触れいますが、フォーラム投稿については直接的に触れていません。

サプライチェーンリリースパス：Vercel の立場 ラウシュ氏は最も影響を与えるシナリオに対して直接言及し、「サプライチェーンを分析し、Next.js, Turbopack、および多くのオープンソースプロジェクトがコミュニティのために安全であることを確保しました」と述べています。執筆時点でリリースパスの完全性の独立した検証が続いています。Next.js, Turbopack、または他の Vercel オープンソースプロジェクトを使用する組織は、パッケージ完全性シグナル（チェックサム、署名、プロヴェナンスアテステーション）を標準的な慣行として監視し続けるべきです。フォーラム主張のデータに対する独立した検証がない場合、それらの主張は確認されていないものとして扱うべきです。Vercel が説明する OAuth ベースの攻撃チェーンは技術的に妥当であり、フォーラム投稿者が主張するアクセス範囲を必要としないため、主張は誇張されているか、別の無関係なインシデントを表すか、または偽造されている可能性があります。

MITRE ATT&CK マッピング

確認された攻撃チェーンは、確立された MITRE ATT&CK テクニックに清潔にマッピングされます（表 6 でサマリー）。このマッピングは Vercel の公開説明で明確に記述された行動を反映し、新しい悪用ではなくよく理解されている OAuth 虐待パターンと整合しています。

表 6. Vercel インシデントの MITRE ATT&CK テクニックマッピング

このマッピングに基づくと、OAuth アプリケーションアクセスから内部システムへのアクセスへの変換（T1199 から T1078）が最も価値のある検出ポイントです。したがって、組織は異常な OAuth アプリケーションの行動、特に予想されるスコープの外側のリソースへのアクセスや期待しない IP ランジからのアクセスに注意を払うべきです。

サプライチェーンの包囲：LiteLLM, Axios 及び収束したパターン

Vercel の侵害は孤立して起こりませんでした。2026 年 3 月から 4 月の期間は、ソフトウェアサプライチェーン攻撃の未曾有の集中を目撃しており、これは調整されたキャンペーン活動を示唆するか、あるいはより可能性が高く、複数の脅威アクターが同じ構造的弱点（パッケージレジストリ、CI/CD システム、OAuth プロバイダー、デプロイメントプラットフォーム間の境界）を収束して発見したことを示唆しています。

2026 年 3 月 24 日：LiteLLM PyPI サプライチェーン侵害

• 事象: 窃された CI/CD パブリッシング認証情報を使用して、悪意のある PyPI パッケージ「litellm」バージョン 1.82.7 および 1.82.8 が公開されました。攻撃は、約 340 万のダウンロード数を誇る広く使用されている LLM プロキシ LiteLLM を標的にしました。
• 初期アクセス: 攻撃者（"TeamPCP"として追跡）が Trivy (Aqua Security の脆弱性スキャナー) の CI/CD パイライン認証情報を侵害し、PyPI パブリッシング権限を持っていました。
• ペイロード: メインクラウドプロバイダーの 50 を超える認証情報タイプを対象とした三段階のバックスドア、Kubernetes DaemonSet を介した横方向移動への永続化。
• 驻在時間: 悪意のあるパッケージは検出と削除されるまで約 40 分〜3 ヶ月間稼働しました。
• CVE: CVE-2026-33634

2026 年 3 月 31 日：Axios npm サプライチェーン侵害

• 事象: npm パッケージ axios（週 7,000〜100 万ダウンロード）が維持者アカウントハイジャックを介して侵害されました。悪意のあるバージョン 1.14.1 および 0.30.4 は、クロスプラットフォーム RAT を含む plain-crypto-js@4.2.1 に依存性をインジェクトしました。
• 初期アクセス: 維持者アカウントがハイジャックされた（メカニズムは未公開；認証情報スタッフィングまたはファイッシングが疑われている）。
• 規模: 攻撃者コマンド・アンド・コントロール基盤に連絡したエンドポイントが 135 も検出されました。
• 驻在時間: 検出されるまで 2〜3 ヶ月間。
• 帰属: Microsoft はこの攻撃を、北朝鮮国家支援の脅威アクター Sapphire Sleet に帰属しました。

収束パターン: 3 つの週にわたる 3 つの攻撃。3 つ異なるベクトル。同じターゲット：開発者がツールチェーンに保存する認証情報と機密。

表 7. 開発者認証情報および機密保存層を標的にした最近のサプライチェーン隣接インシデントサマリー

以前のプラットフォーム侵害から何が明らかか

Vercel の侵害は、顧客機密をスケーリングで暴露するプラットフォームレベルの侵害のよく文書化されたパターンに続いています。

• Codecov Bash アップローダー侵害 (2021 年 1 月 – 4 月): 攻撃者は Codecov の Bash アップローダースクリプトを改変し、顧客の CI 環境からの環境変数を奪出しました。侵害は約 2 ヶ月間検出されませんでした。29,000 以上の顧客が潜在的に影響を受けました。
• CircleCI セキュリティインシデント (2023 年 1 月): マルウェアにより個人デバイス上の従業員 SSO セッショントークンが盗まれ、CircleCI の内部システムへのアクセスおよび顧客機密と暗号化キーの奪出に使用されました。CircleCI はプラットフォーム上に保存されたすべての機密をローテーションするようすべての顧客に推奨しました。
• Snowflake 顧客認証情報攻撃 (2024 年 5 月 – 6 月): UNC5537 という脅威アクターは、インフォスチーラーマルウェアから得た認証情報を使用して、MFA が設定されていない Snowflake 顧客アカウントへのアクセスを行いました。165 以上の組織に影響を受けました。
• Okta サポートシステム侵害 (2023 年 10 月): 盗まれた認証情報を使用して攻撃者は Okta のカスタマーサポートケース管理システムにアクセスし、Okta 顧客のセッショントークンを含む HAR ファイルを表示しました。

パターンスアマリー: パターンは明確です。CI/CD、アイデンティティ、データウェアハウス、デプロイメントプラットフォームを超えて繰り返し利用されてきたプラットフォームレベルの顧客機密へのアクセスは体系的なリスクです。各インシデントは同じ弧を辿ります：信頼関係または認証情報を通じた初期アクセス、内部システムへの横方向移動、スケーリングでの顧客機密の奪出。

表 8. 信頼ベースの初期アクセスと長期化された検出ラグに続く顧客機密の繰り返し暴露を иллюстраする最近のプラットフォームレベル侵害のパターン

未解明な事項

今回のインシデントを囲繞する公的報告、CEO 声明、第三者評論の量にもかかわらず、公記録には依然として重要なギャップが存在します。厳密な分析には、何が知られているかを見るだけでなく、公開されていないかまたは独立して検証されていないことを明示的に認めることが必要です。以下の未解決の問題は重要なギャップを形成しています：

• Context.ai がどのように侵害されたか: OAuth アプリケーション侵害の根本原因は公開されていません。ラウシュ氏の声明「Vercel は Context に支援するために連絡を取った」ことは、Context.ai 自身にさえも範囲が不明瞭である可能性があります。
• Vercel が初めて異常活動を検出した時期: Vercel の顧客が受けた 2026 年 4 月 10 日の OpenAI 通知はこの質問を鋭く提起します。Vercel は内部検出タイムラインを発表していません。
• 暴露と公表の間の 9 日ギャップの理由: 複数の説明が可能です；公記録はどれが適用されるかを解決していません。
• 影響を受けた顧客の数: ラウシュ氏は影響を「非常に限定されたもの」と記述しましたが、具体的な数は公開されていません。
• ShinyHunters フォーラム主張が同じ攻撃者を表しているか: 主張が確認された攻撃チェーンと一致するか、別のインシデントかは未検証です。
• Context.ai の現在の状況および下流顧客への通知: Context.ai が独自のインシデント報告を発表し、他の顧客に通知したかどうかは不明です。
• 内部アクセスの完全な範囲: 環境変数だけでなく、22 ヶ月の驻在時間中に攻撃者がアクセスした Vercel の他の内部システムまたはデータ。

検出およびハンティングガイダンス

このセクションは、インシデントの影響を受ける可能性のある組織向けの実践的な検出およびハンティングガイダンスを提供します。

Vercel 顧客向け（即時）

1. すべての環境変数を監査する: 以下のコードを Vercel プロジェクトに入力して構成を検証してください：

# CLI を介してすべての Vercel プロジェクトの env vars をリストする
vercel env ls --environment production
vercel env ls --environment preview
vercel env ls --environment development

# 機密としてマークされていない変数をチェックする
# (Vercel CLI は現在 sensitive フラグを公開していないため、ダッシュボードまたは API で確認してください)

2. 暴露された認証情報の不正使用を検索する:

• クラウドプロバイダー CloudTrail/オーディットログのクエリ: イベントソースに

  sts.amazonaws.com

  ,

  iam.amazonaws.com

  ,

  s3.amazonaws.com

  を含むものをフィルタリングします。ローテーションした Vercel 保存アクセスキーと一致する

  userIdentity.accessKeyId

  を検索します。既知の CIDR レンジ外のいずれかの

  sourceIPAddress

  や、

  python-requests

  ,

  curl

  ,

  Go-http-client

  , または不明な自動化文字列を含む

  userAgent

  はフラグしてください。タイムウィンドウ: 2024 年 6 月 – 現在。
• GCP オーディットログ: Vercel に保存されたキーを持つサービスアカウントの

  protoPayload.authenticationInfo.principalEmail

  をクエリします。既知のレンジに対して

  protoPayload.requestMetadata.callerIp

  をフィルタリングします。期待しないソースから来た

  protoPayload.methodName

  が

  storage.objects.get

  ,

  compute.instances.list

  , および

  iam.serviceAccountKeys.create

  を含むかを確認してください。
• Azure アクティビティログ: Vercel env vars に認証情報が含まれていたアプリケーション ID またはサービスプリンシパルと一致する呼び出しをフィルタリングします。期待しないレンジの

  callerIpAddress

  をフラグしてください。優先度クエリ:

  Microsoft.Storage/storageAccounts/listKeys

  ,

  Microsoft.Compute/virtualMachines/write

  ,

  Microsoft.Authorization/roleAssignments/write

  。
• データベースアクセスログ: Vercel 環境変数として保存された接続文字列を持つすべてのデータベースについて、完全な暴露ウィンドウ（2024 年 6 月 – 2026 年 4 月）の接続ログをクエリします。アプリケーションの既知のエグレスレンジ（Vercel エッジ IP、VPN、オフィス）、および期待しない VPC/IP から始まる接続を検索してください。
• 決済処理機: Stripe の場合、Dashboard → Developers → Logs で暴露されたキーを使用した API 呼び出しを確認します。サーバー外の

  source_ip

  をフィルタリングします。認識できない

  /v1/charges

  ,

  /v1/transfers

  ,

  /v1/payouts

  , および

  /v1/customers

  の呼び出しを検索してください。
• 不意打ちの漏洩認証情報通知をチェックする: 暴露ウィンドウ中、OpenAI, Anthropic, GitHub, AWS, Stripe、および類似のプロバイダーからの通知を監視します。これらは主要な早期警告チャネルです。

3. ローテーションと再デプロイを行う: 重要な運用上の詳細：Vercel 環境変数をローテーションしても、古いデプロイメントは遡って無効化されません。Vercel のドキュメントによると、前のデプロイメントは再デプロイされるまで古い認証情報値を使用し続けます。ローテーション後の再デプロイを行わずに古い認証情報が以前の実装アーティファクト内で引き続き存続します。各認証情報のローテーションには、その変数を使用したすべての環境の再デプロイが追跡されなければなりませんか、または古いデプロイメントを明示的に無効化しなければなりません。

ローテーションの優先順位:

1. クラウドプロバイダー認証情報 (AWS, GCP, Azure)
2. データベース接続文字列
3. 決済処理機キー
4. 認証シークレット (JWT シークレット、セッションキー)
5. サードパーティ API キー
6. モニタリングおよびロギングトークン

セキュリティチーム向け（能動的）

OAuth アプリケーション監査 — Google Workspace:

• Admin Console → Security → API Controls → Third-party app access. すべての認証された OAuth アプリケーションをレビューします。広範なスコープ（Drive, Gmail, Calendar）を持つアプリケーションをフラグしてください。アクティブなビジネス関係のないベンダーからのアプリケーションは調査してください。期待しない IP ランジからの OAuth トークン使用を監視してください。
• 既知の悪質 OAuth Client ID を検索:

  110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

SIEM 実装向けの検出ロジック

以下の検出パターンは、確認された攻撃チェーンのステージにマッピングされます。組織はこれらを生体 SIEM プラットフォーム（Sigma, Splunk SPL, KQL, Chronicle YARA-L）固有のルールに変換する必要があります。

1. OAuth アプリケーション異常値 (ステージ 1–2) Google Workspace トークンと Admin オーディットログを以下の 3 つのパターンで監視してください：

• 既知の悪質 OAuth Client ID と関連するトークンのリフレッシュまたは認証イベントは、即時アラートをトリガーすべきです。
• 広範なスコープを与える OAuth アプリケーション認証イベントは、アクティブなベンダーインベントリに対してレビュー対象となります；アクティブなビジネス使用から除外されたアプリケーションは撤回する必要があります。
• 期待しない企業およびベンダー CIDR ランジ外のソース IP から来るいずれかの認証された OAuth アプリケーションでのトークン使用はフラグすべきです。

2. 内部システムアクセスと横方向移動 (ステージ 3, T1078) 攻撃者が侵害された Google Workspace アカウントを制御すると、そのアイデンティティを信頼する内部システムへピボットします。検出は以下の 4 つの指標に焦点を当てるべきです：

• 異常な SSO/SAML 認証イベント: 侵害されたワークスペースアカウントが不明朗な IP アドレス、地理的位置、またはデバイスフィンガープリントから内部アプリケーションへの認証を確認するためのアイデンティティプロバイダーログを監視します。特に、そのアカウントが以前に接触したことがないシステムへの初めてのアクセスに注意してください。
• メールおよびドライブ認証情報収集: Google Workspace オーディットログをバッチメール検索クエリ（"API key", "secret", "token"などのキーワード）、異常な Google Drive ファイルアクセスパターン、および侵害されたアカウントでのメール転送ルール作成のレビューを行います。
• OAuth 接続内部ツールの利用: セッション作成または API アクティビティが発生したダウンストリームサービス（Slack, Jira, GitHub, 内部ダッシュボード）を監視し、侵害されたユーザーが通常の業務時間外に発生することをチェックします。
• 権限昇降の試み: 侵害されたアイデンティティが上位許可をリクエストし、新しいグループに参加するか、admin コンソールへのアクセスを試みるかを監視します。Google Workspace の場合、Directory API の呼び出し、代表変更、または他のユーザーの OAuth トークンを列挙する試みを監視します。

3. 環境変数の列挙 (ステージ 4) Vercel チームオーディットログで異常な環境変数アクセスパターンを監視します。ベースラインボリューム、タイミング、またはソースアイデンティティから逸脱するアクセスパターンについてアラートを発火します。サービスアカウントではなくユーザーアカウントから来るいずれかの環境変数アクセスに特に注意を払ってください。

4. 下流認証情報の悪用 (ステージ 5) 暴露ウィンドウ中に非機密 Vercel 環境変数として保存された認証情報のすべてについて、対応するサービスのアクセスログを期待しないソースからの使用でクエリします。自社のインフラストラクチャに帰属できないどの認証情報も、侵害されたとみなし、即時ローテーションし、調査してください。

5. サードパーティ認証情報漏洩通知 GitHub, AWS, OpenAI, Anthropic, Stripe, Google Cloud などの自動機密スキャンを運営するプロバイダーからの不意打ちの漏洩認証情報通知の監視を設定します。これらは主要な早期警告シグナルです。

脅威ハンティング

Google Workspace Admin Console — マニュアル検索手順:

1. Admin Console → Reports → Audit and Investigation → OAuth Log Events
   • フィルタ: アプリケーション名 = "Context.ai" OR Client ID =

     110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

   • 日付範囲: 2024 年 1 月 – 現在
   • 全結果をエクスポート。ヒットがある場合 = 即時撤回およびインシデント調査。
2. Google Workspace — 広範なスコープを持つすべてのサードパーティ OAuth アプリ:
   • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
   • ソート: "App access" → "Unrestricted"
   • アプリごとに：(a) アクティブなベンダー関係が存在するか、(b) スコープがビジネス使用によって正当化されるか、(c) 最終使用日付が最近かを検証。90+ 日間使用されていないアプリは撤回してください。

防御上の勧告

即時的アクション (0–48 時間)

• **すべての Vercel 環境変数をローテーションする：**機密としてマークされていないものを含め、アクセスされたかどうかに関係なくローテーションしてください。
• **ローテーション後にすべての環境を再デプロイする：**ローテーション自体は古いデプロイメントを無効化しません。
• **すべての認証情報を格納する環境変数に sensitive フラグを有効にする：**トークン、キー、または機密のいずれかを含むすべての環境変数で。各プロジェクトを検証してください。
• **Google Workspace（または Microsoft Entra）管理コンソールでの OAuth アプリケーション権限を監査する：**アクティブに使用されていないアプリケーションへのアクセスを撤回してください。
• **Vercel 環境変数として保存された認証情報を有するすべてのサービスのアクセスログをレビューする：**2024 年 6 月〜現在までの期間をカバーします。

中期的強化 (1–4 ヶ月)

• **シークレットを専用シークレットマネージャへ移行する：**HashiCorp Vault, AWS Secrets Manager, Doppler, Infisical など。プラットフォーム環境変数として保存するのではなく、ランタイムでシークレットを注釈付けるようにしてください。
• **CI/CD およびデプロイメントパイプラインにおいて可能であれば OIDC ベースの認証を実装する：**長期にわたる認証情報を完全に排除します。
• OAuth アプリケーション監視をデプロイする：（商用ソリューションまたは Google Workspace の組み込み管理を使用）。
• **認証情報ローテーション自動化を確立する：**インシデントステータスに関係なく、定義されたスケジュール（30–90 日）でシークレットをローテーションする必要があります。
• **OAuth グラントをベンダー関係として扱う：**契約済みベンダーと一緒にあなたのサードパーティリスクインベントリに追加してください。

アーキテクチャの変更 (1–6 ヶ月)

• **環境変数に対するゼロトラスト姿勢を採用する：**デプロイメントプラットフォーム内に格納されるいかなるシークレットも、プラットフォームレベルの侵害において暴露される可能性があることを前提にしてください。単一の認証情報の暴露がカスケードしないようにシステムを設計してください。
• すべての認証情報への最小権限スコープを実装する: データベース認証情報は最小限の権限を持つべきで、API キーは特定の操作のスコープを持つべきで、クラウド認証情報はロールベースの一時的な認証情報を長く存続するアクセスキーに代わるものを使用すべきです。
• **企業アイデンティティシステムへのアクセスを有する OAuth アプリケーションまたはインテグレーションのためのサードパーティベンダーセキュリティレビューを確立する：**既存の権限の定期的な見直しを含めてください。
• PaaS プラットフォームを SBOM/ASPM インベントリに含める: この侵害は、デプロイメントプラットフォームを外側サービスではなく、階層 1 のサプライチェーン依存関係として扱うべきであることを示唆しています。

推奨されるモニタリング

• 上記の OAuth Client ID について Google Workspace Admin Console を監査します。
• 予期しない

  env.read

  または

  env.list

  API コールについて Vercel オーディットログを監視します。
• 2024 年 6 月〜2026 年 4 月の期間中、Vercel env vars として保存された認証情報の使用に関する CloudTrail, GCP オーディットログ、および Azure アクティビティログをチェックします。IP アドレスまたはユーザーエージェントが期待しないものである場合。
• そのパッケージを依存関係ツリーに含んでいる場合、これらのパケットに関連する LiteLLM または Axios の関連 IOCs について respective advisories が公開しているものを監視します。
• 暴露ウィンドウ中に主要な API プロバイダーからの不意打ちの漏洩認証情報通知について監視します。

規制およびコンプライアンスの影響

Vercel 侵害を介して認証情報が暴露された組織は、以下の通知義務を検討すべきです：

• GDPR (EU): 暴露された認証情報が EU 個人データを含むシステムへのアクセスを提供した場合は、暴露の確認時点で 72 時間のブリーフィング時計が開始されることがあります。4 月 10 日の OpenAI 通知は、一部の組織の認識が Vercel の 4 月 19 日の公表より前にあるかどうかという疑問を提起しています。
• CCPA/CPRA (California): 消費者データへのアクセスを提供する認証情報の暴露は、通知要件をトリガーする可能性があります。
• PCI DSS: 決済処理機認証情報（Stripe, Braintree, Adyen）が暴露された場合、PCI インシデントレスポンス手順およびフォレンジック調査要件が適用される可能性があります。
• SOC 2: SOC 2 の義務を持つ組織は、インシデント、実施した認証情報ローテーションアクション、および更新された制御を継続的モニタリング証拠として文書化すべきです。
• SEC サイバーセキュリティ規則 (8-K): ブリーチが重大であると判断する公開会社には、4 ビジネス日以内の公表義務があります。

課題は、多くの組織が暴露された認証情報が実際に不正アクセスのために使用されたかどうかをまだ知らない可能性があることです—しかし規制フレームワークは通常、確認された悪用ではなく暴露に対してトリガーされます。

結論

Vercel の侵害は孤立したインシデントではありません—それはソフトウェア業界が機密と信頼関係を管理する方法における構造的な脆弱性の最新の現れです。3 ヶ週の間に私たちは以下を見てきました：

• LiteLLM: CI/CD 認証情報が盗取られた → マルicious パッケージがスケーリングでの開発者シークレットを収穫しました。
• Axios: メインテナーアカウントがハイジャックされた → ラットが数百万の開発者環境に展開されました。
• Vercel: OAuth アプリケーション侵害 → 顧客デプロイメント機密へのプラットフォームレベルアクセス、少なくとも一つの公的報告は暴露される以前に下流認証情報の悪用が「野生で」検出されたことを示唆しています。

各攻撃はソフトウェアサプライチェーンの異なるリンクを標的にします。それらはすべて一緒に、認証情報は万能なターゲットであり、信頼関係は万能な攻撃表面であるエコシステムを描きます。業界が警告してきたカスケードはもはや純粋に理論的ではありません。

防御への道のりは明確ですが簡単ではありません：

1. プラットフォーム環境変数内に長期にわたる認証情報を保存することをやめましょう。専用シークレットマネージャとランタイム注釈を使用してください。
2. OAuth アプリケーションを暗黙的に信頼することをやめましょう。監査、監視、および定期的な再権限化を行ってください。
3. プラットフォームプロバイダーの内部セキュリティ姿勢を前提假设することをやめましょう。侵害されるシナリオを設計してください。
4. 認証情報を能動的にローテーションし始める—そしてローテーション後に再デプロイすることを忘れないでください。
5. サードパーティプロバイダーからの漏洩認証情報通知を高優先度の早期警告シグナルとして扱い、通常のノイズと見なさないようにしてください。

次のプラットフォーム侵害を耐えることができる組織は、それが起こると仮定し、そのように認証情報アーキテクチャを構築した組織です。

侵害の指標 (IoCs)

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com