Next.js、Astro、Nuxt、ヘッドレス WordPress — 2026年のセキュリティ

ヘッドレス化は攻撃対象を排除しなかった。移動させただけだ。2025～26年の記録が示すところはこうだ：React Server Components（CVE-2025-55182、認証なしのリモートコード実行、2025年12月3日公開）、Astro のサーバーアイランドと画像エンドポイント、CDN の背後にある Nuxt ペイロードキャッシング、npm パッケージ、そして依然として PHP を実行する WordPress バックエンド。フレームワークレベルのリスクのほとんどを除去するのは、サーバーランタイムを持たない完全に静的なエクスポートだけだ。ただし多くの「静的」サイトは実際には静的ではない。以下では、まずフレームワークごとにインシデント、次にシークレット、CSP、サプライチェーン、WordPress オリジンとエッジ制御を掲載し、最後に自分のスタックに適応させられる強化テーブルで終える。

「静的 = ハッキング不可」が真実ではなくなった理由

まず率直に言うと、ビルド出力がプレーン HTML、CSS、JS ファイルであり、CDN がそれらを提供する場合、攻撃対象となるフレームワークサーバーは存在しない。React Server Components エンドポイントはない。サーバーアクションはない。バイパスするべきミドルウェアもない。それは本当に小さい攻撃対象であり、昔の Jamstack のピッチに重みがあった理由はそこだ。

だが 2026年に実際にデプロイされている大多数の Next.js、Astro、Nuxt プロジェクトを見てみよう。コンタクトフォーム用のサーバーアクション。クッキーをチェックするミドルウェア。画像最適化エンドポイント。パーソナライズされたヘッダー用のサーバーアイランド。ISR またはオンデマンド再検証。これらのそれぞれは、プロセスがリクエストをリッスンし、入力を解析し、環境変数を保持していることを意味する。それはサーバーだ。リポジトリには単にサーバーには見えないだけだ。

だから問題は「このサイトはヘッドレスか？」ではない。「リクエスト時に何が実行されるか？」だ。3つの正直な答えがある：

• 何もない。純粋に静的な出力だ。リスクはビルドパイプラインと CMS にあり、フレームワークにはない。
• 小さく、既知のエンドポイントセット。画像最適化、フォームハンドラー。パッチを当て、制限し、レート制限する。
• フルアプリケーションランタイム。SSR、サーバーアクション、認証、データベースアクセス。それが何であるか、つまりウェブアプリとして扱う。

アーキテクチャ比較を WordPress と比較したことは他の場所で書いた（headless vs WordPress security 参照）ため、ここでは繰り返さない。このポストはインシデント記録とその対応だ。

Next.js：React2Shell、サーバーアクション、プロキシトラップ

React2Shell

CVE-2025-55182（React）と CVE-2025-66478（Next.js）は 2025年12月3日に公開された。クリティカル。React Server Components への細工されたリクエストを通じた認証なしのリモートコード実行。Vercel の変更ログによれば、影響を受ける Next.js バージョンは >=14.3.0-canary.77、15.x、16.x（App Router 使用）だ。パッチされた Next.js リリースは 15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7、16.0.7 であり、React は 19.0.1、19.1.2、19.2.1 で修正された。

スピードがここで重要だ。Datadog Security Labs は公開エクスプロイトコードと 2025年12月5日までのアクティブな悪用試行を報告した。2日だ。パッチプロセスが月1回のリズムで実行される場合、そのギャップが曝露期間だ。

Vercel は npx fix-react2shell-next で影響を受けたバージョンをバンプするために提供する。どのルートを取るにせよ、リンクされたアドバイザリで自分のリリースラインの現在のパッチバージョンを確認してほしい。フォローアップでターゲットが変更されたためだ。

12月11日のフォローアップ

2025年12月11日、Next.jsチームは2つの追加の脆弱性をカバーする別のセキュリティ更新をリリースしました：

• CVE-2025-55184、サービス拒否（高）。App Routerのリクエストがサーバーをハングさせる可能性があります。最初の修正は不完全で、完全な修正はCVE-2025-67779として追跡されています。
• CVE-2025-55183、ソースコード露出（中）。細工されたリクエストにより、Server Functionが他のServer Functionのコンパイル済みソースを返すことができます。ハードコードされたものはすべて漏洩します。実行時に環境から読み込まれたシークレットは漏洩しません。

