PHPの緊急セキュリティ更新とWordPress保守―法律・税理士事務所の確認，バックアップ，互換性試験及び復旧手順（AI作成）

第１　結論

PHPの重大な脆弱性に関する通知を受けたときは，メールに書かれた対象バージョン又は危険度をそのまま事実として扱わず，PHP公式発表，利用中の正確な版，レンタルサーバーの提供状況及びWordPressの構成を対応させて判断する必要がある。

緊急性が高くても，確認せずにPHPの系列だけを切り替えると，テーマ，プラグイン又は独自コードとの互換性問題により，公開画面，管理画面，問合せフォーム，メール送信，予約，検索又は定期処理が停止することがある。他方，互換性を理由に更新を無期限に延期すれば，既知の脆弱性を残すことになる。

実務上は，①公式情報と現在値の確認，②ファイル及びデータベースの一体的なバックアップ，③復旧経路と責任者の確保，④影響の大きい変更を分けた実施，⑤管理画面と匿名の公開画面の双方による検証，⑥ログ，版及び判断理由の記録，という順序で進めるのが安全である。

第２　緊急通知の真偽と影響範囲の確認

１　提供者の公式情報へ遡ること

緊急通知を受けた場合，差出人の名称，リンク先のドメイン，公表日時及び原典を確認する。PHP本体の脆弱性であればPHP公式サイト，WordPress本体であればWordPress公式サイト，テーマ又はプラグインであれば配布元の公式情報を優先する。

保守事業者又は販売事業者のメールは，注意を促す契機として有用である。しかし，営業上の案内，危険性の一般化及び個別サイトの事実認定を含むことがあるため，公式発表の内容，個別環境の測定値及び事業者の推測を分けて読む必要がある。

２　系列，ポイントリリース及びサポート期間を分けること

「PHP 8.3を利用している」という情報だけでは足りない。同じ8.3系列でもポイントリリースが異なれば，修正の有無が異なることがある。管理画面に表示された完全な版番号，確認日時及びサーバー名を記録する。

PHP公式サイトは，各リリース系列について，通常の不具合とセキュリティ問題を修正する積極的サポート期間，重大なセキュリティ問題だけを修正する期間及びサポート終了後を分けている。サポート対象系列であることは，その時点の全ポイントリリースに未修正の脆弱性がないことを意味しない。反対に，事前通知だけから特定の系列を影響対象と断定することもできない。

３　確認済み事項，提供者の説明，推測及び不明点を分けること

緊急対応記録では，次の区分を用いるとよい。

①確認済み事項―公式発表，管理画面の完全な版番号，バックアップの完了表示，更新後の試験結果等
②提供者の説明―保守事業者，レンタルサーバー又はプラグイン作者が公表した対象範囲及び対応予定
③推測―攻撃の開始時刻，個別サイトが既に狙われているか，障害原因等についての仮説
④不明点―影響版，修正版，悪用の有無，ホスティング側の配備時刻等，まだ確認できない事項

第３　更新前に作る構成表

１　少なくとも記録する項目

更新前に，次の構成を一つの表へまとめる。

①PHPの完全な版番号，実行方式及び変更画面
②WordPress本体の版
③有効なテーマ，子テーマ及び独自変更
④有効・無効を含むプラグインと版
⑤WPCodeその他のコードスニペット，mu-plugin及びサーバー側の追加設定
⑥データベースの種類及び版
⑦キャッシュ，CDN，WAF，DNS及びメール送信の経路
⑧バックアップ先，保存世代，最終成功時刻及び復旧担当者
⑨公開画面，管理画面，フォーム，検索，ログイン，メール及び定期処理の試験項目

無効なテーマ又はプラグインも，サーバー上に残り，後に有効化される可能性がある。直ちに削除するかは別に判断するが，構成表から除外しない。

２　担当範囲を明らかにすること

レンタルサーバーがPHPの更新を提供していても，WordPress本体，テーマ，プラグイン，独自コード及び公開後の動作確認までサーバー会社が担うとは限らない。事務所，制作会社，保守事業者，サーバー会社及びセキュリティ事業者のうち，誰が公式情報を確認し，誰がバックアップ，変更，検証及び復旧を行うかを明らかにする。

法律・税理士事務所では，ウェブサイトが単なる広報媒体ではなく，問合せ，採用，予約，資料送信又は顧客連絡の入口になっていることがある。サイト停止時の代替電話，メール及び告知方法も構成表に含める。

３　保守会社への照会文例

保守会社へは，次の事項を一度に照会すると，誰がどこまで対応したかを確認しやすい。
これは確認漏れを防ぐための文例であり，法令又はPHP公式がこの様式の使用を義務付けているという意味ではない。

