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

 (trendmicro.com)
2 ポイント 投稿者 GN⁺ 9 일 전 | 1件のコメント | WhatsAppで共有
  • OAuthサプライチェーン侵害がVercel内部システムへのアクセスにつながり、限定された一部顧客プロジェクトで環境変数の露出が発生
  • 発端はContext.ai従業員のLumma Stealer感染で、流出したGoogle Workspace OAuthトークンがVercel従業員アカウントおよび内部システムへのアクセスに使われた
  • 攻撃者は顧客プロジェクトの環境変数を列挙できる権限を得て、とりわけnon-sensitiveと表示された変数を通じて下流サービスの認証情報露出の可能性が拡大
  • 公開された状況から、少なくとも1件ではVercelの公表前に流出したAPIキーの検知があり、検知と通知のあいだの時間差が主要なリスク要因として浮上
  • 今回の侵害は、OAuthの信頼関係とプラットフォームの環境変数保存方式が組み合わさることで、サプライチェーン全体での認証情報拡散につながり得ることを示した事例

主要な含意

  • OAuthの増幅効果を確認
    • 1つのOAuth信頼関係の侵害がベンダーからVercel内部システムまで連鎖的に拡大
    • 侵害されたベンダーと直接関係のない顧客プロジェクトの環境変数まで限定的に露出
  • AI加速型の攻撃行為の可能性が提起
    • CEOが攻撃者の異例の速度をAIによる補強と結び付けて公に発言
    • ただしこの評価は公式なフォレンジック結論ではなく、公の発言レベルにとどまる
  • 検知から公表までの遅延が浮き彫りに
    • 少なくとも1件の公開された顧客報告では、Vercel公表の9日前に流出キー検知の状況が存在
    • プラットフォーム侵害では、検知後の通知遅延が重要なリスク要因として指摘される
  • 2026年のより広いパターンとの接続
    • LiteLLM、Axios、Codecov、CircleCIと並び、開発者が保管する認証情報を狙うサプライチェーンの流れと重なる

インシデントのタイムライン

  • 2026年2月ごろ、Context.ai従業員がLumma Stealerに感染し、企業の認証情報、セッショントークン、OAuthトークンが流出
  • 2026年3月ごろ、攻撃者がContext.aiのAWS環境にアクセスし、一般ユーザー向けOAuthトークンを窃取
    • ここにはVercel従業員のGoogle Workspaceトークンが含まれていた
  • 2026年3月、窃取されたOAuthトークンによりVercel従業員のGoogle Workspaceアカウントへのアクセスが発生
  • 2026年3月から4月にかけて、Vercel内部システムへ移動した後、顧客環境変数の列挙を開始
  • 2026年4月ごろ、ShinyHunters関連の攻撃者がVercelデータの販売を始めたとの主張が提起
  • 2026年4月10日、あるVercel顧客がOpenAIから流出APIキー通知を受け取った事実に言及
  • 2026年4月19日、Vercelがセキュリティ告知を掲載し、Xスレッドを公開
  • 2026年4月19日以降、顧客通知、認証情報ローテーション案内、ダッシュボード変更の展開が進行
  • 比較的短い約2か月の滞在期間にもかかわらず、第三者ベンダー感染から顧客環境変数流出まで至る速度が確認された
  • Google WorkspaceのOAuth監査ログの既定保持期間は多くの料金プランで6か月
    • 今回の約2か月の滞在期間は保持ウィンドウ内に残っている可能性
    • より長期の類似侵害では既定保持期間を超え得る点も指摘

攻撃チェーン

  • 第1段階: 第三者OAuth侵害

    • Context.aiはVercel従業員が承認したGoogle Workspace OAuthアプリケーションを保有
    • このアプリケーションの侵害は、2026年2月ごろのContext.ai従業員のLumma Stealer感染にさかのぼる
    • Hudson RockとCyberScoopの報道によれば、この従業員はRobloxゲームのエクスプロイトスクリプトをダウンロードした後に感染したと報じられた
    • 窃取された認証情報により、攻撃者はContext.aiのAWS環境へアクセスし、2025年6月に公開されたContext AI Office Suiteの一般ユーザー向けOAuthトークンを流出させた
    • Context.aiは2026年3月、AWS環境への不正アクセスを検知して遮断したと告知
    • ただし、OAuthトークン流出自体はVercelの調査まで特定されなかったと明記
    • 承認済みOAuthアプリケーションは次の特性を持つ
      • ユーザーパスワードが不要
      • パスワード変更後も持続し得る
      • メール、ドライブ、カレンダーなど広い権限範囲を持つことが多い
      • 初回承認後は監査対象になることがまれ

  • 第2段階: Workspaceアカウント乗っ取り

    • 侵害されたOAuthアプリケーションへのアクセスから、Vercel従業員のGoogle Workspaceアカウントへ移行
    • これにより、メールアクセス、Google Drive上の内部文書へのアクセス、カレンダーおよび接続リソースの可視性、他のOAuth接続サービスへのアクセス可能性を確保

  • 第3段階: 内部システムアクセス

    • 侵害されたWorkspaceアカウントからVercel内部システムへさらに移動
    • Rauchは、同僚の侵害されたVercel Google Workspaceアカウントから始まった一連の操作でエスカレーションが進んだと述べた
    • 具体的な横展開の手法は非公開
      • SSO連携
      • メールまたはDriveで収集された認証情報
      • 他のOAuth接続内部ツール
      • 上記のどれだったのかは公開されていない

  • 第4段階: 環境変数の列挙

    • 攻撃者は、顧客プロジェクトの環境変数を列挙できる程度の権限でVercel内部システムへアクセス
    • Vercelは顧客環境変数の保存時に「non-sensitive」を指定する機能を提供
    • 公開発言ベースでは、顧客環境変数はすべて同じ方式で保護されておらず、機密表示のない変数の列挙を通じて追加アクセスが得られた

  • 第5段階: 下流サービス悪用の可能性

    • 露出した環境変数には通常、下流サービスの認証情報が含まれる
    • Andrey Zagoruikoの2026年4月19日の公開報告によれば、4月10日にOpenAIの流出キー警告を受信
    • そのキーは、報告者の主張ではVercel以外には存在しなかった
    • この状況は、少なくとも1つの露出認証情報がVercel公表前に外部で検知された可能性を示唆

