※本記事はプロモーションが含まれています。

「PHPに重大な脆弱性が見つかった」「OpenAIのAIが発見に関わった」「IPAが注意を呼びかけている」。ニュースを見て、自分のWordPressブログは何をすればよいのか、不安になった方もいるでしょう。
ブログ運営者が優先する対策は、使っているPHPの版を確認し、契約サーバーの対応状況を調べ、修正済みPHPがサイトに適用されていることを確かめることです。WordPress本体・テーマ・プラグインの更新だけでは、今回のPHP本体の脆弱性は修正されません。
2026年10月21日、PHPは2件の重大な脆弱性を修正した版を公開しました。この記事では、OpenAI・IPA・PHP・WordPressの発表を整理し、レンタルサーバー利用者が進める手順と、自分でサーバーを管理する場合の注意点を説明します。
PHPのブログ対策|まずやることはこの順番

| 優先 | やること | 判断の目安 |
|---|---|---|
| 1 | サーバーとPHPの版を確認 | WordPressのサイトヘルスやサーバー管理画面 |
| 2 | 公式の対応案内を読む | 修正版の適用・提供予定・利用者作業を確認 |
| 3 | バックアップと互換性を確認 | ファイルとデータベースの両方 |
| 4 | 修正版の適用を確認 | 表示番号だけで判断せず事業者の説明も見る |
| 5 | 更新後の動作を試す | 記事表示・管理画面・画像・フォーム |
共有レンタルサーバーでは、PHPを更新する主体がサーバー会社である場合があります。自分が行うのは、更新そのものではなく、対象ドメインで使う版の選択や、更新後の動作確認ということもあります。まず「誰が更新する契約か」を確認しましょう。
出典 WordPress公式「Critical PHP Security Release」
何が起きた?IPAの注意喚起とOpenAIの発表を整理

