Vercelハッキングの手口と対策｜2026年4月の侵害と脆弱性・DDoS、安全性の確認

2026年4月19日、Vercelは社内システムへの不正アクセスを公表しました。従業員が使っていた外部のAIツールを足がかりに、一部の顧客の環境変数が読まれた事件です。Vercel自体への侵入と、利用者側の設定ミスやNext.jsの脆弱性による被害は、原因と対策を分けて考える必要があります。この記事では、4月の侵害で何が起きたのかと利用者がいま確かめる項目を先に示し、そのうえで環境変数の扱い、Next.jsの脆弱性、DDoS・ボット対策を、Vercel公式のドキュメントと告知に沿って整理します。

まとめ：Vercelの安全性とハッキング対策の要点

• Vercel自体の侵害は実際に起きた：2026年4月、Context.aiの侵害を起点に従業員のGoogle Workspaceアカウントが乗っ取られ、Sensitive指定の無い環境変数が復号されました。Vercelは2026年10月16日に対応完了と事件の終結を告知しています。
• 最優先はSecret型への切り替えとローテーション：2026年8月24日から環境変数はConfig型とSecret型に分かれました。APIキーやDBパスワードがConfig（旧Non-sensitive）のままなら、値を新しくしてSecret型で登録し直します。
• Next.jsの脆弱性はホスティング先で影響が変わる：CVE-2025-29927や2026年8月の脆弱性はVercel上のアプリには影響しませんでしたが、自前ホストでは更新が必須です。
• DDoS対策とAttack Modeは全プラン無料：Firewallが遮断・チャレンジした通信は課金されません。一方、OWASP Core RulesetはEnterprise限定です。
• 設定漏れは vercel security check で洗い出せる：2026年8月26日に全プランで一般提供されたSecurity Dashboardが、2FA未設定のメンバーや公開状態のプレビューを一覧にします。

2026年4月のVercel侵害：Context.ai経由で環境変数が読まれた経緯

経緯はVercelのセキュリティ告知「Vercel April 2026 security incident」に沿って整理し、攻撃者側の主張とは分けて扱います。

侵入経路と告知の時系列

起点は、Vercelの従業員1人が使っていた外部AIツールContext.aiの侵害です。攻撃者はそこからその従業員のGoogle Workspaceアカウントを乗っ取り、本人のVercelアカウントへ入りました。さらにVercelの社内環境へ移動し、Sensitive指定の無い環境変数を列挙して復号しています。Vercelは攻撃者を、動きの速さと製品APIへの理解の深さから「高度な技術を持つ」と評価し、Google Mandiantなどと調査しました。

影響を受けた範囲と攻撃者の主張の違い

Vercelが認めた被害は、限られた顧客の「復号すると平文になる」環境変数、つまりSensitive指定の無い値です。追加調査では同じ事件で侵害されたアカウントが少数見つかりました。別系統の侵害も少数見つかりましたが、Vercelのシステムが起点ではなく、4月の事件の拡大でもないと説明されています。

一方、ShinyHuntersを名乗る人物はアクセスキーやソースコードを売りに出したと主張し、200万ドルを要求したと報じられました（BleepingComputerの報道）。これらは攻撃者側の主張で、Vercelは裏付けていません。対応を決めるときは、告知に書かれた範囲を前提にしつつ、Sensitive指定をしていなかった値は漏れた前提で扱うのが安全です。

利用者がいま確かめる6項目

Vercelの告知が挙げる推奨を、手を付ける順に並べると次のとおりです。プロジェクトやアカウントを削除しても、漏れた値で本番システムに入れる状態は残ります。削除より先にローテーションしてください。