公表時点までの9日間の空白

  • Guillermo Rauchの4月19日のXスレッド返信で、顧客Andrey Zagoruikoが2026年4月10日にOpenAIの流出キー通知を受け取った事実を公表
  • OpenAIの流出認証情報検知は通常、GitHubやpasteサイトなど公開された場所で発見された場合に作動する
  • Vercel環境変数からOpenAI通知に至る経路は、記事では単純ではないと評価
  • 日付上では、最も早い公開露出の証拠とVercel公表のあいだに9日間のウィンドウが存在

  • この9日間の空白が意味することと、意味しないこと

    • 単一の公開報告であり、フォレンジックで確定した結果ではない
    • Vercelが4月10日にすでに侵害を認識していた証拠と解釈してはならない
    • 一方で、少なくとも1つの認証情報が、顧客への秘密情報更新通知より前に外部で検知されていた状況としての意味はある

  • ステークホルダー別の示唆

    • 規制当局
      • GDPRでは、管理者が侵害を認識した時点から72時間の通知時計が始まる
      • Vercelがいつ認識したかが公開上の争点として浮上
    • 監査人
      • SOC 2とISO 27001の評価者は、検知-通知遅延を継続的モニタリングの証拠として検討し得る
    • 顧客
      • 露出ウィンドウが4月19日に始まったとは想定できない
      • それ以前から積極的に悪用されていた可能性があると記事は示している
    • プロバイダー発の流出認証情報通知は、早期警戒チャネルとして重要性が高まる
    • OpenAI、Anthropic、GitHub、AWS、Stripeなどが例として含まれる

AI加速型の攻撃行為

  • Guillermo Rauchは2026年4月19日、Xで攻撃グループが高度に巧妙であり、AIによって大幅に加速されていたと強く疑っていると発言
  • 記事ではこの発言を、影響を受けたプラットフォームCEOの公開記録上の評価として扱い、慎重な検討の必要性に言及

  • フォレンジック証拠で期待される兆候

    • 手作業の速度を超える列挙速度
      • スクリプト化だけでも一部は説明可能
      • LLMベースの偵察は、スキーマ探索、エンドポイント探索、認証情報形式の認識を並列化できる
    • 文脈認識型のクエリ構成
      • 明白な事前偵察がなくても、Vercel固有の用語、プロジェクトslug、デプロイ先名、env varの命名規則を知っているかのようなクエリ
    • エラー対応への適応性
      • APIエラーやrate limitの後に戦略を変更する柔軟性が、静的スクリプトより高い
    • ローカライズされたようなソーシャルエンジニアリング生成物
      • フィッシング誘導文、コミットメッセージ、サポートチケットが、翻訳文やテンプレートよりもローカル文脈に近い品質

  • Vercel事案を超えた重要性

    • この評価が正式なフォレンジックで維持されるかどうかに関わらず、AI補強型の攻撃運用というカテゴリーは、もはや純粋な推測だけではない
    • Microsoftは2026年4月の発表で、AIベースのdevice-code phishing、動的コード生成、超個別化されたおとり、バックエンド自動化オーケストレーションの事例を文書化
    • 人間の速度基準に合わせたテレメトリのベースラインは、AI加速型のオペレーターに対してfalse negativeを生み得るとの指摘

  • 検知エンジニアリング上の含意

    • 列挙と横移動の圧縮が起きると、従来の滞在時間や速度しきい値ベースのルールでは過少警報になる可能性
    • 次の項目の再検討が必要と提起
      • セッションごとのユニーク資源列挙速度
      • エラーに対する成功回復曲線
      • 短時間内のクエリパターンの多様性

