PHP更新後にWarning・Deprecatedが出たら？WordPressの安全な対処法

2026年10月23日

PHP2Shellへの対応でサーバーのPHPを更新した後、WordPressの画面に「Warning」「Deprecated」「Notice」が表示されたり、ログが急に増えたりしていませんか。結論から言うと、まず公開画面へのエラー表示を止めて情報漏えいを防ぎ、同時に原因を記録して機能への影響を調べます。表示を隠すことと、不具合を直すこと、PHP2Shellの修正済み環境にすることは別の作業です。Warningが出たから更新を必ず戻す、Deprecatedだからすべて放置する、という一律の判断も危険です。

この記事は、WordPressサイトを運用する担当者が、PHP更新後の診断メッセージを安全に切り分けるための実務手順です。2026年10月23日にPHP公式マニュアルとWordPress公式資料を確認しました。PHP2Shellそのものの影響版や修正状況はPHP公式の緊急勧告と契約先の告知を作業時に再確認してください。今回の問題はPHP実行環境側の脆弱性であり、テーマのWarningを消しても対策済みにはなりません。今回の問題の全体像はWordPress利用者向けPHP2Shell対策、対象かどうかの基本判断はPHP2Shellの影響版確認記事、更新前の準備はWordPressのPHP更新手順も参照してください。

まず5分で行う：公開表示と業務停止の有無を分けて判断

最初の目的は「エラー文を消すこと」ではなく、訪問者に機密情報が見えていないか、サイトの重要機能が動いているかを判断することです。公開ページにファイルの絶対パス、プラグイン名、SQL文の断片、ユーザー情報などが表示されているなら、露出を先に止めます。PHP公式は本番でのdisplay_errorsを無効にするよう勧めています。理由は、エラー出力から機密情報が漏れる可能性があるためです。ただし、display_errors=Offは出力制御にすぎません。動作不良や脆弱なPHP本体を修正しません。

運用担当者は変更直後の時刻、公開URL、発生画面、エラー種別を記録します。利用者の入力値や認証情報をスクリーンショットに含めないよう注意してください。その後、トップページだけでなく、ログイン、問い合わせフォーム、検索、決済、予約など事業上重要な経路を確認します。HTTP 200でもメールが送られない、注文が保存されない、といった障害はあります。利用者の操作結果まで確かめます。

見えた状態	優先度	最初の担当と行動	更新を戻す判断
画面に機密情報を含むエラー、管理画面へ入れない、決済・送信に失敗	高	運用責任者が利用者影響を確認し、サーバー担当が表示を抑えてログを保全	影響が継続し代替手段がない場合に検討。ただし脆弱な版への無条件の巻き戻しはしない
画面は正常だがWarningが同時刻に大量発生、容量・速度に影響	高〜中	保守担当が発生元と頻度を特定し、ディスク・負荷を監視	ログ肥大や機能低下の閾値を超えた場合のみ責任者が判断
Deprecated/Noticeがログに少数、重要機能は正常	中	開発担当がプラグイン・テーマの互換更新を計画	通常は即時巻き戻しせず、期限を設けて修正
一時的な診断メッセージで再現せず、影響も不明	要調査	発生時刻と操作を保存し、再発監視	証拠だけで判断せず、再現と影響を確認

この表は故障の有無を決めつけるものではありません。たとえばDeprecatedが画面に露出していれば、メッセージの種類が軽くても情報露出は別の問題です。逆にWarningが1件でも決済の途中で発生したなら、影響確認を優先します。担当者は「エラー種別」と「利用者影響」を別列で記録してください。

特にPHP2Shell対応では、脆弱なPHPへ戻して画面だけ正常にすることを安易な解決策にしないでください。PHP公式が2026年10月21日に示した修正版は8.2.35、8.3.36、8.4.27、8.5.12です。ただし、レンタルサーバー側のバックポートや提供形態で見た目の版が異なる場合もあります。契約先にCVE-2026-109618とCVE-2026-109619の修正適用状況を確認し、互換性問題と安全性問題を並行して解決します。サーバー別の照合はレンタルサーバーでのPHP2Shell対応に整理しています。

Warning・Deprecated・Noticeの違いを「影響」で読む

PHPの診断メッセージは、プログラムが処理中に検出した状態を伝えます。E_WARNINGは多くの場合その場で処理を止めない警告、E_NOTICEは注意が必要な状態、E_DEPRECATEDは将来の互換性に関する警告です。ただしPHPの版が変わると同じ処理の診断レベルが変わる場合があり、開発者が例外へ変換することもあります。「Warningなら必ず動く」「Deprecatedなら絶対安全」という判定はできません。PHP公式の診断エラーの説明とエラーレベル一覧もこの区別を前提にしています。

