（2026年8月6日 追記）
2026年8月6日時点で、本脆弱性の影響を受けるバージョンのWordPressをご利用中のドメインを除き、
REST APIのバッチエンドポイント（/wp-json/batch/v1）への通信遮断を解除いたしました。
遮断が継続しているドメインにつきましては、WordPress本体のアップデートをご対応のうえ、
お手数ですが解除をご希望のドメイン名を添えて、弊社サポートまでお問い合わせください。
アップデートの完了を確認のうえ、個別に遮断を解除いたします。

https://www.xserver.ne.jp/news_detail.php?view_id=18963

エックスサーバーで急にウィジェットが保存できなくなった？原因はセキュリティ対策

WordPressサイトを運営、あるいはクライアントのサイトを保守しているフリーランスの皆様、ここ最近「ウィジェットの設定を変更したのに保存できない」「更新ボタンを押しても反応しない、またはエラーになる」といったトラブルに直面していませんか？

この現象は、特にエックスサーバー（Xserver）を利用している環境で顕著に発生しています。実はこれ、WordPressのシステムバグではなく、サーバー側で実施された緊急のセキュリティ対策（通信遮断）が原因です。

WordPress制作に15年以上携わってきたWebデザイナーの視点から、このトラブルが発生している背景（脆弱性「wp2shell」について）と、クライアントワークでもすぐに使える具体的な迂回策・対処法を分かりやすく解説します。

トラブルの背景：緊急の脆弱性「wp2shell」の公表とサーバー側の対応

まずは、なぜこのような制限がかけられたのか、一次情報をもとに時系列で整理します。クライアントに状況を説明する際の説明資料としてもご活用ください。

1. WordPressの緊急脆弱性「wp2shell」が公表される

2026年7月17日、WordPressのコア（本体）における重大な脆弱性「wp2shell」が公表されました。この脆弱性は、悪意のある第三者がWordPressサイトに対して不正な操作を実行できてしまう恐れがある極めて危険度の高いものです。詳細な技術検証や背景については、セキュリティ企業による以下の解説記事が参考になります。

2. エックスサーバーがREST APIの特定エンドポイントを通信遮断

この緊急事態を受け、国内大手のレンタルサーバーであるエックスサーバーは、迅速な防御措置を講じました。脆弱性が公表されたわずか2日後の2026年7月19日、攻撃経路となる特定の通信をサーバー全体で遮断する対応を実施したのです。

エックスサーバー公式の障害・メンテナンス情報では、以下のようにアナウンスされています。

https://www.xserver.ne.jp/news_detail.php?view_id=18963

引用「対象サーバーにおいて本脆弱性の攻撃経路となるREST APIのバッチエンドポイント（/wp-json/batch/v1）への通信を遮断する対応を実施いたしました。」

この「REST APIのバッチエンドポイント」は、複数のAPIリクエストを1回にまとめて送信・処理するための仕組み（一括処理用）です。サーバー側でこの通信が遮断されたことにより、同エンドポイントに依存しているWordPressの機能が動作しなくなりました。

なぜウィジェットの変更・保存ができなくなるのか？

WordPress 5.8以降、ウィジェット管理画面は「ブロックエディター（Gutenberg）」をベースにした新しいUIへと変更されました。この新しいウィジェット画面では、ブロックの配置や設定変更を保存する際、裏側で先述の「REST APIのバッチエンドポイント（/wp-json/batch/v1）」を利用してデータを送信しています。

つまり、以下のような流れでトラブルが発生しています。

• ユーザー：ウィジェット画面でテキストやリンクを変更し、「更新」ボタンを押す。
• WordPress：変更データを /wp-json/batch/v1 経由でサーバーに送信しようとする。
• エックスサーバー：脆弱性対策のため、該当の通信を「遮断（ブロック）」する。
• 結果：通信が成立せず、画面上で「保存できない」「エラーが発生しました」と表示される。

この影響はウィジェットの保存だけでなく、同様のバッチエンドポイントを利用している一部のプラグイン（多機能型プラグインや外部サービス連携ツールなど）の動作不良にも繋がっています。

現在の公式対応状況（2026年8月6日時点）

エックスサーバー側では、2026年7月22日に以下の追記を行っています。

引用「（2026年7月22日 追記）
batch v1 の REST API を利用したプラグイン・テーマ・外部サービス連携・独自開発機能をご利用のお客様で、本対策により機能に影響が生じている場合は、個別に制限の解除を検討いたします。お手数ですが、解除をご希望のドメイン名を添えて、弊社サポートまでお問い合わせください。」

