Vercel は秘密情報を平文で保管し、それを機能と呼びました

Vercel が侵害を受けました。攻撃者は検出されるまで約 2 か月間内部に潜伏していました。攻撃者は Vercel の任意の「sensitive」フラグを使用していなかったすべてのプロジェクトの顧客環境変数 — API キー、データベースのパスワード、署名キー、トークン — を列挙し、復号しました。

攻撃の連鎖は次の通りです。Context.ai というサードパーティ製の AI ツールが侵害されました。攻撃者はその足がかりを使って Vercel の従業員の Google Workspace アカウントを乗っ取り、そこから Vercel の内部システムへ横移動しました。そして秘密情報の読み取りを開始しました。

このデータは現在、BreachForums において 200 万ドルで売りに出されていると報じられています。

デフォルトではなかった「sensitive」チェックボックス

重要な点はここです。

Vercel の環境変数には 2 種類があります。通常の環境変数は「保存時に暗号化」されますが、Vercel のシステムによって復号・読み取りが可能です。一方「sensitive」な環境変数は追加の暗号化を使用しており、Vercel によれば内部からのアクセスも防止できるとされています。

攻撃者は通常の環境変数をすべて読み取ることができました。保護されていたのは「sensitive」な変数のみでした。

問題は、「sensitive」がオプトインであり、デフォルトではなかったことです。チェックボックスをオンにせずに DATABASE_URL や STRIPE_SECRET_KEY、JWT_SIGNING_KEY を設定した開発者 — その大半が該当します — は、内部アクセスを持つ攻撃者が復号可能な形式で値を保持していたことになります。

Vercel の侵害後ガイダンスは「暗号化ストレージのために sensitive 環境変数機能を有効にしてください」というものです。言い換えれば、あなたが秘密情報を守っていると思っていた暗号化は、実際には Vercel 自身や、Vercel のシステムに侵入した者から守っていなかったということです。

2 か月の滞在時間

初期侵害は 2026 年 2 月に発生しました。Vercel が最初のセキュリティ公告を公開したのは 4 月 19 日です。攻撃者が内部システムへアクセスできた期間は、およそ 2 か月に及びます。

Vercel のセキュリティチーム自身が、攻撃者を「運用速度と Vercel のプロダクト API サーフェスに対する深い理解から見て highly sophisticated（高度に巧妙）」と評しています。自社のインフラをホストしている企業が、攻撃者が想定以上に自社システムを理解していたと述べる場合、それは注意を促すべき事象です。

この 2 か月の間に、攻撃者は影響を受けた顧客プロジェクト全体でアクセス可能な環境変数を列挙する時間、持ち出す時間、売却する時間を持っていました。

OAuth サプライチェーン

侵入経路は Vercel 自身のコードではありませんでした。Vercel の従業員が Context.ai — AI プロダクティビティツール — に Google OAuth で認可を与えていました。Context.ai が侵害されると、攻撃者はその OAuth 許可が提供していたすべての権限を継承しました。

これは繰り返し起きているパターンです。組織は主要な認証を慎重に固めた上で、独自の、しばしばより弱いセキュリティ体制を持つサードパーティ製ツールに OAuth トークンを配布します。チェーンの中で 1 つのアプリが侵害されれば、攻撃者は従業員のアクセス権を継承します。

侵害された OAuth App ID は公開されています: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com。自組織がこのアプリを認可している場合は、今すぐ取り消してください。

実施すべきこと

Vercel 上でデプロイしている場合:

• すべての環境変数を直ちにローテーションしてください。「影響を受けたか」を確認しようとするのを待たないでください
• 今後はすべての環境変数で sensitive フラグを有効にしてください
• Google Workspace の OAuth アプリ権限を監査し、積極的に使用していないものは取り消してください
• 2026 年 2 月から 4 月にかけての予期しない変更がないか Vercel のデプロイログを確認してください
• Vercel に保存されていた資格情報を用いた不正アクセスがないか、下流サービス（データベース、決済代行、API）を確認してください

本質的な教訓

Vercel のアーキテクチャは、顧客の秘密情報を内部アクセスから復号可能な形で保存していました。より強力なオプションは提供されていましたが、デフォルトにはされていませんでした。2 か月もの間、誰も攻撃者がそれらの秘密情報を読み取っていることに気づきませんでした。

これが「私たちを信頼してください」というセキュリティの問題です。Vercel は環境変数を保存時に暗号化していました — 技術的には正しい記述です。しかし復号鍵を保持していたのは Vercel 側です。Vercel のシステムが侵害された時点で、あなたの秘密情報も侵害されたことになります。

代替案はゼロ知識アーキテクチャです。サービス提供者が数学的にあなたのデータを復号できない構成です。「復号しない」のではなく、復号できないのです。いかなる内部侵害も、不正行為を行う従業員も、インフラに 2 か月も潜伏する高度な攻撃者も、サーバーが復号鍵を一度も保持していなかったものを読み取ることはできません。

Vercel は顧客に対して、実効的な暗号化をオプトインするためにチェックボックスをオンにするよう求めています。問うべき質問は、なぜそれが最初から唯一の選択肢ではなかったのか、という点です。