環境変数設計上の中核的脆弱性

  • 記事で最も重大な側面は、初期アクセスベクトルそのものよりVercelの環境変数センシティビティモデル

  • 当時のVercel環境変数の動作方式

    • プロジェクトはサーバーレス関数とビルド過程に環境変数を注入
    • 変数ごとにsensitiveフラグが存在
    • デフォルト値はnon-sensitive
    • sensitiveは明示的な有効化が必要
    • non-sensitive変数はダッシュボードに表示
    • sensitive変数は作成後にマスキング
    • 内部API経由のアクセスはnon-sensitiveでは可能で、sensitiveは制限
    • 暗号化保存は公開発言ベースではnon-sensitiveには適用されず、sensitiveには追加制限とともに適用
    • 今回の侵害で攻撃者がアクセス可能だった対象はnon-sensitiveとして表示されていた

  • 決定的な設計選択

    • sensitiveフラグがデフォルトで無効
    • 開発者が明示的に有効化していないすべてのDATABASE_URL、API_KEY、STRIPE_SECRET_KEY、AWS_SECRET_ACCESS_KEYは、Vercel内部のアクセスモデルでは暗号化されていない形で保存
    • 個々の秘密ごとに明示的なopt-inを要求し、デフォルト保護やガードレールのないセキュリティ制御は、実際の導入率が低いと評価

  • Vercelの対応

    • 環境変数の概要ページと機密変数の作成・管理UIの改善がデプロイされたことを確認
    • 可視性の面で改善はあったが、執筆時点ではデフォルト変更ではない
    • 依然として変数ごとのopt-inが必要
    • デフォルト切り替えの有無は公開された問いとして残っている

  • 業界比較

    • 業界はVault、AWS Secrets Manager、Doppler、Infisicalのような専用シークレットストアへ移行
    • Vercelの環境変数ベースのアプローチと比べ、専用シークレット管理アーキテクチャの選択を今回の事案が裏づけたと評価
    • 比較表によれば
      • Vercelはnon-sensitiveがデフォルトで、自動検出なし
      • AWS SSM Parameter StoreはSecureStringをサポート
      • HashiCorp Vaultはすべてのシークレットの暗号化とACLを提供
      • GitHub Actionsはすべてのシークレットをログでマスキング
      • Netlifyはsecretトグル付きの環境変数方式

認証情報ファンアウトと下流リスク

  • Credential fan-outとは、1つのプラットフォーム侵害が、そのプラットフォームに保存された認証情報で認証されるすべての下流サービスへ連鎖的に露出が広がる現象
  • Vercelプロジェクトの環境変数にしばしば含まれ得る項目と下流への影響の整理
    • データベース
      • DATABASE_URL, POSTGRES_PASSWORD
      • 全データへのアクセス可能性
    • クラウド
      • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
      • クラウドアカウント侵害の可能性
    • 決済
      • STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
      • 財務データ、返金詐欺リスク
    • 認証
      • AUTH0_SECRET, NEXTAUTH_SECRET
      • セッション偽造、アカウント乗っ取りの可能性
    • メール送信
      • SENDGRID_API_KEY, POSTMARK_TOKEN
      • 信頼ドメインを悪用したフィッシングの可能性
    • モニタリング
      • DATADOG_API_KEY, SENTRY_DSN
      • テレメトリ改ざんの可能性
    • ソースとパッケージ
      • GITHUB_TOKEN, NPM_TOKEN
      • サプライチェーン注入の可能性
    • AI/ML
      • OPENAI_API_KEY, ANTHROPIC_API_KEY
      • API悪用、コスト発生の可能性
  • 単一のVercelプロジェクトには通常10〜30個の環境変数が含まれる
  • 組織規模では、50プロジェクトのポートフォリオで500〜1,500件の認証情報がプラットフォーム上に存在し得る
  • 今回の事案では一部の限られた顧客プロジェクトにのみアクセスされたとされるが、露出した認証情報1件ごとに別システムへ移動する起点になり得る
  • 記事ではこの点を、プラットフォーム侵害を単なる機密性インシデントではなく、ソフトウェアサプライチェーン全体へ拡散する乗数効果として規定

OAuth信頼関係と境界防御の回避

  • OAuthベースの侵入は、従来の認証情報ベース攻撃を検知・遮断する多くの統制をすり抜ける
  • 記事には約22カ月という文言があるが、冒頭の訂正では滞在期間が約2カ月に修正されている
  • セキュリティチームが左列で依存する防御統制は、OAuthアプリ侵害経路では無意味になるか、すでに満たされた項目になると記述
  • この非対称性により、OAuthガバナンスがIAMとは別個のセキュリティ領域として浮上

  • OAuthガバナンスはベンダーリスク機能

    • 多くの組織はOAuth承認を開発者のセルフサービス問題として扱う
    • 従業員ごとの必要ツール承認と最小限の中央レビューにとどまる
    • 今回の事案は、承認済みOAuthアプリを持続的アクセス権を持つサードパーティベンダーとして扱うべき根拠として提示
    • ベンダーレビュー、定期的な再承認、異常利用のモニタリングが必要

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

  • 地下フォーラム上の脅威アクターの主張は、本質的に信頼しにくいという前提
  • ここでの情報は確認済み事実ではなく、認識および追跡目的で整理したもの

  • ShinyHunters関連の主張

    • BreachForumsの投稿者はShinyHuntersとの関連を主張し、Vercelのデータを保有していると主張
    • 主張されたデータ項目
      • 従業員記録約580件
      • ソースコードリポジトリ
      • APIキーと内部トークン
      • GitHubおよびNPMトークン
      • 内部コミュニケーション
      • Linear workspaceへのアクセス
    • 上記の数量と範囲はすべて未検証

  • 帰属を難しくする要因

    • 既知のShinyHuntersメンバーはBleepingComputerに関与を否定
    • Telegramを通じて200万ドルの身代金要求があったとの主張がある
    • ShinyHuntersというブランドは、元のキャンペーン以降、多数または無関係のアクターによって使われてきた
    • Vercelのセキュリティ告知には当該フォーラムの主張への言及がない
    • Rauchのスレッドは攻撃チェーンを扱っているが、フォーラム投稿には直接触れていない

  • サプライチェーンのリリース経路に関するVercelの見解

    • RauchはNext.js、Turbopack、複数のオープンソースプロジェクトのサプライチェーンを分析し、コミュニティに対して安全だと述べた
    • 執筆時点で独立検証は進行中
    • Next.js、Turbopack、その他のVercelオープンソースを利用する組織は、チェックサム、署名、provenance attestationなどのパッケージ完全性シグナルを継続的に確認すべきだと勧告
    • フォーラムで主張されたデータについて独立した検証がない以上、未確認情報として扱う必要がある
    • Vercelが明らかにしたOAuthベースの攻撃チェーンだけでも事案は技術的に成立しており、フォーラム投稿者が主張した広範なアクセス範囲までは必須条件ではないとの評価

