「PHPに重大な脆弱性が見つかった」と聞いても、自社でPHPを使っているのか、誰に対応を頼めばよいのか、すぐには分からないことがあります。

2026年10月21日、PHP開発元は外部から不正なプログラムを実行されるおそれがある2件の脆弱性について、修正版を公開しました。[1]

まず必要なのは、自社のサイトやシステムが対象かを確認し、修正を適用することです。管理会社へ連絡する際は、「大丈夫ですか」だけでなく対象のURL、修正状況、確認結果まで聞くと、対応の抜けを見つけやすくなります。

※脆弱性と修正版に関する情報は2026年10月22日時点のものです。公開後の更新情報はPHP開発元や利用しているサービスの提供元で確認してください。

今回公表されたPHPの脆弱性2件とは

PHPはWebサイトやWebシステムをサーバー上で動かすためのプログラミング言語です。WordPressなどにも使われています。

今回の問題はPHP本体の内部処理にあります。2件とも深刻度は「Critical」で、CVSS v4.0の評価は10点満点中9.2です。[2][3]

識別番号 どのような問題か 起こり得る影響
CVE-2026-109618 メモリ不足が起きた際、準備が途中の内部データを、終了処理で正常なデータとして扱ってしまう問題 条件によって、ログインしていない第三者に不正なプログラムを実行されるおそれがある
CVE-2026-109619 使用を終えたメモリを参照する内部情報が残り、後のリクエスト処理で使われてしまう問題 条件によって、ログインしていない第三者に不正なプログラムを実行されるおそれがある

出典：PHP開発元のセキュリティアドバイザリ。[2][3]

ここでいう「リクエスト」は、ブラウザーなどからサーバーへ送られる処理の依頼です。担当者が仕組みを細かく理解する必要はありませんが、管理画面のパスワード変更だけで解消する問題ではないことは押さえておきたい点です。

また、脆弱性が存在することと、実際に不正アクセスや情報漏えいが起きたことは別です。自社の被害の有無は修正状況とは分けて確認します。

影響を受ける環境と修正版

PHP公式はWebからのリクエストを処理するPHPの各実行環境を確認対象として挙げています。Apacheのmod_phpに限らず、PHP-FPMなどを使っている場合も確認が必要です。[1]

今回の2件を修正したバージョンは、次のとおりです。

利用している系列 今回の修正版
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

出典：PHP公式の2026年10月21日のリリース情報。[4]

同じ系列で表の修正版より前のバージョンを使っている場合は、今回の修正が適用されているかを確認します。

OSやサーバーの提供元が、元のバージョン番号を大きく変えずに修正を取り込む場合もあります。そのため、表示される数字だけで未対応と決めず、今回の2件に対する修正が含まれているかを提供元に確認してください。[1]

PHP 8.1以前はPHPプロジェクトの通常のサポートが終了しています。ただし、一部の提供元による修正や、今回の問題に対応するために公開された旧版向けの修正コードもあります。「古いので何もできない」と判断せず、提供元の対応状況と、サポート中の系列への移行を確認します。[1]

なお、PHP 8.2のセキュリティサポートは2026年12月31日までです。今回の修正を急いで適用する対応と、その後の移行計画は分けて進めます。[5]

WordPressを更新すればよいのか

今回の問題はPHP本体にあるため、WordPress本体やプラグインの更新だけでは解消しません。

WordPress公式は管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でPHPのバージョンを確認できると案内しています。レンタルサーバーの管理画面で確認できる場合もあります。[6]

確認できたバージョンを管理会社へ伝え、実際に動いている環境へ修正が適用されているかを聞きましょう。

会社サイトだけでなくフォームや別システムも確認する

会社のトップページを管理している会社と、問い合わせフォームや受発注システムを管理している会社が異なることがあります。最初の問い合わせでは確認してほしいURLやシステム名を明示します。

<!-- 本文画像1 挿入位置：会社サイト・フォーム・別システムの確認範囲を説明した段落の直後 -->

会社サイト、問い合わせフォーム、受発注システムなどの確認対象を並べたイメージ

例えば、次のように一覧にすると、確認できていない対象が分かります。

以下は架空の確認例です。

対象 PHPの利用状況 確認先 現時点の状況・次にすること
会社サイト 利用あり 制作・保守会社 修正適用の完了連絡あり。対象URLと稼働環境の確認結果を受け取る
問い合わせフォーム 未確認 フォームの提供会社 会社サイトとは別に、今回の2件への対応状況を問い合わせる
取引先向け受発注システム 利用あり システム保守会社 更新作業中。完了予定と、それまでの公開範囲を確認する
過去のキャンペーンサイト 未確認 社内の契約担当者から確認 管理先を特定し、公開を続ける必要があるかも確認する

「制作会社に連絡した」という記録だけでは、どこまで確認したかが残りません。URL、確認先、回答日時、未確認の項目を一緒に記録しておくと、後から引き継ぎやすくなります。

外部からアクセスできるシステムの確認を優先しつつ、PHPを組み込んだ製品やサービスについても提供元の情報を確認します。英国NCSCもPHPの利用箇所の特定と、第三者の製品・サービスの更新情報を確認するよう勧めています。[7]

「対応済み」と回答されたら何を追加で聞くか

管理会社の「対応済み」はWAFの設定変更、修正版の配布、実際の更新作業など、異なる意味で使われることがあります。

以下は管理会社の回答を想定した例です。