1. Sensitive指定をしていなかった機密値は、新しい認証情報を発行してSecret型で保存し、利用する全プロジェクト・対象環境を再デプロイする。通常は動作確認後に旧値を失効させ、悪用が疑われる場合は停止の影響を判断して旧値の即時失効を優先する。
2. Google Workspaceの管理者は、IOCとして公開されたOAuthアプリ 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com の利用履歴を確認する。
3. Activity Logで身に覚えのない操作が無いかを見る（ダッシュボードか vercel activity）。
4. 最近のデプロイ一覧に心当たりの無いものがあれば削除する。
5. Deployment Protectionを最低でもStandard（本番ドメイン以外をすべて保護）にし、Protection Bypass for Automationのトークンを使っていれば作り直す。社内ツールなら、2026年9月9日から全プラン無料になったVercel AuthenticationのAll Deployments（本番も保護）を選べます。
6. 認証アプリかパスキーで2FAを設定し、チームでは2FAの強制を有効にする。

侵入口はVercelの製品ではなく、従業員が連携させた外部ツールのOAuth権限でした。自社でもGoogle WorkspaceやGitHubに連携させたAIツールの権限を棚卸しの対象に入れてください。

環境変数の漏洩を防ぐ：Config型とSecret型の使い分け

4月の侵害で読まれなかったのは、Sensitive指定をした値でした。Vercelはその後、2026年8月24日に環境変数をConfig型とSecret型に分ける変更を出しています。

Secret型へ切り替える手順

Config型は保存後もアクセス権のあるメンバーが値を読めます。Secret型は保存後に誰も読み出せず、デプロイからだけ使えます。既存のSensitive変数は自動でSecret扱いになります。Configに機密値を置いていた場合は、読み出せた旧値をローテーションし、新しい値をSecret型で保存してから、その値を使う環境を再デプロイします。CLIでは --type config か --type secret で型を指定します。

# 新しい値をSecret型で本番に登録する（--sensitive でも同じ）
vercel env add STRIPE_SECRET_KEY --environment production --type secret

# 読み返す必要がある公開設定はConfig型（--no-sensitive でも同じ）
vercel env add NEXT_PUBLIC_API_BASE --environment production --type config

Secret型の値は、32文字以上であればビルドログに出ても [REDACTED] に置き換わります。チームのSecurity設定にある「Separate Production Secret Values」を有効にすると、本番の値をプレビューや開発と同じにできなくなります。プレビューから本番の鍵が漏れる経路を断てます。画面での設定手順と vercel env pull の扱いはVercelの環境変数の設定手順：Production・Previewの分け方とvercel env pull・Secret型で解説しています。

NEXT_PUBLIC_とフレームワーク接頭辞の落とし穴

Secret型にしても、名前が NEXT_PUBLIC_ で始まる変数はビルド時にクライアント側のJavaScriptへ埋め込まれ、ブラウザから誰でも読めます。Secret型が守るのはVercelのダッシュボードとAPIからの読み出しであって、配信されるバンドルの中身ではありません。機密値には公開用の接頭辞を付けず、Route HandlerやServer Actionなどサーバー側だけで参照してください。Security Dashboardにも、フレームワークがクライアントへ出している変数を検出する項目があります。

Next.jsの脆弱性とVercel上での扱い

Next.jsの脆弱性は、Vercel基盤への侵入とは別に、アプリへの影響を確認する必要があります。Vercel上と自前ホストで影響が分かれるので、ホスティング先ごとに判断します。

CVE-2025-29927：Vercelが影響を受けなかった理由

2025年3月に公開されたCVE-2025-29927は、内部用ヘッダー x-middleware-subrequest を付けるだけでミドルウェアの処理を飛ばせる脆弱性で、ミドルウェアで認可していたアプリでは保護ルートに素通りできました。Vercelのpostmortemによると、影響を受けたのは next start と output: 'standalone' の自前ホストです。Vercelでは、Next.jsのルーティング処理が別システムに分離されて世界中に配置されているため、結果として影響を受けませんでした。修正版は12.3.5・13.5.9・14.2.25・15.2.3です。ただし15.2.3はその後のReact2Shell（CVE-2025-66478）の影響範囲に入るので、今から上げるなら最新の修正版にしてください。影響判定の条件とログでの検知方法はCVE-2025-29927とは？Next.jsミドルウェア認可バイパスの影響範囲・修正版・検知方法にまとめています。

