PHP脆弱性対策・安全管理ガイド|サイト運営者が確認すべきこと

PHPの脆弱性対策は、WordPressやプラグインの更新だけでは完了しません。サイトを動かすPHP本体、そこで動くアプリ、サーバーの公開設定を分けて確認する必要があります。

この特集は、会社・店舗のサイトやブログを運営する方、制作会社へ保守を任せている方のための管理ガイドです。2026年10月21日に公表された重大な脆弱性を例に、今すぐ確認することと、次の緊急更新で慌てないための日常管理をまとめます。

対象:サイト運営者・保守担当者 / 情報確認日:2026年10月23日(日本時間)

10月21日公表のPHP脆弱性:対象と修正版を確認する

The PHP Groupは2026年10月21日付で、認証なしに遠隔からコードを実行されるおそれがある2件の脆弱性を公表しました。IPAは22日に正式な注意喚起を掲載し、この組み合わせを「PHP2shell」と説明しています。サイト閲覧者がPCへPHPを入れ直す問題ではなく、PHPを使うサイト・製品・サービスの運営側が対応する問題です。

この表は今回の修正が入った版であり、将来もその版のままでよいという意味ではありません。後続のセキュリティ更新も適用します。OSや保守ベンダーが古い版へ修正を取り込む「バックポート」を提供している場合は、表示番号だけで未対策と決めず、2件のCVE番号に対応したパッケージと適用状況を確認してください。PHP 8.1以前はPHPプロジェクトの通常サポートが終了しています。今回、旧系列向けの限定的なソース修正が示されても、通常サポートが再開したわけではありません。

出典:IPA「PHPの脆弱性対策について」、PHP公式の緊急告知。

PHP-FPMも確認対象。mod_phpだけの問題ではありません

PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを扱うPHPを対象に挙げています。特にmod_phpでは、アプリの処理が始まる前に攻撃が成立する実証があると説明しています。一方、すべての構成で同じ攻撃が成功したという意味ではなく、成立条件は実行方式や設定で異なります。

• CVE-2026-109618:メモリ不足時の処理によって、PHP内部の不完全なデータが後の処理で使われる問題です。通常のアプリ修正だけではPHP本体の欠陥を直せません。PHP開発元の技術情報。
• CVE-2026-109619:解放されたメモリを指す内部状態が残り、同じ処理担当プロセスが次のリクエストで使ってしまう問題です。エラーを画面に表示しない設定でも、脆弱性そのものは解消しません。PHP開発元の技術情報。

完全な対策は修正の適用です。公式の暫定策にはサーバー全体の資源管理やプロセスの再起動を伴うものがあり、一部の攻撃経路を減らすにとどまります。メモリ制限を無条件に外すなど、設定値だけを抜き出して本番へ貼り付けないでください。すぐ更新できない場合は、保守担当と公開範囲の制限・一時停止・移行を検討し、未対策のまま公開を続ける期間を決めずに放置しないことが重要です。

サービスごとの対応続報は、速報ページのPHP更新情報で確認できます。

PHPがサイバー攻撃の入口になるのはなぜか

PHPは、サーバー側でプログラムを実行するための言語・実行環境です。WordPressでは、ページの生成、ログイン、検索、フォームなどの処理に関わります。閲覧者のブラウザーへ送られるHTMLとは別に、サーバーの中でデータベースやファイルを扱います。

そのため、不正な入力を安全に処理できなかったり、PHP本体に欠陥があったりすると、ページ表示だけでなく、保存情報の読み出しや改ざんへ影響が及ぶ場合があります。PHPを使っていること自体が侵害の証拠なのではなく、外から届く入力を扱い、重要なデータへ接続する部分を保守し続ける必要があるということです。

小さなサイトでも、公開された古い入口は調べられます

攻撃者が一社ずつサイトを選んでいるとは限りません。公開サーバーを自動的に探すプログラムもあるため、アクセス数の少なさは防御策になりません。本番サイトだけ更新しても、放置した検証サイト、旧ドメイン、使わなくなったフォームが公開されたままなら、別の入口が残ります。PHP公式も、サイトの規模に関係なく接続可能なサーバーが対象になり得ると説明しています。PHP公式:セキュリティの基本的な考え方。

