Vercelハッキングの手口と対策｜情報漏洩・脆弱性・DDoSを実例で整理

「Vercelハッキング」という言葉で検索する人が抱える不安は一様ではありません。公開サイトの改ざんを心配している人もいれば、環境変数からのAPIキー漏洩、Next.jsの脆弱性、DDoSによるサービス停止を気にしている人もいます。それぞれ有効な対策がまったく異なるため、まず攻撃の類型を切り分けることが出発点になります。この記事では、2025年に大きな話題となったNext.jsの認証バイパス脆弱性CVE-2025-29927や環境変数の漏洩といった実例をもとに、Vercel環境で現実に起きる侵害の手口と、Vercel Firewallで防げる範囲、検知と初動対応までを整理します。

まとめ：Vercelハッキングで押さえる要点

• 攻撃は3類型に分かれる：サイト改ざん、アカウント/チーム権限の乗っ取り、ビルド・依存関係経由のサプライチェーン攻撃。立場と扱うデータで優先順位が変わる。
• 最大の脅威はアプリ側の脆弱性と設定ミス：Next.jsのCVE-2025-29927（CVSS 9.1）、NEXT_PUBLIC_環境変数への機密混入、認証なしプレビューデプロイが代表例。Vercel基盤そのものの侵害より頻度が高い。
• プラットフォーム防御は標準で強い：Vercel FirewallのDDoS Mitigationは全プラン無料でL3/L4/L7を自動遮断。WAFカスタムルールとBotIDでL7の悪用を抑える。ただしアプリ内部の認可漏れは自力で塞ぐ必要がある。
• 検知と初動を先に決めておく：Audit Logsの監視、侵害時のデプロイ停止とトークン失効の手順を用意しておくと復旧が早い。

Vercelハッキングが指す3つの攻撃類型と狙われる理由

同じ「ハッキング」でも、Vercel環境では侵入口と被害がまったく違います。対策を組む前に、自分がどの類型に備えるべきかを決めます。

改ざん・アカウント乗っ取り・サプライチェーンの3類型

1つ目は公開サイト本体への改ざん、2つ目はVercelアカウントやチーム権限の乗っ取り、3つ目はビルド工程や依存ライブラリを経由するサプライチェーン攻撃です。開発者個人であればソースコードや環境変数の漏洩が直接のリスクになり、受託開発ではクライアント環境への二次感染から損害賠償に波及することもあります。運営企業では顧客データ流出やサービス停止による売上損失が中心的な被害になります。攻撃者の目的も、クラウド課金の悪用や暗号資産採掘を狙う金銭目的型と、情報窃取を狙う諜報目的型で挙動が変わります。

JamstackとVercelが狙われやすい構造的な理由

Vercelはビルド時に環境変数を読み込み、GitHubなどのリポジトリと密に連携します。この「リポジトリ→ビルド→デプロイ」の自動化パイプラインが利便性の源であると同時に、OAuth連携トークンや環境変数という高価値な資格情報が一箇所に集まる攻撃対象になります。さらにServerless Functionsは実行環境が使い捨てで痕跡が残りにくく、プレビューデプロイが自動生成されるため、公開範囲の設定漏れが起きやすい構造です。攻撃者はサイト本体を破るより、こうした周辺の設定不備を突く方が容易だと判断します。

ハッキングと設定ミス漏洩の初動での切り分け

Vercelで起きる事故の多くは、外部攻撃者による能動的な侵害ではなく、自社の設定ミスに起因します。両者は対応方針が異なるため、初動で識別を誤ると被害が拡大します。

ただし両者は完全には分離できません。設定ミスで漏れた情報を足がかりに能動的な攻撃へ発展する複合型もあるため、片方を塞いだら終わりとは考えないほうが安全です。

Vercelで実際に起きる脆弱性・設定ミスと情報漏洩

「vercel 漏洩」「next.js 脆弱性」で検索される事故の中身は、基盤そのものの侵害よりアプリ側にあります。頻度の高い順に具体例を挙げます。

CVE-2025-29927：Next.jsミドルウェア認証バイパス

2025年3月に公開されたCVE-2025-29927は、CVSS 9.1（Critical）のNext.js脆弱性です。ミドルウェアの無限ループ防止用に使われる内部ヘッダーx-middleware-subrequestをリクエストに付与すると、ミドルウェアの処理自体を丸ごとスキップできてしまいます。認証・認可をミドルウェアだけに依存していたアプリでは、この一手で保護ルートに素通りできる深刻な問題でした。修正版はNext.js 12.3.5・13.5.9・14.2.25・15.2.3で、まずはこのいずれか以降へ更新するのが確実です。なおVercelでホストしている場合は、Vercel側がエッジで当該ヘッダーを遮断する緩和を適用済みで、Vercel上のアプリは一定程度自動保護されました。ただしアプリ本体の修正版更新は依然必須です。自己ホストなどVercel外で運用している場合は、Cloudflareやロードバランサなどのプロキシ層で外部から来るx-middleware-subrequestヘッダーを削除すれば緩和できます。この事例が示す教訓は、認可の最終判定をエッジのミドルウェアだけに委ねず、データ取得の直前（Route HandlerやServer Action）でも検証すべきということです。