当サイトについて，CVE-2026-109618及びCVE-2026-109619への対応状況をご回答ください。
①対象ドメイン，本番・検証環境，ウェブ処理と定期処理の区別及びPHPの実行方式
②現在の完全な版番号，パッケージの版又はビルド情報，確認日時及び確認方法
③各CVEの修正状況と，独自修正の場合の提供者の告知又は対象CVEを示す資料
④適用日時，必要なプロセス・ワーカーの再起動又は再読込み，及び作業担当者
⑤バックアップと復旧手段，互換性試験，公開画面・管理画面・フォーム等の確認結果
⑥未対応の環境，暫定措置，残るリスク及び完了予定
⑦今回の保守契約に含まれる作業範囲，追加費用の有無，承認が必要な事項及び緊急時の連絡先

回答が「更新済み」だけである場合は，対象と確認資料を補ってもらう。
修正の適用を確認する資料と，更新後にサイトが動作したことを確認する資料は，それぞれ残す。

第４　WordPressサイトヘルスの読み方

１　「致命的な問題」は侵害確定を意味しないこと

WordPressのサイトヘルスは，設定又は動作状態を「致命的な問題」，「おすすめの改善」及び合格したテスト等に分けて表示する。公式説明は，致命的な問題を，潜在的なセキュリティ上の弱点又は重大な性能問題となり得る事項として説明している。

したがって，「致命的」という表示だけから，マルウェア感染，不正アクセス又は情報漏えいが既に生じたと判断してはならない。他方，単なる表示上の問題とも決め付けず，検出条件，現在の設定，別の管理手段及び実際の更新履歴を確認する必要がある。

２　自動更新を別の管理手段が制御している場合

WordPressのコードは，プラグイン又はテーマの自動更新について，完全な判定方法はなく，いくつかの条件から潜在的な問題を推測すると説明している。自動更新を無効にしているのに標準の設定欄が表示されたままであれば「致命的」と判定し，自動更新を無効にするフィルターがプラグインとテーマの双方に存在すれば「おすすめの改善」と判定する実装である。

Easy Updates Managerその他の管理プラグインが更新を一括制御する環境では，WordPress標準の表示と実際の管理経路が食い違わないようにし，どの仕組みがWordPress本体，プラグイン及びテーマの更新を担当するかを記録する。表示上の判定を消すこと自体を目的にせず，更新が実行され，失敗時に検知され，復旧できることを確認する。

３　おすすめ項目を一括で消そうとしないこと

REST API，ループバック要求又はページキャッシュに関する警告は，CDN，WAF，認証，ホスティング又はプラグインの構成と関係することがある。原因を確認せずに防御設定を弱め，外部からの到達範囲を広げるべきではない。

個々の項目について，WordPressの機能障害，意図した防御，外部サービスの制限又は誤検知の可能性を分ける。対応しない項目にも，判断日，理由，代替措置及び再確認時期を残す。

第５　バックアップと復旧可能性

１　ファイルとデータベースの双方が必要であること

WordPress公式資料は，典型的なサイトを完全に復旧するためには，WordPressのファイルとデータベースの双方が必要であると説明している。データベースには記事，コメント及び設定等が入り，ファイル側にはWordPress本体，テーマ，プラグイン，画像，設定ファイル及び追加コード等が入る。

PHPの切替え又は大きな更新の前には，両者を同じバックアップセットとして取得する。バックアップ成功の表示だけでなく，対象，取得時刻，保存先，暗号化，容量，世代及び復旧に必要な認証情報を記録する。

２　バックアップの存在と復旧できることは別であること

復旧手順，復旧先及び担当者が不明であれば，バックアップが存在しても緊急時に利用できないことがある。平時に，別環境又は安全な手順で復元できるかを試し，所要時間と不足事項を記録する。

本番と同じ管理アカウント，サーバー又は同期経路でバックアップまで削除・暗号化できる構成は避ける。複数世代を持ち，少なくとも一つは通常の本番環境と障害を共有しにくい場所へ保管する。

第６　安全な更新順序

１　変更を分けること

同時にPHP，WordPress本体，テーマ，複数のプラグイン及びキャッシュ設定を変えると，不具合が起きた場合に原因を切り分けにくい。緊急性，依存関係及び復旧時間を考慮しつつ，可能な範囲で変更単位を分け，変更ごとに版と試験結果を残す。

ただし，公式修正版が公開され，関連する複数系列を直ちに更新する必要がある場合に，形式的な分割のため対応を遅らせてはならない。事前の互換性確認，変更窓，ロールバック及び検証担当を準備し，緊急性と切分け可能性を両立させる。

ロールバック先も，今回の脆弱性への対応状況を確認する必要がある。
以前は正常に動いていた構成でも，PHPを未修正の状態へ戻せば，脆弱性が再び残ることがある。
修正済みの構成で復旧できない場合は，公開停止又は到達制限を継続する必要性と代替連絡手段を管理者が判断し，単に表示が戻ったことだけで公開再開を決めない。