Pages Routerは影響を受けず、ワークアラウンドはありません。アップグレードしてください。修正版には14.2.35、15.5.9、16.0.10が含まれます（アドバイザリでご自身のラインを確認してください）。

サーバーアクションのレッスンは明確です。サーバーアクションは、より便利な呼び出し規則を持つパブリックHTTPエンドポイントです。その引数を悪意のある入力として扱ってください。その中で認可を実行してください。そして、サーバー関数が到達できるファイルにシークレットを文字列リテラルとして書き込まないでください。

ミドルウェアは認可の境界ではない

CVE-2025-29927、2025年3月21日に公開（CVSS 9.1）、細工されたx-middleware-subrequestヘッダーでミドルウェアを完全にスキップできます。唯一の認証チェックがミドルウェアに存在した場合、それはバイパスされました。Datadogの記事は12.3.5、13.5.9、14.2.25、15.2.3の修正をリストしています。Vercelホスト型アプリはインフラストラクチャレベルで保護されていました。セルフホスト型アプリはパッチが当たるまで露出していました。

Next.js 16はmiddleware.tsをproxy.tsに名前変更し、デフォルトではNode.jsランタイムで実行します。middleware.tsは非推奨です。この名前変更は正直だと思います。プロキシはアプリの前にあります。リダイレクト、リライト、ヘッダーの追加ができます。これは見知らぬ人とあなたのデータの間の唯一のものであるべきではありません。

実際のチェックを配置する場所：

1. データレイヤーで、行を返すクエリの横。
2. 何かを変更するすべてのサーバーアクションで。
3. ルートハンドラーで、ルートごとに。
4. プロキシでは、ログアウトしたユーザーの便利なリダイレクトとしてのみ、ロックとしてではなく。

proxy.tsを削除するとデータが露出する場合、あなたの認可は間違った場所にあります。

Astro：サーバーアイランド、イメージエンドポイント、ミドルウェアパス

Astroのデフォルトは静的で、それは強みです。しかし3つの2025年の勧告はランタイムを追加する部分に当たりました。

サーバーアイランドXSS。CVE-2025-64764、2025年11月19日公開、高（CVSS 7.1）。サーバーアイランドエンドポイントのslotsパラメータを通じた反射型XSS。アイランドコンポーネントがスロットを使用しない場合でも、サーバーアイランドを使用していたすべてのアプリに影響を与えました。バージョン5.15.6以前が影響を受けました。5.15.8がそれをパッチしました。詳細はGitHub勧告に記載されています。

イメージエンドポイントSSRF。CVE-2025-58179は@astrojs/cloudflareアダプター（11.0.3～12.6.5）に影響を与えました。output 'server'とデフォルトのコンパイルイメージサービスで、イメージエンドポイントはURLを検証しませんでした。これはサーバーサイドリクエストフォージェリーを有効にしました。SSRFは厄介です。なぜなら、サーバーはネットワーク内からリクエストを実行し、メタデータサービスまたは内部APIに到達する可能性があるためです。

ミドルウェアパスバイパス。Astro 5.15.8はダブルエンコードURL（CVE-2025-64765）を使用したパス正規化バイパスも修正しました。Next.jsヘッダートリックと同じ一族の間違い：URLが特定の方法に見えることに依存する認可。

withastro/astroセキュリティ勧告で正確なバージョン範囲を確認してから、影響を受けているかどうかを決定してください。指摘できない境界について推測するつもりはありません。

Astro 6とビルトインCSP

Astro 6はsecurity.cspの下にCSP APIを搭載しています。Astro 6ベータアナウンスメントによると、バンドルされたスクリプトとスタイルをハッシュ化し（デフォルトではSHA-256）、ビルドとプレビューで機能しますがdevでは機能しません。最後の点は人々を引っかけます：astro devの下では問題ないように見えるページは、ポリシーが本番ビルドに適用されるとき破損する可能性があります。常にビルト出力をテストしてください。