2025年12月以降のデプロイ自動ブロックと2026年8月の保護

Vercelは2025年12月5日から、React2Shell（CVE-2025-66478）の影響を受ける版のNext.jsを含む新規デプロイを、既定で失敗させています。2026年8月25日に公開されたNext.jsの脆弱性2件（AVIF画像の処理によるRCEと、WindowsサーバーでのRCE）でも、VercelはAVIFの最適化を止め、Linuxで動く自社の実行環境は対象外だとして、利用者の対応を不要としました（Vercelのchangelog）。自前ホストの場合は15.5.24または16.3.3以降への更新が必要でした。その後の修正の経緯はReact2Shell（CVE-2025-55182）とNext.jsの脆弱性の対応手順、現在の最新版はNext.js 16の最新バージョンとリリース履歴で確認できます。

Vercel上で守られるのは、プラットフォームが吸収できる種類の脆弱性だけです。認可はミドルウェアだけに置かず、データを取得する直前でも確認してください。

DDoS・ボット対策：Vercel Firewallで防げる範囲

Vercel Firewallの各機能がどこまで無料で、どこから設定が要るかを整理します。Firewallはリクエストに対して、DDoS対策のルール、WAFのIPブロック、WAFのカスタムルール、WAFのマネージドルールセットの順に評価します。

DDoS Mitigationと課金の扱い

DDoS Mitigationはプランを問わず全デプロイで自動的に動き、L3・L4・L7の攻撃を遮断します（DDoS Mitigationのドキュメント）。Firewallが遮断した通信は課金されず、2026年5月18日からはWAFが拒否・チャレンジ・レート制限した通信もCDN RequestsとFast Data Transferの課金から外れました。ただし、DDoSと判定される前に返したリクエストや、DDoSと見なされなかったボットの通信は課金されるので、Proでは支出管理の上限設定を併用してください。

WAFカスタムルールとプラン別の上限

WAFの設定変更は300ミリ秒以内に全世界へ反映され、以前の設定へすぐ戻すこともできます。使えるルール数と機能はプランで変わります（Vercel WAFのドキュメント）。

OWASP Core RulesetはHobbyとProでは使えません。もっとも、SQLインジェクションの根本対策はプランを問わずアプリ側でSQLの値をパラメーター化することで、入力検証やWAFのカスタムルールは補助策です。2026年5月からは vercel firewall rules add --ai "Rate limit /api to 100 requests per minute by IP" のように、CLIから自然文でルールを作ることもできます。

Attack ModeとVercel Security Checkpoint画面

Attack Modeを有効にすると、ブラウザからの訪問者は全員がチャレンジを受けます。全プランで無料で、ブロックした通信は使用量に数えられません。Googlebotなど既知の正規ボットと、同じアカウント内のFunctionsやCron Jobsからのリクエストはチャレンジされずに通ります。

チャレンジ中の訪問者に表示されるのが「Vercel Security Checkpoint」画面です（Firewallの概念ドキュメント）。JavaScriptでブラウザかどうかを確かめ、通過すると1時間有効なセッションが作られます。Attack Modeのほか、チャレンジ動作のカスタムルールやBot Protectionルールセット、DDoS対策の自動判定でも表示されます。閲覧者として何度も表示されるなら、JavaScriptを有効にし、VPNやプロキシを切って開き直してください。運営者の場合、curlやPostman、外部サーバーからのAPI呼び出しはチャレンジを通過できず失敗します。FirewallのTrafficタブでどのルールが当たったかを確かめ、正当な自動処理にはバイパスルールを足します。

BotIDのBasicとDeep Analysis