２　検証環境と本番環境の違いを記録すること

検証環境がある場合は，PHP，WordPress，テーマ，プラグイン，データベース及び独自コードを本番に近付ける。個人情報又は依頼者・顧客の秘密を含むデータを検証環境へ複製する場合は，必要性，アクセス権，保管期間及び削除を別に検討する。

検証環境がない場合でも，バックアップ，復旧経路，低利用時間帯，監視，試験項目及び連絡方法を先に決める。更新を開始してから復旧方法を探さない。

３　自動更新と手動更新の役割を決めること

WordPress本体の軽微なセキュリティ更新，プラグイン及びテーマの更新を全て同じ方式で扱う必要はない。自動更新を利用する対象，事前試験を要する対象，緊急時に手動で更新する対象及び更新を止める条件を決める。

自動更新を有効にする場合も，失敗通知，更新後試験及び復旧を用意する。自動更新を無効にする場合は，脆弱性情報の受領者，判断期限，代替担当者及び更新完了の確認方法を決める。

第７　更新後の検証

１　管理画面だけで完了としないこと

更新後は，管理画面の版表示，更新履歴，エラーログ及びサイトヘルスを確認する。これに加えて，ログインしていない利用者として公開画面を開き，主要記事，画像，内部リンク，検索，フォーム，メール送信，モバイル表示及び主要なブラウザー操作を確認する。

キャッシュ又はCDNがある場合，管理者には新しい画面が見えていても，匿名利用者には古い画面又はエラーが残ることがある。管理画面，保存された設定値，匿名の公開HTML及び必要に応じた複数の表示幅を別々に確認する。

２　異常がないことの証拠を限定すること

トップページが表示されたことだけで，全記事，管理画面，フォーム，定期処理又はメール送信が正常とは限らない。逆に，サイトヘルスのおすすめ項目が残っていることだけで，更新が失敗したともいえない。

確認したURL，操作，時刻，結果，確認者及び未確認範囲を記録する。「異常なし」という表現には，どの試験の範囲で異常を認めなかったかを付記する。

第８　法律・税理士事務所の業務継続と事故対応

ウェブサイトが停止した場合，問合せ又は予約の未着，依頼者・顧客への連絡不能，採用応募の未受信及び信用への影響が生じ得る。障害期間，送信フォームの記録，メールサーバーの受信記録及び代替連絡先を確認し，必要に応じて未着連絡を監査する。

改ざん，不審な管理者，第三者サイトへの転送又は不明なコードを認めた場合は，単なる更新失敗として上書きしない。画面，ファイル，アクセスログ，管理者操作，DNS，CDN，WAF，サーバー及びWordPressのログを保全し，確認済み事実，技術上可能なこと及び不明点を分ける。個人データ又は秘密情報へのアクセス可能性がある場合は，個人情報保護法，職業規範，委託契約及び保険に基づく報告・通知の検討へつなげる。

復旧を急ぐ場合も，どの証拠が変更又は失われるかを記録する。脆弱性を修正したことと，過去の侵害がなかったことは同じではない。

第９　令和８年１０月２１日のPHP緊急セキュリティ更新

１　公式発表で確定した影響版と修正版

PHPは，令和８年１０月２１日，認証を受けていない第三者による遠隔コード実行につながり得る二つの重大な脆弱性を公表した。識別子はCVE-2026-109618及びCVE-2026-109619であり，いずれもCVSS v4.0で9.2と評価されている。

公式アドバイザリが示す影響版と修正版は，次のとおりである。

PHP公式発表は，PHP-FPM，Apacheのmod_php，php-cgi，FrankenPHP及びLiteSpeedを含め，ウェブリクエストを処理する全てのPHP環境がリスクの対象であり，実証された攻撃がアプリケーションコードの実行前に到達し得るmod_phpのリスクを特に高いとしている。したがって，「PHP 8.1以下だけが対象であり，8.2以上なら安全である」という説明は誤りである。

２　二つの脆弱性の概要

CVE-2026-109618は，メモリー不足時の処理が，PHP内部のリクエストデータが不完全な状態で処理を中断し，終了処理が無効な状態を有効なものとして扱う可能性に関する脆弱性である。公式アドバイザリは，mod_phpについて，通常の入力・メモリー制限下でHTTP経由の未認証遠隔コード実行を実証したとしている。PHP-FPMについても影響を受け得るとのソース解析結果が示されているが，同じ実証範囲であると読み替えてはならない。