クライアント向けに Astro サイトを構築している場合で、セキュリティ対策を最初から組み込みたいなら、当社の Astro 開発ページでプロジェクトの立ち上げ方を説明しています。

Nuxt: ペイロードキャッシュポイズニングと `runtimeConfig.public` の露出

CVE-2025-27415

2025年3月19日に公開。深刻度は高、CVSS スコアは 7.5、影響は可用性です。条件は、キャッシュキーにクエリ文字列を含めない CDN の背後で Nuxt を実行している場合です。攻撃者は /?/_payload.json のようなリクエストを送ります。Nuxt はそのリクエストに対して JSON をレンダリングします。CDN はそれを / のキーの下にキャッシュし、すべてのアクセス者にその JSON を提供します。キャッシュの有効期限ごとに繰り返し可能です。影響を受けるバージョン: 3.0.0 から 3.16.0 未満。3.16.0 で修正済み（アドバイザリ）。

このバグがどのような種類のものかに注目してください。Nuxt のコードと CDN の設定は、それぞれ単独では正常に動作しました。しかし一緒に使うと、ホームページが破壊されました。そのため、学ぶべき教訓は「Nuxt をアップグレードする」を超えています。CDN キャッシュキー設定はアプリケーションセキュリティの一部です。チームの誰かがそれを管理する責任を持つべきで、ダッシュボードのデフォルト設定に任せるのではなく、文書に記録しておくべきです。

ステージング環境での簡単なチェック方法は、ステージングドメインだけを使って行います。奇妙なクエリ文字列を付けてページをリクエストし、何が返されるかを確認します。その後、クリーンな URL をリクエストして、それが依然として HTML であることを確認します。キャッシュレイヤーがパフォーマンスのためにクエリ文字列を無視する設定になっている場合、フレームワークの内部ルートがその設定から除外されていることを確認してください。

`runtimeConfig.public` が露出するもの

Nuxt は runtimeConfig を private キー（サーバーのみ）と runtimeConfig.public（ブラウザに送信）に分けています。名前自体が警告です。public の下にあるものはすべて、ページペイロードに入り、誰でも読むことができます。Stripe の公開可能キーをそこに置くのは問題ありません。CMS の管理トークンをそこに置いたら、それは公開してしまったことになります。

3つのフレームワーク全体でのシークレットと環境変数

すべてのフレームワークにはプレフィックスルールがあり、プレフィックスは「ブラウザに送信する」という意味です。

詳細はフレームワークごとに異なるため、各フレームワークのドキュメントをお読みください（Next.js は NEXT_PUBLIC_ の値をビルド時にバンドルにインライン化するため、1つを変更するとリビルドが必要になるということも意味します）。原則は変わりません。変数がパブリックプレフィックスを持つ場合、それがホームページに印刷されているものとして扱ってください。

3つの習慣がほとんどのミスをキャッチします。

• パブリックプレフィックスの背後に、書き込み可能なトークンを「一時的に」であっても置かないでください。
• デプロイする前に、ビルド済みの出力（.next/static、dist/、.output/public）でトークンの断片を検索してください。
• フロントエンドに対して、CMS の読み取り専用でスコープを限定した認証情報を与えてください。エディターが使うものとは別にしてください。

CVE-2025-55183 の教訓

That Next.js source-exposure bug is a neat illustration. It could return compiled source of Server Functions. Secrets read from the environment at runtime weren't in that source. Secrets pasted into the code as literals were. The framework bug was the framework's fault; the leaked API key was ours. After patching, if a literal secret ever lived in a server function on an affected version, assume it was readable and rotate it. Moving it to an env var is the fix for next time, not for the past.

Jamstackサイト向けセキュリティヘッダーとCSP

スタティックホスティングではリポジトリにサーバー設定ファイルがないため、ヘッダーを忘れやすくなります。しかし、ヘッダーはXSS対策（上記のAstroサーバーアイランドの問題のような）に対する安価で実質的な保護を得られる場所です。

すべてのサイトに配信するベースラインセット：Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options: nosniff、Referrer-Policy、および frame-ancestors（CSP内）または X-Frame-Options。

