PHPの脆弱性「php2shell」を受けて、WordPressで運営しているサイトを別のCMSへ移すべきか、気になっている方もいると思います。

当社の考えは、今回の脆弱性だけを理由に、WordPressから急いで乗り換えるべきではないというものです。先に行うのは、PHPの修正版の適用、侵害の有無の調査、更新できない環境の公開範囲の制限です。CMSの移行先を決めるまで、これらの対応を待つことはできません。

そのうえで、記事を誰が編集するのか、必要な機能は何か、更新を続けられる体制があるかを比較します。この記事では、2026年10月22日時点の公表情報を基に、Webサイトを運営する事業者の判断材料を整理します。

今回の問題は、WordPressを動かすPHP本体にある

php2shellは、PHPのメモリ処理に関する2件の脆弱性を扱った調査の名称です。PHP公式のアドバイザリでは、条件が成立すると外部からコードを実行される問題として、OOMに関する脆弱性とリクエスト間に残る状態に関する脆弱性が公表されています。

WordPressを動かす、PHP本体を確認する
WordPress
サイト・アプリ
WordPressなど
PHP
PHP本体
今回の更新対象
WordPress本体やプラグインの更新とは別に、サーバーで動くPHPの修正が必要です。
ロゴ：PHP © Colin Viebrock（CC BY-SA 4.0、形状・配色の変更なし）、WordPress®（WordPress Foundation）。

WordPressはPHPで動くCMSです。WordPressの画面上で更新を完了していても、サーバー側のPHPに修正が入っているとは限りません。調査を行ったCalifの報告には、WordPressに対するコード実行の検証も含まれています。ただし、攻撃の成立条件はPHPの実行方式や設定、アプリケーションの動作によって異なります。

「WordPressだからすべての環境で同じ攻撃が成立する」とも、「WordPressを最新版にしたから影響がない」とも判断できません。また、別のPHP製CMSへ移しても、未修正のPHPが動いていれば問題が残り得ます。詳しい影響範囲と更新先は、php2shellの概要と対応にまとめています。

サイト運営にどんな影響が考えられるか

PHP公式のアドバイザリは、Webワーカーの権限で認証なしのコード実行を確認したと説明しています。その権限で何にアクセスできるかによって、想定すべき被害は変わります。以下はこの権限を起点に考える調査対象であり、すべてのサイトで被害が発生したという意味ではありません。

確認する対象起こり得る影響
PHPから読める設定ファイルや秘密情報DB接続情報や外部APIのキーの取得
接続先のデータベース権限の範囲内での顧客情報・投稿・会員情報の読み取りや変更
書き込み可能なファイルページ改ざん、不正なファイルの設置
サーバーの処理や接続先サービス停止、付与されたクラウド権限などを使う追加の不正操作

パッチを適用しても、それ以前に持ち出された情報が戻るわけではありません。不審な変更やアクセスがある場合は、情報漏洩時の初動と原因の切り分けに沿って、封じ込め・証拠保全・調査を並行して進めます。

移行を検討する前に、いまのサイトを保護する

まず、契約しているホスティング事業者または保守担当へ、次の事項を確認してください。自社管理の場合は、社内で実行する担当者と完了条件を決めます。

  1. Webサイトで動くPHPを確認する。 管理画面の表示やサーバー構成を調べ、修正が適用されているか確認します。SSHで実行するPHPと、Webのリクエストを処理するPHPが同じとは限りません。
  2. 修正版を反映する。 必要な再起動や再デプロイ、古い実行環境の停止まで確認します。OSベンダーが修正を取り込む場合は、数字の比較だけでなく、そのパッケージの対応情報を確認します。
  3. 主要な機能と侵害の兆候を確認する。 ログイン、投稿、フォーム、決済などを検証し、ログやファイルの変化を調べます。侵害が疑われる場合は、証拠を保全しながら被害を止める判断を優先します。
  4. すぐ修正できない部分の公開を制限する。 事業者・保守担当と、外部からの到達を制限する方法や一時停止を検討します。移行完了まで未修正の環境を公開し続けないようにします。