IPAは修正版公開に備えた対応を呼びかけた
IPAは10月21日、PHPの2件の脆弱性に関するセキュリティリリースの事前準備を呼びかけました。予告していた公開予定は同日23時、日本時間です。IPAの事前案内は、その時点でIPAが悪用した攻撃を確認したという報告ではなく、速やかな修正適用に向けた予防的な注意喚起でした。
その後、PHP側は修正版を公開しています。「これから公開されるので待つ」という段階のニュースと、公開後の更新案内を混同しないことが大切です。
出典 IPA「PHPのセキュリティリリース公開予定について」
OpenAIのAIは発見・調査に関与、修正はPHP開発側が主導
OpenAIの発表では、同社の「Patch the Planet」の取り組みの中で、セキュリティ企業CalifがGPT-5.6 Solを使って重大な欠陥を特定したと説明しています。Wizも独立して両脆弱性を発見・報告し、PHPのメンテナーが修正とリリースを主導しました。
つまり「OpenAIのAIがIPAにブログを危険と判定された」という関係ではありません。AIを使う研究者らによる発見・調査、PHP開発側の修正、日本でのIPAの注意喚起という役割を分けて理解できます。
出典 OpenAI「Patch the Planet」公式発表
さらにPHP Foundationは、一方の問題の兆候は2024年の監査後の対応で見つかっており、2026年の追加報告で影響の大きさが明確になったと説明しています。AIだけがすべてを初めて発見し、自動で直したという単純な話ではなく、人の調査・判断・修正作業が積み重なっています。
影響するのはWordPressだけ?2件の脆弱性の内容
問題はPHP本体にあり、WordPress専用の不具合ではありません。PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、ウェブのリクエストを処理するPHP環境を対象として挙げています。
| 識別番号 | 問題の概要 | 想定される影響 |
|---|---|---|
| CVE-2026-109618 | メモリ不足時に内部データが不完全な状態で扱われる問題 | 条件がそろうと認証なしの遠隔コード実行 |
| CVE-2026-109619 | 前の処理で解放されたメモリを参照する内部状態が残る問題 | 条件がそろうと認証なしの遠隔コード実行 |
遠隔コード実行とは、攻撃者がサーバー上で意図しないプログラムを動かせるおそれがあるということです。ただし、PHPを使うすべてのサイトで既に侵入被害が起きたという意味ではなく、影響の受け方には実行方式や設定、アプリケーションの処理も関係します。
出典 PHP公式アドバイザリ CVE-2026-109618
出典 PHP公式アドバイザリ CVE-2026-109619
「ログイン画面を守っている」「記事しか投稿していない」だけで対象外とは判断しないでください。PHP Foundationは、Apacheのmod_phpではアプリケーションのコードが動く前に影響する経路があると説明しています。
修正されたPHPのバージョン|8.3や8.4という表示だけでは不足
| 利用系統 | 今回の修正が入った版 | 運営者が確認すること |
|---|---|---|
| PHP 8.2 | 8.2.35 | 修正版の適用と、今後の移行計画 |
| PHP 8.3 | 8.3.36 | 対象ドメインでの適用状況 |
| PHP 8.4 | 8.4.27 | 同じ系統でも古い小番号のままではないか |
| PHP 8.5 | 8.5.12 | 利用中のテーマ等との対応状況 |
表は今回の脆弱性に対応した公開版です。たとえば「PHP 8.3を使っている」という情報だけでは、今回の修正が入っているかまでは分かりません。小数点の後まで含めた版と、事業者の告知を確認してください。
一方で、Linuxの提供元や長期サポート事業者が、古い版へ修正を組み込むこともあります。表示される番号が表と一致しないだけで未対応と即断せず、今回の2件のCVEに対応したパッケージかを提供元へ確認します。
PHP 8.1以前は、通常の公式セキュリティサポートが終了
PHP 8.1以前はPHPプロジェクトの通常のセキュリティ更新対象外です。今回、古い一部系統向けの限定的なソース修正も案内されていますが、それを長期のサポート再開と捉えず、提供元の保守状況と移行先を確認してください。
PHP 8.2のセキュリティサポートも2026年12月31日までです。今回の緊急修正と、より新しい対応系統への計画的な移行は、別々に進める必要があります。
出典 PHP公式のサポート期間
WordPressで使用中のPHPを確認する方法
① WordPress管理画面で「ツール」を開きます。
② 「サイトヘルス」へ進み、「情報」タブを選びます。
③ 「サーバー」を開き、PHPのバージョンを確認します。
④ 対象サイトのドメインと、表示された版を控えます。
管理画面を開けない場合は、サーバーの契約画面や管理画面でも確認できます。複数のブログを運営している場合、同じ契約内でもドメインごとに設定が違う可能性があるため、対象サイトを取り違えないようにしてください。
WordPress本体の版と、PHPの版は別の情報です。また、自主管理者がコマンドで調べる場合も、コマンド用PHPとウェブサイト用PHPが同じとは限りません。読者がアクセスするサイトで実際に動く環境を確認することが必要です。
確認のためにサーバー情報を全面表示するファイルを公開したり、外部の診断サービスへ管理者パスワードを入力したりする必要はありません。契約サービスの管理画面やサポートを使いましょう。
レンタルサーバー利用者が確認すること|告知と自分の契約を照合