Public環境変数とプレビューデプロイの設定不備

Next.jsでNEXT_PUBLIC_接頭辞を付けた環境変数は、ビルド時にクライアント側のJavaScriptバンドルへそのまま埋め込まれます。ここにAPIキーやシークレットを置くと、ブラウザの開発者ツールから誰でも読めてしまいます。機密値には接頭辞を付けず、サーバー側（Serverless Function内）でのみ参照するのが原則です。もう一つ多いのが、プレビューデプロイの公開範囲です。VercelはブランチやプルリクエストごとにプレビューURLを自動生成しますが、既定では認証が掛からず、ステージング環境の情報が第三者に見える状態になり得ます。Deployment Protection（Vercel AuthenticationやPassword Protection）を有効にして、本番以外のデプロイを保護してください。加えてnext.config.jsのheaders設定でセキュリティヘッダーを欠くと、クリックジャッキングなどの余地が残ります。

// next.config.js：クリックジャッキング等を抑えるヘッダー例
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Frame-Options', value: 'DENY' },
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
      ],
    }]
  },
}

依存パッケージ経由のサプライチェーン攻撃

直接使うライブラリだけでなく、その先の間接依存（transitive dependency）が汚染される攻撃も増えています。npmエコシステムでは、正規パッケージの乗っ取りやワームによる自己増殖型の攻撃が現実に発生しており、ビルド時にマルウェアが混入すれば環境変数やトークンがそのまま外部へ送信されます。手口と影響確認の方法はnpmサプライチェーン攻撃（Shai-Hulud）の全体像と対策で詳しく扱っています。Vercel側では、依存の固定（lockfileのコミット）とDependabot等による監査、ビルドで参照する環境変数の最小化が基本の防御になります。

Vercel標準セキュリティ機能の実効範囲と守備限界

「vercel ddos」「vercel waf」「vercel bot protection」で求められているのは、Vercelが標準で用意する防御の実効範囲です。プラットフォーム層は強力ですが、守備範囲を正しく把握しないと過信につながります。

Vercel FirewallのDDoS Mitigation・WAF・BotID

Vercel Firewallは全プランで有効なプラットフォーム全体のファイアウォールで、L3/L4のTCPフラッドやL7のDDoSをリアルタイムに遮断します。DDoS Mitigationは設定不要・追加料金なしで自動発動します。その上にあるWAF（Web Application Firewall）は、L7トラフィックをログ・ブロック・チャレンジ・レート制限するカスタムルールを自分で定義でき、ルール変更は全世界のエッジへ300ミリ秒未満で伝播します。OWASP Top 10に対応するmanaged rulesetの有効化や、標的型攻撃を受けている間だけ防御を強めるAttack Modeも用意されています。ボット対策のBotIDはCAPTCHAやAPIキーなしで多数のリクエスト信号を解析し、なりすましブラウザや自動化を検出します。Firewallが遮断・チャレンジ・レート制限したトラフィックはCDNリクエスト等の課金対象から除外されるため、防御が課金増に直結しない設計です。

環境変数の暗号化・SAML SSO・チーム権限設計

Vercelは環境変数を暗号化して保管し、チームの権限はロールで制御します。組織的に運用するならSAML SSO連携で認証を一元化し、退職者アカウントの放置や個別ログインの乱立を防ぎます。ただしSAML SSOはEnterpriseプラン向けの機能で、プランによって使える範囲が変わります。どのプランで何が使えるかはVercelのHobbyプランとProプランの違いを確認してください。権限は「必要最小限のロールを、必要な期間だけ」を徹底し、個人アクセストークンには有効期限とスコープを設定します。

標準機能では防ぎきれない領域

ここまでの機能はネットワーク層とプラットフォーム層の防御です。一方、CVE-2025-29927のようなアプリの認可ロジックの欠陥、Serverless Functionの認可漏れ、機密を含む環境変数の設計ミスは、Vercel Firewallでは検知も遮断もできません。攻撃はWAFから見れば正規のHTTPリクエストに見えるからです。プラットフォーム防御は「土台」であって「アプリのセキュリティ」ではない、という切り分けが重要です。認可はアプリ側で二重化し、依存関係の監査は自社で回す前提で設計してください。

侵害の検知と発生時のインシデント対応

侵害はゼロにできない前提で、早く気づき、素早く封じ込める仕組みを先に用意します。「vercel audit log」「vercel インシデント」で探される実務はここです。

Audit Logsと監視による異常検知

Vercelのteam Audit Logsには、メンバー追加・権限変更・トークン発行・環境変数の更新・デプロイといった操作が記録されます。監視すべき代表的な兆候は、身に覚えのないアクセストークンの発行、深夜帯の権限昇格、想定外のIPやリージョンからのデプロイ、環境変数の連続更新です。加えてWeb Analyticsで特定エンドポイントへの不自然なトラフィック増を見張り、GitHubの通知（不審なワークフロー変更やforce push）とVercelの通知を組み合わせると、パイプライン全体での早期警戒になります。外部SIEMへログを転送すれば相関分析もできますが、まずは上記の兆候を人が見られる状態にするだけでも検知遅延は縮まります。

