技術 約6分で読めます

VercelがContext.ai起点と独立の先行侵害を4/23に確認、Lumma Stealer経由のVercelトークン直接窃取も想定

Vercel セキュリティ OAuth インシデント マルウェア サプライチェーン
いけさん目次

4月19日の初期告知（Context.ai侵害がOAuthチェーンでVercel本体まで到達したセキュリティインシデント）から4日後、Vercelが公式KBを更新して続報を出した。
ポイントは1つ、「今回のインシデントとは独立した、先行して侵害されていた顧客アカウント」を検出したという発表だ。
TechCrunch も同日 Vercel says some of its customers’ data was stolen prior to its recent hack で報じている。

文言はあっさりしているが、実務上の意味はかなり違う。
Context.ai 起点の OAuth 連鎖だけを気にしていれば済んだ話ではなく、Vercel 認証情報自体を標的にした infostealer（情報窃取マルウェア）活動が、この事件より前から別経路で走っていたということになる。

4/23 で何が増えたか

Vercel の続報から読める増分を整理する。

項目4/19 時点4/23 時点
侵害顧客アカウントContext.ai 起点で一部上記に加え追加のアカウントを通知
事件外の先行侵害言及なしindependent of and predates this incident と明記
攻撃経路Context.ai の OAuth 連鎖上記に加え、社員端末直接の infostealer 感染が想定に入る
npm 供給チェーン確認中GitHub / Microsoft / npm / Socket と共同調査、汚染なし

independent of and predates は Vercel 公式の言い回し。「Vercel 側から発生したものではない」とも明記しており、責任線引きよりも「経路が複数ある」ことの告知に比重がある。

CEO Guillermo Rauch の TechCrunch 向けコメントでは、攻撃者が「Context.ai の侵害の範囲外でも活動していた」「Vercel のトークンのような価値ある鍵を探し回る infostealer マルウェアを使っていた」と触れられている。
つまり、Context.ai 経由の OAuth が修復されても、個別に感染した開発者端末から奪われた VERCEL_TOKEN や API キーが並行して使われていた、という構図だ。

Lumma Stealer まで遡る攻撃チェーン

TrendMicro・Hacker News・The Hacker News の追加情報を合わせると、Context.ai 側の初期感染までの経路まで見える。

Context.ai の従業員は2026年2月頃、Roblox のチート検索を経由して Lumma Stealer を踏んだ。
Lumma Stealer は典型的な infostealer で、Chrome に保存された認証情報・Cookie・OAuth トークン・クリップボード内容を Telegram や C2 サーバに吸い上げる。今回は Google Workspace 認証情報と、Supabase・Datadog・Authkit の各キーが抜けていたことが確認されている。

そこから Context.ai 側の OAuth アプリ権限 まで到達し、「allow all」で承認されていた Vercel 従業員アカウントの Google Workspace 権限に連鎖した、というのがここまでの確定路線だ。

flowchart TD  
    A[Context.ai従業員端末<br/>Lumma Stealer感染<br/>2026/2頃] --> B[Google Workspace認証情報<br/>Supabase/Datadog/Authkitキー窃取]  
    B --> C[Context.ai OAuthアプリ乗っ取り]  
    C --> D[Vercel従業員Google Workspaceアカウント乗っ取り<br/>allow all権限悪用]  
    D --> E[Vercel内部システムへの横移動]  
    E --> F[non-sensitive環境変数の列挙と復号]

    X[別の感染経路<br/>Vercelトークンを直接狙う<br/>infostealerの活動] --> Y[先行侵害された顧客アカウント<br/>4/23で検出]  
    Y --> Z[Context.aiインシデントとは独立]

右側の枝（X→Y→Z）が 4/23 で新たに確認された部分で、時系列的には Context.ai 経路より前に走っていた可能性がある。

ShinyHunters の BreachForums 売却リスト

4月中旬、OX Security の分析にある通り、ShinyHunters を名乗る攻撃者が BreachForums に Vercel 関連データを $2M で出品した。出品内容は次のとおり。

  • データベースアクセスキー
  • ソースコードの一部
  • 従業員アカウント情報
  • API キー群

真偽は現時点で未確定で、Vercel 側も具体件数と内容は公表していない。
ただし「売っている」という事実があるだけで、VERCEL_TOKEN・GitHub トークン・npm アカウントのローテーションは前提にしたほうが安全だ。

infostealer が狙う「鍵の置き場所」

今回の根が infostealer 活動という前提で見るなら、ブラウザや OS が認証情報をどう扱っているかを押さえておく必要がある。

保存場所infostealer の回収対象対策
Chrome / Edge のパスワードストア保存済みパスワード、Cookie、セッショントークンブラウザの同期を棚卸し、Vercel・GitHub・npm セッションは随時リログイン
~/.vercel/auth.json 等の CLI 認証ファイルVERCEL_TOKEN の平文vercel logout → 再ログインで再発行
OS キーチェーン（macOS Keychain, Windows Credential Manager）一部 infostealer は対応パスフレーズと連携、自動ロック短縮
Discord / Telegram クライアントログイン済みトークン多要素と定期サインアウト

Lumma Stealer は2024〜2025年にかけて特に Chrome 系のブラウザストアと OAuth Cookie の窃取を強めており、開発者の作業端末が真っ先に標的になる。

sensitive フラグの実体を改めて

Vercel の環境変数は、sensitive フラグの有無で保存・取り出しの挙動が変わる。
未設定の値は Plaintext または Encrypted として保存され、ダッシュボードや API から復号して読める。今回の事件で攻撃者が参照したのはこちら。
sensitive マーク付きの値は、保存後の再取得が UI・API 問わず不可能になり、デプロイ時のみランタイムに注入される。

このフラグ1つで値の露出面が桁違いに狭まるため、4/19 時点で Vercel が「sensitive にマークされていなかった値」と限定している理由はここにある。
逆に言えば、sensitive 未設定の値は事実上全部露出したものと見て動くのが妥当で、4/23 続報でさらに対象が広がった以上、この前提は変わっていない。

実務で今日やること

前記事で書いた OAuth 棚卸しと sensitive ローテーションに加えて、infostealer 前提の項目を足す。

  • 開発者端末のウイルス対策実行ログを4月に絞って確認し、EDR の検知がなかったかを見る。特に Chrome パスワードストア参照・クリップボード監視系のイベント
  • vercel logout → vercel login で VERCEL_TOKEN を全員再発行。複数の ~/.vercel 設定ファイルが残っている端末は特に注意
  • Chrome / Edge に保存した Vercel / GitHub / npm の認証情報を削除し、ブラウザの「ログインを保存する」をチームで無効化する運用に切り替えを検討
  • Google Workspace の OAuth アプリ棚卸しは Context.ai に限らず、ここ6ヶ月で許可した AI ツール全般に拡げる。ShinyHunters の動きを見る限り、Context.ai 単体で止まる話ではない
  • sensitive フラグを付けていない環境変数の棚卸し。DB 接続文字列・決済キー・サードパーティ配信キーは最優先

関連記事