MITRE ATT&CKマッピング

  • 確認された攻撃チェーンは既存のMITRE ATT&CK手法に自然にマッピングできる
  • マッピング項目
    • Initial Access / Trusted Relationship / T1199
      • Context.aiのOAuthアプリを信頼された第三者として活用
    • Persistence / Application Access Token / T1550.001
      • OAuthトークンはパスワード変更後も持続
    • Credential Access / Valid Accounts / T1078
      • 侵害された従業員Workspaceの認証情報
    • Discovery / Account Discovery / T1087
      • 内部システムおよびプロジェクトの列挙
    • Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
      • non-sensitive環境変数へのアクセスが可能
    • Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
      • 露出したクラウド認証情報を利用できる可能性
    • Collection / Data from Information Repositories / T1213
      • プロジェクト全体にわたる環境変数の列挙
  • このマッピングで最も価値の高い検知ポイントは、OAuthアプリケーションのアクセスから内部システムアクセスへ移行する区間
  • 組織は、想定範囲を外れる、または予期しないIPレンジからリソースにアクセスするOAuthアプリの異常な振る舞いを監視する必要がある

サプライチェーン包囲戦: LiteLLM、Axios、Vercel

  • Vercelの事案は単独事件ではなく、2026年3月〜4月に集中したサプライチェーン攻撃の流れの中に位置づけられる
  • 記事では、これを協調キャンペーンの可能性もある一方、より可能性の高い解釈として、複数の攻撃者が同じ構造的弱点、すなわちパッケージリポジトリ、CI/CD、OAuthプロバイダー、デプロイプラットフォーム間の信頼境界を同時に発見した結果かもしれないと指摘している

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

    • 悪意あるPyPIパッケージlitellm 1.82.7、1.82.8が公開
    • Aqua Securityの脆弱性スキャナーTrivyから窃取したCI/CDデプロイ認証情報を使用
    • LiteLLMは1日あたり約340万ダウンロード規模のLLMプロキシ
    • 3段階バックドアが主要クラウドプロバイダー全体で50種類以上の認証情報タイプを標的
    • Kubernetes DaemonSetによる永続化を含む
    • 検知および削除までの滞留時間は約40分〜3時間
    • 関連CVEはCVE-2026-33634

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

    • npmパッケージaxiosは週あたり7000万〜1億ダウンロード規模
    • メンテナーアカウントの侵害により、悪性バージョン1.14.1、0.30.4が配布
    • plain-crypto-js@4.2.1依存関係の注入、クロスプラットフォームRATを含む
    • 感染した135台のエンドポイントが攻撃者のC2と通信したことが検知された
    • 滞留時間は2〜3時間
    • Microsoftはこの攻撃を北朝鮮支援の脅威アクターSapphire Sleetに帰属

  • 収束パターン

    • 3週間で3件の攻撃
    • 互いに異なるベクトル
    • 共通の標的は、開発者がツールチェーンに保存した認証情報とシークレット
    • 表の要約では次が示されている
      • LiteLLM: CI/CD認証情報の窃取 → PyPI、開発者認証情報とAPIキー、40分〜3時間
      • Axios: メンテナーアカウントの侵害 → npm、開発者ワークステーションRAT、2〜3時間
      • Vercel: OAuthアプリ侵害 → プラットフォーム、顧客環境変数、表では約22カ月と記載されているが、冒頭の訂正と本文では約2カ月に修正されている

過去のプラットフォーム侵害との共通パターン

  • Vercel侵害は、プラットフォームレベルの侵害が顧客シークレットを露出させる反復パターンとつながっている

  • Codecov Bash Uploader侵害、2021年1月〜4月

    • 攻撃者がBash Uploaderスクリプトを改ざんし、顧客CI環境の環境変数を流出させた
    • 約2カ月間未検知
    • 2万9000社超の顧客に影響の可能性、Twitch、HashiCorp、Confluentを含む
    • Vercelとの共通点はプラットフォーム侵害を通じた顧客環境変数の露出

  • CircleCIセキュリティ事故、2023年1月

    • 個人端末のマルウェアにより従業員のSSOセッショントークンが窃取
    • 内部システムにアクセスした後、顧客シークレットと暗号鍵が流出
    • CircleCIはすべての顧客に対し、プラットフォームに保存されたすべてのシークレットのローテーションを推奨
    • Vercelとほぼ同じ構造
      • 従業員アカウント侵害
      • 内部システムへのアクセス
      • 顧客シークレット流出

  • Snowflake顧客認証情報攻撃、2024年5〜6月

    • UNC5537がinfostealerで取得した認証情報とMFA未適用アカウントを使用
    • 165以上の組織に影響
    • Ticketmaster、Santander Bank、AT&Tを含む

  • Oktaサポートシステム侵害、2023年10月

    • 窃取された認証情報により顧客サポートケース管理システムにアクセス
    • HARファイル内のセッショントークンを閲覧
    • Cloudflare、1Password、BeyondTrustを含む顧客に影響

  • パターン要約

    • 信頼関係または認証情報を通じた初期アクセス
    • 内部システムへの横展開
    • 顧客シークレット流出
    • 対象範囲は一部標的からプラットフォーム全体までさまざま
    • 表には事案ごとの初期ベクトル、露出資産、検知遅延が整理されている
      • Codecov 約2カ月
      • Okta 数週間
      • CircleCI 数週間
      • Snowflake 数カ月
      • Vercel 約2カ月