文言だけでなく、発生箇所・操作・結果を一組で見る

エラーメッセージの冒頭にある種別だけで優先順位を決めず、どのURL・操作で起きたか、利用者に何が起きたかを結び付けてください。たとえば「Deprecated: 動的プロパティ」という文言が管理画面の保存操作で繰り返し発生していても、保存内容が正常に反映されているなら、まずは互換性修正を予約して監視します。一方、フォームの送信後にWarningが出てメールも記録も残らないなら、業務停止として扱います。データが重複送信された可能性もあるため、再送ボタンを押す前にDBや管理画面側の保存結果を確認してください。

ログの行数は被害件数と同じではありません。アクセスの多いページで同じ診断が毎回記録されれば、大量行になっても原因は一つかもしれません。逆に1件しかなくても、管理者操作や購入処理に関係していれば重大です。発生時刻、同じメッセージの件数、ファイルと行番号、直前の変更、対象機能、利用者影響を整理すると、開発者やホストへ伝えるべき情報が明確になります。

「PHP本体の脆弱性」と「アプリの互換性エラー」を混同しない

PHP2ShellはPHP実行環境に関する二つの脆弱性です。PHP更新後にテーマのfunctions.phpやプラグインのファイル名がログに出た場合、まず疑うのはそのコードと新しいPHPとの互換性です。そのWarningがPHP2Shellの攻撃を受けた証拠とは限りません。逆にWarningが一切ないことも、PHP2Shellの修正適用や侵害不存在の証明にはなりません。版・事業者の修正状況、アプリの動作、侵害兆候は異なる検査項目です。

PHP公式のPHP 8.4移行ガイドには非互換変更や非推奨化が整理されています。更新先と更新前の版を正確に残し、該当する移行ガイドから理由を探します。ただし「どの版で必ずこの文言が出る」と経験則だけで断定しないでください。プラグインが独自に出している警告、WordPressが出す非推奨通知、PHPエンジンの警告が混在するからです。

Fatal error、HTTP 500、真っ白な画面は別の優先レーン

Fatal errorや例外でページが正常に返らない場合、Warningの表示設定だけを触っても復旧しません。WordPressの「重大なエラー」表示、HTTP 500、白画面などは、公開機能が停止している可能性があります。最初に重要導線の停止を確認し、事前に取ったバックアップと変更履歴を保全します。ホストのエラーログ、PHP-FPMログ、Webサーバーログなど、環境ごとの記録場所を担当者と確認し、発生時刻を突き合わせます。WordPress公式の一般的なエラーの案内もログ確認を勧めています。

復旧優先で一時的に機能を停止する場合は、何をいつ止めたか、再開条件は何かを記録します。プラグインの一括停止は決済、セキュリティ、キャッシュなど別の機能まで止め得ます。ステージングで候補を絞る、ホストに障害範囲を確認する、代替画面を用意するなど、影響を限定する順番を選びます。

本番では画面に出さず、安全な場所へ記録する

本番環境の診断メッセージは公開画面へ出さない一方で、調査に必要な記録は残します。PHPではdisplay_errorsが画面出力、log_errorsがログ記録、error_reportingが対象レベルを扱います。display_errors=Offとlog_errors=Onの役割は別です。PHP公式マニュアルは、公開システムでは画面表示よりログを使う方針を示しています。PHPのエラー設定をサーバー構成に合わせて確認してください。

PHP設定はphp.ini、PHP-FPMのプール設定、レンタルサーバーのパネル、コンテナの環境設定など、管理場所が異なります。変更する前に設定の管理者と反映方法、再起動の必要性を確認します。WordPressのwp-config.phpだけを変更しても、Webサーバー側の起動時エラーなどすべてを制御できるわけではありません。また、処理の途中で発生する致命的な問題には実行時のini_set()が間に合わないこともあります。アプリ設定だけで「完全に非表示になった」と考えず、公開URLで実際の出力を確認します。

WordPressのデバッグ定数を正しく使う

WordPressではWP_DEBUGを有効にするとNoticeやDeprecatedを含めて詳しい診断を取得できます。WP_DEBUG_DISPLAYは画面表示、WP_DEBUG_LOGはログの書き込みを制御します。WordPress公式資料によると、後二者はWP_DEBUGが有効なときに働きます。ステージングでの短時間の調査なら、たとえば次の考え方を使えます。実環境の設定位置を確認し、同じ定数を二重定義しないでください。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/非公開領域への絶対パス/wp-errors.log' );

