PHPに重大な脆弱性！ブロガーが今すぐやるべき対策とエックスサーバーの更新方法を解説！

「PHPに重大な脆弱性って…WordPressでブログを書いてる僕らも関係あるの！？(ﾟ-ﾟ；)」

はい、今回はサイト運営者も確認しておきたい問題です。記事や画像をコツコツ積み上げても、土台のプログラムに穴が残っていたら困りますよね。

そこで今回は、2026年10月に公表されたPHPの脆弱性と、エックスサーバーでのPHPバージョン変更手順、更新時の注意点、今後考えられる脅威まで、ブロガー向けに解説していきます〆(・∀・＠)

まず何をすればいい？ブログ運営者の優先順位

最初に結論を言うと、「WordPressを更新したからOK」「PHP 8系だからOK」だけでは、今回の確認は終わりません。

WordPressとPHPは別のソフトウェアです。PHPはWordPressを動かす土台なので、WordPress本体の更新とは別に、PHP側の修正が適用されているかを確認する必要があります。

また、レンタルサーバーでは「PHP本体に修正を入れる作業」と「自分のドメインで使うPHPの系統を選ぶ操作」が分かれていることがあります。僕らが管理画面で8.3を選んでも、その環境が今回の修正済みかは別問題なんですよね(^-^;)

PHPで何が起きた？2026年10月の重大な脆弱性を解説

PHP開発チームは10月20日に緊急リリースを予告し、翌21日に2件の重大な脆弱性を修正したバージョンを公開しました。いずれも認証なしのリモートコード実行につながるおそれがあります。深刻度を示すCVSS v4.0の評価は、それぞれ9.2です。

リモートコード実行とは、ざっくり言えば外部の攻撃者がサーバー上で意図しない処理を動かせてしまう可能性がある、ということ。単に記事の表示が少し崩れるような話とは、深刻さが違います。

出典：PHP公式アドバイザリー：CVE-2026-109618／CVE-2026-109619

「ログイン画面を守れば大丈夫」とは言えない理由

PHP公式は、Webリクエストを処理するPHP環境を広くリスク対象として挙げています。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどが含まれ、特にmod_phpでは、アプリケーションのコードが動く前に攻撃が成立する実証例が示されています。

つまり、WordPressのログインURL変更やログイン試行制限だけで、今回のPHPの問題まで解決したとは言えません。「パスワードを知られていないから安心」という判断は避けましょう。

ただし、これは「すべてのPHPサイトが同じ方法で簡単に侵入される」「エックスサーバーで被害が発生した」という意味ではありません。実際の影響は実行方式、設定、パッチ適用状況などによって変わります。

すでに攻撃されているの？

CERT-EUは10月21日の更新で、技術情報の公開と初期の実証コードの流通を伝え、速やかな修正を勧告しています。ただ、攻撃が可能なこと、悪用の懸念が高まっていること、特定サイトの被害が確認されたことは別です。この記事では、国内ブログで大規模被害が確定したとは扱っていません。

出典：PHP公式セキュリティ告知（2026年10月21日）／CERT-EU Security Advisory 2026-018

どのPHPに更新する？修正済みバージョンを確認しよう

PHP公式が今回の修正を含めて公開したバージョンは、次のとおりです。

表は2026年10月22日確認時点の情報です。今後さらに更新版が出た場合は、その系統の新しい修正版を確認してください。PHP 8.2は今回修正されましたが、公式サポート終了が近いため、長期運用では次の系統への移行計画も必要です。

一方、PHP 8.1以前はPHPプロジェクトによる通常の更新対象から外れています。一部のOS・LTSベンダーは修正を古い版へ取り込む「バックポート」を提供する場合がありますが、それが自分の契約サーバーに適用済みかは確認が必要です。

「番号が古い＝今回の修正が絶対に入っていない」とも、「サーバー会社が管理している＝必ず対応済み」とも決めつけない、ということですね〆(・∀・＠)

出典：PHP公式リリース情報／PHP公式サポート期間一覧

変更前にやっておきたい準備！バックアップは記事だけじゃ足りない

「よし、今すぐPHPを変えちゃおう！」と行きたいところですが、古いテーマやプラグインが新しいPHPに対応していないと、エラーでサイトが表示されなくなることがあります。

だからといって、何週間も準備だけして放置するのも避けたいところ。必要な確認を短時間で済ませて修正を適用する、難しければサーバー会社に一時的な保護方法を相談する、という進め方にしましょう。