管理会社からの回答例 追加で確認したいこと
「WAFで対応しました」 PHP本体の修正も完了しているか。未完了なら、修正予定と、それまでの暫定対応の範囲は何か
「修正版が利用できるようになりました」 自社サイトへの適用も完了したか。利用者側で切り替えなどの作業が必要か
「PHPを更新しました」 どのURL・サーバーを更新したか。実際に動いているPHPへ反映されたことをどう確認したか
「PHPは使っていません」 会社サイトのほか、フォーム、別ドメイン、委託先のシステムも確認範囲に含まれているか
「不審なログはありませんでした」 何のログを、どの期間、どの範囲で確認したか。今回の修正は別途完了しているか

WAFはWebへの攻撃を検知・遮断するための仕組みです。PHP公式は今回の脆弱性を完全に解消するには更新が必要であり、暫定措置だけでは安全にならないと説明しています。[1]

また、ログに問題が見つからなかったことだけで、侵害がなかったと断定はできません。PHP開発元も、ログにエラーがないことは安全の証明にならないと説明しています。[3]

担当者としては「対応済み」の内訳を確認し、残っている作業があれば担当者と期限を記録します。

管理会社への最初の連絡に入れる6項目

最初の問い合わせで次の項目をそろえると、追加のやり取りを減らせます。分からない項目は未確認であることを伝えて構いません。

<!-- 本文画像2 挿入位置：管理会社への連絡に入れる6項目を示すリストの直前 -->

管理会社への確認に使うメールとチェックリストのイメージ

  1. 確認対象：サイト・システム名、URL、分かれば契約番号。
  2. PHPの利用有無：対象ごとに、PHPを使っているか。
  3. 今回の2件への対応状況：CVE-2026-109618とCVE-2026-109619の修正を適用済みか。
  4. 未対応の場合の予定：完了予定、暫定対応の内容、公開を続けられるかの判断。
  5. 自社で必要な作業：更新の承認、停止時間の調整、利用者への連絡などが必要か。
  6. 完了時の報告内容：適用日時、対象環境、動作確認結果、不正アクセスの調査状況。

すべての調査結果がそろうまで待つのではなく、修正作業と並行して回答してもらうとよいでしょう。被害調査が続く場合は、その項目だけ「調査中」として、次の報告予定を確認します。

すぐに更新できないときは公開を続けるかも判断する

「更新するとシステムが動かなくなるかもしれない」と言われた場合は、互換性の確認と並行して、修正までの間の扱いを決める必要があります。

英国NCSCは、暫定措置を適用できない場合や、その適用に時間がかかる場合には、システムを一時的にオフラインにすることも検討するよう案内しています。[7]

社内では技術担当者や管理会社と次の点を確認します。

  • 修正版の適用を妨げている問題と、解消の見込み。
  • 暫定対応で減らせるリスクと、残るリスク。
  • 停止・アクセス制限の対象と、影響を受ける業務。
  • 電話やメールなどの代替受付と、利用者への案内方法。
  • 再開するための確認項目と、判断する責任者。

画面上で問い合わせフォームを非表示にすることと、脆弱なPHPへの外部アクセスを遮断することは同じではありません。制限する範囲は管理会社に確認し、社内では業務への影響と代替手段を整理します。

更新後に確認する3項目

更新後の報告は次の3項目に分けると状況を把握しやすくなります。

<!-- 本文画像3 挿入位置：更新後に確認する3項目の表の直前 -->

更新後に問い合わせフォームの送信とメールの受信を確かめるイメージ

確認すること 受け取りたい報告の例
修正が反映されているか 対象URL・サーバー、適用日時、修正済みパッケージの情報、実行中のPHPへの反映確認
必要な業務が動くか 問い合わせの送信と受信、ログイン、受注登録など、自社で使う機能の確認結果
不正アクセスの疑いがないか 調査した対象と期間、分かったこと、未確認の範囲、追加調査の予定

例えば、会社サイトの表示が正常でも、問い合わせメールが届かなければ業務上の問題は残ります。更新前に、普段の業務で使う機能を担当者と共有しておくと、確認対象を決めやすくなります。

また、修正版の適用は更新前に侵入されていなかったことの証明にはなりません。不正アクセスの疑いがある場合は、更新完了とは別に調査を進めます。[7]

社内向けには、確認した範囲が伝わるように、例えば次のように記録します。

以下は架空の報告例です。

会社サイトと問い合わせフォームは、今回の2件の修正適用を確認済み。送信・受信も確認した。受発注システムは保守会社が更新作業中で、完了予定は本日18時。不正アクセスの調査結果は別途報告を受ける。

「全体として対応済み」とまとめるより、どの対象で何が終わり、何が残っているかを伝える方が、次の判断につながります。

今回の確認をきっかけに保守の担当範囲や連絡体制も見直したい場合は、次の記事で整理しています。

システム開発の保守はどこまで必要？止まったときの影響から考える保守体制

参考資料

以下の公式資料を2026年10月22日に確認しました。確認表、追加質問、社内報告の例は、担当者が対応を進めるために本記事で整理したものです。

[1] PHP「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-5

[2] PHP開発元「RCE via OOM corruption」（CVE-2026-109618） https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

[3] PHP開発元「RCE via stale global state」（CVE-2026-109619） https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

[4] PHP「News Archive — 2026」（各系列の2026年10月21日のリリース情報） https://www.php.net/archive/2026.php

[5] PHP「Supported Versions」 https://www.php.net/supported-versions.php

[6] WordPress「Critical PHP Security Release」（2026年10月21日） https://wordpress.org/news/2026/10/critical-php-security-release/

[7] 英国NCSC「Critical security issue affecting PHP」（2026年10月21日） https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php

お問い合わせ

ニチコマではWebシステムや業務システムの開発についてご相談を承ります。

お問い合わせ