この例のログパスは説明用です。そのまま貼り付けず、Webから直接取得できない場所、書き込み権限、ローテーションと保管期限を管理者が決めてください。WordPress公式のデバッグ手順は開発・ステージングで使うことを前提にしています。本番では調査時間を区切り、取得後は設定を戻し、ログに機密情報が含まれていないか確認します。日常運用のPHPログはサーバー側で安全に保持する設計が望ましく、WordPressデバッグを常時ONにする必要はありません。

WP_DEBUG_LOG=trueの既定先は通常wp-content/debug.logです。WordPress公式は、このファイルが公開可能な場所に置かれ得ると警告しています。URLを誰でも取得できないか、サーバー設定でアクセスを拒否しているか、実際に未認証で試して確認します。ログにCookie、メールアドレス、問い合わせ内容、パスが残る可能性も考えて、アクセス権を絞り、外部共有時は必要箇所だけ伏せ字にします。ログファイルを個人チャットや公開チケットへ丸ごと貼らないでください。

ログを「読める」だけでなく「扱える」ようにする

大量のログが出始めたら、記録先の空き容量と書き込み速度を確認します。ログがディスクを圧迫すると、それ自体がサイト停止やメール送信失敗を起こすことがあります。担当者は15分あたりの増加量、同じ診断の割合、容量の警戒閾値、保管期限、削除権限を決めます。監視のために一時的に出力レベルを調整する場合も、何を記録しなくなったかを記録してください。安易なerror_reporting(0)やエラー抑制演算子で見えなくすると、修正の優先順位を決める材料を失います。

記録先にはOS側の権限とアプリ側の権限の両方が必要です。書けないパスを設定すると、ログが残ったつもりで調査できない恐れがあります。ステージングで意図的なテスト用通知を発生させ、指定先へ書き込まれるか確認した後、そのテストコードを削除します。本番での故障の再現を目的に危険な入力を送らないでください。PHP公式のerror_log関数資料にも記録先の違いが説明されています。

もし公開状態のログへ第三者がアクセスできた可能性があれば、単にログを削除して終わりにしません。アクセス可能だった期間、ログへ入っていた情報の種類、Webサーバーのアクセス履歴を確認します。パスワードやトークンが含まれたなら、該当する認証情報を無効化・再発行し、関係者へ報告する必要があります。問い合わせ内容など個人情報を含むなら、社内の個人情報管理手順にも従います。証拠となるログ原本は権限を絞った場所へ保全し、閲覧・共有した人を記録します。外部へ提出する抜粋は、氏名やメールアドレス、Cookie、セッション値、秘密のパスを伏せます。伏せ字にした後でも調査に必要な時刻・ファイル・行番号・診断種別は残すと、原因を追いやすくなります。

「ログが増えるからすべて記録しない」という方針は、事故の証拠と互換性問題の早期警告を同時に失います。容量の問題ならまず発生源を特定し、監視・ローテーション・保持期間を整えます。診断レベルを一時的に下げるなら、変更前後の設定と復帰予定日をチケットへ残し、少なくとも重大なエラーを拾えることを確認してください。運用環境によってはPHPとWordPressの双方でログが出るため、重複記録か別件かも時刻とメッセージで見分けます。

原因を追う順番：時刻、更新差分、プラグイン・テーマ

エラーの解決では「どの設定を変えたら消えたか」だけでは足りません。同じ時刻にPHPの更新、WordPressの更新、プラグインの自動更新、キャッシュ変更が重なることがあるからです。まず変更履歴を時系列に並べます。PHPの実際のWeb実行版、ホストのパッチ適用状況、WordPress版、テーマ名・版、主要プラグイン版、変更時刻を記録します。VPSのCLIでphp -vだけを見ると、Webを動かすPHP-FPMやmod_phpの版と異なる場合があります。Web側の版はホストの管理画面またはWordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」などで確認します。

一つの再現経路を選び、結果を明確にする

「たまにエラーが出る」では原因を絞りにくいため、再現条件を一つ決めます。たとえば「管理者が商品を編集し、保存ボタンを押すと、保存後の画面でWarningが出る」という形です。再現に使ったアカウントの権限、URL、操作、時刻、期待する結果、実際の結果を記録します。個人情報や決済情報はダミーデータに置き換えます。ステージングがある場合は本番データを適切にマスキングし、本番と同じPHP系列・プラグイン版で再現します。差がある環境では再現しないことも重要な情報です。