公式サイトのメンテナンスと、利用者のブログが止まることは同じではありません。また、メンテナンス告知が出ているだけで、自分のPHPへの修正適用が完了したとも限りません。次の表は、各社の個別告知が説明している範囲を整理したものです。
| サービス | 個別の公式告知 | 読み取る際の注意 |
|---|---|---|
| さくら | 一部の管理機能を緊急メンテナンス。対象告知ではWeb表示・メール送受信への影響なしと説明 | 管理機能の停止とPHP更新完了は別に確認 |
| ConoHa WING | 10月21日19時~22日10時の保守作業予定と、一時的な利用不可の可能性を案内 | 予定時刻だけで終了・修正完了を断定しない |
| mixhost | マイページを予防的な安全対策で一時停止。Web表示・メールは通常利用と説明 | マイページの状況と各サイトの修正を分ける |
ConoHaの上記告知はシステムの保守作業として案内されており、その文面だけでPHPの2件の修正内容まで確認できるものではありません。他社でも、契約プラン・収容サーバー・利用中のPHP系統に対応する案内まで確認しましょう。
サポートへ伝えたい5つの質問
利用中のドメインと契約プランで、CVE-2026-109618/CVE-2026-109619の修正は適用されていますか。
こちらでPHPの版を切り替えるなどの作業が必要ですか。
表示される版が古い場合、修正を組み込んだパッケージですか。
未適用の場合、修正までの保護策と提供予定を教えてください。
動作不具合が出た場合、修正済み環境を保ったまま復旧する方法はありますか。
サーバー管理の担当範囲を整理したい方は、WordPressブログの始め方とサーバーの基本も参考になります。契約先の管理画面とWordPress管理画面を分けて考えると、問い合わせ先を選びやすくなります。
PHP更新前後のブログ対策|バックアップから動作確認まで

1 ファイルとデータベースを両方保存する
WordPressの復旧には、画像・テーマ・プラグインなどのファイルと、記事・設定などを持つデータベースの両方が必要です。記事のエクスポートだけを完全なバックアップと考えないでください。
自動バックアップの取得日時、復元できる範囲、保存先を確かめます。可能ならサーバー以外にも控えを持ち、バックアップを作ったという記録だけでなく、復旧方法も確認しておきましょう。
2 テーマ・プラグインの対応を確かめて更新する
PHPの系統を切り替える場合は、WordPress本体、テーマ、プラグインの対応状況を確認します。一般的な更新準備としては、バックアップを確保してからそれぞれの更新を行い、テスト環境がある場合は動作を試す方法が案内されています。
ただし、今回のような緊急修正は長期間先送りにせず、互換性に不安がある場合はサーバー会社や制作担当者へ相談してください。同じPHP系統内の修正版適用と、別系統への変更も分けて確認します。
3 更新した後は、読者が使う画面を試す
トップページ・個別記事・管理画面へのログイン・画像のアップロード・問い合わせフォームを確認しましょう。販売機能や予約機能がある場合は、その導線も確認対象です。フォームは表示だけでなく、送信先へ届くところまでテストすると実際の不具合を見つけやすくなります。
自動投稿や予約処理を使う場合は、その処理も対象に加えます。WordPressの下書き投稿を自動化する構成を使う方も、普段の投稿処理が動くかを確認してください。
不具合が出ても、既知の脆弱性が残るPHPへ戻して公開を続けることを前提にしないでください。問題のあるテーマ等の切り分けや、修正済みの別環境での復旧を担当者と相談します。
WAFやプラグインで防げる?一時対策と修正を区別する