PHP本体・アプリ・認証や公開設定は、別々に対策する

例えば、PHPを更新しても、プラグインが受け取った入力から不適切なSQL文を作る問題は残り得ます。反対に、プラグインを更新しても、今回のPHP本体の問題が自動的に修正されるわけではありません。「すべて更新済み」と確認するときは、何を更新したのかを分けて記録します。

自分のサイトで動いているPHPと、更新担当者を調べる

WordPressでは「ツール → サイトヘルス → 情報 → サーバー」を開く

管理者権限でWordPressへ入り、「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPバージョンを確認します。「8.3」までではなく「8.3.36」のように末尾まで控え、対象ドメインと確認日時も記録してください。画面の情報を外部へ相談するときは、パス・構成情報などを丸ごと公開せず、必要な項目だけを渡します。WordPress公式:サイトヘルスの情報画面。

レンタルサーバーの設定画面は選択中の系列を示し、WordPress側はそのサイトの処理に使われたPHPを示します。複数ドメイン・検証環境を持つ場合は、それぞれ確認します。技術担当者は、SSHで実行するphp -vが示すCLI用PHPと、Web用PHPが同じとは限らない点にも注意してください。定期処理のCronやコンテナーも、実際に指定されている実行環境を別に確認します。

公開場所へphpinfo()を表示するファイルを置きっぱなしにする方法は避けます。共有サーバーで細かな版や修正履歴が分からない場合は、管理画面の表示とCVE番号を添えて事業者に確認する方が安全です。

レンタルサーバーとVPSでは、利用者が担当する範囲が異なる

• 共用レンタルサーバー:PHPの配布・小規模な更新は事業者が行い、利用者が系列を選択する構成があります。「自動更新されるはず」ではなく、対象サーバーの対応完了とサイトの実行版を照合します。
• VPS・クラウド・自社サーバー:契約で管理を委託していなければ、OS・PHP・Webサーバーや再起動の管理を自分たちで担う範囲が広くなります。管理サービスの契約範囲を確かめてください。
• 制作会社・保守会社へ委託:記事更新だけの契約か、PHPやサーバーまで対象かを確認します。責任の境界が不明なままでは、双方が相手の担当だと思って更新が止まります。

エックスサーバーでは、サーバーパネルの「PHP Ver.切替」からドメインごとの選択版を確認できます。変更はバックアップと互換性確認を済ませてから行い、画面に古い系列が選択肢として残っていることを、PHP開発元によるサポート継続の意味で受け取らないでください。エックスサーバー公式:PHPのバージョン確認・切替。

修正版の適用と、サポート終了前の移行を分けて計画する

同じ系列内の修正適用と、8.2から8.4などへの系列変更は別の判断です。今回の修正を急いで適用することと、中長期の移行を進めることは両立できます。古いプラグインの互換性を確認せず、選択肢の一番新しい系列へいきなり切り替える必要はありません。

公式は原則として約2年の通常サポートと、その後約2年の重大なセキュリティ問題への対応を案内しています。表は開発元が示す日付で、終了時刻を日本時間の特定の時刻に換算したものではありません。保守ベンダーの延長対応は別契約・別範囲です。特に8.2を使う運営者は、今回の修正を適用したうえで、年末より前に移行先と作業日を決めてください。PHP公式:サポート期間。

PHPを安全に更新する:バックアップから実動作の確認まで

次の手順は、サイト運営のための実務上のチェックリストです。緊急の修正では確認を短時間に集中させ、通常の大きな系列変更では検証に余裕を持たせます。更新作業と他の担当者のデザイン変更を同時に進めず、変更の前後を追えるようにしてください。