発覚直後の初動：デプロイ停止とトークン失効

侵害を疑ったら、被害拡大を止めることを最優先します。実務の順序は、(1)該当プロジェクトのデプロイを停止し自動デプロイを一時無効化、(2)漏洩が疑われるアクセストークン・OAuth連携・環境変数のシークレットを即時失効・再発行、(3)GitHub連携の権限を見直し不審なOAuthアプリを解除、の順です。トークンとシークレットは「疑わしきは全量ローテーション」が原則で、どれが漏れたか特定できるまで待つと被害が広がります。

影響範囲の確定・復旧・報告

封じ込めの後、Audit Logsとアクセスログから侵入経路と影響範囲を確定します。復旧は、クリーンなコミットからのロールバックか、汚染された依存を除去した再ビルドかを、侵入経路に応じて判断します。ビルド工程が汚染された可能性があるなら、単なるロールバックでは不十分で依存関係の総点検が必要です。顧客の個人データ流出が確認された場合は、日本では個人情報保護委員会への報告・本人通知の義務が生じ得るため、法務と連携して対応します。技術的復旧と並行して、公表範囲や監督官庁への報告可否を早い段階で判断しておくと、後手に回りません。

他ホスティング基盤との比較で見るVercelの特性

AWS AmplifyやNetlify、Cloudflare Pagesと迷う場合、セキュリティの観点では「どこまでを基盤が持ち、どこからが自分の責任か」（責任共有モデル）の線引きが判断材料になります。

Vercelは防御機能が既定で有効で設定の手数が少ない一方、細かいネットワーク制御を作り込みたい要件ではCloudflareやAWSの自由度が勝ります。ただしどの基盤でも、アプリの認可ロジックと環境変数の管理は利用者側の責任として残る点は共通です。基盤選定でセキュリティの優劣を語るより、自社が負う責任範囲を運用できるかで選ぶべきです。

Vercelを安全に運用するためのチェックリスト

新規プロジェクトの立ち上げ時と定期点検で確認する項目を、優先度順にまとめます。

• Next.jsを修正版（14.2.25 / 15.2.3以降など）へ更新し、認可をミドルウェアだけに依存させない。
• 機密値にNEXT_PUBLIC_を付けない。クライアントに出る変数とサーバー専用の変数を棚卸しする。
• プレビューデプロイにDeployment Protection（認証/パスワード）を有効化する。
• Vercel FirewallのWAFでmanaged ruleset（OWASP）を有効化し、必要に応じてレート制限ルールを追加する。
• SAML SSO（対応プラン）で認証を一元化し、アクセストークンにスコープと有効期限を設定する。
• 依存関係をlockfileで固定し、Dependabot等で監査する。ビルドで参照する環境変数を最小化する。
• Audit Logsの監視対象（トークン発行・権限変更・環境変数更新）を決め、四半期ごとに権限とトークンを棚卸しする。
• 侵害時のデプロイ停止・トークン失効の手順書を用意し、脆弱性の深刻度はCVSSスコアの見方で優先度を判断する。

よくある質問

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

プラットフォーム層は、全プラン無料のDDoS Mitigationや標準WAF、環境変数の暗号化など強固です。一方でアプリの認可漏れや環境変数の設定ミスは利用者の責任範囲で、実際の事故の多くはこちら側で起きます。基盤の安全性とアプリの安全性を分けて考える必要があります。

Vercel自体がハッキングされて情報漏洩することはありますか？

「vercel 漏洩」で語られる事例の大半は、Vercel基盤そのものの侵害ではなく、NEXT_PUBLIC_環境変数への機密混入や認証なしプレビューデプロイなど、利用者側の設定に起因します。まず自社の環境変数と公開範囲の設定を点検するのが先決です。

CVE-2025-29927にはどう対応すればよいですか？

Next.jsを12.3.5・13.5.9・14.2.25・15.2.3のいずれか以降に更新するのが確実です。即時更新が難しい場合は、プロキシ層で外部から来るx-middleware-subrequestヘッダーを削除して緩和し、認証・認可をミドルウェアだけに委ねない設計へ見直します。

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

DDoS Mitigationは全プランで無料・自動発動です。さらにWAFで拒否・チャレンジ・レート制限したトラフィックはCDNリクエスト等の課金対象から除外されるため、防御によって課金が跳ね上がらない設計になっています。

ボット対策のBotIDとは何ですか？

BotIDはVercelのボット管理機能で、CAPTCHAやAPIキーを使わずにリクエスト信号を解析し、なりすましブラウザや自動化・リプレイ攻撃を検出します。ユーザー体験を損なわずに悪性ボットを抑えられるのが特徴です。

関連記事

• Shai-Hulud（シャイ・フルード）とは？npmサプライチェーン攻撃の全体像と対策
• Vercel（ヴァーセル）とは？料金・できること・他サービスとの違い
• VercelのHobbyプランとProプランの違いを徹底比較
• CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点