利用者影響が大きい箇所から確認します。問い合わせフォームなら送信完了画面だけでなく、通知メール、保存レコード、二重送信の有無を見ます。ECならカート、決済結果、注文レコード、顧客メール、在庫の整合性を確認します。会員サイトならログイン、権限、マイページ表示を確認します。この検品を省くと、画面の警告が消えたことを復旧と誤認します。

ログのファイル名だけで犯人を決めない

ログにプラグイン内のファイルパスが出ていても、原因がそのプラグイン単独とは限りません。呼び出し元のテーマ、データの形式、PHPの設定、別プラグインとの組み合わせが影響することがあります。先頭の1行だけでなく、可能なら前後のリクエスト時刻、スタックトレース、関連する操作を見ます。ただし機密情報を含むフルログを外部へ送らず、必要な行だけを保全・伏せ字にして共有してください。

切り分けの基本は一度に一要素です。ステージングでプラグインAを止めて再現が消えたら、Aを戻して再現が戻るか確認します。これでAの関与は強まりますが、A単独のバグと断定するには版や設定の確認が必要です。親テーマ、子テーマ、カスタムコードにも同じ方法を使います。すべてのプラグインを同時に停止して「直った」としても、どれが原因かは分かりません。変更前の状態へ戻せるスナップショットを作り、操作履歴を残します。

切り分け作業を始める前に、対象ページの通常時の動きを短い動画や検品票に残すと、修正後との比較ができます。たとえば問い合わせフォームでは「送信完了」と「通知メール受信」と「管理画面に記録」の三点を別々に確認します。警告表示が消えても通知メールだけが止まっていれば、改善は未完了です。画面キャッシュがあるサイトでは、ログインした管理者と一般訪問者で表示が違うこともあります。キャッシュを消す前後、PCとスマートフォン、管理者と未ログインの状態を分けて検品します。再現条件を変えながら試す場合は、同時に複数の設定を触らず、変更ごとにログと機能結果を記録してください。

開発者・ホストへ渡す最小の報告書

報告書には、発生日時とタイムゾーン、Web側PHP版、WordPress・テーマ・プラグイン版、対象URL、再現手順、期待結果と実結果、伏せ字にしたログ抜粋、直前の変更、暫定回避策、利用者影響を含めます。「PHP更新後から壊れた」だけでは、担当者が同じ調査をやり直すことになります。ホストへはPHP2Shellの二つのCVEに対するパッチ状況と、設定変更の可否を別質問として伝えます。プラグイン開発者へは互換性再現を伝え、機密情報やログ全文を送らないでください。

入力情報	担当	成果物	完了条件
更新前後の版・変更時刻	サーバー担当	版とパッチ状況の記録	Webで実行中のPHPと提供元を特定
再現操作・重要機能の結果	運用担当	匿名化した再現票	第三者が同じ操作を再現可能
ログの該当行と周辺時刻	開発担当	原因候補と検証計画	次に試す変更が一つに絞られる
修正版の動作結果	検品担当	機能検品表	表示とデータ整合性が基準内

修正・復旧の条件を先に決め、再発を防ぐ

原因候補が見つかったら、修正方法を影響の小さい順に選びます。対象プラグインやテーマに互換更新があるなら、開発元の変更履歴を確認してステージングへ適用します。独自コードなら、PHPの移行ガイドとテスト結果を使い、コードを修正します。代替プラグインへの乗り換えや一部機能の一時停止は、データ移行と権限に影響するため責任者の承認を取り、戻し方を用意します。コードの古い書き方を放置したまま出力だけ消すことは、将来のPHP更新でより大きな障害を招きます。

本番変更の前に、ファイルとデータベースのバックアップを取得し、復元できるか試します。バックアップの取得だけでは完了ではありません。復元先、作業担当、所要時間、どの時点までの注文やフォームデータが失われ得るかを確認します。WordPress公式のPHP更新ガイドも、更新前のバックアップと互換性確認を案内しています。

ステージングから本番へ進む品質ゲート

開発担当はステージングで修正を一つずつ適用し、同じ操作をもう一度実行します。単にログの文言が消えるだけでなく、処理結果が正しいか確認します。運用担当はトップページ、代表記事、問い合わせ、ログイン、検索、決済・予約など該当サイトの重要経路を検品します。サーバー担当は本番と同じPHP系列・必要な拡張が揃っているか、ログの保管場所と空き容量を確認します。検品で新しいWarningが出たなら、それを残課題として分類し、重大度を判断してから公開可否を決めます。