まだ公開されていない事項

  • 公開報道や経営陣の発言は多いが、核心的な空白も依然として存在する
  • 公開記録上の未解決の問い
    • Vercelが異常活動を最初に検知した時点
    • 最も早い公開認証情報悪用の証拠と公開との間にある9日間の差の理由
    • 影響を受けた顧客数
      • Rauchは「quite limited」と表現したが、具体的な数字は非公表
    • ShinyHuntersフォーラムの主張が同一攻撃者によるものかどうか
    • Context.aiの現在の状況と下流顧客への通知の有無
    • Vercel内部アクセスの全体範囲
      • 影響を受けたチーム数、プロジェクト数、環境変数数は非公表
      • 顧客環境変数以外の内部システムへのアクセス有無も未確認
  • 記事では、判明している事実だけでなく、公開されていない事項を明示的に認める姿勢が厳密な分析に必要だと強調している

検知およびハンティングガイド

  • Vercel顧客向けの即時対応

    • すべてのプロジェクト環境変数の監査が必要
    • 記事には次のCLI例が含まれる
      • vercel env ls --environment production
      • vercel env ls --environment preview
      • vercel env ls --environment development
    • CLIは現在、sensitiveフラグを直接表示しないため、ダッシュボードまたはAPIでの確認が必要

  • 露出した認証情報の不正利用の探索

    • クラウドプロバイダー監査ログの検索
      • AWS CloudTrail
        • sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com を含む eventSource フィルタ
        • ローテーションしたVercel保存済み access key と一致する userIdentity.accessKeyId を検索
        • 組織の既知CIDR外の sourceIPAddress、python-requests、curl、Go-http-client、見慣れない自動化文字列の userAgent を検知
        • 期間は2026年2月から現在まで
      • GCP Audit Logs
        • Vercelに保存されたキーを使用するサービスアカウントの protoPayload.authenticationInfo.principalEmail を検索
        • 既知の範囲を外れる callerIp
        • storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create などのメソッドを確認
      • Azure Activity Logs
        • Vercel env vars にあったアプリケーションIDまたはサービスプリンシパルを基準にフィルタ
        • 想定範囲を外れる callerIpAddress
        • Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write を優先確認
    • データベースアクセスログの検索
      • 接続文字列がVercel環境変数に含まれていたすべてのDBが対象
      • 2026年2月〜4月の全期間ウィンドウを分析
      • Vercel edge IP、VPN、オフィスなど既知のegress範囲外のIPを確認
      • 通常のデプロイウィンドウ外で露出した認証情報を使った接続を検知
      • PostgreSQLは pg_stat_activity, log_connections
      • MySQLは general log または audit plugin
      • MongoDB Atlasは Project Activity Feed の DATA_EXPLORER, CONNECT イベント
    • 決済処理ログの検索
      • Stripe Dashboard → Developers → Logs
      • 想定サーバー以外の source_ip
      • /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
      • Braintree、Adyen の同等ログを確認
      • まだローテーションされていない non-sensitive env var 保存APIキーを優先
      • メール送信サービスログで予期しない送信も点検
    • OpenAI、Anthropic、GitHub、AWS、Stripe などからの 非自発的な漏えい認証情報アラート の確認が必要

  • ローテーションと再デプロイを同時に実施する必要

    • Vercelドキュメントによると、環境変数のローテーションだけでは過去のデプロイにある既存の認証情報の値は無効化されない
    • 以前のデプロイは、再デプロイされるまで以前の認証情報を引き続き使用する
    • したがって、すべてのローテーションでは、その変数を使用したすべての環境の 再デプロイ、または過去のデプロイの明示的な無効化が必要
    • 優先順位は次の順序
      • クラウドプロバイダー認証情報
      • データベース接続文字列
      • 決済処理キー
      • 認証シークレット
      • サードパーティAPIキー
      • 監視およびロギングトークン

  • セキュリティチーム向け事前対応

    • 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検知ロジック

  • OAuthアプリケーションの異常兆候、1〜2段階

    • 既知の悪性OAuth Client IDに関連するトークン refresh または authorization イベントに即時アラート
    • メール全体へのアクセス、Drive の読み書き、カレンダーアクセスなど広範なスコープの権限付与イベントを現在のベンダー一覧と照合
    • もはやビジネス利用されていないアプリは取り消し対象
    • 承認済みOAuthアプリのトークン利用が企業およびベンダーの想定CIDR範囲外のIPから発生した場合は調査が必要

  • 内部システムアクセスと横展開、3段階

    • 異常なSSO/SAML認証イベント
      • 侵害されたWorkspaceアカウントが、初見のIP、地域、デバイスフィンガープリントで内部アプリケーションにログインする場合
    • メールおよびDriveベースの認証情報収集
      • API key, secret, token, password, .env のようなキーワードの大量検索
      • 共有認証情報リポジトリ、エンジニアリングランブック、インフラ文書へのアクセス
      • メール転送ルールの作成
    • OAuth接続の内部ツールアクセス
      • Slack、Jira、GitHub、内部ダッシュボードなどで、通常と異なる時間帯またはインフラからのセッション生成やAPI活動
    • 権限昇格の試行
      • 新しいグループ・ロールへの参加
      • 未使用の管理コンソールへのアクセス
      • Google Workspace の Directory API 呼び出し、委任変更、他ユーザーのOAuthトークン列挙の試みを監視

  • 環境変数の列挙、4段階

    • Vercelチーム監査ログで、env read、list、decrypt 系呼び出しの異常な大量・高頻度パターンを検知
    • まず正常なCI/CDビルド時点のベースライン確立が必要
    • その後、ボリューム、時点、送信元主体がベースラインを外れるアクセスにアラート
    • サービスアカウントではないユーザーアカウントからのアクセス、普段そのプロジェクトとやり取りしないアカウントからのアクセスに注目

  • 下流認証情報の悪用、5段階

    • 2026年2月〜4月の期間中、non-sensitive Vercel環境変数として保存されていたすべての認証情報対象サービスのログを確認
    • AWSは特定の access key ID を基準に CloudTrail を検索
    • GCP、Azure はサービスアカウントまたはアプリケーションIDを基準に監査ログを検索
    • Stripe、OpenAI、Anthropic、SendGrid、Twilio などのSaaS APIは、ダッシュボードまたはAPIログで未認識IPや非稼働時間帯の利用有無を確認
    • 自社インフラに帰属できない利用は、直ちに侵害された認証情報とみなし、ローテーションと行動調査が必要

  • サードパーティ認証情報漏えいアラート

    • GitHub secret scanning partner program、AWS compromised key detection、OpenAI、Anthropic、Stripe、Google Cloud などの自動シークレットスキャンアラートを監視する必要
    • デプロイプラットフォームにのみ存在していたキーに対するアラートは、単なる衛生上の警告ではなく プラットフォーム侵害の指標 として扱う必要がある

