まず、サイトを動かすPHPと担当を確認する
朝、PHPの緊急更新の知らせを見たものの、自社サイトが対象なのか分からない。制作会社へ連絡しても「サーバーは別会社の管理です」と返ってくる。そんな場面では、対象と担当をそろえ、どこまで確認できたかを残すことから始めます。
PHPは、Webサイトなどをサーバー側で動かすために使われる言語です。PHP公式は2026年10月21日、認証なしで外部からコードを実行されるおそれがある2件の重大な脆弱性に対し、修正版を公開しました。対象の識別番号はCVE-2026-109618、CVE-2026-109619です。
この記事の公式情報の確認日は10月22日です。修正版の公開を待つ段階ではありません。自社に被害が起きたと決めつけず、利用の有無と更新状況を運用担当へ確認してください。
SHINJIDAI独自作成。対象と担当・確認事項を整理する業務上の提案で、個別環境の安全性や復旧を保証する図ではありません。
修正版と、提供会社の適用情報を照合する
PHP公式が示す修正版は、8.5系が8.5.12、8.4系が8.4.27、8.3系が8.3.36、8.2系が8.2.35です。Webリクエストを処理するPHPの実環境について確認します。手元の開発用パソコンの番号だけでは、本番の確認になりません。
ディストリビューションや長期サポートの提供会社が、既存パッケージへ修正を取り込む場合があります。PHP 8.1以前はPHPプロジェクトの更新対象外ですが、提供会社による修正の有無は個別に確認する必要があります。表示番号だけで対応済み・未対応を断定しません。
運用担当からは、対象環境、パッケージと提供元、該当する2件への修正情報、適用した時刻と確認結果を受け取ります。更新に使ったコマンドの実行だけで終わらず、実際に動いている環境へ反映されたかを確認する役割も決めます。
PHP 8.5系
8.5.12
PHP 8.4系
8.4.27
PHP 8.3系
8.3.36
PHP 8.2系
8.2.35
出典：PHP「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日、修正版と更新方法）。原資料はこの節のリンク。公式発表のバージョン情報をSHINJIDAIが独自に整理した図です。提供会社による修正パッケージは個別確認が必要です。
自社管理・委託・サービス利用で、確認先を分ける
一覧には、公開サイトだけでなく、申込画面、会員向けの画面、使っているWebシステムなど、確認すべき対象を並べます。対象名、URL、利用環境の確認者、運用会社、更新を判断する担当、回答の期限が分かる形にします。
自社でサーバーを管理しているなら、自社の運用・セキュリティ担当が提供元情報と対象を照合します。制作とサーバー運用を委託しているなら、契約上の役割を確かめ、双方の回答をつなぐ窓口を決めます。外部サービスの利用では、提供会社の正式な案内と自社の利用範囲を確認します。
PHPを使っているか不明な対象は、不明のまま確認先を付けます。一つのサイトが未使用と分かっても、別のシステムや委託先まで対象外とは判断できません。
運用・提供会社
- 利用環境と対象を照合
- 修正の根拠・適用結果を記録
- 暫定対応と残る作業を説明
自社の業務・管理窓口
- 止めると困る手続きと代替を整理
- 申込・通知・連携の結果を確認
- 再開と残作業の担当・期限を決める
SHINJIDAI独自作成。対象と担当・確認事項を整理する業務上の提案で、個別環境の安全性や復旧を保証する図ではありません。
WordPress本体の更新と、PHPの更新を混同しない
WordPress公式は、今回の脆弱性はWordPress固有ではなく、PHPを使うサーバーに関係すると説明しています。この問題に対するWordPress本体の更新は必要・予定ともしていないため、WordPressの更新ボタンだけで解消したとは判断しません。
同公式は、管理画面の「ツール→サイトヘルス→情報→サーバー」でPHPのバージョンを確認できると案内しています。ただし、確認できる権限と対象のサイトに限ります。分からない場合は、IDやパスワードを社外フォームへ書かず、既存の運用担当へ確認してください。
ホスティング会社の案内も、契約やサーバーの管理方式で役割が変わります。例えばNamecheapの10月21日の案内は、同社側の対応と、利用者が管理するVPS・専用サーバーでの更新を区別しています。他社の対応案内を、自社の契約先も完了した根拠にはしません。
4つの対象を並べると、次に確認することが変わる
次の4つは架空の業務例です。Aは会社案内サイトで、PHPの利用が不明。窓口担当が運用会社へ確認中です。Bは申込サイトで、提供会社が暫定対応を案内していますが、修正版の適用完了はまだ確認できていません。
Cは会員向けの画面で、修正版の適用を運用担当が確認したものの、ログイン後の手続きと通知の確認が残っています。Dは外部サービスで、提供会社の対象範囲と自社契約の対応を確認し、必要な業務確認も終えた想定です。どれも実在のシステムや被害を示すものではありません。
経営・業務責任者には「何件対応中か」だけでなく、利用への影響、残る確認、判断する担当と次の時刻を共有します。「業者へ連絡した」を全対象の安全確認へ置き換えないためです。
A｜利用の有無が不明
運用会社の回答待ち。未使用・対応済みとしない
B｜暫定対応の連絡あり
修正版の適用結果と、残る制約を確認
C｜修正版の適用を確認
業務担当が手続き・通知・連携を確認する
D｜必要な確認を実施
確認範囲を記録し、続報・残作業を引き継ぐ
SHINJIDAI独自作成。対象と担当・確認事項を整理する業務上の提案で、個別環境の安全性や復旧を保証する図ではありません。
暫定対応を更新完了とせず、業務への影響も決める
PHP公式は、更新だけが完全な解決策であり、暫定的な対策は一部の攻撃経路への露出を下げても安全な状態を保証しないとしています。「WAFがある」「設定を変えた」という説明だけで確認を終えません。
すぐに更新できない場合は、運用・セキュリティの責任者が公式情報と環境を照合し、公開を続ける条件、一時停止の必要性、次に判断する時刻を決めます。担当者が記事の断片を見て本番の設定を変更する進め方は避けます。
停止を検討する対象では、申込や問い合わせの代替窓口、処理中のデータ、再開の判断者も必要です。連絡文は確認済みの影響を基にし、被害が未確認の段階で侵入・漏洩が起きたと断定しません。疑わしい事象がある場合は、既存の事故対応手順と専門担当へつなぎます。
更新後は、画面の表示から業務の記録まで確認する
業務を戻す前に、確認する手続きを対象ごとに決めます。会社案内の表示だけでなく、申込、ログイン、ファイルの受け渡し、通知、外部システムとの連携など、実際に使う機能を運用担当と洗い出します。
問い合わせフォームなら、画面で成功と出ること、受付の記録が残ること、担当へ届くことは別の確認です。実送信の試験が必要なら、担当と実施条件を決め、診断用のデータを実際の相談や売上へ混ぜません。
切替前のバックアップと戻す条件は運用担当が合意します。ただし、脆弱な版へ単純に戻せばよいという意味ではありません。不具合が出た場合の公開範囲や代替手順も含め、業務と安全性の双方から判断します。
- 対象環境に該当する修正の根拠と、適用結果・確認者・時刻が残っている。
- 主要な業務と例外・外部連携を、合意したテストデータと手順で確認する。
- フォームの成功表示、受付記録、通知・配送を分けて確認する。
- 不具合・制約・未確認を残し、次の担当と期限を引き継ぐ。
- 再開や切替の判断者と、続報を確認する担当を決める。
確認が止まっている箇所から、既存保守と改修を整理する
最初に相談したいのは「PHPを使っているか分からない」「委託先の担当が分かれる」「更新後の業務確認が決まっていない」といった箇所です。対象の概要と既存の契約先から整理でき、認証情報や本番データを初回に送る必要はありません。
SHINJIDAIは課題の確認・解決策の提案から、合意した設計・開発・導入まで伴走します。このテーマでは、対象・連携・既存保守の役割を確認し、提供会社の更新、既存設定、接続部分の見直し、必要なアプリ改修を比較します。緊急更新を理由に、サイト全体の作り直しを先に決めるものではありません。
発注側は対象と業務の優先順位、既存委託先との調整、停止・再開や完成確認の担当を決めます。支援側は合意した調査・実装・移行・検証を設計します。費用は環境の数、旧版との互換性、連携、確認範囲、変更・保守で変わるため、対応可否と範囲を着手前に確認します。
常時監視、緊急駆け付け、侵害調査や復旧の完了を、この相談だけで約束するものではありません。既存の運用・事故対応を止めず、必要な専門担当との役割をそろえます。
業務の課題整理から、設計・開発・導入まで
対象と担当をそろえ、更新後の業務確認までつなぐ
SHINJIDAIにご相談ください。
- PHPの利用や、誰が更新するかが分からない
- 委託先の「対応中」から先の確認が止まる
- 申込・通知・外部連携の確認範囲を決めたい
課題の整理から伴走対象・連携・既存保守の役割を確認し、提供会社の更新、設定・接続・必要な改修を比較します。合意した範囲を実装し、業務担当者と主要手続き・通知・連携・残作業を確かめます。
最初は対象と、確認が止まる箇所の概要から。調査・実装・検証・移行・保守の範囲と費用は着手前に合意します。
個別環境の対応可否は確認が必要です。常時監視・即時対応・侵害調査や復旧完了を、この相談だけで約束しません。
ID・パスワードや顧客データは、フォームに記載しないでください。
セキュリティ整備・伴走の範囲を見る出典
確認日：2026年10月22日。PHP公式の10月21日の修正版公開と勧告を主な技術根拠にし、WordPressとホスティング会社の公開案内を照合しました。続報と、実際に使う製品・提供元の案内を確認してください。
本文の4対象と業務図は独自の架空例・運用提案です。第三者の図・ロゴ・画面は転載していません。公的機関や製品提供会社による推薦、SHINJIDAIとの提携、個別環境の診断・修正済みを意味しません。
よくある質問
WordPressを更新すれば、今回のPHPの問題も直りますか？
WordPress本体と、サーバーで動くPHPは別です。WordPress公式も今回の問題をPHP側の脆弱性として案内しています。ホスティング・運用担当へ、Webリクエストを処理するPHPへの修正適用を確認します。
PHPを使っているか分からない場合はどうしますか？
サイトとシステムを対象ごとに並べ、運用担当・提供会社へ確認します。ドメイン、サービス名、契約先、確認時刻と回答待ちを残し、不明を未使用や対応済みへ変えません。
委託先から「対応中」と返事があれば完了ですか？
対象を受け付けたのか、暫定対応をしたのか、修正を適用したのかを分けます。対象環境と修正の根拠、適用時刻、残る作業、業務確認を誰が行うかまで確認します。
表示されたPHPの番号が公式の修正版より古ければ、必ず未対応ですか？
提供会社が修正を既存のパッケージへ取り込む場合があります。番号だけで断定せず、対象環境のパッケージと公式の提供元情報、該当脆弱性への修正適用を運用担当に確認します。
すぐ更新できないときは、担当者が設定を変えればよいですか？
管理者・セキュリティ担当が公式情報と個別環境に基づいて判断します。暫定対応を更新完了と扱わず、公開を続ける条件や一時停止、代替業務、次の判断時刻を合意します。この記事は具体的な設定値の変更手順ではありません。
SHINJIDAIへは何を相談できますか？
現在のサイトや連携、委託先との役割、確認が止まっている箇所を整理し、既存保守・設定・連携・改修の選択肢を比較できます。調査・実装・確認の対象と費用を先に合意し、個別の対応可否を確認します。