BotIDは、画面に何も出さずにブラウザ側でチャレンジを解かせ、サーバー側の checkBotId() で結果を確かめる仕組みです。サインアップや決済、APIなど狙われやすいルートに組み込みます（BotIDのドキュメント）。

Deep AnalysisはKasadaの機械学習で数千の信号を見て、PlaywrightやPuppeteerで動く高度なボットを検出します。課金されるのは checkBotId() を呼んだ回数だけで、通常のページ閲覧は対象外です。

前段にCloudflareなどのプロキシを置く場合の注意

Vercelは、Vercelのプロジェクトの前にリバースプロキシを置く構成を推奨していません（リバースプロキシのドキュメント）。Firewallの判定精度が落ち、利用者の実IPも分からなくなり、Bot Protectionも正しく動きません。どうしても必要なら、CloudflareやAWS CloudFrontなどは全プランで自動有効になるVerified Proxyの対象なので、実IPを運ぶヘッダーを送る設定にします。NginxやHAProxyの自前プロキシはEnterprise限定の個別手続きです。前段プロキシでは、実IPヘッダーに加え、Vercelの検証用パスをキャッシュしない設定と、ACME検証用パスのHTTPからHTTPSへのリダイレクト除外も必要です。

Security DashboardとCLIによる設定漏れの点検

4月の侵害を受けて、Vercelは2026年8月26日にSecurity Dashboardを全プランで一般提供しました（一般提供の告知）。チームのメンバー、トークン、プロジェクト、環境変数を決まった項目で点検し、リスクの高い順に並べます。Security Dashboardのドキュメントにある点検項目は次の9つです。

同じ点検はCLIでも回せます。Vercel公式のCLIリファレンスに掲載されているオプションを使うと、次のように点検できます。

# チーム全体を点検し、項目ごとの違反件数を表示
vercel security check

# 違反しているメンバー・トークン・変数を個別に一覧
vercel security check --findings

# 1つのプロジェクトに絞り、JSONで出力
vercel security check --project my-app --json

違反があっても終了コードは0なので、CIで止めるならJSONの中身で判定します。出力は攻撃者に役立つ情報なので、公開リポジトリのCIログには出さないでください。チーム全体を点検するCIとプロジェクト単位のデプロイ用CIはトークンを分け、後者は2026年7月30日に追加されたProject-scoped Tokens（1プロジェクトだけに権限を絞るトークン）にすると、漏れたときの被害を1プロジェクトに抑えられます。

侵害を疑ったときの初動と影響範囲の確定

侵害を疑ったら、封じ込め、原因の特定、報告の順に進めます。調べるための記録は、プランによって使えるものが違います。Activity Logは全プランで使え、チームとプロジェクトの変更を時系列で残します。CSVでの書き出しや外部の保管先への転送ができるAudit LogsはEnterprise限定です。

1. 封じ込め：疑わしいデプロイを削除し、自動デプロイを止めます。トークン、環境変数のSecret、GitHub連携のOAuth権限は、どれが漏れたか分かるまで待たずにすべて作り直します。
2. 原因の特定：vercel activity ls --all --since 30d でトークンの発行、メンバーの追加、環境変数の更新を洗い出します。--type env-variable-read で平文の読み出しイベントを確認できます。ただし、CLI経由の復号や共有環境変数の読み出しには別のイベント種別があるため、それらも調査対象に含めてください。ビルド工程に不審な依存パッケージが入った疑いがあれば、ロールバックだけでは足りず、依存関係を総点検してから作り直します。手口と確認方法はShai-Hulud（シャイ・フルード）とは？npmサプライチェーン攻撃の全体像と対策で扱っています。
3. 報告：不正アクセスによる個人データの漏えい等、またはそのおそれは、原則として人数にかかわらず個人情報保護委員会への報告対象です。ただし、高度な暗号化等の措置を講じたデータの除外や、委託先が委託元へ通知した場合の例外があります。対象となる場合は本人通知も確認してください。発覚したらまず速やかに報告し、不正の目的によるおそれがある場合は発覚から60日以内に確報を出します（個人情報保護委員会「漏えい等の対応とお役立ち資料」）。