WAFは不審な通信を遮断するための仕組みですが、有効にしただけでPHP本体の修正が入るわけではありません。サーバー会社の一時的な防御策があっても、最終的には修正済みPHPの適用を確認する必要があります。
PHP公式は、一部の攻撃経路への対策を挙げる一方、更新以外では完全な解決にならないと説明しています。SNSで見かけた設定値を、仕組みを理解しないまま貼り付けて「対策完了」としないでください。
とくにメモリの上限解除などは、サーバー全体の資源管理と組み合わせて考える設定です。また、WordPressのPHPコードへ追加する処理では、アプリケーションの実行前に起きる問題を防げない場合があります。一般のブログ運営者は、独自の応急コードよりサーバー会社の修正案内を優先しましょう。
修正がすぐできない場合|サーバー側の公開制限を相談する
ENISAなど欧州の関係機関は、インターネットへ公開しているシステムを優先して修正し、即時対応できない場合は修正適用まで公開ネットワークから隔離することを検討するよう勧告しています。
自主管理のVPSやクラウドでは、サーバー側でのアクセス制限や一時停止を管理担当者と検討します。WordPress上で「メンテナンス中」と表示するプラグインは、PHP処理そのものへの外部アクセスを遮断する措置とは限りません。
共有レンタルサーバーなら、利用者がサーバー全体の設定を変えられない場合があります。自己判断で設定ファイルを大量に書き換えるより、適用状況と一時的な保護方法を契約先へ確認してください。
改ざんが疑われるときは、更新だけで終わらせない
知らない管理者が増えた、記事やリンクが書き換わった、不明なファイルがあるなどの異常は調査が必要です。ただし、それだけで今回の2件が原因だとは特定できません。
異常を見つけた時刻・画面・通知を記録し、ログやファイルをむやみに消す前にサーバー会社や保守担当へ相談します。PHP更新は脆弱性の修正であり、すでに侵入された場合の不正ファイル除去や原因調査まで自動で終わる作業ではありません。
出典 WordPress公式「サイトが侵害された場合のFAQ」
AIへ相談するときに渡してよい情報・伏せる情報
状況を整理するためにAIを使うなら、公開されている公式告知、PHPの版、秘密情報を除いたエラーの内容などから始めましょう。管理者パスワード、秘密鍵、データベース接続情報、顧客情報をそのまま送る必要はありません。
AIに「安全です」と言われても、サーバーの修正適用が確認されたことにはなりません。設定変更案は契約先の公式手順と照合してください。ChatGPTへの入力を見直したい方は、学習への利用設定・一時チャット・多要素認証の使い分けも参考になります。
今後のブログ運営は、更新できる環境を基準に選ぶ
緊急対応が落ち着いてから、PHP更新の案内、バックアップの復元範囲、問い合わせ窓口を見直しましょう。移転すること自体が今回の修正ではなく、まず現在の環境で対応を確認することが先です。
契約内容を整理する入口として、WordPressブログとレンタルサーバーの基本も参考になります。選ぶ際はキャンペーン価格だけでなく、継続して更新・復旧できるかを比較してください。
保守の基本を手元で読み返したい場合は、WordPressのバックアップやセキュリティを扱う入門書も選択肢です。無料の公式手順を優先し、本を購入する場合は刊行年と目次を確認しましょう。
>WordPressの保守・安全対策を学ぶ書籍を楽天市場で探す
PHPのブログ対策でよくある質問

WordPressを最新版にすれば今回の問題は直りますか?
WordPress本体の更新とPHP更新は別です。今回の2件には、サーバー側のPHP修正が必要です。
PHP 8.3と表示されています。安全ですか?
系統名だけでは判断できません。今回の修正版は8.3.36です。提供元が修正を組み込んでいる場合もあるため、小番号と公式告知を確認してください。
PHP 8.1以前を使っている場合はどうしますか?
通常のPHP公式セキュリティサポートは終了しています。提供元の修正・延長保守状況を確認し、対応する系統への移行を相談してください。
パスワードを変えれば大丈夫ですか?
パスワード変更だけではPHP本体の欠陥は直りません。PHP更新を進め、不正利用の疑いがある場合は調査と認証情報の見直しも行います。
WAFをオンにすれば更新は不要ですか?
不要にはなりません。WAFなどは一時的なリスク低減策で、修正適用の代わりとは考えないでください。
ブログを必ず停止しなければいけませんか?
修正済みか、どの環境かによって判断が変わります。修正ができず公開中の場合は、契約先や管理者へ公開制限を相談してください。
サーバー会社がメンテナンス中なら、ブログも侵入されたのですか?
その告知だけでは判断できません。予防的な措置の場合もあります。停止範囲・修正状況・個別の影響を公式案内で分けて確認します。
AIで発見されたなら、AIに直してもらえば完了しますか?
修正済みPHPが実際のサーバーで動くことの確認が必要です。AIの助言だけを適用完了の証拠にせず、提供元の手順と照合してください。
対策のゴールは「実際に使うPHPへ修正が入った」と分かること
まずサイトヘルスでPHPの版を確認し、契約サーバーの対応案内と照合してください。必要な更新・切り替えを済ませた後は、記事やフォームが動くかまで試します。WordPressの更新通知が消えた、WAFを有効にしたという状態だけで終わらせないことが大切です。