脅威ハンティングの手動手順

  • Google Workspace Admin Consoleでの手動検索

    • Admin Console → Reports → Audit and Investigation → OAuth Log Events
    • Application Name = Context.ai または Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
    • 期間は2026年2月から現在まで
    • 結果があれば、直ちに権限を取り消し、インシデント調査が必要

  • 広範なスコープを持つサードパーティOAuthアプリの点検

    • Admin Console → Security → API Controls → Third-party app access → Manage Google Services
    • App access が Unrestricted のアプリを並べ替え
    • 各アプリの確認項目
      • アクティブなベンダー関係が存在するか
      • スコープに業務上の正当性があるか
      • 最終利用日
    • 90日以上未使用のアプリは取り消し対象

防御の推奨事項

  • 即時対応、0〜48時間

    • sensitive として表示されていないすべてのVercel環境変数をローテーション
    • ローテーション後、すべての環境を再デプロイ
    • 認証情報、トークン、キー、シークレットを含むすべての環境変数で sensitive フラグを有効化
    • Google WorkspaceまたはMicrosoft Entraの管理コンソールでOAuthアプリ承認を監査
    • もはや活発に利用していないアプリのアクセスを取り消し
    • 2026年2月から現在まで、Vercel環境変数に保存されていた認証情報が使われたすべてのサービスのアクセスログを確認

  • 短期的な強化、1〜4週間

    • HashiCorp Vault、AWS Secrets Manager、Doppler、Infisicalのような専用シークレットマネージャーへ移行
    • プラットフォーム環境変数への保存ではなく、ランタイム注入方式を利用
    • 対応している箇所では OIDCベース認証 により長期認証情報を排除
    • OAuthアプリ監視を導入
      • Nudge Security、Grip Security、Valence Security、またはGoogle Workspaceの標準管理機能
    • 認証情報ローテーションの自動化を構築
      • 30〜90日周期を推奨
    • OAuth承認を、契約ベンダーなどと同様の サードパーティリスクインベントリ に含める

  • 構造的変更、1〜6か月

    • 環境変数に対して Zero Trust の姿勢を採用
      • デプロイプラットフォームに保存されたすべてのシークレットは、プラットフォーム侵害時に露出し得ると仮定
    • 最小権限スコープを適用
      • DBアカウントは最小権限
      • APIキーの操作範囲を制限
      • クラウド認証情報は長期 access key ではなく、ロールベースの一時認証情報を使用
    • 企業アイデンティティシステムにアクセスするすべてのOAuthアプリ・統合について、サードパーティセキュリティレビューと定期的な再レビューを実施
    • PaaSプラットフォームをSBOM/ASPMインベントリに含める
      • 外部サービスではなく、第一級のサプライチェーン依存関係 として扱う必要がある

  • 推奨モニタリング

    • Google Workspace Admin Consoleで上記OAuth Client IDを監査
    • Vercel監査ログで予期しない env.read、env.list API呼び出しを監視
    • 2026年2月〜4月の間にVercel env varsへ保存された認証情報について、想定外のIPやuser agentによる利用がないかをCloudTrail、GCP Audit Logs、Azure Activity Logsで確認
    • 依存関係ツリーに LiteLLM または Axios があるなら、各勧告文にあるIOCもあわせて監視
    • 露出期間中、主要APIプロバイダーによる非自発的な漏えい認証情報アラートを監視

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

  • この侵害で認証情報露出の可能性がある組織は、以下の義務を評価する必要がある

  • GDPR

    • 露出した認証情報によりEU個人データを含むシステムへのアクセスが可能だった場合、72時間通知のカウントダウンは露出確認時点から始まる可能性がある
    • 4月10日のOpenAI通知は、一部組織の認知時点が4月19日の公開より前だった可能性があるという疑問を提起

  • CCPA/CPRA

    • 消費者データへのアクセス権を与える認証情報の露出は、通知義務を生じさせる可能性がある

  • PCI DSS

    • Stripe、Braintree、Adyenなどの決済処理認証情報の露出時には、インシデント対応手順とフォレンジック調査が求められる可能性がある

  • SOC 2

    • インシデント記録、認証情報ローテーション対応、更新された統制を継続的モニタリングの証跡に反映する必要がある

  • SEC Cybersecurity Rules 8-K

    • 重要性があると判断した上場企業は、4営業日以内の開示義務を負う
    • 記事では、実際の不正アクセス利用の有無がまだ不明でも、多くの規制フレームワークは 悪用の確認ではなく露出そのもの を基準に動く可能性があると指摘している

