Vercel侵害、AI OAuthアプリが侵入口　追加影響アカウントも判明

今回の事故はどこが破られたかより、どこから入られたかが重い

Vercelの4月セキュリティ告示で最も重いのは、内部システムへの不正アクセスそのものより出発点だ。会社の説明では、侵入はVercelの外側、社員が利用していたサードパーティーAIツール Context.ai の侵害から始まった。攻撃者はそこから社員の Google Workspace アカウントを乗っ取り、その先で Vercel アカウントに到達し、さらに内部環境へ横移動した。これは単なる1アカウント事故ではない。AI周辺ツールの OAuth 連携が、そのまま開発基盤の入口になり得ると示した。

読まれたのは非機密とラベルされた値だった

Vercelによると、攻撃者は平文で復号できる non-sensitive environment variables を列挙し、復号できた。名前だけ見ると被害が軽く見えるが、運用の現場ではここにも API キー、トークン、接続情報が入りがちだ。Vercelは当初、影響を受けた限定的な顧客だけに連絡したが、その後は追加の IOC とログ上の environment variable read イベントを広く洗い直した。その結果、侵害の証拠がある追加アカウントも見つかった。調査が進むほど半径が広がったタイプの事故だ。

最悪の供給網シナリオは今のところ否定された

今回の告示で最も重要な安心材料は別の行にある。Vercelは GitHub、Microsoft、npm、Socket と連携して調べた結果、Vercelが公開した npm パッケージが侵害された証拠はないと述べている。改ざんの痕跡もなく、供給網は安全だという判断だ。ここが崩れていれば影響はVercel利用者を大きく越えていた。会社がまず線を引いたのはその最悪ケースである。

Vercelだけの問題で終わらない

さらに重いのは、問題の Google Workspace OAuth アプリ自体がより大きな侵害の一部であり、その影響が多くの組織にまたがる数百人規模の利用者へ及ぶ可能性があるとVercelが書いた点だ。教訓は単純で、社内で小さな便利ツールとして導入したAIサービスでも、ID基盤にぶら下がった瞬間に本番アクセスの一部になる。非機密扱いの環境変数も、読み出されればすぐ運用リスクへ変わる。

Vercelが出した対応は実務寄りだ。認証手段を二つ以上有効にし、sensitive にしていなかった環境変数を優先的にローテーションし、activity log と recent deployments を点検すること。プロジェクトやアカウントを削除するだけでは十分ではないとも明記した。開発基盤を預かるチームは、Vercelの公式セキュリティ告示を起点に、自社の OAuth アプリ管理と秘密情報の扱いをすぐ見直したほうがいい。