本番反映の開始条件を「PHP2Shellの修正適用確認」「バックアップと復元手順がある」「担当者がそろう」「検品票がある」とし、停止条件を「主要機能の失敗」「想定外のエラー出力」「ログ容量の危険域」「データ不整合」とします。条件を数値化できるサイトでは、たとえば決済・フォームの成功率、HTTP 5xx、ログ増加量を変更前の基準と比べます。固定の数値を全サイトへ当てはめず、普段の水準と許容範囲を責任者が決めます。

反映後は最初の30分で重要経路を手で検品し、その後数時間はログと5xxの増加を監視します。翌日には利用者問い合わせと保存データを見直します。エラーが再発しなければ、調査用に有効化したWordPressデバッグ設定を戻し、不要なログを適切に保管または削除します。ログ内に個人情報があれば、保存先と共有履歴も点検します。変更履歴に「版、修正箇所、検品結果、残課題、担当者、時刻」を記録して作業を終えます。

更新を戻す場合も安全性を同時に評価する

PHPを前の版へ戻す判断は、サービス停止を短時間で解消できる場合があります。しかしPHP2Shellの修正前の版へ戻せば、公開環境のリスクが増す可能性があります。戻す前に、契約先のバックポート状況、代替の修正版の有無、公開機能の一時停止、ホストの支援を確認します。重大な障害でやむを得ず一時的に戻す場合も、責任者が理由と期限、公開範囲、追加監視、再更新の予定を明記します。「画面が直ったので終了」としません。感染の疑いがあるなら、ログとファイルを保全してから侵害時の初動手順へ移ります。

今回の二つのCVEの修正は、警告を出すか出さないかではなくPHP本体へのパッチが中核です。セキュリティプラグイン、WAF、画面表示の抑制、古い版への巻き戻しのいずれも、PHPの修正適用の代わりとは言えません。この境界を社内の作業記録にも明記してください。

よくある質問と公式情報の確認先

画面からWarningが消えたら修正完了ですか？

いいえ。display_errorsやWP_DEBUG_DISPLAYを無効にすれば、画面に見えなくなるだけの可能性があります。ログの発生、処理結果、PHP2Shellへの修正適用は別途確認します。画面非表示は情報漏えい対策として必要ですが、それを不具合修正や脆弱性対策と同一視しないでください。まず利用者の重要操作が正常に完了し、保存データが一致しているか確認します。

Deprecatedはすぐに直さなくてもよいですか？

直ちに停止しないケースは多いものの、将来の互換性の警告として記録し、修正期限を決めます。公開画面に表示されるなら、優先して非表示化と露出確認をします。発生件数が多くログ容量や性能に影響するなら、運用上の優先度も上がります。開発元が互換更新を出しているか、更新先PHPの移行ガイドに該当するかを確認し、次回の保守計画へ組み込みます。

`wp-content/debug.log`を公開したまま使ってよいですか？

いいえ。WordPress公式はデフォルトのログ先が公開可能な場所になり得ると注意しています。ログにはパスや入力情報が入る可能性があります。必要ならWebから取得できないパスを指定し、ホストが提供する非公開ログを使い、アクセス権と保管期間を設定します。サーバー設定を信じるだけでなく、未認証状態から取得できないことを確認します。調査が終わったログは方針に従って処理してください。

Warningが出たらPHPを旧版へ戻すべきですか？

自動的には戻しません。まず機能の実害、プラグインやテーマの更新可否、ホストが提供する別の修正版、復旧までの見込みを評価します。PHP2Shellの未修正版へ戻すとセキュリティ上の問題が残り得ます。戻す場合は一時措置として期限と再更新計画を決めます。PHP公式の修正版だけでなくホスト側のバックポート状況を照合することも必要です。

ログの急増は攻撃の証拠ですか？

ログの増加だけでは断定できません。PHP更新で以前は記録されなかった互換性メッセージが見えるようになった、アクセスの多い箇所で同じ警告が繰り返された、という理由でも増えます。一方でアクセスログ、認証ログ、ファイル変更に不審な兆候があれば、侵害対応へ切り替えます。診断ログは単独で結論を出すものではなく、時刻と関連記録を合わせて判断します。

参考にした公式資料

PHP公式：2026年10月21日の緊急セキュリティ勧告。PHP2Shellの修正版と対象環境。2026年10月23日確認。
PHP公式：Diagnostic errors。エラーレベルと表示・記録の考え方。2026年10月23日確認。
PHP公式：Runtime Configuration。display_errors、log_errors、error_reporting。2026年10月23日確認。
WordPress公式：Debugging in WordPress。デバッグ定数とログ。2026年10月23日確認。
WordPress公式：wp-config.php。公開環境の設定とログの注意。2026年10月23日確認。
WordPress公式：PHP更新ガイド。バックアップと互換性確認。2026年10月23日確認。