PHPの緊急セキュリティ更新が公開。会社のサイト担当が確認すること

PHPの重要な脆弱性に対応する修正版が、2026年10月21日に公開されました。開発元は、Webからのリクエストを処理するPHPの導入環境に注意を促しています。会社のサイト担当者は、自社でPHPを使う場所と更新する相手を確認し、利用している構成に適した修正を保守会社や提供元へ依頼してください。

この記事は、同日に確認した開発元の公開済みアドバイザリを反映し、事前予告から更新したものです。

公開された修正と対象の条件を確認する

修正版と製品提供元の更新を確認

PHP開発元が今回の問題を修正した版として示したのは、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。導入している系統や、利用するサーバー・製品の管理方法を確認し、適用する更新を担当者と特定してください。修正版の番号が公表されたことと、自社へ反映されたことは別の状態です。

Linuxの配布元や長期保守の提供元が修正を取り込む場合もあるため、表示された番号だけで適用の有無を判断できないことがあります。製品や管理サービスの利用者は、提供元からの対応案内も確認してください。経営者が独自に配布物を選び、本番へ直接入れ替えることを前提にしません。

影響と攻撃の確認を分ける

開発元は、認証されていない利用者からのリクエストによって、遠隔からコードを実行される可能性がある問題を説明しています。これは影響を受ける条件と修正の必要性についての説明であり、自社が既に侵害されたことを示すものではありません。

一方で、被害が確認できていないという理由だけで、対応を後回しにすることも避けます。自社のサイトの構成、公開範囲、更新する相手を整理し、公式案内に照らして対応を進めます。不審な操作が見つかった場合は、更新の作業とは別に、確認した時点と残っている記録を専門家へ伝えてください。

利用している構成と対象を照合する

開発元は、Webリクエストを処理するPHPの導入環境を注意対象として挙げています。PHPの処理方法や、組み込まれた製品によって、自社で更新できる部分と提供元が管理する部分が異なります。会社の代表サイトだけでなく、受付や業務システムも含めて利用先を確認してください。

PHPプロジェクトによる通常の更新提供が終了した古い系統についても、提供元による修正の取り込みや移行の条件を確認します。独自の設定変更だけで安全になると判断せず、正規の修正と自社の構成に合った対処を管理担当へ依頼してください。確認できていない環境は、対象外として片付けず一覧へ残します。

自社のどこで使っているかを整理する

会社のサイトと受付機能を挙げる

自社の代表サイトだけでなく、採用、通販、会員向けページ、問い合わせ受付など、会社が運用するサイトを一覧にします。PHPを使っているか分からなくても、用途、URL、制作会社、サーバーの契約先が分かれば、確認を依頼する手がかりになります。

見た目が普通のWebページでも、受付や会員機能の処理にPHPが使われる場合があります。画面の印象だけで判断せず、実際の構成を確認できる担当へ聞いてください。過去に制作したまま担当が不明のサイトや、終了した企画の公開環境が残っていないかも、併せて整理します。

社内システムや組み込みの製品も確認する

Webサイト以外の業務システムや、提供元が管理する製品にPHPが含まれている場合もあります。自社で直接管理しているPHPと、製品の一部として使われる構成では、更新を提供する相手や方法が異なる可能性があります。

製品の一覧や契約から、提供元へ利用の有無と今回の影響を問い合わせます。利用版の表示だけでは判断できない事情がある場合は、その説明も残してください。ひとつの環境を更新すれば、会社のすべての利用先が変わるとは限りません。対象となる製品と実際の更新担当を対応させます。

利用していないことの根拠を残す

制作会社からPHPを使っていないと回答があった場合は、どのサイトや機能について確認した回答かを明確にします。サイトの表側だけの回答なのか、問い合わせの送信先や外部の業務機能まで含むのかで、確認できた範囲が変わります。

対象外の一覧には、回答した相手、確認した環境、確認日を残します。これは不必要な作業を増やすためではなく、別の環境の回答と取り違えないためです。自社の構成が後から変わった場合や、対象条件の続報が出た場合は、その根拠に照らして見直してください。

公開された更新の適用を依頼する

サーバー会社と制作会社の役割を分ける

サーバー上のPHPを管理する相手と、サイトのプログラムを管理する相手が同じとは限りません。保守契約で、今回のような注意情報の確認、更新、動作試験、問題が出た場合の対応がどこまで含まれるかを確認します。

相手が分かれた場合は、技術的な調整を誰がまとめるかも決めます。サーバー会社が更新しただけで、会社のフォームや通販の動作まで確認したとは限りません。逆に、制作会社が表示を確認しただけで、稼働中のPHPの更新が済んだとは限らないため、両方の結果を揃えます。

更新前の確認と戻す方法を相談する

更新によって必要な業務が動かなくなる場合に備え、検証する環境、バックアップの対象、復旧方法を担当者へ確認します。保存しているファイルだけでなく、注文や問い合わせなどのデータがどう扱われるかも重要です。

ただし、公開されたアドバイザリだけから、自社で使える復元手順まで決めることはできません。問題が出たら古い状態へ戻せばよい、と一律に考えず、脆弱性が残ることや、その間に受け付けたデータの整合性も専門家へ確認してください。更新の準備と、事故の調査のための記録保全も区別します。

作業時間と連絡先を揃える

作業中に影響を受けるのが、ページ表示、問い合わせ受付、受注、社内の処理のどれかを確認します。業務を止める必要がある場合は、関係する担当と代わりの受付方法を考えます。停止や再開の見込みは、提供元の予定と自社で合意した作業を分けて説明してください。

根拠のない固定日数や時間を、一般的な対応基準として指定するものではありません。公式の注意情報と実際の影響を踏まえて優先度を判断します。作業を行う担当、了承する責任者、問題が出たときに連絡する相手を、すぐ確認できる状態にしておきます。

適用後に確かめることを決める

更新が反映された環境を確認する

修正が公開されたことと、自社環境へ適用されたことは別です。保守担当には、更新した環境、適用した内容、実施日時、反映を確認した方法を報告してもらいます。検証用の環境だけで終わっていないか、本番の対象も確認してください。

提供元側で準備が必要な製品については、対応の予定と、まだできていないことを確認します。依頼を受け付けた記録を更新完了と扱わないようにします。対象外とした環境があれば、その判断の根拠も残してもらうと、対応漏れと区別しやすくなります。

表示だけでなく受付や連携を試す

更新後は、会社の業務に必要な操作を確認します。例えば問い合わせフォームなら、送信画面だけでなく、受付先で確認できることや必要な通知が届くことも、担当者と試験の範囲を決めます。通販や会員機能がある場合は、その業務に応じた項目を追加します。

テスト用の送信が顧客への通知や実際の注文にならないよう、実施する条件を先に揃えてください。確認していない機能や、検証と本番の違いが残る場合は、未確認として報告します。すべての会社に同じ試験や一律の合格率を当てはめるものではありません。

続報と未対応を追跡する

公開後も、対象の説明や製品提供元の対応状況が更新される可能性があります。公式情報を確認する担当と、自社の一覧へ結果を反映する方法を決めてください。未対応の環境には、理由、次の対応、担当者を残します。

今回の更新に対応したことだけで、サイト全体の安全性や、過去に侵害がなかったことまで保証できるわけではありません。不審な挙動がある場合は、更新作業とは別に調査の窓口へ相談します。まずは自社の利用先と管理の役割を整理し、公開された修正を、自社の利用環境へ適用する対応を進めます。