1. 対象と変更前の状態を記録する。ドメイン、Web用PHPの版・系列、CMS・テーマ・主要プラグイン、必要な拡張機能、更新担当者を控えます。広告コードや計測タグ、フォーム、外部連携も点検対象に入れます。
2. データベースとファイルの両方を退避する。記事・設定・受注情報と、画像・テーマ・プラグイン・設定ファイルを同じ時点で戻せるようにします。取得日時、保存先、復元担当、必要時間を確認し、可能なら検証環境で復元します。バックアップはWebから取得できない場所に保管してください。
3. 変更先の互換性を確認する。CMS・プラグイン・テーマの提供元が案内するPHP対応範囲を調べます。検証環境では本番に近い構成で試し、コピーした顧客情報の公開や、本番宛てのメール・決済を止めておきます。互換性チェッカーだけで合否を決めず、実際の操作も確認します。
4. 対象を絞って修正を適用する。正規の管理パネルや、OS・保守ベンダーが案内するパッケージから更新します。自社管理サーバーでは、更新済みファイルがあっても古いプロセスが動いていないか確認し、提供元の手順に従って必要な再起動を行います。
5. 更新後の実行版を再確認する。設定画面の選択値だけでなく、サイトヘルスなどで実際のPHPを確認します。キャッシュされたトップページが開くことだけを、更新成功の判定にしません。
6. 利用者の主要操作とログを照合する。下の点検表を使い、確認した操作・時刻・結果を記録します。問題があれば対象の変更とログを照合し、必要な範囲だけを修正します。

更新前のバックアップ・互換性確認の参考:WordPress公式:PHP更新の準備。古い説明中の推奨バージョン番号ではなく、現在のPHPサポート表と各製品の対応情報を基準にしてください。

更新後に不具合が出た場合も、脆弱な版へ戻して公開を続けることを恒久対策にしないでください。保守担当が影響と公開制限を判断し、互換性のある修正済み環境で復旧します。受注・会員登録が進むサイトでは、古いデータベースへの復元によって更新後の記録が消える可能性があるため、復元対象と差分の扱いを先に決めます。

WAFは補助防御。更新の代わりにも、侵害を消す道具にもならない

WAF(Webアプリケーションファイアウォール)は、不審なWebリクエストを検知・遮断する仕組みです。検査位置やルールによって防げる範囲が異なり、導入済みでもPHPの欠陥が消えるわけではありません。すでに置かれた不正ファイルや盗まれた認証情報を、WAFの有効化だけで元へ戻すこともできません。

管理者は対象ドメインでWAFが有効か、検知ログを誰が確認するか、必要なルールが適用されているかを確かめます。正当なフォーム送信や記事保存が拒否された場合は、時刻・URL・操作内容と検知記録を照合し、事業者へ相談してください。原因調査のために全項目を無期限に無効化する対応は避け、必要な例外を最小限に限定します。エックスサーバーの公式説明も、WAFによる完全な防御は保証せず、アプリ側の更新が必要としています。WAF設定の役割と注意点。

また、WordPressが読み込まれてから働く保護と、その前段で働く保護では範囲が異なります。今回のようにアプリの実行前の処理が問題になる場合、「セキュリティプラグインを入れたから大丈夫」とは判断できません。

PHP周辺の設定とファイルを、必要な機能を残して守る

エラーは訪問者へ見せず、管理者が読める記録を残す

本番では、詳細なエラー表示から内部パスや構成が漏れないようにします。一方、障害や不正操作を調べるためのログは必要です。display_errorsとログ記録を別々に扱い、保存先が公開領域になっていないか、閲覧権限・保管期間・容量も確認してください。エラーを隠すことと、エラーの原因や脆弱性を修正することは別です。PHP公式:エラー表示による情報露出 / OWASP:PHP設定の確認事項。

バックアップ・設定・アップロードを、公開用のページと分ける

データベースの書き出しや設定ファイルのコピーには、個人情報や認証情報が含まれ得ます。拡張子を変えただけで公開フォルダーに置くのではなく、Webから取得できない保管先へ分けます。管理者は、認証していないアクセスから読み出せないことも確かめてください。

アップロード機能があるサイトでは、受け付ける種類・容量・利用者の権限を絞り、保存されたファイルがプログラムとして実行されない構成にします。拡張子の検査だけに依存せず、CMSや提供元の実装を利用してください。OWASP:ファイルアップロードの保護。

Apache向けの.htaccessを置いても、別のWebサーバーや静的配信経路に同じ制限が効くとは限りません。管理者が実際の配信構成を確認して適用します。サイトを直すために全フォルダーの権限を一律に広げたり、設定ファイルをまとめて削除したりしないでください。