1. 現在のPHPと対象ドメインをメモ。同じドメイン配下の別ブログ・会員機能・フォームも確認します。
2. ファイルとデータベースをバックアップ。サーバーの自動バックアップも、取得日時・保存対象・復元方法を確認します。
3. WordPress・テーマ・プラグインの対応情報を確認。必要な更新を行い、更新が止まっているものは代替を検討します。
4. 可能ならテスト環境で確認。本番に近い構成で投稿・画像・フォームを試します。
5. 復旧を担当できる時間に作業。長時間サイトを見られない直前の切り替えは避けましょう。

WordPressの「エクスポート」で記事データを保存しただけでは、サイト全体のバックアップとは言えません。画像ファイルやテーマのカスタマイズ、データベースなど、復旧に必要なものがそろっているかまで見てくださいね。

テスト用サイトを作った場合も、古いPHPのままネット上へ放置しないこと。検証環境まで含めて管理対象です。

参考：WordPress公式：PHP更新ガイド／WordPress公式：セキュリティ強化

エックスサーバーでPHPをバージョンアップする方法

ここからは、通常のレンタルサーバー「エックスサーバー」を想定して進めます。XServer VPSなど、自分でサーバーを管理するサービスは手順が異なるので、そのまま当てはめないでください。

STEP 1：サーバーパネルへログイン

エックスサーバーの公式サイトや普段使っているブックマークから、契約サーバーのサーバーパネルへ進みます。WordPressの投稿管理画面ではないので、ここは間違えないようにしましょう〜！

複数の契約がある人は、どのサーバーに対象サイトが入っているかも確認してください。緊急対応を装ったメールのリンクからではなく、自分で公式サイトへアクセスすると安心です。

STEP 2：「PHP Ver.切替」を開く

サーバーパネルの「PHP Ver.切替」を開きます。新しい画面では対象ドメインの右側にあるペンのアイコンから編集する形式が、公式検索結果に案内されています。

旧画面ではドメインを選び、「現在のバージョン」と「変更後のバージョン」を確認する形式です。どちらでも、最初に現在の設定を控えておきましょう。

STEP 3：対象ドメインと影響範囲を確認する

変更するドメインが合っているか確認します。同じドメインの下に「/blog/」「/shop/」など複数のシステムを置いている場合は、ひとつのブログだけ見て終わらせないでください。

個別の実行設定が入っている環境では、パネル上の選択と実際に動くPHPが一致しない場合もあります。以前に制作会社へ特殊な設定を依頼した人は、作業前に確認しておくと確実です。

STEP 4：修正済みのPHPを選び、変更を確定する

「変更後のバージョン」などの選択欄で、サイトとの互換性があり、今回の修正が適用済みと確認できたPHPを選びます。画面の案内に従って、変更・保存を確定してください。

ここで「推奨」と書かれた版でも、今回のCVEへの対応済みかは別に確認します。細かな修正版が選択肢に出ない場合、利用者側で無理にPHPをインストールするのではなく、サーバー会社の対応案内を確認しましょう。

確認できないときは、次の内容をサポートに聞けば要点が伝わります。

利用中のサーバーで、CVE-2026-109618とCVE-2026-109619への修正は適用済みでしょうか。現在利用中のPHP系統にも適用されますか。利用者側の切り替え操作や追加対応が必要か教えてください。

問い合わせは正規のサポート窓口で行い、必要な契約情報だけを伝えましょう。パスワードを本文へ書く必要はありません。

STEP 5：WordPress側で反映を確かめる

WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で、実際に動いているPHPのバージョンを確認します。画面の表記はWordPressの版によって多少変わる場合があります。

サーバーパネルで操作が終わっただけで安心せず、ここまで確認しておきましょう。独自パッチ対応の場合は、表示番号だけで判断せず、サーバー会社の回答・対応告知も残しておくと後から確認しやすくなります。

手順の出典：エックスサーバー公式：PHPのバージョンについて。公式検索結果を2026年10月22日に確認。

更新後にチェックする場所！トップページだけじゃ見落とす

PHPを切り替えたあと、トップページが表示されて「はい完了！」となりがちですが、キャッシュされたページだけ正常に見えることもあります。

実際にログインして下書きを保存する、画像を1枚アップロードする、問い合わせフォームからテスト送信して受信まで確かめるなど、PHPが動く操作を試すのがポイントです。

収益ブログならアフィリエイトリンクの遷移先や広告表示も確認。通販・会員サイトならカート、ログイン、通知なども対象です。決済を試す場合は、サービスが用意したテスト機能を使い、意図しない購入を発生させないようにしましょう。

真っ白な画面・500エラーが出たらどうする？

