PHPの緊急更新、何をすれば「対応完了」なのか ── 2つの重大な脆弱性（CVE-2026-109618・CVE-2026-109619）の仕組みから環境別コマンド・ワーカー再起動・緩和策・動作検証までの完全手順書

2026年10月22日 01:27

YouTubeポッドキャスト本編（フルHD図解動画・音声解説）はこちら：PHPの緊急更新、何をすれば「対応完了」なのか (https://youtu.be/9TWUJYY_5qw)

情報確認日：2026年10月21日（修正版公開後のPHP公式発表・GitHub Security Advisoriesに基づく）
対象読者：Webサイトの運営責任者、WordPress等のサイト管理者、Linuxサーバー／コンテナ／レンタルサーバーの保守担当者

はじめに：更新ボタンを押した、その先まで確認する

Slide 1: PHPの緊急更新、何をすれば「対応完了」なのか

公開しているWebサイトでPHPを使っている場合、今すぐサイトの裏側で動いている仕組みを確認する必要があります。今回の緊急対応で本当に必要なのは、「修正版への更新」と、「更新した仕組みが実際のWebサイト側で本当に動いているかの確認」の2つです。パッケージやファイルを入れ替えただけで対応を終わりにしないでください。

PHPは、Webサイトの裏側でログインや検索、問い合わせフォームの送信などを処理するプログラム言語です。利用者の画面に「PHP」という名前が出ていなくても、WordPressをはじめ多くのサイトや業務システムの土台として裏側で動いています。

鍵をかけて営業しているお店でも、建物自体に問題があれば鍵だけでは守れません。「サイトのログイン画面があるから大丈夫」「管理画面にパスワードをかけているから平気」と判断しないことが出発点になります。

本記事では、サイト運営者と実務担当者の双方が迷わず判断できるよう、以下の順序で作業の意味と具体的な確認・実行コマンドまで詳細に解説します。

Step 1（特定）：自分のサイトでどのPHP・どの実行方式（PHP-FPM / Apache mod_php / コンテナ等）が使われているかを調べる
Step 2（準備）：公式修正版またはOS配布元のバックポートパッケージを照合し、戻せる準備（バックアップ・段階的切り替え）を整える
Step 3（更新と再起動）：環境に合った手順で更新し、古いワーカー（処理係）を残さず入れ替える
Step 4（動作検証と完了判定）：利用者目線の機能確認と裏側のログ・プロセス確認を行い、「対応完了」を判定する

1. 何が公表され、何が危険なのか（CVE-2026-109618 / CVE-2026-109619）

Slide 2: 2つの重大な脆弱性（CVSS 9.2）と遠隔コード実行

まず、一次資料で確認できている事実を整理します。2026年10月20日、PHPのセキュリティチームが重大な問題2件の修正版公開を予告し（予定は日本時間10月21日午後11時／14:00 UTC）、10月21日に修正版および技術詳細（GitHub Security Advisories）が公開されました。

危険度の評価（CVSS v4 ベーススコア）は、2件とも10点満点で「9.2（Critical）」です。なお、この「9.2」という数字は「攻撃に成功する確率が92%」という意味ではありません。ネットワーク経由で認証なしに狙えることや、万一起きた場合の機密性・完全性・可用性への影響度を総合評価した点数です。

問題になるのは、RCE（Remote Code Execution：遠隔からのコード実行）です。外部の攻撃者が送り込んだ命令を、Webサーバー側で動かされるおそれがあります。単にサイトが表示されなくなる（サービス停止）だけでなく、内部情報の読み取りや改ざんにつながる危険があります。

① CVE-2026-109618（GHSA-w8hw-w9fx-j79w）：メモリ不足（OOM）処理での内部状態破損

1つ目は、プログラムが作業中の情報を置く「メモリ」が不足したとき（Out-of-Memory：OOM）の片付け処理の問題です。

技術的な仕組み：PHPはメモリ不足（OOM）が発生した際、longjmp() を使って現在の処理を中断しリクエストの終了処理へ飛びます。しかし一部の文脈では、リクエスト用メモリが完全に初期化される前に一時的に到達可能な状態になっており、そのタイミングでメモリ割り当てが失敗すると、不完全なメモリ状態のままリクエスト終了処理（shutdown）が走り、不正なメモリを読み取ったり分岐したりして遠隔コード実行（RCE）に至ります。
制限内でもOOMが起きる理由：公式アドバイザリでは、post_max_size などの見かけ上の制限内に収まりながらメモリ上限（memory_limit）を使い切る複数の経路が示されています。たとえば、有効なContent-Length宣言のないマルチパート要求、1つのパート内に大量のヘッダを含める要求（PHP内部での表現が通信上のサイズより大幅にメモリを消費する）、max_file_uploads にカウントされない空のファイル入力欄とネストしたフィールド名の組み合わせなどです。
修正内容：修正版ではOOM時の longjmp() が廃止され、VMの安全な地点で停止する「遅延ソフトOOM（delayed, graceful soft OOM）」と、さらに高い第2の閾値に達した際に _exit() で即座に終了する「ハードOOM」の2段階方式へ置き換えられました。

② CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）：リクエストをまたぐ古いグローバル状態の残留（Use-After-Free）

2つ目は、前のリクエスト処理で使った情報への参照（ポインタ）がワーカー内に残り、後のリクエスト処理で使われてしまう問題です。片付けたはずの作業台に古い指示書の参照だけが残り、次の仕事でそのまま参照されてしまうイメージです。

技術的な仕組み（Producer と Consumer）：永続的に動くワーカープロセスが保持するグローバル状態（エラー、セッション、オブジェクト、拡張機能の状態など）が、1つのリクエストが所有するメモリを指したまま残ることがあります。OOMや致命的エラー（構文エラー、未捕捉エラー、require 失敗、実行時間超過など）、あるいは終了処理後半の非致命的警告によってリセットが飛ばされると、リクエストのメモリ（ヒープ）が解放された後もワーカーのグローバル変数が古いアドレスを指し続けます（Producer）。同じワーカーが次のリクエストを処理する際、通常の初期化が終わる前に動く処理がその古い参照を読み書き・解放してしまい（Consumer）、解放済みメモリの使用（Use-After-Free）からRCEに至ります。
確認されている2つのConsumer経路：

1. 初期化前のINI診断メッセージ：.htaccess や PHP_VALUE 等で無効・非推奨なINI設定が適用される際、通常の初期化前に出る警告や非推奨通知（display_errors や log_errors を無効にしていても内部でアクセスされる）。

2. 通常初期化前のセッションアップロード進捗（session.upload_progress）：ファイルアップロード進捗の記録処理が通常のセッション初期化より前に動き、前のリクエストが残した状態を参照する経路。

PHP 8.5での顕著な例：PHP 8.5で fatal_error_backtraces が有効な場合、致命的エラー時のバックトレース状態が終了時にリセットされず、次のリクエストの診断処理で確実に古い状態へ到達することが確認されています。

実行方式（SAPI）ごとのリスクの受け止め方

公式発表では、Webリクエストを処理するすべてのPHP環境（PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed）がリスク対象とされています。

Apache mod_php：リクエスト起動（startup）が失敗しても無条件に終了処理（shutdown）を呼ぶため、サイト独自のプログラムが1行も動く前に、標準のメモリ・入力制限のままでHTTP経由の未認証RCEが成立することが実証されています。
PHP-FPM / FrankenPHP / LiteSpeed：PHP-FPMは起動失敗時に子プロセスを終了させるため起動時の悪用は防がれますが、通常起動後のOOMや設定・アップロード進捗経由の状態残留についてはソースコード解析上影響を受けるとされています。また、FrankenPHPも mod_php と同様に終了処理を無条件に呼ぶ構造が指摘されています。

したがって、「すべての構成で同じ攻撃が実証された」という意味ではありませんが、「自分の環境は mod_php ではなく PHP-FPM だから安全」とも判断せず、すべてのWeb実行環境で更新を進める必要があります。

2. 最初の作業は、サイトの裏側を特定すること

Slide 3: コマンド画面の「php -v」とWebサイト側のPHPは別

最初の実務は、「自分のサイトでどのPHPが使われているか」を正確に特定することです。

レンタルサーバーの場合：管理画面の「PHP設定」を開きます。
自社担当者や制作会社に管理を任せている場合：「①PHP使用の有無、②現在のバージョン、③誰が更新作業を行うか」の3点を確認します。
WordPressを使っている場合：WordPress本体やプラグインの更新とは別に、土台として動いているPHP自体のバージョンを調べます。

コマンド画面の php -v だけで確認を終えてはいけない理由

サーバーにSSH等で入れる担当者は、まず php -v でバージョンを確認できます。しかし、その結果だけでサイト全体の確認を終えてはいけません。

サーバーには、文字で命令を打つ画面から使うPHP（CLI）と、実際のWebサイトがリクエストを処理するために使うPHP（PHP-FPM や Apacheモジュール）が別々に存在する場合があります。事務所のパソコンを更新しても、店頭のレジが古いままという状況と同じです。

また、1台のサーバーの中でサイト（ドメイン）ごとに異なるPHPバージョンやFPMプールを使い分けている構成も珍しくありません。公開サイトだけでなく、管理画面、別ドメイン、APIサーバー、予備のサーバー（ステージングや待機系）まで漏れなく一覧表にしてください。

構成一覧表に必ず残す4項目：①サイト名、②動いている場所（サーバー／コンテナ）、③Web側のPHPバージョンと実行方式、④更新担当者
やってはいけない確認方法：確認のために、詳細な設定を表示する診断ページ（phpinfo() を書いたファイルなど）を誰でもアクセスできる公開領域に新設しないでください。管理画面や既存の制限された確認手段を使います。

3. 更新先を決め、戻せる準備をする

Slide 4: 公式修正版（8.5.12〜8.2.35）とバックポートの確認

次に、更新先のバージョンと、万一問題が起きたときに戻せる準備を固めます。

公式修正版バージョン一覧

PHP公式から公開された修正版は以下の4系列です。

PHP 8.5 系列：8.5.12
PHP 8.4 系列：8.4.27
PHP 8.3 系列：8.3.36
PHP 8.2 系列：8.2.35

緊急対応の場では、まず「いま使っている系列の中で修正版へ進める方法」（例：8.3.x なら 8.3.36 相当へ更新）を優先します。緊急時にメジャー／マイナー系列の引き上げ（例：8.2 から 8.5 への変更）まで同時に行うと、非互換による不具合の切り分けが難しくなるためです。

なお、PHP 8.1 以前（7.4 / 8.0 / 8.1）については、公式リポジトリに最小限のソースバックポート用ブランチが用意されましたが、これは通常の公式サポート再開を意味しません。OS配布元や保守ベンダーが修正パッケージを提供しているかを確認し、提供がなければサポートされる版への移行が必要です。

OS配布元の「バックポート」の見分け方

UbuntuやRed Hat Enterprise Linux（RHEL）などのOS配布元が管理するパッケージでは、「バックポート」（新しい版で直した修正内容だけを、保守している版のパッケージに取り込む方式）がよく使われます。

この場合、php -v の表示上の番号が 8.3.36 より古く見えても、パッケージの枝番（リビジョン）で修正が取り込まれている可能性があります。逆に、表示番号の大小だけでは修正済みか判定できません。必ず「配布元のセキュリティ告知が今回の2件（CVE-2026-109618・CVE-2026-109619）への対応を明記しているか」と、「実際に入っているパッケージの完全な版番号」を照合します。

作業前のバックアップと段階的切り替え計画（運用提案）

復旧手順の確認：現在の設定ファイル（php.ini、FPMプール設定、Webサーバー設定）、サイトのプログラム、データベースを復旧できることを確認します。「バックアップファイルが存在する」だけでなく、「どこから、どの手順で戻すか」まで把握しておく必要があります。
段階的な切り替え：複数台構成（ロードバランサ配下など）なら、1台への新規アクセスを止め、処理中の通信を終えてから更新・検証する手順を採ります。1台構成なら、短いメンテナンス時間を決めて実施します。

4. サーバーを自分で管理している場合の更新（Linuxパッケージ管理とワーカー再起動）

Slide 5: 模擬実行・拡張機能の整合・全ワーカーの再起動

Linuxサーバーを自分で管理している場合、Ubuntu / Debian 系（apt）と Red Hat 系（dnf）では命令が異なりますが、確認しながら進める6つの段階は共通です。

1. 配布元から更新候補の一覧を取り直す（お店の最新カタログを取り寄せる段階であり、まだPHP本体は更新されていません）

2. いま入っているパッケージと更新候補を比較する（「更新がありません」と出ても、まだ配布元に届いていない・バージョン固定（pin/hold）されている・別リポジトリを使っている可能性があるため、配布元のCVE告知と照合します）

3. 模擬実行（ドライラン）を行う（実際に変更する前に、何が更新され何が削除される予定かを確認し、予想外の大量削除や意図しない系列変更が出たら中断して対象を見直します）

4. PHP本体と拡張機能（モジュール）をそろえて更新する（データベース接続や画像処理などの拡張機能と本体の整合を保ちます）

5. 設定ファイルの構文確認（テスト）を行う（設定を正しく読み込めるか検査してから再起動へ進みます）

6. サイトの処理を担当するサービスを再起動し、古いワーカーが消えたことを確認する

なぜ「すべてのワーカーの再起動」まで必須なのか

新しいパッケージやファイルをサーバーに置いても、メモリ上で既に動き続けている古い処理プログラム（ワーカー）がそのまま残る場合があります。特に今回の CVE-2026-109619 はワーカーが保持する状態に関わる脆弱性であり、公式アドバイザリでも 「すべてのPHPワーカーを再起動すること（Restart every PHP worker）」 が明確に求められています。

PHP-FPMで処理しているならPHP-FPMサービスを、Apache内部（mod_php）で処理しているならApache側を再起動し、プロセスの起動時刻（lstart）が更新作業の後に変わっていることまで確認します。

5. 借りている環境と、コンテナでは何をするか

Slide 6: 事業者へのCVE確認とコンテナイメージの再ビルド

サーバーのOS内部を自分では操作できない環境や、コンテナ環境での対応ポイントを整理します。

レンタルサーバー・マネージド環境・制作会社委託の場合

レンタルサーバーの管理画面に「PHP 8.3」としか表示されていない場合、その画面だけでは今回の修正版（8.3.36 相当）が適用済みか判別できません。事業者のメンテナンス・セキュリティ告知を確認し、不明な場合はサポート窓口へ以下の2点を問い合わせます。

「今回の2つの脆弱性（CVE-2026-109618、CVE-2026-109619）への修正は、契約している環境に適用済みでしょうか。また、利用者側でのバージョン切り替え操作やワーカー・サービスの再起動は必要でしょうか。」

制作会社や保守ベンダーに依頼している場合も、「依頼メールを送ったこと」と「作業が完了したこと」は別です。①修正が入ったバージョン（またはパッケージ番号）、②反映した日時、③動作確認の結果の3点を受け取って記録に残します。

Docker等のコンテナ環境の場合

コンテナ環境では、古いイメージからコンテナを再起動するだけでは、同じ古いPHPが動き続けます。

1. ベースイメージ配布元が今回の2件に対応した修正済みイメージを公開したか確認し、参照するタグまたは固定ダイジェスト（@sha256:...）を更新します。

2. 新しいベースを取得する --pull と、古いビルドキャッシュを使わない --no-cache を付けてアプリケーションのイメージを再ビルドします（※Dockerfile等でベースイメージのダイジェストを古い値に固定していると、--pull を付けても古いベースが使われるため注意してください）。

3. 1つのコンテナを置き換えて終わりにせず、稼働しているすべてのコンテナを更新し、さらにオートスケール（自動増設）やジョブ実行の設定でも新しいイメージが参照されるよう設定まで確認します。

6. すぐ更新できないとき、何を優先するか（一時的な緩和策と注意点）

Slide 7: 入口での遮断・公式緩和策と「memory_limit=-1」の注意

業務調整や互換性確認が必要で、今すぐPHP本体を更新するのが難しい現場もあると思います。ここで検討するのが「緩和策（Mitigation）」ですが、これは攻撃の通り道を一部狭める一時措置であり、修正パッチを適用した状態と同じにはなりません。

① 【私なりの解釈と運用提案】入口側での公開一時停止・接続元制限を最優先に検討する

私がまず勧めたいのは、一時的に公開を止められるか、または接続元を絞れるかの検討です。その際、PHPで動くサイトのプログラム側で「メンテナンス画面」を出すだけでは不十分なことがあります。

なぜなら、今回の脆弱性（とくに Apache mod_php 等での CVE-2026-109618 や、初期化前に動く CVE-2026-109619 のConsumer経路）は、サイト独自のPHPプログラムが動き始める前の段階で成立する例があるからです。前段のWebサーバー（Nginx / Apache）、ロードバランサ、WAF、CDNなどの「入口」で対象のPHPへリクエストを流さない形にするか、社内IPやVPN等に接続元を制限して外部から触れられる範囲を減らします。

② 公式が示す設定面（INI）の緩和策と適用条件

公式アドバイザリでは、確認済み経路の一部に対する設定面の緩和策が案内されています。

session.upload_progress.enabled=0：ファイル送信の進捗を記録する機能を無効化し、通常初期化前のアップロード進捗Consumer経路を塞ぎます。
fatal_error_backtraces=0（PHP 8.5のみ）：PHP 8.5で重大なエラー時の処理履歴（バックトレース）が終了時にリセットされず残留する経路を無効化します。
重要な適用条件：これらの設定は、利用者からのリクエストを解析する前に有効でなければなりません。サイトのPHPプログラムの途中（ini_set() など）で切り替えても間に合わないため、php.ini や php_admin_value / FPMプール設定など指定された場所で設定し、すべてのワーカーを再起動します。また、display_errors や log_errors をオフにしたり @ 演算子を使ったりするだけでは、内部での状態参照を防げません。

③ memory_limit=-1 を全サーバーで一斉変更してはいけない理由

CVE-2026-109618（OOM側）のアドバイザリには、管理設定で memory_limit=-1（PHPのメモリ上限なし）を強制する緩和策の記載があります。これはリクエストごとの予測可能なメモリ上限をなくすことで、攻撃者が意図的にソフトなOOMを引き起こすのを難しくするためです。

しかし、この1行だけを見て全サーバーで一斉に memory_limit=-1 へ変更しないでください。

PHP側の上限を外すと、1つのリクエストがサーバーの物理メモリを使い果たし、OSのOOM KillerによってWebサーバー全体やデータベースごと強制終了される危険があります。コンテナやcgroup（memory.max）等で外側からメモリ上限を管理する設計が別途必要になります。
さらに、OSの mmap() 等のメモリ確保自体が失敗すれば依然として脆弱な longjmp() 経路に入るため、memory_limit=-1 でも完全な対策にはなりません。
絶対に避けるべき設定：代替のメモリ制限として RLIMIT_AS や RLIMIT_DATA を使ってはいけません。これらを使うと上限到達時に mmap() が失敗し、まさに問題となっている longjmp() 経路を誘発するため、公式アドバイザリで明確に禁止（Do not use）されています。
post_max_size 等の引き下げ：受け取るデータ量（post_max_size や max_input_nesting_level）を小さく絞り、フロントエンド側でもリクエストサイズを制限する措置も有効ですが、正規のファイルアップロード等を止めてしまう可能性があるため、業務影響を確認したうえで一時的に適用します。

7. 何を確認して、「対応完了」とするのか

Slide 8: 対応完了の4条件と、次の更新にも使える構成一覧

「更新コマンドが成功しました（Complete!）」という画面は大切な途中経過ですが、それだけでサイトの安全な稼働まで確認したことにはなりません。以下の4つの確認がそろって初めて「対応完了」となります。

1. 全環境のパッケージ番号・修正版の照合：今回の2件に対応したソフトが、公開サイト・管理画面・API・予備機・全コンテナに入っているかを配布元告知と実際のパッケージ番号で確認する。

2. 古いワーカーが残っていないことの確認：ワーカープロセスの起動時刻やWeb実行系（PHP-FPM / Apache等）がすべて新しい版に入れ替わっていることを確認する。

3. 利用者目線での主要機能・APIの動作検証：トップページの表示だけでなく、ログイン、検索、問い合わせ送信、ファイルアップロード、外部連携窓口（API）を実際に試す。

4. 裏側のログ（500番台エラー）とリソース監視：サーバー側の失敗を表す500番台エラーが増えていないか、メモリ使用量や応答時間が作業前と比べて不自然に変わっていないかをログと監視画面で確認する。

不具合が出たときの判断と、侵害調査の分離

もし更新後に不具合が出た場合でも、古い（脆弱な）版へ戻してそのまま一般公開を続ける判断は避けてください。公開を一時停止するか、接続元を制限した状態で復旧・原因切り分けを行います。戻せる準備（ロールバック）は、脆弱な状態で営業を続けるためではなく、制御された状態で立て直すためのものです。

また、「今日パッチを当てて更新したこと」は、「それ以前に侵入されていなかったこと」を証明するものではありません。不審なファイル、見覚えのない管理者アカウント、不自然な外部通信やエラーログが見つかった場合は、更新作業とは切り分けて記録を保全し、別途フォレンジック（侵害調査）を行う必要があります。

緊急対応で本当に差が出るのは、コマンドを打つ速さよりも「どのサイトが、どの土台で動き、誰が更新し、誰が完了を確認するのか」を把握できているかどうかです。今回作った構成一覧表は、ぜひ次の更新にも使えるよう手元に残しておいてください。

8. 付録：担当者向け詳細操作ガイド・コマンド一覧

対象サーバーのOS、パッケージ配布元、サービス名、拡張機能、保守手順を確認してから使ってください。設定検査（configtest / -t）が成功した場合にだけ再起動へ進み、失敗時は原因を直してから再実行してください。

A. 脆弱性識別番号（CVE / GHSA）と公式修正版の照合表

識別番号：CVE-2026-109618 ／ 公式アドバイザリ：GHSA-w8hw-w9fx-j79w ／ CVSS v4：9.2 (Critical) ／ 公式の説明（問題の概要）：メモリ不足（OOM）時の longjmp() 早期終了により未初期化状態が残り、終了処理で参照されてRCEにつながり得る（Apache mod_php で未認証RCE実証）。／ 基本対応方針：修正を含むPHPへ更新し、全ワーカーを再起動する。
識別番号：CVE-2026-109619 ／ 公式アドバイザリ：GHSA-6wmf-4rv5-p3rp ／ CVSS v4：9.2 (Critical) ／ 公式の説明（問題の概要）：解放済みリクエストメモリを指すワーカーのグローバル状態が残り、同一ワーカーの別リクエスト初期化前の処理（INI診断・upload_progress等）で使われRCEにつながり得る。／ 基本対応方針：修正を含むPHPへ更新し、全ワーカーを再起動する。

現在のPHP系列：PHP 8.5 ／ 今回の公式修正版：8.5.12 ／備考：2026年10月21日公開
現在のPHP系列：PHP 8.4 ／ 今回の公式修正版：8.4.27 ／備考：2026年10月21日公開
現在のPHP系列：PHP 8.3 ／ 今回の公式修正版：8.3.36 ／備考：2026年10月21日公開
現在のPHP系列：PHP 8.2 ／ 今回の公式修正版：8.2.35 ／備考：2026年10月21日公開
現在のPHP系列：PHP 8.1 以前 ／ 今回の公式修正版：保守元のバックポート有無を確認／備考：7.4 / 8.0 / 8.1 向け最小ソースバックポートは通常の公式サポート再開を意味しない（公式情報）

CVE-2026-109618（GHSA-w8hw-w9fx-j79w / CVSS 9.2）：メモリ不足（OOM）の処理で内部状態が破損し、遠隔からのコード実行（RCE）につながり得ます。
CVE-2026-109619（GHSA-6wmf-4rv5-p3rp / CVSS 9.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 です。保守ベンダーのバックポートは番号の大小だけで判定せず、両CVEへの対応告知とパッケージの完全な版番号を記録します。

B. サーバー内でPHPの版・設定・稼働プロセスを特定するコマンド

php -v

php --ini

php -m

php -v はコマンドライン（CLI）のPHPバージョン、php --ini は読み込まれる設定ファイル一覧、php -m は有効な拡張機能一覧、ps -eo pid,lstart,args は稼働中プロセスのID・起動日時・実行引数を表示します（PHP公式オプション説明）。
これだけでWebサイト側の版や未使用を確定せず、Webサーバー設定の接続先（ソケット／ポート）、FPMプール、コンテナ、管理画面と照合します。出力を共有する際は内部構成や機密情報を取り除きます。

C. Ubuntu / Debian 系（apt）で確認・模擬実行・更新・再起動する手順

以下は php8.3 系列の例です。環境に合わせて 8.2、8.4、8.5 や実際のパッケージ名に置き換えてください。

sudo apt-get update

dpkg-query -W 'php*' 'libapache2-mod-php*'

apt-cache policy php8.3 php8.3-cli php8.3-fpm

sudo apt-get --only-upgrade -s install 'php8.3*'

apt-get update で配布元の最新一覧を取得し、dpkg-query -W で導入済みパッケージ一覧、apt-cache policy で現在版と更新候補（Candidate）を比較します。
apt-get --only-upgrade -s install は新規導入を行わず既存パッケージの更新だけを模擬実行（シミュレーション）する命令です（apt-get(8) 公式マニュアル）。
候補が配布元のセキュリティ告知にある修正済み版であること、また apt-mark showhold で保留（hold）になっていないこと、模擬実行で意図しない削除や別系列への変更がないことを確認してから本番実行へ進みます。

sudo apt-get --only-upgrade install 'php8.3*'

sudo php-fpm8.3 -t

sudo systemctl restart php8.3-fpm

systemctl status php8.3-fpm --no-pager

ps -eo pid,lstart,args | grep '[p]hp-fpm'

sudo php-fpm8.3 -t でFPM設定の構文検査が成功したことを確認してから、systemctl restart php8.3-fpm でサービスを再起動し、ps の起動時刻（lstart）が更新後に変わっていることを確認します。
Apacheの組み込み方式（mod_php）を使っている場合は、対応する libapache2-mod-php8.3 等を更新対象に含め、sudo apache2ctl configtest の成功後に sudo systemctl restart apache2 を実施します（Ubuntu公式パッケージ管理手順）。

D. RHEL / AlmaLinux / Rocky Linux 系（dnf）で確認・模擬実行・更新・再起動する手順

rpm -qa 'php*'

sudo dnf check-update 'php*'

rc=$?

printf 'dnf check-update終了コード: %s\n' "$rc"

dnf check-update の終了コードは、100 が更新候補あり、0 が更新候補なし、1 などがエラーです（DNF公式コマンドリファレンス）。終了コード 100 を失敗と誤認しないよう注意してください。
更新候補が0件でも、それだけで修正済みとは判断せず、rpm -qa 'php*' の版番号と配布元のCVE対応告知を照合します。

sudo dnf upgrade --assumeno 'php*'

sudo dnf upgrade 'php*'

sudo php-fpm -t

sudo systemctl restart php-fpm

systemctl status php-fpm --no-pager

ps -eo pid,lstart,args | grep '[p]hp-fpm'

dnf upgrade --assumeno は確認プロンプトに自動でNoと答えて変更内容だけを確認する模擬実行です。問題なければ sudo dnf upgrade 'php*' を実行します。
sudo php-fpm -t の成功後に php-fpm を再起動します。Apache組み込み方式なら、sudo apachectl configtest の成功後に sudo systemctl restart httpd を実施します（RHEL 9 DNF公式手順）。

E. Dockerコンテナ・レンタルサーバー・Windows / IIS 環境での対応手順

docker build --pull --no-cache -t example-app:php-2026-10-21 .

docker run --rm example-app:php-2026-10-21 php -v

コンテナでは修正済みベースイメージの提供を確認し、Dockerfileが参照するタグまたは固定ダイジェストを更新します。--pull は新しいベースの取得、--no-cache はビルドキャッシュを使わない指定です（※固定ダイジェストが古いままなら --pull を付けても古いベースが使われます：Docker公式ベストプラクティス）。
配備（デプロイ）後は、稼働中のすべてのコンテナで docker exec <コンテナ名> php -v 等を実行し、古いイメージで動くコンテナや古いオートスケール設定が残っていないことを確認します。
レンタルサーバー・保守委託先への確認事項：①CVE-2026-109618・CVE-2026-109619への修正適用有無、②適用済みバージョン／パッケージ番号、③利用者側での切り替え・再起動の要否、④反映日時と動作確認結果。
Windows / IIS 環境：修正済みの対応ビルド（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）を用意し、アーキテクチャ（x64 / x86）、実行方式（FastCGI / Non-Thread Safe等）、拡張機能との整合を確認したうえで切り替え、対象のIISアプリケーションプールやFastCGIプロセスを確実に入れ替えて動作確認します。

F. すぐ更新できないときの一時的な緩和策と注意点（完全な対策ではありません）

設定項目・措置：入口での公開停止・接続元制限 ／対象：全環境（運用提案）／ 目的（公式アドバイザリの記載）：リクエストが対象のPHPへ到達するのを防ぐ。／ 注意点・運用上の副作用：PHPアプリ内のメンテナンス画面ではなく、前段のWebサーバー・LB・WAF・CDN等で制御する。
設定項目・措置：session.upload_progress.enabled=0 ／対象：CVE-2026-109619 ／ 目的（公式アドバイザリの記載）：通常初期化前のアップロード進捗による古い状態参照を止める。／ 注意点・運用上の副作用：リクエスト解析前に有効な設定場所で指定し、全ワーカーを再起動する。進捗表示機能は止まる。
設定項目・措置：fatal_error_backtraces=0 ／対象：CVE-2026-109619（PHP 8.5）／ 目的（公式アドバイザリの記載）：PHP 8.5の致命的エラー履歴が終了時にリセットされず残る経路を止める。／ 注意点・運用上の副作用：リクエスト解析前に有効な設定場所で指定し、全ワーカーを再起動する。
設定項目・措置：memory_limit=-1（管理設定で強制）／対象：CVE-2026-109618 ／ 目的（公式アドバイザリの記載）：予測可能なリクエスト単位のメモリ上限によるOOM誘導を抑える。／ 注意点・運用上の副作用：全サーバーでの安易な一斉変更は禁物。OSやコンテナ全体のメモリ枯渇・OOM Killを招くため外側の制限設計が必須。RLIMIT_AS / RLIMIT_DATA は mmap() 失敗から脆弱な longjmp() を誘発するため使用禁止。
設定項目・措置：post_max_size の引き下げ（例：8M〜32M）／対象：両方（補助的制御）／ 目的（公式アドバイザリの記載）：大きな送信データによるメモリ消費・OOM到達を抑える。／ 注意点・運用上の副作用：正規のフォーム送信やファイルアップロードが失敗しないか業務影響を確認し、フロントエンド側の上限とも整合させる。

設定を書き換えた場合も、構文確認とすべてのPHPワーカーの再起動、および変更前設定の控えが必須です（OOM側の公式詳細、状態残留側の公式詳細）。
error_reporting の変更、@ 演算子、display_errors=0、log_errors=0 では CVE-2026-109619 の内部状態参照を防げません。

G. 「対応完了」と判定するための最終チェックリスト

[ ] パッケージ・修正版の照合：配布元のCVE告知と一致する修正版（または 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）が、公開サイト・管理画面・別ドメイン・API・予備機・全コンテナに適用されている
[ ] 全ワーカーの入れ替え確認：PHP-FPM / Apache / コンテナ等の再起動後、古い起動時刻のワーカープロセスが残っていない
[ ] 主要機能とAPIの動作検証：トップページ、ログイン、検索、問い合わせ送信、ファイルアップロード、外部連携APIが正常に動作する
[ ] エラーログとリソース監視：Webサーバー・PHPのエラーログで500番台エラーの急増がなく、メモリ使用量や応答時間に異常がない
[ ] 構成台帳の更新と侵害調査の分離：今回特定した「サイト名・場所・版・担当者」の一覧表を次回更新用に保存し、万一不審なファイルやアカウントを発見した場合は別途侵害調査へ回す