PHP 脆弱性/今後の注意と確認事項

PHP（ピーエイチピー）問題で今はサイトが使えていても、運営者は修正適用と受付の動作を、利用者は予約・申請の完了を確認してください。画面が表示されることだけでは、対策済みかどうかは分かりません。

今すぐ確認すること

自社サイトや店舗のホームページを任されている人は、次の項目を順に埋めます。操作に不慣れなら、サーバーの設定を変更する前に契約先の保守担当へ渡せる確認表にしてください。

1. 対象と担当を特定する。自社サイト、予約ページ、会員画面などのURLと、サーバー会社・保守会社・連絡先を控えます。
2. 今回の2件の修正が適用済みか、対象ドメインを指定して確認します。「対応を進めています」という全体案内だけなら、自分の環境への適用状況を尋ねます。
3. Web（ウェブ）で使うPHPへの反映日時を確認します。更新ファイルを入れただけか、必要な再起動も含めて稼働中の処理へ反映したかを保守担当に尋ねます。
4. 予約・問い合わせ・注文を、許可されたテスト方法で最後まで確認します。送信完了画面、受付履歴、通知先への到着を照合します。
5. バックアップの保存日時・保存先・復元手順を確認します。更新に備えるときはファイルとデータベースの両方を対象にします。
6. 不審な変更やエラーがあれば、発生日時・URL・画面を記録し、保守担当へ連絡します。個人情報や認証情報をSNSへ載せないでください。

この確認表は当サイトが提案する運用手順です。予約や決済を試すときは、本番の二重予約・二重請求を起こさないよう、店舗やサービスが指定するテスト方法を使います。

修正済みの確かめ方

PHP公式の10月21日の発表では、今回の修正版は次の4つです。今回の2件（CVE-2026-109618、CVE-2026-109619）が修正されています。CVE（シーブイイー）は脆弱性の識別番号です。ログイン前の処理を含む問題のため、管理画面に強いパスワードを設定しただけで解決したとは言えません。

この表は今回の修正が入った版です。今後さらに更新が出た場合は、契約先が提供する対応済みの新しい版を確認してください。

表示される版番号だけで、未対応と断定しないでください。配布元が元の版番号を保ちながら修正を取り込む「バックポート」があるためです。たとえばUbuntu（ウブントゥ）は、独自のパッケージ番号で今回の修正を案内しています。サーバー会社の適用回答や配布元の告知と照合します。

WordPress（ワードプレス）では「ツール→サイトヘルス→情報→サーバー」でPHPの版を見られます。ただし、コマンド操作用のPHPとWeb表示に使うPHPが異なる環境もあります。保守担当には、実際に対象サイトのリクエストを処理する環境で確認してもらいます。

WordPress公式は、今回の問題に対するWordPress本体の更新は必要・予定ともにないと説明しています。今回の確認先はサーバー側のPHPです。テーマやプラグインに別の更新があるかの点検は、日々の保守として続けます。

利用者ができる確認

予約サイトや不動産・行政・買い物のサービスを利用する立場なら、提供元のPHPを自分で更新することはできません。まず公式サイトや公式アプリのお知らせから、使う機能が対象か、代替窓口があるかを確かめます。

• 送ったつもりの予約・申請は、受付番号や利用履歴が残っているか確かめる。
• 決済後にエラーが出た場合は、利用履歴や公式窓口で状況を確認してから再操作する。
• 停止中なら、公式に案内された電話・窓口・代替フォームを使う。
• 修正を装うメールのリンクからログインせず、普段のブックマークや公式アプリから案内を開く。

「復旧したから、途中の手続きも完了している」とは限りません。心配なのは、画面の再開と自分の受付結果を一緒にしてしまうことです。締切のある申請や予約は、問い合わせ日時と先方の回答も控えておくと照合できます。ここに挙げた項目は確認の提案で、特定サービスの未処理や被害が発生したという報告ではありません。

今後の備えと更新期限

PHP 8.2を今回の8.2.35へ更新しても、そのまま何年も使い続けられるわけではありません。PHP公式のサポート表では、8.2のセキュリティ修正は2026年12月31日までです。8.3は2027年末、8.4は2028年末、8.5は2029年末までと案内されています。

8.1以前は通常の公式サポートが終わっています。一部の旧版には今回だけの最小限のソース修正が提供され、配布元が独自対応する場合もありますが、通常サポートが再開したという意味ではありません。適用可否と継続保守の期限を契約先に確認し、サポートを受けられる環境への移行日を決めます。

私は、今回の対応を「更新しました」という連絡で終えず、次の担当者と期限まで残す形が現実的だと考えます。サイト制作を頼んだ会社と、毎月の保守を担当する会社が同じとは限らないからです。

• サポート終了日と移行予定日を一覧にし、更新作業を誰が行うか決める。
• PHPの版を上げる前に、テーマ・プラグイン・予約や決済の仕組みが対応するか、検証用の環境で確認する。
• バックアップを保存するだけでなく、ファイルとデータベースを復元できる手順を用意する。
• 公式の障害・セキュリティ案内を受け取る担当者と、休業日の連絡先を決める。
• 一時停止中も案内できる電話番号や受付方法を用意し、再開後は未処理分を照合する。

不審な管理者の追加、覚えのないページ、外部サイトへの転送などが見つかった場合は、画面と日時を記録して保守担当へ連絡します。更新を済ませたことだけで、すでに起きた変更まで調査済みとは判断できません。WordPress公式の侵害時の案内も、起きたことの記録と専門的な調査につながる情報の保全を勧めています。

管理会社への確認文

以下は問い合わせ用の文例です。サイトURLと担当者名を置き換え、契約先の窓口へ送ってください。パスワードや顧客情報を本文へ加える必要はありません。

今日の確認は、修正の根拠・受付の結果・次の更新担当がそろえば記録できます。回答がまだなら「確認中」として、誰がいつ返答するかまで決めておきます。サイトが動いている今のうちに、その記録を残してください。

出典・公式資料

確認時点：2026年10月22日。確認表と問い合わせ文は、上記資料を踏まえた当サイトの提案です。個別サービスの修正・被害・受付結果を保証するものではありません。アイキャッチはPexelsのコード画面写真（素材番号270360）を加工したイメージです。