Nonceまたはハッシュ、`unsafe-inline`ではなく

スクリプトに'unsafe-inline'を許可するCSPはXSS対策としてほぼ役に立ちません。実質的な選択肢は2つです：

• ハッシュ。各インラインスクリプトとスタイルのビルド時SHA-256ハッシュ。コンテンツがリクエストごとに変わらないため、スタティック出力に適しています。これはAstro 6のsecurity.cspが自動化するものです。
• Nonce。リクエストごとに生成されるランダム値で、ヘッダーと各スクリプトタグに追加されます。生成にサーバーまたはエッジ関数が必要なため、スタティックファイルよりもSSRに適しています。Next.jsはそのプロキシレイヤーを使用したnonceパターンをドキュメント化しています。

レンダリングモデルで選択します。純粋なスタティック：ハッシュ。動的：nonce。

ディレクティブごとに、すべてのサードパーティオリジンをリストアップ

これが面倒なところであり、ポリシーが失敗する場所です。アナリティクス、タグマネージャー、フォント、ビデオ埋め込み、チャットウィジェット、フォームプロバイダー、CMSの画像ホスト。それぞれが正しいディレクティブ（script-src、connect-src、img-src、font-src、frame-src）の下にリストされる必要があります。1つのオリジンからスクリプトをロードして別のオリジンのAPIを呼び出すウィジェットは両方が必要です。

ヘッダーの例です。形を示すだけです（実際のオリジンに置き換え、nonceはリクエストごとに生成される必要があります）：

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM' https://analytics.example.com; connect-src 'self' https://api.example.com; img-src 'self' data: https://cms.example.com; frame-ancestors 'none'; base-uri 'self'

Content-Security-Policy-Report-Only で開始し、1～2週間違反を収集して、リストを修正してから強制します。そしてサードパーティオリジンと誰がそれぞれをリクエストしたかの短いインベントリファイルを保持します。6か月後、チャットウィジェットがなぜ script-src にあるのか誰も覚えていません。

npm供給チェーン：chalk、debug、Shai-Hulud

フレームワークがパッチされてサーバーがロックダウンされていても、依存関係があなたの週を台無しにすることができます。2025年の2つのイベントがどのように起こるかを示しています。

chalk とdebug、2025年9月8日。メンテナがnpmjs.helpからの偽の2FAリセットメールでフィッシングされました。攻撃者はchalkとdebugを含む約18パッケージの悪意のあるリリースを公開しました。ペイロードはブラウザバンドルからcrypto-walletアクティビティを盗むことを目的としていました。Upwindの分析によると、パッケージは約2～2.5時間以内に削除されました。2時間は短いです。しかし、そのウィンドウで新しいバージョンを解決したCIジョブはペイロードを本番環境に配信しました。

Shai-Hulud、2025年9月。2025年9月23日のCISAアラートは、500以上のnpmパッケージを侵害した自己複製ワームについて説明しています。GitHubトークンとクラウドキー（AWS、GCP、Azure）を収集し、Shai-Huludという名前のパブリックGitHubリポジトリに公開し、被害者自身のnpm認証情報を使用して他のパッケージに再発行しました。2025年11月の第2波は、およそ796パッケージに影響を与えたと報じられています（二次報告なので、数字は報告されたものとして扱います）。

それらを封じ込めたはずのコントロール

どちらのインシデントも巧妙なエクスプロイトを必要としませんでした。どちらも「latest」への自動的な信頼に頼っていました。したがって：

1. lockfileをコミットして `npm ci` でインストールします。これはlockfileが言うとおり正確にインストールし、package.jsonが矛盾する場合は失敗します。毒されたリリースへのサイレント漂流はありません。
2. クールダウンを追加します。公開された時間にバージョンを採用しないでください。pnpmは最小リリース年齢設定をドキュメント化しています。1日の遅延でさえchalk/debugウィンドウを完全に回避したはずです。
3. インストールスクリプトを無効にしてください。Shai-Huludのようなワームはライフサイクルスクリプトを通じて実行されます。例の .npmrc 行：ignore-scripts=true。その後、実際にビルドステップが必要なパッケージをホワイトリスト化します。
4. CI トークンのスコープを設定します。ビルドジョブはほとんど公開権やブロードなクラウドキーを必要としません。短命で最小権限の認証情報は、盗まれたトークンがほぼ何も買えないことを意味します。
5. CISAのアドバイスに従ってください。ロックファイル（ネストされた依存関係を含む）の確認、アーティファクトキャッシュのチェック、既知の安全なバージョンへのピン止め、開発者認証情報のローテーション、npmとGitHubでのフィッシング耐性MFAの要求、およびシークレットスキャン、Dependabot、ブランチ保護の有効化を実施します。