まず、変更時刻とエラーが出るURLを記録します。古いプラグインやテーマ、独自に追加したコードが新しいPHPに対応していない可能性がありますが、表示不良だけで原因を断定しないことが大切です。

直前のPHPへ戻すと表示が回復する場合があります。ただし、戻した版が未修正なら、そのまま公開を続けることは安全な解決ではありません。復旧のための一時対応と、脆弱性への修正対応をセットで考えてください。

エラーログを確認し、問題のテーマ・プラグインを更新・交換するか、制作会社やサーバー会社へ相談しましょう。必要に応じて外部公開を制限したうえで復旧します。エラーの詳細を訪問者全員に表示して調査する方法は避けてください。

なお、サーバーの修正パッチは過去の侵入まで取り消してくれるわけではありません。変更前から不審なファイルや転送があったなら、次の「侵害が疑わしいとき」の確認も必要です。

放置すると何が怖い？ブロガーが知っておきたい被害

以下はサーバー上で不正な処理を実行された場合に考えられる、一般的な被害シナリオです。今回の脆弱性によって、これらがすべて実際に発生したと確認されたわけではありません。

記事やアフィリエイトリンクを書き換えられる

記事の中に不審なリンクを入れられたり、読者を別のサイトへ転送されたりすると、収益だけでなく信用にも関わります。管理者には正常に見えて、特定の訪問者だけ違うページへ飛ばす改ざんも考えられるので、「自分のスマホでは見えた」だけでは判断できません。

保存している情報や、ほかのサイトに影響する

攻撃者がアクセスできる範囲によっては、設定ファイルやデータベース内の情報に影響するおそれがあります。問い合わせや会員機能を使っている場合、どんな個人情報をどこに保存しているかを把握しておくことも重要です。

同じ契約内に複数サイトを置いている場合も、ファイル権限や隔離の仕組みによって影響範囲は変わります。「ひとつ侵入されたら必ず全部やられる」とは言えませんが、放置ブログを含めて確認する理由にはなります。

「小さいブログだから狙われない」は通用しない

攻撃は、運営者の知名度だけで選ばれるとは限りません。一般に、公開されたサイトへ自動的にアクセスし、弱い環境を探す手法も使われます。訪問者が少ないサイトでも、不正なページや中継地点として悪用される価値はあるわけです。

しかも復旧には、記事を書いて収益を伸ばすはずだった時間も取られます。ブロガーとしては、ここもなかなか痛いところですよね…(^-^;)

WAF・セキュリティプラグインを入れていれば大丈夫？

WAFは不審なWeb通信を検査・遮断する仕組みです。役立つ防御策ですが、WAFをONにしただけで今回の2件への完全な対策が済んだとは判断できません。対応ルールや通信経路、利用環境によって効果が変わります。

PHP公式も、暫定的な設定変更は特定の攻撃経路を減らすものであり、更新の代わりにはならないとしています。

ネット上ではメモリ制限やセッション関連の設定変更が紹介されていますが、共用サーバーでは変更できる範囲も、反映のされ方も異なります。意味がわからないまま設定値をコピペして「対策済み」にしないこと。特にメモリ上限を無制限にする変更は、サーバー資源や可用性への影響も伴います。一般のブロガーは、サーバー会社が案内する措置を優先してください。

すぐ更新できない場合は、サーバー会社へ修正予定と一時的なアクセス制限を相談します。WordPressのメンテナンスプラグインで見た目を閉じるだけでは、PHPにリクエストが届く状態が残る場合がある点にも注意しましょう。

出典：PHP公式セキュリティ告知／CERT-EUの勧告

今後の懸念点と、更新後も続けたい対策

技術情報の公開後は、未修正サイトが狙われる懸念

脆弱性の情報が公開されると、防御側だけでなく攻撃側も内容を調べられるようになります。今後、攻撃手法の改良や自動化が進む可能性はありますが、現時点で被害件数や拡大速度を断定する材料はありません。

だからこそ「大騒ぎが落ち着くまで待つ」より、修正済みかを確認することが先です。サーバー会社のお知らせが出たら、対象サーバー・対象PHP・実施日時・利用者の操作が必要かをチェックしましょう。

古いテーマが更新の足かせになる

「PHPを変えるとテーマが動かないから、ずっと古いまま」という状態は、今回だけでなく今後も悩みの種になります。PHPの修正対応と並行して、更新が止まったテーマ・プラグイン・独自コードの整理を進めましょう。