CVE-2026-109619は，一つのリクエストに属する内部状態が，そのメモリーの解放後もワーカーに残り，後続リクエストが通常の初期化前に古い状態を利用する可能性に関する脆弱性である。悪用には，状態を残す処理と，後続リクエストでその状態を利用する処理等の条件が必要であるが，権限又は利用者の操作を必要としないネットワーク経由の攻撃として評価されている。

３　直ちに行う確認と更新

PHP公式は，完全な緩和策はなく，修正版への更新だけが完全な対策であると説明している。まず，サイトヘルス又はサーバー管理画面で完全な版番号と実行方式を記録し，8.5.12，8.4.27，8.3.36又は8.2.35以上へ更新する。レンタルサーバーが同じ番号ではなく独自の修正済みパッケージを提供する場合は，バックポートの対象CVE，提供日時及び再起動の要否を事業者情報で確認する。

PHP 8.1以前はPHPプロジェクトのサポートを終了している。公式は今回に限り，ソースから構築する利用者等のために7.4，8.0及び8.1への最小限のバックポートを示したが，通常の公式サポートが再開したわけではない。LTS提供者の修正済みパッケージを確認できない限り，サポート対象系列への移行を優先する。また，PHP 8.2も令和８年１２月３１日にサポートを終了するため，8.2.35への緊急更新とは別に，8.3以降へ移行する計画が必要である。

４　直ちに更新できない場合の限定的措置

公式発表は，更新できない場合の一時的措置として，CVE-2026-109618について管理者設定での「memory_limit=-1」，控えめな「post_max_size」及びフロントエンド側の入力制限等を，CVE-2026-109619について「session.upload_progress.enabled=0」として全ワーカーを再起動すること等を挙げている。しかし，いずれも特定の攻撃経路の露出を減らすだけで，安全な状態にするものではない。

これらの設定変更は，可用性，ファイルアップロード，フォーム及びサーバー資源へ別の影響を及ぼし得る。設定名だけをコピーして本番へ投入せず，サーバー管理者又はホスティング事業者と影響，適用範囲及び再起動を確認し，修正版への更新までの暫定措置として扱う。

５　メール通知の評価

今回の事前通知が強い警戒を促した点には理由がある。しかし，「PHP 8.1以下が今回のリスク対象である」との限定は，正式発表後の公式情報と一致しない。また，公式発表は脆弱性と実証可能性を示しているが，午後１１時を境に世界中で必ず一斉攻撃が始まることや，個別サイトが既に侵害されたことまでは示していない。

したがって，受信メールを攻撃開始時刻又は個別侵害の証拠として扱うのではなく，公式の影響版，現在の完全な版番号，実行方式，ホスティング事業者の修正状況及びログを対応させて判断する。修正版へ更新したことは将来の攻撃経路を閉じるために必要であるが，更新前に侵害がなかったことの証明にはならない。

第１０　確認用チェックリスト

①メールのリンクではなく，PHP及びWordPressの公式情報を確認した
②PHPの系列だけでなく完全な版番号と確認時刻を記録した
③WordPress本体，テーマ，プラグイン，独自コード及びサーバー設定を一覧にした
④ファイルとデータベースを同じ更新前のバックアップセットとして取得した
⑤バックアップの保存先，世代，復旧担当及び復旧手順を確認した
⑥互換性試験，変更窓，連絡先及びロールバック条件を決めた
⑦自動更新と手動更新の対象，担当及び失敗通知を決めた
⑧サイトヘルスの表示を侵害確定又は安全証明と取り違えていない
⑨管理画面と匿名の公開画面の双方で主要機能を試験した
⑩問合せ・予約・メールの未着及び業務期限への影響を確認した
⑪改ざん又は侵害の疑いがあれば，上書き前にログと画面を保全した
⑫確認済み事項，提供者の説明，推測及び不明点を分けて記録した
⑬令和８年１０月２１日の脆弱性について，8.5.12，8.4.27，8.3.36又は8.2.35以上，若しくは利用する提供者の修正済みパッケージであることを確認した

第１１　出典

①PHP「Security advisory: Critical remote code execution vulnerabilities, update now」（令和８年１０月２１日付。同日午後１１時台確認）
②php/php-src「RCE via OOM corruption」（CVE-2026-109618。令和８年１０月２１日確認）
③php/php-src「RCE via stale global state」（CVE-2026-109619。令和８年１０月２１日確認）
④PHP「Supported Versions」（令和８年１０月２１日確認）
⑤WordPress.org「Site Health screen」（令和８年１０月２１日確認）
⑥WordPress Developer Resources「WP_Site_Health::detect_plugin_theme_auto_update_issues()」（令和８年１０月２１日確認）
⑦WordPress Developer Resources「Backups」（令和８年１０月２１日確認）
⑧WordPress.org「Updating WordPress」（令和８年１０月２１日確認）
⑨WordPress Developer Resources「Hardening WordPress」（令和８年１０月２１日確認）