Vercelがハッキング被害（2026年4月）：今すぐ実行すべき開発者向け60分緊急対応マニュアル
2026年4月19日、Vercelは攻撃者がサードパーティ製AIツール（Context.ai）を侵害し、Vercel従業員のGoogle Workspaceアカウントを乗っ取り、限定的な顧客プロジェクト_subset_において「機密（sensitive）」としてマークされていなかった環境変数を閲覧したことを確認しました。過去30日以内にVercelへ何かをデプロイしていた場合、あなたの環境変数のいずれかがすでに第三者の手中にある可能性を想定し、迅速に行動する必要があります。
ここで受け入れなければならない不快な真実があります。多くのvibecoders（感覚的にコーディングする開発者）は、テンプレートから.envの値をそのままデプロイし、「機密」トグルに触れることすらありません。まさにこのクラスの変数が攻撃者によって閲覧されました。このプレイブックでは、次の60分で何をチェックし、何をローテーション（更新）し、次のプラットフォーム侵害でアプリが壊れないようにスタックを強化するかを順を追って説明します。
TL;DR：今後60分でやるべきこと
他は何も読まなくても、今すぐこの6つを実行してください：
- 本番ブランチでの自動デプロイを一時停止します。
vercel env pullを実行し、出力結果をシークレットパターン（sk_live_、AKIA、ghp_、eyJ）でgrep検索します。- 非機密環境変数として保存されているすべてのAPIキーをローテーションします。支払い、データベース、認証、クラウドプロバイダーのキーから始めます。
- Vercelの「機密」環境変数トグルを使用してローテーション済みのシークレットを再登録し、再デプロイします。
- Vercelのアクティビティログ（4月1日〜20日）を開き、認識のないデプロイ、ログイン、またはトークンイベントにフラグを立てます。
- 同じ期間のGitHub組織の監査ログを確認し、新しいPAT（Personal Access Token）、デプロイキー、またはワークフローの変更がないか調べます。
以下では、必要なコマンド、パターン、およびローテーションの順序を含む完全な内訳を解説します。
Vercel 2026年4月の侵害で実際に何が起こったのか？
Vercelは2026年4月19日、攻撃者がVercel従業員が使用していたサードパーティ製AI生産性ツールであるContext.aiを侵害したと発表しました。そこから攻撃者は従業員のVercel Google Workspaceアカウントを乗っ取り、Vercelの内部環境にピボット（横移動）し、「機密」としてフラグ付けされていない環境変数にアクセスしました。
「機密」とマークされた変数は別の暗号化された読み取りパスを使用しており、Vercelによるとそれらが漏洩した証拠はないとしています。その他、APIキー、データベースURL、JWTシークレットを保存している通常の環境変数はすべて読み取り可能でした。サイバー犯罪フォーラムへの投稿では、Vercelのデータが200万ドルで販売されていると主張されていますが、Vercelはデータ持ち出しを確認していません。いずれにせよ、安全策としては、Vercelから直接メールが届いていなくても、ローテーションの目的のために侵害があったと想定するのが賢明です。
同社は攻撃者について、「その作戦速度とVercelシステムの詳細な理解に基づき、非常に洗練されている」と評価しました。つまり、これはスクリプトキディの仕業ではなく、時間を真剣に捉える必要があるということです。
あなたは影響を受けていますか？ 5分で確認する方法
短く答えれば、Vercelを使用していて**「機密」トグル**を厳格に適用していなかった場合、あなたは影響を受けたとみなすべきです。5分のトリアージ手順は以下の通りです：
- Vercelのアクティビティログを開き、2026年4月1日から現在までをフィルタリングします。見覚えのないログイン、トークン作成、またはデプロイがあるか探します。
- Google Workspace管理コンソール → セキュリティ → APIコントロールに移動し、公開された侵害指標（IoC）であるOAuthクライアントID
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.comを検索します。承認されている場合は、直ちに無効化してください。 - チームメンバーの中にGoogle SSOを使用してContext.aiにログインしたことがある人がいるか確認します。もしいる場合、そのアカウントは高リスクとして扱います。
- Vercelプロジェクトの「環境変数」タブを確認します。「機密」としてマークされていない変数の数を数えます。それらはすべて対象範囲内です。
Vercelから「お客様のアカウントに影響を与えるセキュリティインシデントを特定しました」という件名のメールを受け取っている場合、あなたは確認された影響対象者です。ローテーションセクションにスキップして、今すぐ開始してください。
60分緊急対応プレイブック
これは被害範囲の大きさ順に並べられています。ステップを飛ばさないでください。各ステップが次のステップの前提条件となります。
ステップ1：環境を凍結する（最初の10分）
フォレンジック調査を始める前に出血を止めます：
main/productionブランチでの自動デプロイを一時停止します（Vercelダッシュボード → プロジェクト → 設定 → Git）。- より深い侵害が疑われる場合は、
github.com/organizations/<your-org>/settings/installationsでVercel GitHub Appを一時的に無効にします。 - Vercelの監査ログをCSVにエクスポートし、ローカルに保存します。これが後でGDPR通知義務のあるインシデントに発展した場合に必要になります。
- Observability Plus（試用版でも可）を有効にし、拡張ログを保持できるようにします。
これは「証拠保全」のステップです。ログのスナップショットを取得する前にローテーションを行うと、タイムラインが破壊されます。
ステップ2：環境変数を取得し、シークレットをスキャンする
ターミナルを開いて以下を実行します：
vercel link
vercel env pull .env.vercel-audit次に出力をスキャンします。最も速い方法はGitGuardianのCLIを使用することです：
ggshield secret scan path .env.vercel-audit何もインストールしたくない場合は、以下のパターンでgrep検索を行います。これにより、envファイル内の漏洩シークレットの80%を検出できます：
grep -E "AKIA[0-9A-Z]{16}|sk_live_[0-9a-zA-Z]{24}|ghp_[0-9a-zA-Z]{36}|ghs_[0-9a-zA-Z]{36}|npm_[0-9a-zA-Z]{36}|eyJ[a-zA-Z0-9_-]+|-----BEGIN" .env.vercel-audit一致したものはすべてローテーション候補です。また、DB URL、Redisパスワード、Webhook署名キーなど、依然として資格情報である一致しなかったシークレットもローテーション候補です。grepは明らかなものだけを捕捉します。
ステップ3：優先順位に従ってシークレットをローテーションする（アルファベット順ではない）
ここで多くのチームが失敗します。40個のシークレットをランダムな順序でローテーションすると、セッションキーが無効になり、すべてのアクティブなログインが切断され、サポートチケットが爆発します。階層別に行います：
ティア0 — 今後30分以内にローテーション：
- すべてのGitHub Personal Access Tokens（細粒度およびクラシック）
- 既存のすべてのVercel機密環境変数トークン
- デプロイ保護トークン
ティア1 — 今日中にローテーション：
- 決済プロセッサのシークレットキー（Stripe
sk_live_、Adyen、Braintree） AUTH_SECRET、NEXTAUTH_SECRET、JWT署名キー、セッションクッキー- 書き込みアクセス権を持つデータベース接続文字列（
DATABASE_URL、Mongo、Redis） - クラウドプロバイダーキー（AWS IAM、GCPサービスアカウント、Azureクライアントシークレット）
- Webhook署名シークレット（送信側と受信側の両方で更新）
ティア2 — 今週中にローテーション：
- サードパーティSaaSキー（メール、SMS、アナリティクス、CRM）
- OAuthクライアントシークレット
- SMTP認証情報、CDNキー
ティア3 — 都合の良い時にローテーション：
- 読み取り専用アナリティクストークン、Sentry DSN、公開/匿名キー
重要な操作順序：
- データベースの場合：古いユーザーを取り消す前に新しいユーザーを作成してください。そうしないと、ローテーション中にサイトがダウンします。
- セッションキーの場合：ログアウトイベントを計画してください。すべてのアクティブなセッションが終了します。
- Webhookの場合：同じデプロイウィンドウ内で両側を更新します。
- 環境変数を変更するたびに再デプロイしてください。Vercelはビルド時に値を焼き付け、ランタイム時ではありません。
ステップ4：すべてを「機密」として再追加する
新しい値を戻す際は、すべての変数で**「機密」**トグルをオンにしてください。機密値は別の暗号化パスを使用し、Vercel自身の公告によれば、今回のインシデントでは暴露されていません。これは、影響を受けたほとんどの顧客を救えたであろうワンクリックの変更です。
ステップ5：リポジトリ内の不要な変更を監査する
メインブランチのHEADと、4月1日より前の既知の正常なコミットを比較します。特に以下に注目します：
package.jsonのスクリプト、特にpostinstall、prepare、preinstall- ロックファイル（
package-lock.json、pnpm-lock.yaml）内の予期しない新しい依存関係 - 新しいワークフローやピン留めされていないアクションがないか
.github/workflows/*.ymlを確認 - ビルドコマンドの変更や不審なリライトがないか
vercel.jsonを確認 - 不明なドメインを指す新しいヘッダーやリダイレクトがないか
next.config.jsを確認
npmパッケージを公開している場合は、npm view <pkg> time --jsonを実行し、あなたが作成していないものがリリースされていないか確認してください。
ステップ6：下流システムを追跡する
攻撃者は環境変数で止まりません。それらを利用します。4月1日から現在までの期間について、下流システムをクエリします：
- AWS CloudTrail： 予期しない
CreateUser、AttachUserPolicy、S3GetObjectの急増、新しいIPからのログイン。 - データベース監査ログ： 大規模な
SELECT *クエリ、エクスポート、異常な地域からの接続。 - Stripe / Adyen： 新しいAPIキー、不審な返金、奇妙な場所からの顧客作成。
- 認証プロバイダー： 不可能な移動（impossible-travel）ログイン、不正なパスワードリセット、新しいOAuthアプリ。
ここで何らかのヒットがあれば、これは単なるローテーション演習から実際のインシデントへと変わります。エスカレーションし、通知義務（GDPR：72時間）を検討してください。
「Vibecoders」が見落とすもの：隠れた攻撃面
Claude Code、Cursor、またはCopilotなどのAI支援コーディングツールを使って育った場合、セキュリティドキュメントを読む前に最初のVercelアプリを出荷していたかもしれません。それは構いません。しかし、熟練した開発者よりもvibecodersをより強く襲う4つの隠れた罠があります：
NEXT_PUBLIC_の落とし穴。NEXT_PUBLIC_というプレフィックスが付いたものはすべてクライアントサイドJavaScriptにバンドルされます。「テスト用だから」とAPIキーをそこに置いた場合、侵害以前からすでに公開されていました。ビルド出力をgrepします：grep -rE "sk_|AKIA|eyJ" .next/static/。- Linear / Slackからの漏洩。 チームが「ちょっとだけ」とLinearの課題やSlackのスレッドにシークレットを貼り付けた場合、それらのシークレットはサードパーティのログに残ります。Linearの監査ログを確認し、上記と同じ正規表現パターンで検索します。
- プライベートリポジトリ内の
.env.localという思い込み。 Vercel GitHub Appが侵害された場合、プライベートリポジトリはプライベートではありません。コミットされたすべての.env.*ファイルが対象範囲内です。 - 本番シークレットを使用したプレビューデプロイ。 多くのvibecodersはプレビュー環境に本番環境変数を再利用します。これは攻撃面を倍増させます。分離してください。
これはAIコーディングツールが跳过してしまう退屈なインフラ作業です。解決策はAIの使用を止めることではなく、AIのスピードにセキュリティ基準を組み合わせることです。アプリがどこにあるのかさえまだ把握できていない場合は、Vercel vs Netlifyの比較やRailway vs Render vs Fly.ioの内訳が良い出発点となります。
次の侵害で燃え尽きないためにスタックを強化する方法
プラットフォーム侵害は「もし」ではなく「いつか」起こるものです。月曜日までに本番アプリが整えておくべき基準は以下の通りです：
- Vercelで**新しい環境変数はすべてデフォルトで「機密」**に設定します。これをチームの筋肉記憶にしてください。
- 短期間の資格情報を使用します。 長寿命のAWS/GCPキーをGitHub OIDCフェデレーションに置き換えます。クラウドプロバイダーはCIアイデンティティを直接信頼するため、漏洩する長寿命のシークレットがありません。
- pre-commitシークレットスキャンを導入します（gitleaks、Trufflehog）。シークレットがリポジトリに入るのを最初に防ぎます。
- GitHub Appの権限を特定のリポジトリに制限し、組織全体にはしません。
- Google Workspace、Microsoft 365、GitHub、Vercel全体で四半期ごとのOAuthアプリレビューを実施します。認識できないものはすべて削除します。
- Claude Codeフックとしてシークレットスキャンを実行し、AIが忘れた場合でも確定的なpre-commit強制を実施します。
- Next.jsのバージョンを固定し、アドバイザリを監視します。Vercelは主要なNext.jsの管理者であるため、ここでのインシデントは連鎖します。
- バックエンドシークレットをセグメント化します。 SupabaseまたはFirebaseを使用している場合、行レベルセキュリティを使用し、サービスロールキーは控えめに使用します。漏洩したサービスキーはデータベース全体の侵害を意味します。
このロックダウンを手伝う必要がありますか？ Techsyの役割
正直なところ、ほとんどの小規模チームにはセキュリティエンジニアがおらず、午前2時に60ステップのインシデント対応プレイブックを読むことは、誰も月曜日に過ごしたい時間ではありません。
Techsyでは、過去2年間で40以上の本番Next.jsおよびNode.jsアプリのインシデント対応とプラットフォーム強化を実行してきました。Vercelのインシデント specifically に関して、私たちは以下を提供しています：
- 72時間緊急対応： ティア0 / ティア1のローテーションを実行し、200以上のシークレット署名に対して環境変数をスキャンし、Vercel + GitHub + クラウドログをエンドツーエンドで監査します。通常のターンアラウンドは1営業日です。
- プラットフォーム強化監査： 機密変数の移行、OIDC資格情報のローテーション、pre-commitシークレットスキャン、GitHub Appのスコープ設定、そして次の侵害時に将来の自分が何をすべきかを知るための文書化されたランブック。
- 継続的なDevSecOps： 四半期ごとのOAuthレビュー、継続的なシークレットスキャン、インシデントドリルを行い、「自分たちには起こらない」という主張を実際に裏付けられるようにします。
私たちはチェックボックス型のセキュリティベンダーではなく、エンジニアです。今パニックになっている場合は、無料の30分トリアージコールにご連絡ください。あなたに私たちが必要なのか、上記のプレイブックで対応できるのか、率直にお伝えします。
よくある質問
Vercelのハッキングは本当の確認事実ですか、それとも単なる噂ですか？
確認済みです。Vercelは2026年4月19日に公式セキュリティ bulletin を公開し、侵害されたサードパーティ製AIツール（Context.ai）および乗っ取られた従業員のGoogle Workspaceアカウントを介した不正アクセスを認めました。「機密」としてマークされていない環境変数がアクセスされました。別のBreachForumsへの投稿ではデータが200万ドルで販売されていると主張されていますが、その部分は未検証です。
Vercelからメールが届いていません。私は安全ですか？
おそらく安全ですが、「おそらく」はセキュリティ体制ではありません。Vercelは、確認された影響を受けた限定的な顧客_subset_に連絡したと述べています。メールが届かなかった場合、リスクは低いですが、Vercelプラットフォーム全体の非機密環境変数はすべて被害範囲内にありました。上記の10分トリアージはいずれにしても実行してください。
Vercelにおける「機密」環境変数と通常の環境変数の違いは何ですか？
「機密」環境変数は別の暗号化された読み取りパスを使用し、作成後はダッシュボードで閲覧できません。通常の環境変数は、プロジェクトアクセス権を持つ anyone（今回のインシデントでは攻撃者も含む）によって読み取り可能です。修正は無料で、変数ごとにワンクリックで完了します。
Vercel上のシークレットだけでなく、すべてのシークレットをローテーションする必要がありますか？
非機密Vercel環境変数に保存されているすべてのシークレットをローテーションしてください。同じキーを他の場所で使用していた場合（一般的なアンチパターン）、すべての場所でローテーションしてください。プレビューデプロイの.env.local、GitHub ActionsなどのCIシステム、LinearやSlackに貼り付けた参照も忘れないでください。
環境変数を実際のシークレットに対して迅速にスキャンするにはどうすればよいですか？
vercel env pull .env.auditを実行し、その後ggshield secret scan path .env.auditを実行します。GitGuardianをインストールできない場合は、プレイブックのステップ2にあるgrep一行コマンドを使用します。これにより、AWSキー、Stripeキー、GitHubトークン、npmトークン、JWT、PEMブロックを検出します。
この後、Vercelから離れるべきですか？
このインシデント alone が理由ではありません。Vercelの対応、公開されたIoC、タイムライン、ローテーションガイダンスは比較的透明性がありました。あらゆるプラットフォームは最終的に侵害を受けます。重要なのは、それに備えて設計しているかどうかです：機密変数のデフォルト設定、短期間の資格情報、セグメント化された環境。代替案を検討している場合、Vercel vs NetlifyおよびRailway vs Render vs Fly.ioの記事でトレードオフを解説しています。
影響を受けた場合、顧客に通知するまでの猶予はどれくらいありますか？
GDPRでは、通知義務のある侵害を認識してから72時間以内です。カリフォルニア州（CCPA）にはデータ分類固有のトリガーがあります。SOC 2 / ISO 27001契約では、規制当局よりも早期の通知を要求することがよくあります。有料顧客がおり、そのデータの持ち出しを確認した場合、72時間の時計が始まっていると想定し、何かを送信する前に法務部門に相談してください。
Vercelを使用していなくても、Next.jsアプリはこの方法で攻撃される可能性がありますか？
このインシデントはVercelプラットフォーム固有です。他の場所でホストされているNext.js自体は、侵害メカニズムの影響を受けません。しかし、シークレットを偶然暴露してしまう同じNEXT_PUBLIC_環境変数パターンを使用していた場合、それらの問題はホストに関係なくコードと共に移動します。いずれにせよ、ビルド出力を監査してください。
被害の大部分を防ぐことができたワンクリックの修正は何ですか？
初日からVercelで資格情報を含むすべての環境変数を**「機密」**としてマークすることです。これはダッシュボードのチェックボックスです。このインシデントでは、機密変数はアクセスされず、通常の変数だけがアクセスされました。それが修正であり、コストはゼロドル、プロジェクトあたり約5分です。
チームが二度とマークされていないシークレットを出荷しないようにするにはどうすればよいですか？
3つの層：(1) gitleaksによるpre-commitシークレットスキャン、(2) Vercel API経由でsensitive: trueフラグなしで環境変数が追加された場合に失敗するCIチェック、(3) 編集ごとにスキャナーを実行するClaude Codeフック。多層防御により、3つのうちの1つで80%を検出でき、3つすべてで約99%を検出します。
まとめ
Vercel 2026年4月の侵害は深刻ですが、今後60分で行動すれば survivable です。デプロイを凍結し、環境変数を取得し、grepを実行し、階層別にローテーションし、機密として再追加し、下流を追跡します。それがプレイブックの全体です。
プラットフォーム侵害は、私たちがデフォルトにどれだけ依存しているかを露呈させます。ここで被害を受けたほとんどのチームは間違ったことをしたわけではありません。ただ、誰もそれが重要だと言わなかったため、「機密」トグルをチェックせずに放置していただけです。それがvibecodersにとっての真の教訓です。AI生成コードは迅速に出荷されますが、セキュリティデフォルトは生成時に付属しません。
スタックについてセカンドオピニオンが必要な場合、または午前2時に一人でこのプレイブックを実行したくない場合は、Techsyチームとの無料トリアージコールを予約してください。そうでなければ、幸運を祈ります。迅速に行動し、Those variablesを機密としてマークしてください。