PHP 8.2を使う人は、2026年末の公式サポート終了も予定に入れておきたいところです。年末の忙しい時期に慌てないよう、互換性確認を前倒ししておくとラクですよ〆(・∀・＠)

「緊急修正してください」という偽メールにも注意

大きなセキュリティニュースに便乗して、サポート担当者を装う連絡が来る可能性も考えられます。「添付した修正プラグインを入れて」「パスワードを返信して」と言われても、その場で従わないでください。

公式サイトを自分で開き、告知内容と一致するか確かめる。このひと手間が大切です。AIに相談する場合も、パスワードやAPIキー、顧客情報が入ったログをそのまま貼らないようにしましょう。

月1回の点検と、緊急告知への対応を分ける

普段は月1回などのタイミングで、PHPのサポート期限、テーマ・プラグインの更新、不要な管理者、バックアップの取得状態を確認する運用にすると続けやすくなります。ただし、今回のような重大な告知は、定期点検日まで待たずに対応してください。

何をいつ更新したか、誰が復旧できるかもメモしておくと、次のトラブル時に役立ちます。ブログを複数持っている人は「ドメイン／PHP／最終確認日／修正済み根拠」を一覧にしておくと、確認漏れを減らせます。

すでに改ざんされたかも？と思ったときの対応

見覚えのない管理者が増えた、勝手に他サイトへ飛ぶ、不審なPHPファイルがある、身に覚えのないメールが送られている…。こうした異常があれば、単なる更新作業とは分けて考える必要があります。

1. 異常の時刻・URL・画面を記録。ログやファイルを手当たり次第に削除しないでください。
2. サーバー会社へ連絡。外部公開の制限、調査に必要な記録、復旧方法を相談します。
3. 侵入経路と影響範囲を確認。同じ契約内の別サイトや、保存している情報も確認対象にします。
4. クリーンな状態へ復旧し、侵入口を修正。バックアップにも不正なファイルが入っている可能性を考えます。
5. 関係する認証情報を見直す。安全な端末から、必要に応じてパスワード変更、キーの失効、セッション無効化などを実施します。

個人情報の流出が疑われる場合は、影響確認や連絡・報告の要否を専門家へ相談してください。見た目だけ元に戻っても、原因が残っていれば再発するおそれがあります。

PHPの脆弱性と更新でよくある疑問

WordPressを最新にしたらPHPも更新される？

別の更新です。WordPress本体の更新とは別に、サーバー側のPHPの修正適用状況を確認してください。

PHPを変えると記事や画像が消える？

PHPの切り替えそのものは、通常、記事や画像を削除する操作ではありません。ただし互換性の問題で表示や機能が止まる可能性があるため、バックアップと動作確認は必要です。

アクセスが少ないブログなら後回しでいい？

規模だけを理由に後回しにはしない方がよいでしょう。公開中のブログはもちろん、放置した別サイトやテスト環境も確認してください。

エックスサーバーが管理画面を停止していたら？

画面が開かないときは公式のお知らせや正規サポートで状況を確認します。停止だけで「被害が出た」とも「すべて対策済み」とも判断できません。制限を回避してアクセスしたり、別サービスの手順を流用したりせず、復旧後に自分の環境を確認しましょう。

自動更新に任せれば今後も安心？

自動更新は助けになりますが、対象範囲と失敗時の通知を把握する必要があります。更新が成功しているか、サイトの主要機能が動くか、復旧できるかまで確認する運用にしましょう。

ブログは「書く」だけじゃなく「守る」ことも大事！

記事を書く、検索順位を上げる、収益を伸ばす。ブロガーはやることが多いですが、その成果を積み上げるには、サイトが安全に動いていることが土台になります。

今回のポイントは、PHP公式の修正版が出たことと、自分のサイトに修正が入ったことを分けて確認することです。怖がって止まるより、現在の環境と公式案内を確認して、ひとつずつ対処していきましょう。

大事に育てたブログを守るためにも、まずはPHPの確認から始めてみてくださいな〆(・∀・＠)

主な参考情報・確認先

• PHP公式：2026年10月21日のセキュリティ告知・リリース
• PHP公式：CVE-2026-109618
• PHP公式：CVE-2026-109619
• CERT-EU：Critical Vulnerabilities in PHP
• PHP公式：サポート期間
• エックスサーバー公式：PHPのバージョンについて
• エックスサーバー公式：ニュース
• WordPress公式：PHP更新ガイド
• WordPress公式：セキュリティ強化

確認日：2026年10月22日。設定画面・提供バージョン・対応状況は変更される場合があります。この記事の図解は独自制作であり、公式管理画面の再現画像ではありません。