PHPの重大な脆弱性で、Web制作・保守は何をすべき？WordPressサイトの確認と更新の進め方

PHPの重大な脆弱性に関するニュースを見て、「自社のホームページも対象なのか」
「制作会社に何を確認すればよいのか」と気になった方もいるのではないでしょうか。

Web制作・保守の現場で大切なのは、ニュースを共有して終わることではありません。
管理している環境を把握し、修正の適用担当を決め、更新後に事業で使う機能まで確かめることです。

この記事では、2026年10月に公表されたPHPの問題を入口に、
WordPressサイトを制作・管理する立場から確認の進め方を整理します。
実際に個別サイトを調査した結果や、当社の対応完了を報告する記事ではありません。

情報確認日：2026年10月22日。修正情報や提供状況は変わるため、
作業時にはPHP公式と利用サーバー会社の最新案内を確認してください。

今回のPHPの問題で、公式に案内されていること

PHP公式は2026年10月21日、認証なしの遠隔コード実行につながり得る2件の重大な脆弱性を公表し、
修正版への速やかな更新を呼び掛けています。識別番号はCVE-2026-109618とCVE-2026-109619です。

同日の修正版は、次のとおりです。

利用している系列	今回の修正が入ったバージョン
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Webリクエストを処理するPHP環境が対象とされ、特定のWordPressプラグインだけの問題ではありません。
公式は、暫定措置では完全な解決にならず、更新が必要と説明しています
。PHP公式のセキュリティ告知

この表は、今回修正された版を示すものです。今後も常にこの番号が最新版という意味ではありません。
また、サーバー会社やOSの提供元が修正を取り込んだパッケージを提供する場合もあるため、
画面上の番号だけで適用の有無を決めず、提供元の告知と照合します。

WordPressの更新と、PHPの更新は別に確認する

WordPressは、PHPを使って動く仕組みを含みます。
ただし、WordPress本体、テーマ、プラグイン、PHPは、それぞれ別の更新対象です。

管理画面でWordPressを更新しただけでは、サーバー側のPHPが修正済みになったと判断できません。
セキュリティプラグインの導入や、トップページが正常に表示されていることも、
PHPへの修正適用の証明にはなりません。

制作担当は、どの層の問題に対して、どこを更新したのかを分けて説明する必要があります。
「対策済みです」と伝えるなら、その対象と確認根拠も残しましょう。

最初に作るのは、対象サイトと担当者の一覧

まず、管理しているドメインとサーバーを並べます。
本番サイトだけでなく、公開状態の検証環境、サブドメイン、旧サイトも確認対象として洗い出します。

確認項目	記録する内容
対象	ドメイン、用途、本番・検証の区別
環境	サーバー会社、契約、Web側で使用するPHP
修正状況	提供元の告知、適用済みか、未確認か
担当	更新する人、動作確認する人、判断する人
次の行動	作業予定、確認先、残っている課題

WordPressでは、管理画面の「ツール→サイトヘルス→情報」に、
サーバーなどの技術情報を確認する入口があります。表示項目や権限は環境により異なります
。WordPress公式のサイトヘルス案内

サーバー管理画面の表示と合わせて確認し、分からなければ管理会社へ問い合わせます。
複数のサイトやPHP実行環境がある場合は、一つの表示を全環境へ当てはめないようにします。

技術担当がコマンドで確認する場合も、CLI用PHPとWebから実行されるPHPが同じとは限りません。
コマンドの表示だけで、本番サイトの適用確認を済ませないことが大切です。
確認用の詳細情報を公開ページへ出したままにする運用も避けます。

サーバー会社と制作会社の役割を、契約に沿って分ける

レンタルサーバーではPHPの更新をサーバー会社が担当する場合があります。
一方、管理者自身がOSやPHPを管理する契約なら、管理担当が更新する必要があります。
実際の分担は契約とサービス仕様で確認してください。

「サーバー会社が作業するから、制作側は何もしなくてよい」とは限りません。
制作・保守側には、対象サイトの把握、顧客への説明、アプリケーションの互換性確認、
更新後の機能確認などの役割があります。

連絡するときは、次の四つをそろえます。

• この契約・環境に対する修正の提供状況
• 自動で適用されるか、利用者の操作が必要か
• 適用を確認する方法と、サービス再起動等を含む作業範囲
• 制作側が動作確認すべき時点と、問い合わせ先