レンタルサーバー、VPS、Dockerなどで手順は異なります。サービス別の対応から、自社の管理方法に近いものを確認してください。テーマやプラグインに互換性の問題がある場合も、まず更新可能にする方法と一時的な保護を検討します。

WordPressを続ける場合と、乗り換える場合の比較

移行の価値は、どの運用負担を減らせるかで考えます。「WordPressをやめる」とだけ決めても、管理する対象や担当者が決まるわけではありません。

以下は構成を選ぶ際の比較です。製品ごとの機能や契約範囲により異なるため、候補が決まった段階で実際の編集・公開・復旧を試します。

選択肢メリットデメリット・残る管理
WordPressを継続し、保守やホスティングを見直す編集画面や既存機能を活かしやすく、移行作業を抑えられるPHP・本体・テーマ・プラグインの更新と互換性確認が必要。委託しても担当範囲の確認は残る
公開ページを静的ファイルで配信する構成へ移す公開リクエストごとにPHPを実行する部分をなくせる。必要な機能だけに構成を絞れるプレビュー・公開手順の整備が必要。フォーム・検索・会員機能は別途設計し、ビルド環境も管理する
SaaS型CMSやサイト作成サービスへ移す契約範囲に応じ、OSや実行環境の更新を提供元に任せられる月額費用、機能制約、データの取り出し方を確認。管理者権限・APIキー・外部連携は自社でも管理する
別のCMSや独自のWebアプリへ移す業務に合わせた機能やシステム連携を設計できる開発・保守の負担が増える場合がある。移行先の依存関係や実行環境にも更新が必要

WordPressを使い続けることにも、慣れた編集画面や機能を維持できる利点があります。更新が滞る原因が「担当者がいない」「保守契約にPHPの更新が含まれていない」ことであれば、CMSの変更より、担当と契約範囲を整えるほうが直接的な改善になる場合があります。

WordPress公式のセキュリティガイドも、ホスティング事業者とサイト所有者の責任範囲を理解すること、更新やバックアップなどを継続することを説明しています。マネージドサービスを選ぶ場合も、どこまで任せられるかを確認します。

ヘッドレスWordPressにすれば解決するのか

ヘッドレス構成は、WordPressを記事の管理側に残し、表示側を別の技術で作る方法です。WordPress REST APIを使うと、別のアプリケーションから記事などのデータを扱えます。

この構成を選んでも、記事を管理するWordPressとPHPは動き続けます。表示側を静的にしただけで、管理側のPHPの修正が不要になるわけではありません。公開するAPI、管理画面への到達方法、更新担当まで設計して初めて、攻撃を受ける入口を減らせます。

急な移行で見落としやすい、編集・機能・検索流入の影響

記事を移せても、業務がそのまま動くとは限らない

WordPressの標準エクスポートは、投稿、固定ページ、カスタムフィールドなどをWXRというXML形式で書き出します。そのデータを取り込めることと、移行先で同じ表示・機能を再現できることは別に確認します。

確認する業務・機能移行前に試すこと
記事の編集と承認担当者が見出し・画像・下書き・予約公開を扱えるか
既存記事の表示ブロック、ショートコード、埋め込み、画像やPDFが正しく表示されるか
問い合わせと外部連携フォームの送信・通知・CRM登録・計測まで動くか
会員・EC認証、権限、購入履歴、注文・決済に必要なデータを引き継げるか
復旧と保守誰が更新し、障害時にどこまで戻せるか

必要な機能を移行後に気づいて作り直すと、費用だけでなく、記事の公開や問い合わせの受付にも影響します。代表的な記事とフォームを移した検証環境で、実際の担当者が操作して判断するのがよいでしょう。

検索流入があるサイトは、URLと公開後の確認を計画する

CMSを変えるときも、既存のURLを維持できるか確認します。変更が必要なら、旧URLと新URLの対応を作り、適切なリダイレクト、内部リンク、canonical、サイトマップを設定します。記事だけでなく、画像やPDFのリンクも対象です。