同じ疑念は、開発環境に導入されているAIツールにも当てはまります。Claude Codeスキル、プラグイン、MCPサーバーを検証する方法を執筆した理由は、これらがサードパーティコードがあなたのトークンに接近するもう一つの手段だからです。

Headless WordPress：テーマを隠すことはPHPを隠さない

ここがチームを驚かせる部分です。Headlessに移行するとパブリックテーマレイヤーが削除されます。WordPressは削除されません。PHPアプリケーション、データベース、REST API、wp-adminはすべて依然として存在し、通常はパブリックホスト名上にあります。なぜなら、フロントエンドがそれらに到達する必要があるからです。

wp2shell

2026年の例は明快です。CVE-2026-63030（REST APIバッチ経路混乱、CVSS 9.8）がCVE-2026-60137（WP_Queryのauthor__not_inでのSQLインジェクション、CVSS 5.9）と連鎖して、WordPress 6.9.0～7.0.1の認証なしリモートコード実行を実現します。デフォルトインストール。プラグイン不要。エントリーポイントは/wp-json/batch/v1です。修正は2026年7月17日に7.0.2、6.9.5、6.8.6で提供されました。TenableのFAQに詳細が記載されています。

攻撃者は素早かった。Patchstackは7.0.2リリースの約90分後に最初の悪用試行を検出し、1,500以上のIPからの65,000以上の試行をブロックし、97%がバッチエンドポイントを対象としていることを確認しました。ファイアウォールに依存する人にとって重要なもう一つの詳細：URL限定のWAFルールでは不十分です。WordPressはPOSTボディ内のrest_routeを受け入れるためです。パスの/wp-json/batch/v1に一致するルールはそれを見落とします。

バックエンドのロックダウン

目標：WordPress オリジンを、修正されるまで待つだけでなく、見知らぬ人が到達できないようにします。

• 可能な限りオリジンをパブリックインターネットから隔離します。IPアローリスト、認証プロキシ、またはフロントエンドとCMS間のプライベートネットワークを使用します。静的サイト用にビルド時にコンテンツを取得する場合、オリジンはビルドランナーとのみ通信する必要があります。
• フロントエンドが使用するフィールドのみを公開します。REST応答とGraphQLスキーマをトリミングします。少ないデータ出力、悪用される余地が少ない。
• 未使用のルート（バッチエンドポイントを含む）を無効化します。スタック内の何も呼び出さない場合。
• WPGraphQLを制限します。スキーマの公開イントロスペクションと認証なしクエリをオフにします。本当に必要でない限り。
• アプリケーションパスワードとプレビュートークンをスコープします。統合ごとに1つ、最小権限、統合終了時に取り消し。
• コア自動更新をオンのままにします。90分の悪用ウィンドウでは、手動週次パッチデーは間違ったペースです。

この部分を専門家に任せたい場合、弊社のWordPress セキュリティサービスがバックエンドのロックダウンと監視をカバーします。その周囲のアーキテクチャについては、Headless WordPress 2026ガイドと弊社のHeadless WordPress開発ページを参照してください。

ホスティングとエッジコントロール

プラットフォームによって保護される内容が異なります。仮定するのではなく、具体的な内容を知ることが重要です。CVE-2025-29927を例に：Vercelでホストされたアプリはインフラレベルで保護されましたが、自己ホストされたアプリはそうではありませんでした。これは管理対象プラットフォームの実際かつ文書化された利点です。NetlifyとCloudflareも同様にエッジに保護レイヤーを実行します（WAF機能、DDoS軽減、管理ルール、プランに応じて）。自己ホストは制御を与えますが、これらのレイヤーはあなたのTo-Doリストに追加されます。