適用日時が未定なら、未定と記録します。「全サイトが更新されたはず」と推測せず、対象ごとの状態を残します。

迅速な更新と、重要機能の確認を並行して進める

今回のように更新が強く求められる場合、普段の月次保守まで待つ前提で考えないことが大切です。
一方、準備なく設定を変更して業務を止めないよう、必要な確認を絞って進めます。

1．バックアップと復元方法を確かめる

データベースとファイルについて、取得時点、保存先、復元する担当と手順を確認します。
バックアップがあることは、脆弱性への対策や、侵害がないことの証明にはなりません。

2．修正の適用と、系列をまたぐ移行を分けて考える

まず利用系列の修正版や、提供元が案内する修正済みパッケージを確認します。
「この機会に全サイトを別系列へ移す」という大きな変更と、緊急の修正適用を混同しないようにします。

古い環境で修正の提供が不明なら、提供元へ確認し、対応方針を決めます。
PHPの公式サポートが終了した系列を使い続ける場合は、延長サポートの有無と対象範囲を確認するとともに、
対応する系列への移行計画が必要です。PHP公式サポート一覧

3．サイトで重要な操作を先に決める

可能なら検証環境で短時間の確認を行い、更新後の本番でも主要操作を確かめます。
検証準備が整うまで無期限に待たず、適用までの露出やサービス継続を管理担当と判断します。

トップページが見えるだけでは、動作確認は終わらない

見た目が変わっていなくても、送信や保存、連携が動かなくなると事業に影響します。
サイトごとに重要な機能を選びます。

機能	確認する到達点
お問い合わせ	入力、送信、受付記録、管理者通知、自動返信
ログイン	ログイン、ログアウト、必要な権限での操作
記事更新	下書き保存、画像登録、プレビュー、公開
予約・購入	検証用の条件で受付・通知・外部連携まで確認
定期処理	対象ジョブの実行結果、失敗通知

フォームは「送信しました」の画面だけでなく、メール到達や保存結果まで見ます。
購入・予約の確認は、実課金や実在客への通知を発生させない方法を事前に決めて行います。

エラーが出た場合は、発生時刻、対象操作、ログを残し、復旧担当と判断します。
問題を避けるために未修正の版へ戻し、そのまま公開を続けることを通常の解決策にしないようにします。

「更新完了」と「侵害がない」は、別の報告

作業記録には、対象環境、適用前後の情報、作業日時、担当、確認した機能、未確認項目を残します。

更新後に異常が見つかった場合は、ログや関連データを保全し、
サーバー会社やセキュリティ対応の担当へ相談します。
ログに目立つ異常がないというだけで、侵害がなかったとは断定できません。

顧客への報告も、次のように分けると誤解を減らせます。

対象環境への修正適用を確認しました。フォーム送信と管理者通知、管理画面のログインを確認しています。
外部予約システムとの連携は確認中です。今回の作業は更新と動作確認であり、
侵害の有無を網羅的に調査したものではありません。

これは報告文の例で、当社や特定サイトの実際の対応状況を示すものではありません。

サイト所有者から管理会社へ送れる確認文

PHPの重大な脆弱性について、自社サイトの対応状況を確認したくご連絡しました。
対象ドメインは【ドメイン】です。Web側で利用しているPHP環境、
今回の修正の適用状況と確認根拠、当社側で必要な操作、今後の予定をご教示ください。
また、更新後のフォーム・ログイン・予約等の動作確認をどなたが担当するか、
未確認の項目があれば併せてお知らせください。

管理情報が分からなくても、ドメインと契約先から確認を始められます。
パスワード等は通常のメール本文へ書かず、管理会社が指定する方法で扱います。

Web制作は、公開後も動く状態を支える仕事

制作会社として考えたいのは、ページを作って終わるかどうかではなく、
更新が必要なときに誰が動ける状態になっているかです。

管理先、担当、確認項目を普段から整理しておけば、緊急時の最初の連絡が具体的になります。
今回の修正適用とあわせ、保守契約の範囲や、連絡がつかないときの引き継ぎ先も見直しておきましょう。

自社サイトの管理状況やWeb制作について整理したい方は、株式会社REPRESENTのホームページ制作をご覧ください。個別の作業範囲は、環境と契約を確認したうえで相談します。