自社のアプリに認可の漏れや設定の不備が残っていないかを第三者に確かめてもらうなら、脆弱性診断・セキュリティ診断でVercel上のNext.jsアプリについて相談できます。侵入テストを伴う場合は、Vercelが許可するPro・Enterprise上の自社アプリを対象とし、基盤自体へのテストは含めません。

Vercelで防げないこと：利用者の責任範囲と他の基盤との違い

Vercelが受け持つのは、DDoS対策、環境変数の暗号化保管、プラットフォームで吸収できる脆弱性の緩和までです。アプリの認可ロジック、公開用接頭辞を付けた変数、連携させた外部ツールの権限、依存パッケージの監査は、どの基盤でも利用者の責任です。

OWASPのマネージドルールをProの価格帯で使いたい、自前のWAFを前段に置きたいという要件があるなら、Vercelは向きません。前段プロキシは推奨されないため、Cloudflare WAFやAWS WAFと素直に組める基盤を選ぶ方が筋が通ります。比較の観点はVercelとCloudflare Pagesの違い：Next.jsの動かし方・料金の増え方・商用条件で選ぶとAWS Amplify Hostingとは？料金・デプロイ手順とS3+CloudFront・App Runner後継との違いで整理しています。SAML SSOはEnterpriseのほか、Proでも有料アドオンで使えます。プランごとの機能の差はVercel料金プラン｜Hobby無料枠とPro($20)の中身・超過単価を参照してください。

よくある質問

Vercelは安全なホスティングですか？

DDoS Mitigationは全プランで自動適用され、攻撃時には無料のAttack Modeを追加で有効にできます。ただし2026年4月の侵害ではSensitive指定の無い環境変数が読まれたため、機密値をSecret型で保存し、2FAとDeployment Protectionを有効にしておくことが前提になります。

Vercel自体がハッキングされたことはありますか？

あります。2026年4月19日に公表された事件で、従業員が使っていたContext.aiの侵害を起点に一部の顧客の環境変数が読まれました。2026年10月16日に事件の終結が告知され、Vercelが公開するnpmパッケージに改ざんは無かったと確認されています。

Vercel Security Checkpointとは何ですか？

Vercel Firewallがチャレンジを出したときに表示される確認画面です。JavaScriptでブラウザかどうかを確かめ、通過すると1時間有効なセッションができます。VPNやプロキシ経由の閲覧、スクリプトからのアクセスでは通過できないことがあります。

VercelのDDoS対策は追加料金が必要ですか？

不要です。DDoS MitigationとAttack Modeは全プラン無料で、Firewallが遮断・チャレンジ・レート制限した通信も課金されません。DDoSと判定される前に返したリクエストは課金対象です。

VercelのBotIDとは何ですか？

画面に何も出さずにブラウザ側でチャレンジを解かせ、サーバー側の checkBotId() で人間かボットかを確かめる仕組みです。Basicは全プラン無料で、Kasadaの機械学習を使うDeep AnalysisはProで呼び出し1,000回あたり1ドルかかります。

関連記事

• Vercelの環境変数の設定手順：Production・Previewの分け方とvercel env pull・Secret型【2026年10月】
• CVE-2025-29927とは？Next.jsミドルウェア認可バイパスの影響範囲・修正版・検知方法
• Shai-Hulud（シャイ・フルード）とは？npmサプライチェーン攻撃の全体像と2.0・Mini・CHAINDROPの最新動向、影響確認と対策
• Vercel（ヴァーセル）とは？サーバー不要の仕組みとできること・料金【2026年】
• Vercel料金プラン｜Hobby無料枠とPro($20)の中身・超過単価【2026年10月】