侵害指標

  • 確認済みIoC

    • OAuth Client ID
      • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
      • 侵害されたContext.ai OAuthアプリケーションに関連付けられた値

関連記事

1件のコメント

 
GN⁺ 9 일 전
Hacker Newsのコメント

  • Vercelが環境変数UIを最初に出したとき、sensitiveオプション自体がなかったことを思い出す。その機能が入るまでほぼ2年以上かかった。関連する議論は GitHub discussion と Vercel changelog に残っている

    • UIにsensitiveフラグを付けてもランタイムが変わるわけではないと思う。ビルド時点で process.env に入った瞬間、覗こうとする依存関係があれば読めてしまう。本当の問題は、すべての秘密情報をひとつのenv袋に詰め込んでビルドツールに丸ごと渡す構造だと思う。Cloudflareのscoped bindingsやFlyはすでに分離していて、他のプラットフォームは遅れているという認識
    • sensitiveは読み取り不可を意味するのではなく、UIで非表示くらいの意味でしかないと思う。action関数やrouteでpropsを少し返しすぎるだけでも簡単に漏れる。この手の問題を防ぐには結局、自前の鍵で環境値を暗号化するしかなく、分離手段が乏しいので一部の秘密はソースにbaked-inする回避策もありそう。攻撃者は環境値を読むだけでなくビルド成果物をダウンロードして復号鍵まで探す必要があるので、少しハードルは上がる。理想的ではないが暫定策としては機能しそう

  • こういう形で引っかかったのは本当に恥ずかしい事故に感じる。引用内容どおりなら、Lumma Stealer感染がContext.ai社員によるRoblox exploit scriptのダウンロードから始まったという点が特にきつい

  • CEOが攻撃者の素早い動きをAIで加速された攻撃手法のせいだと公にしたくだりは、私にはほとんど根拠が見えない。だから実質的に明らかになっている情報もあまりないという印象

    • 最近はAIがとんでもない言い訳市場まで揺らしていて、メディアがそれを検証なしに繰り返しているように見えるという皮肉を感じる
    • 一方で、vibe codedなソリューションがVercelをよく勧める傾向があったことも思い出す。昔のAxios推奨ブームに近い流れに見える

  • 私はStage 2の説明がよく理解できなかった。ContextAIアプリがGoogle mail、drive、calendarのような権限を全部要求していたなら、あまりに過剰だと思う。小さな会社でもないのに、こういうものを自社環境の外で動かすことに同意したとは信じがたかった。ただ、Context.aiのセキュリティ更新記事を見ると、Vercel社員1人が個人的に自分のGoogle Workspace全体へのアクセスを許可した選択のようにも読める

  • 今回の流れが正確にどう動いたのか、まだよく分からない。ここでいうOAuth tokenが Sign in with Google 後に受け取るトークンなのか気になる。普通それは特定のGoogle Appのclient idとclient secretに紐づくものではないかと思う。攻撃者がユーザーのOAuth tokenとclient情報まで知っていても、Driveなどにアクセスするところまでは理解できるが、そこからどうやってVercelのcontrol planeログインに繋がったのかは腑に落ちない。結局Google Driveの中で認証情報を見つけたのだろうか

    • レポートがその部分を明確に言っていないように感じる。だからむしろ何かもっと恥ずかしいミスがあり、それを隠しているのではと勘ぐってしまう。DriveやGmailの中のパスワードだったのかもしれないし、別のコメントにあるようにpasswordless login linkだったのかもしれない
    • OAuthのプロセスを終えると、結局session tokenを受け取り、それでAPIリクエストを送れるという説明が核心に見える。発行されたトークンが被害者のinboxへのアクセス権まで持っていた可能性が高く、攻撃者はメールを読んでワンタイムパスワード、magic link、その他の機密情報を得たのだろうという推測
    • 私も混乱している。本当にContext.aiのOAuthアプリが侵害され、その結果Context.aiが見ていたすべての顧客ワークスペース可視性を攻撃者もそのまま得たのか気になる。だが、なぜ特定の社員1人に責任が集中するのかも疑問。結局、そのVercel社員がVercel全体のワークスペースを読めるようContext.aiに承認したのかが核心に見える

  • 「OAuthアプリを第三者ベンダーのように扱い、長期的なプラットフォーム秘密をなくし、provider-side compromiseを前提に設計すべきだ」という話には同意しつつも、供給者側侵害を前提に設計するのは本当に難しいと感じる。そもそも信頼がシステムの出発点だからだ

    • 私たちのSaaSでOAuthアプリを検討している立場なので、なおさら非常に難しい問題に思える。これをうまく解くmarketplaceがあるのかも気になる。CloudflareはSalesloft事故の後、すべての第三者OAuthとAPIトラフィックを自分たち経由でプロキシしようと提案したが、それは脅威ベクトルを別の場所に移す感じもする。scope最小化、失効短縮、client secret rotationのような基本ルール以外に何ができるのか見当がつかない。clientごとの送信元IP allowlistくらいしか思いつかない
    • こうした事例を見ると、これまで語られてきたzero-trustはかなりの部分がマーケティング文句だったのではと思う。本当のsecurity by designなら、サプライチェーン攻撃で上位プロバイダーが完全に侵害されうる前提を最初から入れるべきだという主張

  • 今後はこういう事件がはるかに増えると思う。大企業でも小規模事業者でも、AIツールを広く試してきたことによるリスク負債を、いまIT経済全体が遅れて支払わされ始めているという感じだ。だからこれを「AI-enabled tradecraft」というより、会社のリーダーシップがスピードを理由に全社へAIツールの導入と試用を圧力的に進めた結果として読んでしまう。この種の攻撃自体はあまりにありふれていて、強制可能なAIインストールallowlistがない会社ならほぼどこも露出している。ContextのようなツールがローカルとSaaS全体でどれだけ入っているかをIT担当者に聞けば、かなり多い可能性が高い。問題は、こうしたツールが事実上あらゆるものにアクセスし、その統制を担うセキュリティベンダーやRBACエコシステムは本格化までまだ18〜24か月は必要そうだという点だ。Vercelは炭鉱のカナリアに見え、Contextだけが標的だったとは思えない。ひとつ崩れれば他も連鎖的に表面化しうる、よく知られていながら無視されてきた脅威ベクトルだという認識。今後6か月は特に厳しくなりそうで、誰もが今まさにAI導入状況を監査しているか、監査すべきであり、攻撃者も遮断される前に今あるアクセス権で動くだろうと思う。ちなみに私はtech業界のセキュリティ責任者

    • 私もここ数年、奇妙なセキュリティ事故がニュースにたくさん出るだろうと言い続けてきた
    • 私も同じ見方だ。かなり興味深い時期に入っているという感じがする

  • 「OAuthの信頼関係がプラットフォーム全体の露出に広がり、CEOは攻撃速度をAIのせいにし、検知から公開までの遅延も疑問」という要約を見て、私には見えている主要な失敗は典型的だと感じる。過剰な権限を持つユーザーアカウントがあり、同様のアカウントが他にもあった可能性がある。2FAやZeroTrustがなかったか、あっても非常に限定的だった可能性も高い。全体的なセキュリティ衛生も良くなかったという判断

    • 今後はAIのせいにすることが、サイトが落ちたとき何でもDDoSのせいにするのと同じような、セキュリティ事故向け万能言い訳になりそうだと思う

  • 多くの人が見落としがちな点がひとつある。Vercelでは環境変数をrotateしても昔のデプロイが自動で無効化されず、古いdeployは再デプロイするか削除するまで古い認証情報で動き続ける。だから告知後にキーを入れ替えていても、すべてのデプロイを再投入していなければ漏えいした値がまだ生きている可能性がある。そしてGoogle WorkspaceのOAuth承認履歴も必ず確認すべきだと思う。Admin Console > Security > API Controls > Third-party app access を見れば、2年前のデモのために承認したアプリがいまだにメールとDrive全体の権限を持っている可能性が高い

    • 私たちはこの理由で複数のGoogleアカウントを分けている。ただ、多くの組織はGoogle Workspaceのユーザー単価の負担でそうできない。私も以前の職場で、こうしたOAuth承認は主アカウントではなく別アカウントで行おうと提案したが失敗したことがある
    • 通常credential rotationといえば、以前の認証情報の無効化まで含むと考える。新しいものだけ作って古いものを生かし続けるやり方は、ほとんど聞いたことがないという反応
    • レポートのその一文は私もかなり混乱した。古いデプロイが古いenv varを使うという事実自体が、そのcredentialの有効性を左右するわけではないからだ。これは機密性というより可用性に影響するfootgunに近いと感じる。レポートの「Environment variable enumeration (Stage 4)」の部分も奇妙に読める。特に「service accountではなくuser accountから、あるいは普段プロジェクトとやり取りしないアカウントから環境変数アクセスが起きていないか見よ」という説明を見て、人々は本当にVercel env varから認証情報を取り出して他システムで使っているのかと違和感があった
    • Preview deployはさらに深刻だと思う。PRごとに同じenv varで1つずつ作られ、誰も片付けない。キーをローテーションしてprodを再デプロイしても、古い値が入ったゾンビpreviewが何百も残っているかもしれない
    • rotationをするときは当然、以前の変数の失効まで行うべきだという指摘

  • このレポートに出てくる一部の詳細、とくに2024〜2025から始まるタイムラインは、他では広く報じられていない内容のように感じた。たとえば「2024年末〜2025年初頭に攻撃者がContext.ai OAuthアクセスからVercel社員のGoogle Workspaceアカウントへピボットした」「2025年初頭〜中盤に内部Vercelシステムへのアクセスと顧客環境変数の列挙が始まった」といった日付がどこから来たのか気になる

    • 私の見る限り、そうした日付はすべてでっち上げで、おそらくhallucinationの可能性が高い