正直な枠組み：エッジ保護は時間をもたらします。パッチを置き換えません。今日あるエクスプロイトパターンをブロックするプラットフォームルールは次のアドバイザリについて何も言いません。また、よく運用されたパッチパイプラインを備えた自己ホストセットアップは完全に健全です。

ホスト先がどこであれ設定すること：

• 本体を検査するWAFルール。パスだけでなく。wp2shellのrest_routeの詳細が覚えるべき例。
• フォームハンドラ、サーバーアクション、ログインルート、および負荷の高い処理をトリガーするエンドポイント上のレート制限。これはCVE-2025-55184のようなサービス拒否バグも軽減する。
• 画像の`remotePatterns`。Next.jsではimages.remotePatternsで、画像最適化ツールがフェッチするリモートホストを制限する。Astroには同等の画像ドメインとパターン設定がある。CMSホストのみを許可し、他は許可しない。オープンな画像プロキシはSSRFへの招待状。
• キャッシュキーの確認。Nuxtのインシデントから、CDNが何を無視するかを把握する。
• オリジン保護。アプリのオリジンがCDNまたはセットアップで許可されているプラットフォームからのみトラフィックを受け入れるようにして、攻撃者がエッジをスキップできないようにする。

Next.jsでデータベースを背後に構築している場合、Next.jsとSupabaseの開発ページではサーバー側のアクセス範囲を設定する方法を示している。

セキュリティ強化チェックリスト

スタックに合わせて調整する。以下で指摘されたすべてのインシデントは引用元から出ており、バージョン番号については（このテーブルを含む）いずれのテーブルも信頼するのではなく、リンク先の各アドバイザリで現在の修正版を確認する。

FAQ

Pages Router は2025年12月の Next.js 問題の影響を受けていますか?

CVE-2025-55183 (ソースコード露出) および CVE-2025-55184 (サービス拒否) の場合、Next.js アドバイザリは影響を受けるパスを App Router と Server Functions として説明し、Pages Router はソース露出の影響を受けないと述べています。それを「永遠に安全」と読まないでください。React2Shell も App Router の React Server Components をターゲットにしており、修正済みリリースを使用する必要があります。2025年12月のアドバイザリであなたのバージョン系列を確認してください。

パッチ適用後にシークレットをローテーションすべきでしょうか?

シークレットが影響を受けた Next.js バージョンのサーバー関数にハードコードされたことがある場合はそうです。コンパイル済みソースを返すバグのため、読まれた可能性があると想定してください。それをローテーションしてから、置換をランタイム環境変数に移動してください。環境からのみ読み取られたシークレットはそのソースに含まれていないため、露出の根拠がはるかに弱くなります。

すべてのチェンジログを読まずにアドバイザリを最新に保つにはどうすればよいですか?

依存するリポジトリ (Next.js, withastro/astro, Nuxt) の GitHub セキュリティアドバイザリを監視し、自分のリポジトリに対して Dependabot アラートをオンにしてください。パッチ適用を担当する人をそれらのフィードに登録し、誰も読まない共有インボックスには登録しないでください。WordPress コアについては、自動更新をオンに保ち、Patchstack などの脆弱性フィードを追加してください。

フロントエンドがビルド時のみにコンテンツをプルする場合、wp-admin をパブリックのままにしておけますか?

できますが、すべきではありません。フロントエンドがビルド時のみにオリジンが必要な場合、全員に公開する理由はありません。ビルドランナーとエディターの IP をアローリストに登録するか、認証プロキシを前に配置してください。IP が変わるエディターが通常の不満で、シングルサインオン付きプロキシがそれを解決します。

パッチ速度とキャッシュキー設定は、チームが最も頻繁に間違える2つのこと：Next.js と WordPress の悪用は開示から数日または数時間以内に到着し、Nuxt バグは CDN がクエリ文字列を無視したことのみが理由で存在しました。リクエスト時に実際に実行されるもの、プロキシではなくデータレイヤーで認可、WordPress オリジンをオープンインターネットから遠ざけることを確認してください。