不要なプラグインを整理し、管理者権限を広げすぎない

停止中のプラグインや使っていないテーマも一覧に含め、必要性と依存関係を確認します。不要と判断したものは、設定・データの退避と復元方法を確かめてから正規の方法で削除します。使用中の子テーマが参照する親テーマを、未使用だと思って削除しないでください。

編集担当へ不要な管理者権限を渡さず、サーバー管理とCMS管理のアカウントをそれぞれ保護します。管理画面からのPHPファイル編集を無効にする設定も検討できますが、通常の更新まで止める設定とは区別します。WordPress公式:権限・ファイル編集・プラグインの保護。

二段階認証を使う場合は、サーバー会社のアカウントとWordPressの管理者アカウントを別々に確認し、本人が認証手段を登録して復旧方法を保管します。プラグインを入れただけで登録が完了したとは扱いません。これは不正ログインへの備えであり、ログインを必要としないPHPの脆弱性を修正する対策ではありません。

改ざんが疑われる場合は、PHPの更新だけで復旧完了にしない

覚えのない管理者、別サイトへの勝手な転送、不審なファイル、見慣れないページなどがあれば、修正版の適用とは別に侵害調査が必要です。見覚えのないファイルを片端から消す前に、サーバー会社・保守担当へ連絡し、ログや対象ファイル、発見したURL・日時を保全します。

1. 被害の拡大を抑える。担当者が公開制限や分離の必要性を判断します。データ保全と利用者への影響を同時に考えます。
2. 入口と影響範囲を調べる。PHPだけでなく、CMS、管理者、外部連携、同じ契約内のサイトも対象を整理します。エラーや停止が起きたことだけで攻撃と断定しません。
3. 原因を直して、信頼できる状態へ戻す。侵害前と確認できるバックアップや正規ファイルから復旧し、修正済みの実行環境を使います。改ざんされた状態のバックアップをそのまま公開し直さないようにします。
4. 認証情報と再発を確認する。保守担当と相談し、安全が確認できる端末から必要なパスワード・キー・セッションを更新または無効化します。公開後も同じ兆候が再び出ていないかログを確認します。

参考:WordPress公式:侵害が疑われる場合の記録・調査・復旧。外部サービスの障害との切り分けにはシステム障害ページも利用できますが、他社の障害が載っていることだけで自サイトの異常原因を決めないでください。

PHP管理を続けるための点検表:担当・期限・確認結果を残す

次は運用を組み立てるための目安です。サイトの更新頻度や扱う情報に合わせて調整し、重大な脆弱性の通知は定例日を待たずに確認します。

管理台帳には、ドメイン/本番・検証の別/PHPの系列と実行版/提供元・修正履歴/サポート終了日/担当者/バックアップ日時/最終確認日/次の作業期限を残すと確認漏れを減らせます。パスワードや復旧コードは、この台帳と同じ共有文書へ書かず、アクセスを制限した専用の保管方法で管理してください。

PHP脆弱性対策で迷いやすいこと

WordPressの更新画面で「最新」なら、PHPも最新ですか?

別です。WordPress本体の更新状態と、サーバー上のPHPの版は個別に確認します。PHPはサイトヘルスとサーバー会社の情報を照合してください。

PHPを使わない静的サイトも、対応が必要ですか?

HTML・画像などを配信するだけでPHPを実行しない構成と、問い合わせフォームだけPHPを使う構成では異なります。表側が静的でも、旧フォーム・管理ツール・検証サイトにPHPが残っていないか、担当者へ確認してください。

PHPのバージョンを隠せば安全になりますか?

情報を余分に出さない対策は有用ですが、欠陥自体は残ります。版の表示を消すことより、修正の適用と不要な公開機能の整理を優先してください。

すぐに更新できない古い業務システムはどうしますか?

運営者・保守担当・事業責任者で、更新を妨げる機能、代替手段、移行に必要なデータと費用を整理します。公開制限で守れる範囲を確認し、有効な保護が難しければ一時停止や移行も判断します。古い版へ依存する事情を、無期限に未対策で運用する理由にはしないでください。