「PHPに重大な脆弱性が出た」と聞いて、自社のホームページも危ないのか、WordPressをやめるべきなのか迷っている方へ。先に行うのは、今のサーバーの修正確認です。CMSの移行先を決めるまで、更新を待つ必要はありません。
CMSは、管理画面から記事やページを更新する仕組みです。WordPressもその一つ。今回問題になったPHPは、その仕組みをサーバーで動かすために使われています。
この記事では、保守会社へ今日聞く内容と、WordPressを使い続けるか移るかの判断を分けます。移行を考える会社には、更新を担う体制に合わせた3案と、フォームや検索流入を守りながら移す手順を示します。
情報の基準日は2026年10月25日です。個々の会社のサーバーや被害の有無を診断した記事ではありません。
この記事で分かること
- 自社サイトで動くPHPの版と修正状況を、保守担当者に確認できます
- WordPressの更新継続と、体制に合うCMS移行先3案を比べられます
- URL・画像・フォームと復旧方法を、移行前に点検できます
2026年10月、PHPの
脆弱性問題の全貌とは？
2026年10月21日、PHPに、外部からプログラムを実行されるおそれのある重大な弱点が公表されました。「PHP2Shell」と呼ばれる2件で、識別番号はCVE-2026-109618とCVE-2026-109619です。
ホームページを店舗にたとえると、CMSは記事を並べ替える設備、PHPはその設備を動かす仕組みです。今回は、設備の使い方ではなく、動かす仕組み自体に欠陥が見つかったような状況です。
そのため、WordPressの管理画面で「最新版」と出ていても、サーバーのPHPまで修正済みとは限りません。WordPress以外でも、WebのリクエストをPHPで処理する環境は点検対象です。
PHP公式は、Apacheのmod_phpという構成で、ログイン前に攻撃できる例が実証されたと説明しています。ただし、使い方によって影響条件は異なります。「PHPを使っている」と「既に侵入された」は同じ意味ではありません。PHP公式の緊急告知を、保守担当者と照合してください。
攻撃は実際に起きて
いるのでしょうか？
攻撃の試行は観測されています。AWSは、攻撃を観測するためのおとり環境で、公表前の10月17日から関連する試行を捉え、公表後にも広い範囲で試行があったと報告しました。
一方、AWSの報告だけで、実際の企業システムへの攻撃成功や、自社の顧客情報流出まで分かったわけではありません。AWSの観測報告は、試行と被害確認を分けて読む必要があります。
今日、保守会社へ何を
聞けばよいですか？
「サーバーで実際に動くPHPの版」「修正の適用状況」「更新後の動作」「不審な記録」を聞いてください。専門知識がなくても、まず自社サイトのURLを伝えれば、点検の入口になります。
例えば、会社案内とブログはWordPress、お問い合わせは別サービスというサイトなら、WordPress側だけでなく、フォームを動かす側の担当も確かめます。契約しているサーバー会社と制作会社のどちらが更新するのか、窓口を決めることも必要です。
CMSを移した後も、更新と保守は必要です。
| 聞くこと | 回答に含めてほしい内容 | まだ分からない場合 |
|---|
どこでPHPを使っていますか？ | 公開サイト・管理画面・フォーム等の対象と担当者 | 制作会社とサーバー会社で担当範囲を照合 |
修正は適用済みですか？ | 稼働版、更新日時、ベンダー修正の有無 | 対象構成と更新予定、待つ間の対処を相談 |
更新後も使えますか？ | 再起動・再配備後の稼働版、記事表示、管理画面、フォーム等の試験結果 | 本番で使う機能を挙げて動作試験を依頼 |
侵入の疑いはありますか？ | ログ、不審なファイル変更、管理者追加等の調査状況 | ログを保全し、必要な調査の範囲を相談 |
問い合わせには、次の文を使えます。URLと保守対象は差し替え、パスワードや顧客情報は送らないでください。
当社サイト［URL］について、10月21日のPHP2Shellと、10月23日のPHP追加注意への該当有無を確認したいです。
公開側・管理画面・フォーム等で使うPHPの稼働版、修正適用日時、再起動後の確認結果を教えてください。
更新後の表示・ログイン・フォーム等の動作と、不審なアクセスやファイル変更の調査状況も知りたいです。
未対応の箇所があれば、担当者、対応予定、それまでの対処をご案内ください。
更新で不具合が心配な場合も、単に先送りするのではなく、保守担当者へバックアップと試験方法を相談します。不審な変更が見つかった場合は、通常の移行作業と分けて、ログやデータを保全しながら侵入調査を進めてください。
PHPは、どの版に直せば
よいのでしょうか？
10月21日の2件に対するPHP公式の修正版は、8.2.35、8.3.36、8.4.27、8.5.12です。PHP 8.5への移行だけが対応方法ではありません。利用中の系列や、OS・サーバー事業者が提供する修正に合わせて判断します。
OSなどの提供元が、見た目の版番号を維持したまま修正を取り込む場合もあります。古く見える番号だけで未対応と決めつけず、提供元の告知と適用記録を確かめてください。
PHP 8.1以前は通常のサポートを終了していますが、ベンダーの延長保守などの例外があります。今回、PHPチームは7.4・8.0・8.1向けの限定的なソース修正も案内しています。それを通常サポートの再開と考えず、担当者と今後の移行計画を相談する必要があります。
10月23日には、別のCVE-2026-115560に関する注意も出ました。セッションという利用者の状態を扱う仕組みで、特定の設定と実行時の切り替えが重なる場合の問題です。公式の追加注意を担当者に確認してもらい、10月21日の更新だけで全件解決と扱わないでください。
保守担当者へ伝える追加注意の条件
設定のsession.serialize_handlerがphp_binaryまたはphp_serializeで、実行時にini_set()でphpへ変更してからsession_start()を呼び、session upload progressも有効な場合です。PHP公式は該当構成でsession.upload_progress.enabled=0を案内しています。実行時に方式を変更しないアプリは、この機能を有効のまま利用できると説明しています。設定変更は互換性を含め担当者が判断してください。
補足：Node.jsやJavaも、同じ問題ですか？
PHP2Shell、Node.jsのBrotli解凍の問題、Javaで案内された証明書の問題は、区別して点検する必要があります。Node.jsの今回の更新にも、Javaと同じeMudhraの証明書問題への対処が含まれます。
PHPから別の言語へ変えても、更新対応が不要になるわけではありません。
| 実行環境 | 今回確認した問題 | 担当者に依頼すること |
|---|
Node.js | Brotli形式の圧縮データをnode:zlibで解凍する処理など。CVE-2026-111497は、攻撃者が渡すデータでメモリーが壊れるおそれ | 10月21日のセキュリティ更新と利用条件を照合。修正版22.23.4／24.22.1／26.12.1を確認 |
Java | 10月20日の定期更新に加え、10月21日にeMudhraの中間認証局の証明書を信頼する問題、CVE-2026-91403を告知 | 利用JDKと提供元の案内を照合。Oracleの10月23日案内にある追加措置も確認 |
Node.jsはJavaScriptをサーバーなどで動かす環境、JDKはJavaを実行・開発するためのソフトウェアです。Javaの今回の証明書問題は、通信相手等の信頼を確かめる仕組みに関わり、PHPと同じ攻撃方法ではありません。
根拠：Node.js公式発表、Oracleの注意喚起、Oracle JDKの追加対応案内。非技術者が設定だけをまねるのではなく、保守担当者に自社の該当性を調べてもらってください。
WordPressを
使い続けてもよいですか？
更新と動作試験を継続でき、今の機能が業務に合っていれば、使い続ける選択肢があります。今回の脆弱性だけで、すべてのWordPressサイトに移行が必要とは判断できません。
記事を複数人で更新している、予約や会員機能を使っているなど、今の仕組みを変える負担が大きい会社もあります。PHP、WordPress本体、テーマ、プラグインの更新担当と、障害時の連絡先を決められるかが判断の一つです。WordPress公式の運用上の対策も参考になります。
反対に、更新できる担当者がいない、使わないプラグインを残している、保守のたびに必要な機能が壊れるなら、構成と契約を見直す理由があります。その際はCMSの名前だけでなく、誰がどの部分を保守するのかまで比較します。
例えば、「会社案内とブログを月に数回更新し、お問い合わせを受ける」サイトと、「会員がログインし、予約や決済を行う」サイトでは、移す作業が違います。後者の機能を記事データと一緒に自動移行できるとは考えないでください。
会社サイトとブログの
移行先は、
どの3案を比べる？
保守をどこまでサービスへ任せたいか、誰が記事やシステムを更新するかで、次の3案を比べます。番号は安全性の順位を示していません。
| 移行案 | 向いている会社 | 選ぶ前に確かめること |
|---|
①管理型CMS：MovableType.netなど | 社内で記事を書きたいが、サーバー等の更新を自社で抱えたくない | 既存フォームや独自機能の再現、権限、必要プラン |
②Movable Type：静的公開中心の構成 | 記事更新を維持しながら、読者向けページをHTMLファイル中心にしたい | 管理側の保守、PHPを使う箇所、ライセンスと構築費 |
③EmDash | Astro・TypeScriptを扱う開発担当がおり、サイトを柔軟に設計したい | テーマと機能の作り直し、プラグインの実行方式、公開環境の費用 |
①サーバーの更新を
任せたいなら、管理型CMS
管理型CMSは、提供会社がサービスを動かすソフトウェアを保守する方式です。例えばMovableType.netは、サービスを支えるソフトウェアの更新とメンテナンスを提供元が行うと説明しています。
記事を書く担当者がいる一方、PHPやサーバーの更新を管理する人はいない会社では、最初に比べやすい案です。ただし、自社のアカウント、編集権限、公開する内容、外部連携まで全部任せられる意味ではありません。
MovableType.netはプラグインを導入する方式ではないため、WordPressの追加機能をそのまま移せるとは限りません。公式の安全性・運用範囲と、自社が必要な機能を照合してください。
業務に必須の独自機能を、そのサービスでは再現できない場合、この案は適しません。外部サービスとの組合せで補えるかも含めて判断します。
microCMSも管理をサービスへ任せる候補ですが、記事の管理と表示するサイトを分ける「ヘッドレスCMS」です。表示側は別途構築・保守が必要になるため、完成したサイト全体を任せる契約とは分けて比較します。
②読むページを静的に
したいなら、Movable Type
静的公開は、閲覧のたびにCMSでページを作る代わりに、事前に作ったHTMLファイルを配る方式です。会社案内や読み物中心のサイトなら、公開側の構成を整理する選択肢になります。
ただし、静的なページにしても、記事を書く管理画面やフォームの保守は残ります。Movable Typeでも、動的公開や一部プラグインにはPHPが使われます。
公開ページ・管理画面・フォームごとに、保守を誰が担うか決めます。
会員ログインや予約処理を、静的なページ配信だけで置き換えることはできません。それらが必要な会社は、別のサービスやプログラムも含めて設計する必要があります。
提供元は10月21日に影響を告知し、10月22日にMovable Typeクラウド版のPHP更新完了を発表しました。ソフトウェア版・AMI版は、利用者側でサーバーのPHPを更新するよう案内しています。「Movable Typeなら今回の問題と無関係」とは言えません。提供元の対応報告を、利用形態ごとに読んでください。
また、MovableType.netとMovable Typeは別の製品です。ソフトウェア版の通常ライセンスは132,000円（税込）と掲載されており、ライセンスだけでも10万円を超えます。ライセンスの公式案内と、構築・保守の見積もりを分けて確認します。
③開発担当がいるなら、EmDash
EmDashは、AstroというWebサイトを作る仕組みを基盤とするCMSです。PHPを前提にしたWordPressの構成から移る案になりますが、Astro・TypeScriptのコードや公開環境を保守できる担当者が必要です。
その開発・保守担当者を確保できない会社では、EmDashを優先候補にしません。記事を編集する担当者と、システムを更新する担当者の両方が必要です。
正式版1.0は公開済みで、10月15日には1.3の機能が案内されています。新しいCMSだから安全と決めるのではなく、必要な機能、更新方法、障害時の戻し方を試してから選びます。EmDash 1.3の公式紹介で、編集画面の使い勝手も検討できます。
WordPressの記事は、WXRという書き出しファイルや専用Exporterから取り込めます。ただし、テーマによるデザインやプラグインの機能まで、そのまま動くわけではありません。公式の移行手順に沿い、画像・URL・表示を試験します。
プラグインも実行方式が異なります。隔離した環境で動かすsandboxed方式と、CMSと同じプロセスで動くnative方式を一緒に扱わないでください。nativeには同じ隔離がありません。
Cloudflareで隔離環境を使う構成にはWorkers Paidなどの条件があり、ホスティングや使用量の費用も別に確認します。プラグイン方式、実行環境の公式条件を、開発担当者と確認してください。
フルスクラッチや、CMSを
使わないサイトはどうですか？
更新が少ない会社案内なら、CMSを使わずHTMLファイルを中心に公開する方法も候補です。ただし、ブログを誰がどう更新するか、フォームをどのサービスで運用するかは別に決めます。
既製品では満たせない独自の予約・会員機能が必要なら、必要な仕組みを個別に開発する「フルスクラッチ」も選択肢になります。会社案内とブログが中心なら、ログイン機能を含む記事管理画面まで自作する必要があるかを先に考えてください。
自作しても、使う部品の更新、動作試験、障害時の担当者は必要です。開発費だけでなく、引継ぎと継続保守まで担えるかを比べます。
記事・画像・フォームを
確認しながら移す手順は？
先に一部のページを非公開環境へ移し、URLと機能を照合してから切り替えます。記事の文字が読めるだけでは、移行完了ではありません。
1．今のサイトと
必要な機能を保全する
記事、画像、データベース、テーマ、設定をバックアップし、戻せるかを確かめます。検索で読まれているURL、フォームの通知先、会員・決済の有無、担当者と権限も一覧にします。
侵入の疑いがある場合は、不審なファイルまで新環境へコピーしないよう、調査と通常移行を分けます。削除や初期化で調査に必要な記録を失わないよう、先に専門の担当者へ相談してください。
2．代表ページとフォームを、
試験環境へ移す
例えば、会社概要、画像の多いブログ記事、お問い合わせフォームを一つずつ選びます。新しいCMSへ移した後、見出し・表・画像・添付ファイルが欠けないか、担当者が記事を更新できるかを試します。
フォームは画面だけでなく、許可を得た試験として、通知メールの到着、入力エラー、迷惑送信対策、個人情報の保管先まで確認します。会員や決済がある場合は、それぞれ独立した移行計画と試験が必要です。
3．URLと検索向けの
設定を照合する
できるだけ元のURLを保ちます。変更するURLは、古い住所から新しい住所へ案内する301リダイレクトを一件ずつ対応させます。全部をトップページへ飛ばす方法では、記事ごとの行き先が失われます。
タイトル、説明文、正規URLを示すcanonical、サイトマップ、検索エンジンに公開する設定も比較します。試験環境の非公開設定を本番へ残さないようにしてください。設定を引き継いでも、検索順位が変わらないとは保証できません。
4．切り替える条件と、
戻す条件を決める
誰が、いつ、どの公開先へ切り替えるかを決めます。その間に増えた記事や問い合わせをどう引き継ぐか、フォームが届かないなどの不具合で何を戻すかも先に合意します。
戻し先は、修正済みで保全した環境を用意します。脆弱な旧サーバーを、そのまま公開し続ける復旧方法にはしないでください。
5．公開後に、外から
見える状態を点検する
スマートフォンとパソコンで代表ページを開き、画像、メニュー、リンク、フォームの受信を確かめます。エラーや不審なアクセスの監視も続け、旧環境は必要な記録を保全したうえで公開停止やアクセス制限などを行います。
移行作業を外部へ頼むときは、開発支援の担当範囲と契約の比べ方も参考に、切り替え後の保守まで誰が持つかを決めてください。
更新・移行の支援費用は、
どこまで含まれますか？
まるっとAIでは、現状の調査、更新対応、CMS移行について、緊急のご相談にも対応します。初月の10万円（税抜）の支援範囲で対応できる場合がありますが、現状確認後に作業範囲と費用をご案内します。
初月に行う作業、別途必要な費用、継続する場合の契約条件は、着手前にご案内します。
例えば、まずサーバーの修正状況を調べ、更新と動作試験をどこまで行うかを決める相談と、会員・決済を含むサイト全体の移行では、必要な作業が異なります。侵入調査、デザイン再制作、外部サービス・ライセンス・ホスティングの費用などが別途必要になる場合もあります。
相談時は、サイトのURL、保守会社の有無、止められない機能、分かる範囲のCMS名をお知らせください。版番号が分からなくても、パスワードや顧客情報を送る必要はありません。開発費用の範囲を揃える考え方と同様、最初にどこまで調べ、何を直すかを合意します。
即日復旧や完全な安全を保証するものではありません。移行先選びで止まるより、今のサイトに修正が必要かを先に確かめるところからご相談ください。
自社サイトの更新・移行を相談する →
まとめ：移行を決める前に、
今のサーバーの修正確認を
PHPの脆弱性への対応と、CMSの移行は別の判断です。まず保守会社へ、稼働版と修正状況、更新後の動作、不審な記録の有無を問い合わせてください。
そのうえで、保守をサービスへ任せるなら管理型CMS、静的公開を中心にするならMovable Type、開発担当と柔軟に作るならEmDashを比べます。今のWordPressを更新しながら使う選択肢も残ります。
次の一歩は、自社サイトのURLを添えて、保守担当者へ修正状況を聞くことです。担当が分からない、更新と移行のどちらから頼めばよいか迷う場合は、まるっとAIへご相談ください。
無料で