2026年8月6日現在、セキュリティ上の観点から、サーバー全体での一律の制限解除は行われていません。どうしても元の仕様のまま利用したい場合は、エックスサーバーのサポート窓口へ個別に問い合わせて制限を解除してもらう必要があります。

しかし、問い合わせから解除対応が完了するまでには時間がかかる場合があり、急ぎの修正対応には向いていません。また、セキュリティの防御壁を一部取り払うことになるため、慎重な判断が求められます。

緊急時の迂回策：クラシックウィジェット（Classic Widgets）への切り替え手順

「クライアントから今すぐウィジェットを修正してほしいと頼まれている」「問い合わせを待っていられない」という場合に有効な、確実かつ安全な迂回策をご紹介します。

それは、ウィジェットの編集画面を従来のクラシックウィジェット（旧エディター版）に戻す方法です。旧エディターは通信にバッチエンドポイント（batch/v1）を使用しないため、エックスサーバーの通信制限の影響を受けずに保存が可能になります。

方法1：functions.phpにコードを追加する

現在使用しているテーマの functions.php に、以下のコードを1行追加します。子テーマを使用している場合は、子テーマの functions.php に記述してください。

// ブロック版ウィジェットエディターを無効化（クラシックウィジェット化）
add_filter( 'use_widgets_block_editor', '__return_false' );

このフィルターフックを通すことで、ウィジェット画面が以前の使い慣れたデザインに戻り、問題なく編集・保存ができるようになります。

方法2：公式プラグイン「Classic Widgets」を導入する

コードの書き換えに不慣れな場合や、クライアント自身で対応してもらう場合は、WordPress公式が提供しているプラグイン「Classic Widgets」をインストール・有効化するだけで、全く同じ効果が得られます。コードを直接触らないため、より安全で手軽な方法です。

【注意点】クラシックウィジェットに戻す際のデメリット

この迂回策を採用する場合、以下の点に注意してください。

• ブロックエディター専用のウィジェットが使えなくなる：これまでブロックエディター形式で作成していたウィジェットエリアは、クラシック画面では「ブロック」という汎用的な項目に置き換わります。
• 編集画面の視覚性が下がる：内部的にはHTMLソースに近い形でコードが表示されるため、HTMLの知識がないクライアントにとっては「編集しづらい」「レイアウトが崩れそうで怖い」と感じる可能性があります。

そのため、この迂回策は「一時的な措置」として導入し、編集作業が終わった後はコードをコメントアウト（またはプラグインを無効化）して元の状態に戻す、といった運用が現実的です。

方法3：javascriptで一時的に上書き

私が対応したケースでは、ウィジェットに複数のブロック（複数カラム、リストなど）を使っていて、複雑になっていたので、一時的な対応としてjsで上書きしました。遮断が解放されたら、元のブロックエディタで修正予定です。

早期に修正する必要があったのと、私が管理しているサイトなので、修正も柔軟に対応できるので一時的な処置としてこの方法にしました。他に、テンプレートに直接書くという方法や、プラグインとして別の方法で実装することも可能です。

フリーランスとしては、問題に対して複数の解決手段を持っている事が重要で、状況によって手段を使い分けるスキルが必要ですね。

クライアントワークで慌てない！フリーランスWebデザイナーの推奨対応フロー

このようなサーバー起因の突発的な不具合が発生した際、クライアントワークを円滑に進めるための推奨対応フローを3つのステップでご紹介します。

• ステップ1：影響範囲の特定と一次回答
  クライアントから連絡を受けたら、まずは「ウィジェット保存時のみのエラーか」「他のプラグインに影響はないか」を素早く確認します。原因がサーバーのセキュリティ対策（wp2shell関連）であると判明した時点で、一次回答として「現在、サーバー側で緊急の防御措置が取られているため」と理由を添えて報告し、安心感を提供します。
• ステップ2：暫定対応（クラシック化）の提案と実施
  急ぎの更新が必要な場合は、前述の「Classic Widgets」プラグインの導入、または functions.php へのコード追加による暫定対応を提案します。この際、管理画面の見た目が一時的に変わるデメリットも合わせて説明し、合意を得た上で作業を行います。
• ステップ3：個別解除申請または恒久対策の検討
  ブロックエディターでの編集がどうしても必要な場合は、エックスサーバーのサポートへ個別解除の申請（ドメイン指定）を行います。申請から反映までは通常1〜3営業日ほどかかる場合があるため、その間の運用スケジュールをクライアントと調整します。

トラブル発生時に、原因の特定と同時に「今すぐできる暫定策」と「時間をかけて行う恒久策」の2つの選択肢を提示できると、フリーランスとしての信頼度は格段に向上します。技術的な解決力はもちろん、クライアントの不安を先回りして解消するコミュニケーションを意識していきましょう。