「ホームページはいつもどおり開けるけれど、緊急更新の話はうちにも関係する？」。
PHPの修正案内を見ても、店主が自分でサーバー設定を変える必要はありません。まず契約済みの保守会社へ、対象かどうかと対応予定を確認しましょう。
PHPは、サーバー側でホームページの処理を動かす仕組みの一つです。見えるページの更新とは別に管理されることがあります。
今回は2026年10月21日に公開された重大な修正について、店舗の責任者が依頼と完了確認を進める3手を整理します。
10月21日のPHP重大修正を受け、店舗が保守会社へ確認する順序を整理。サイトの表示だけで判断せず、利用環境・修正の適用・予約や問い合わせの動作まで確かめます。
この記事でわかること
- PHPを使う場所と管理担当を確認
- 版番号だけでなく、両方の修正への対応を確認
- 更新完了と業務の動作、侵害調査を分ける
修正は公開済み。表示できることと、安全確認は別です
予告を待つ段階から、修正の適用を確認する段階へ。
PHP開発チームは10月21日、認証なしの遠隔コード実行につながり得る2件の脆弱性を修正しました。脆弱性とは悪用されるおそれのある弱点、遠隔コード実行とは外部からサーバーの処理を動かされ得る問題です。
識別番号はCVE-2026-109618とCVE-2026-109619です。公式の修正版は8.5.12、8.4.27、8.3.36、8.2.35。
案内はWebのリクエストを処理するPHP環境全般を対象としており、特定のCMSだけの問題ではありません。レンタルサーバーを使う場合も、サーバー会社と制作・保守会社のどちらが管理するかを確認します。
「まだページが開く」「ログインに問題がない」は未修正かどうかの判断材料になりません。公式は速やかな更新を強く勧めています。
古い予告の時刻だけを見て待たず、現在の配布元の対応状況を確かめてください。
1. サイト名だけでなく、PHPが動く場所を確認します
予約・問い合わせ・管理画面を、担当者と一覧にします。
混同しない3つの更新
どこまで確認したかを分ける
- 1ページの文章案内が新しくてもPHP更新の証明ではない
- 2CMSの更新最新表示だけで実行環境まで判断しない
- 3PHPの修正保守担当が配布元と稼働環境を確認
最初の依頼は「当店の公開サイトでPHPを使っていますか。使う場所と管理会社を教えてください」で十分です。
トップページだけでなく、予約、問い合わせ、会員向け画面、別のサブドメインも確認対象に含めます。これは確認漏れを減らすための店舗向け提案です。
静的なページだけを配信していても、同じサーバーにPHPで動く別の入口がないとは限りません。外部の予約サービスへつないでいるなら、そのサービスの公式案内も別に確認します。
逆に、PHPを使っていないと確認できた範囲まで、この2件の修正対象と決めつける必要はありません。技術面では、メモリー不足の処理で初期化途中の内部データが不正な状態になる問題が説明されています。
mod_phpという実行方式では、アプリ本体が動く前の攻撃実証も示されました。だから、CMSの管理画面のパスワードを変えるだけでは今回の修正の代わりになりません。
実行方式の判断は保守担当へ任せましょう。
2. 「何番にしたか」だけでなく、修正への対応を聞きます
配布元が古い版へ修正を移す場合もあります。
保守会社には、2つのCVE番号を添えて「対応済みか、作業予定はいつか、完了は何で確認するか」を尋ねます。修正を依頼したことと、実際に適用されたことは別です。
回答した担当者と確認日時を残すと、交代時も話がつながります。PHP公式は、Linuxの配布元や長期保守の提供元が修正を提供する場合も案内しています。
これは、古い版を基に必要な修正を移す対応を含みます。画面の数字が上流の修正版と違うだけで未対応と断定せず、提供元の告知とパッケージの修正状況を担当に確認してもらいます。
また、CMSやプラグインの更新と、サーバーのPHP更新は別の確認です。管理画面に「最新」と出ただけで終わらせず、Webで実際に動いているPHPに両方の修正が反映されたかを尋ねます。
端末のコマンドで見た番号だけを、すべてのWeb処理の確認済み報告として受け取らないようにします。
3. 更新の記録と、予約・問い合わせの動作を分けて確かめます
技術担当の適用確認と、店側の業務確認をセットに。
保守会社への依頼メモ
担当・予定・完了確認を一行ずつ
- 1対象使う場所と2件のCVEへの対応
- 2作業担当者、作業予定、残る確認
- 3完了適用の記録と予約・問い合わせ動作
技術担当には、稼働中の環境が修正済みに切り替わったこと、必要な再起動や切替が終わったことを確認してもらいます。店側では、通常の使い方でページ、予約案内、問い合わせ導線を確認します。
実際の顧客情報を使った試験や、攻撃の再現をする必要はありません。もう一つの弱点は、前の処理に属する内部状態が残り、後の処理から参照される問題です。
公式の技術告知は、方式や設定によって成立条件が異なること、設定変更だけで網羅的に防ぐ方法はないことを説明しています。エラーが記録されていないことも安全の証明にはなりません。
すぐ更新できない場合は、暫定対応とその限界、業務への影響、再確認する時刻を責任者と保守担当で決めます。一般向けの記事に載った設定値をそのままコピーせず、自社環境の判断を依頼してください。
更新済みの確認と、過去に侵害がなかったかの調査も別です。不審な変更があれば、記録を自己判断で消さず専門担当へつなぎます。
まとめ：店主の仕事は、担当と完了条件をそろえることです
「任せています」を、確認できる依頼へ変えましょう。
今回の資料で確認できる攻撃の実証と、現実の店舗で被害が確認されたことは同じではありません。ここでは被害件数や全国的な攻撃の広がりを断定しません。
自分の店の対象範囲と、対応の進み具合を確かめることが先です。今日送るなら、「当店でPHPを使う場所、2件のCVEへの対応状況、作業予定と完了確認、更新後の動作確認担当を教えてください」という依頼から始められます。
秘密のパスワードをメールへ添える必要はありません。まず一つ確かめるなら、サーバーの更新完了を報告してくれる担当者は誰ですか。
noticaでは、ホームページの更新担当や案内の引き継ぎを整理する相談を受け付けています。脆弱性対応や侵害調査は保守会社・専門窓口へ。
役割を分けて、迷わず確認できる運用を整えましょう。情報確認日：2026年10月22日。
画像は説明用の生成イラストです。連絡が一度で終わらない場合は、回答待ちの項目と次に連絡する人を短く残します。
「サーバー会社へ確認中」と「修正適用済み」を別の状態にしておくと、忙しい時間帯の引き継ぎでも誤解を減らせます。