Googleのサイト移転ガイドは、一度に行う変更を抑えることや、URLの対応付け、移転後のトラフィックの観察を案内しています。大きな変更では検索順位が一時的に変動する場合もあります。「移行すれば必ず順位が落ちる」「必ず上がる」とは言えません。

現在の流入ページ、問い合わせにつながるページ、画像・資料のURLを把握したうえで切り替えます。脆弱性への初動対応と、CMS・デザイン・URLの全面変更を一度に進めると、問題が起きたときの切り分けも難しくなります。

DNSを切り替えても、古いWordPressが停止するとは限らない

新サイトへ切り替えた後も、旧サーバーのIPアドレスや別のホスト名から、古いWordPressへ到達できることがあります。移行計画には旧環境の公開停止、必要な証拠・バックアップの保全、不要なアカウントやAPIキーの廃止まで含めます。

リダイレクトを残すために、未修正のWordPressを動かし続ける必要はありません。旧URLへの転送は、安全に管理できるWebサーバーや配信基盤で行う方法もあります。

それでも乗り換えを検討したほうがよい場合

今回を機に、構成を見直す価値はあります。たとえば、次の状況が続いている場合です。

  • 保守が止まったテーマやプラグインがあり、PHPやWordPressの更新を妨げている
  • ほぼ更新しない紹介ページが中心で、現在のCMSの機能を十分に使っていない
  • 編集・承認・外部システム連携など、必要な業務に現在の構成が合っていない
  • 更新や復旧を担う体制を確保できず、管理を任せる範囲を変えたい

この場合も、不要なプラグインの削除や代替、ホスティング・保守会社の変更で解決するかを比較します。初期費用だけでなく、毎月の保守、編集の手間、障害時の連絡先、将来の移行方法まで含めて選びます。

現在の環境を安全に運用できない場合は、公開制限や一時停止などの対応を急ぎます。 そのうえで、必要な機能を絞った暫定サイトと、長期的に使うCMSの選定を分けて進めることもできます。

wrenも、採用技術を決めた後の更新を続けている

wrenはad-cre.aiやKokage.aiを開発・運営し、自社でも日々ライブラリのバージョン管理と技術的な防御を行っています。当社のコーポレートサイトはNext.jsを使い、記事はMDXファイルとしてコードと一緒にGitで管理しています。

この構成でも、更新は必要です。依存関係をlockfileで管理し、CIでは固定した依存関係をインストールしています。問い合わせフォームではサーバー側で入力を検証し、確認メールに載せる自由入力をHTMLエスケープしています。自社サイトで実施している対策で具体的に紹介しています。

一方、MDXを使う方式には、Gitや公開手順を扱う必要があります。編集担当者が管理画面で記事を更新する業務なら、その操作を維持できるCMSに利点があります。当社と同じ技術を選ぶことより、担当者が無理なく更新を続けられるかを重視します。

まず修正し、乗り換えは運用を比較して決める

今回のphp2shellは、PHP本体への対応が必要な問題です。WordPressから急いで乗り換えることを結論にする前に、修正の反映、侵害の確認、更新担当と手順の見直しを進めてください。

安全を確保した後に、編集業務、必要な機能、保守体制、継続費用を比較します。移行で管理負担を減らせるなら計画して進め、WordPressを続ける場合も、更新できる体制を整えます。

安全を確保

PHPの修正・公開制限・侵害の確認

業務を確認

編集・フォーム・検索流入を整理

構成を比較

継続・保守変更・CMS移行を検証

運用を決める

担当・費用・更新・復旧を明確に

Fig. 01 — 緊急の保護と、長期的な構成の選定を分けて進めます。

誰が更新するのか、どの構成なら運用を続けられるかという相談は、SRE顧問の対応領域で扱っています。SRE顧問とは何かに、依頼できる内容と契約前の確認事項をまとめています。現在の構成と困っていることが分かれば、相談フォームからお知らせください。