PHP更新後にWordPressへログインできない時の直し方｜Cookie・セッションの安全な切り分け

2026年10月23日

PHPのセキュリティ更新後にWordPressの管理画面へ入れない、ログインしても元の画面へ戻る、「Cookieがブロックされています」と出る。そんな時、すぐにPHPを古い版へ戻したり、Cookieの保護設定を無効にしたりするのは危険です。ログイン画面が開くか、認証が通るか、Cookieが保存されるか、ログイン状態が維持されるかを分けると、直す場所が見えます。この記事では、PHP2Shell対策を維持したまま、WordPressのログイン・セッション・Cookie障害を切り分ける手順を示します。

2026年10月21日にPHPプロジェクトはCVE-2026-109618とCVE-2026-109619に対応するセキュリティ更新を公開しました。更新した直後に障害が出ても、必ずPHP本体の不具合とは限りません。設定差、プラグイン互換性、キャッシュ、ドメインやHTTPSの不一致、ブラウザー側の状態などが重なる場合があります。脆弱性の概要や修正版の確認はWordPress利用者向けPHP2Shell対策を参照してください。ここでは管理者がログインできない時の安全な復旧に絞ります。公式資料の確認日は2026年10月23日です。

ログイン障害を4つの症状に分けて判断する

同じ「ログインできない」でも、画面に至る前のPHPエラーと、正しいID・パスワードを入力した後のCookie不具合では調べる場所が違います。まず利用者から「いつ」「どのURL」「どの端末」「どの画面」「表示された文言」「直前に何を変更したか」を聞きます。パスワードや認証コードは聞かず、スクリーンショットにも写さないよう伝えてください。時刻と対象URLだけでも、サーバーログとの突き合わせに役立ちます。

症状	最初に見る項目	避ける早合点
wp-login.phpが開かない・白画面	HTTP応答、PHPエラーログ、保守画面、WAF	Cookie削除だけで直ると考える
認証後にログイン画面へ戻る	Set-CookieとCookie送信、URL・HTTPS、キャッシュ	パスワードの誤入力と決める
「Cookieがブロック」等の表示	ブラウザー設定、ドメイン、ヘッダー送信エラー	Secure属性を無効にする
入れるがすぐログアウトする	複数ノード、キー・ソルト、トークン保存、時刻	PHPの標準sessionだけを原因とみなす

WordPressは独自の認証Cookieとセッショントークンを使います。PHPの標準的なsession_start()を必ず使ってログインを維持するわけではありません。WordPressのCookie解説は、ログイン状態に関わるCookieを説明しています。PHPのsession.save_pathやsession.gc_maxlifetimeは、セッションを使うプラグインや独自コードでは重要ですが、WordPress標準の認証不具合と直接結び付ける前に仕組みを区別してください。

影響の広さを測り、管理者だけか全利用者かを見る

管理者一人の端末だけで再現するなら、ブラウザーのCookie設定、拡張機能、プライベートウィンドウでの差を先に確認します。複数人かつ複数端末で同時に起きたなら、サーバー設定、CDN、サイトURL、プラグイン更新が疑わしくなります。公開ページは見えるが管理画面だけ失敗するなら、wp-adminのキャッシュと認証リダイレクトが候補です。公開ページも白画面ならPHPエラーの切り分けを優先します。

利用者が多いサイトでは、調査のために全員へ一斉ログアウトをかける前に影響を見積もります。編集者が記事を保存中、EC店舗で受注処理中、会員が購入中の可能性があります。全セッション無効化や認証キーの更新は強い対処ですが、全員に再ログインを要求します。侵害が疑われる時と単純な設定不一致では、優先する手順が違います。

更新履歴を一枚にまとめる

PHP枝と修正番号、切り替え時刻、WordPress本体、テーマ、ログイン・セキュリティ・キャッシュ系プラグイン、CDNやWAFの変更を時系列で記録します。複数の作業が同時に入った場合、時間が近いだけで原因を決めつけません。観測したエラーと再現条件を一つずつ照合します。利用するホスティング会社がPHPへ独自バックポートを入れる場合、同社の適用通知と実稼働環境を確認します。PHP管理画面の表示だけで「本番全ノード完了」と決めないことも重要です。

Cookie・URL・HTTPSを安全に確かめる

WordPressのログイン解説は、テストCookieや認証Cookieを設定できない場合、URLとCookieの条件を確認するよう案内しています。調査は「ブラウザーがCookieを受け取ったか」「次のリクエストで送ったか」「サーバーが受け入れたか」の三段階です。ブラウザー開発者ツールのネットワーク表示で確認できますが、Cookie値や認証トークンをスクリーンショットで共有しないでください。値を見せる必要は通常ありません。Cookie名、属性、送信先ホスト、応答コードだけでも判断できます。

ドメインとパスの不一致を見る

たとえばログイン画面がwww.example.jpで開き、ログイン後はexample.jpへ戻される場合、Cookieの送信先ドメインが合わないことがあります。WordPressアドレスとサイトアドレス、リバースプロキシの転送設定、CookieのDomain/Path、リダイレクト先を並べて確認してください。公開サイトのURLを本番でいきなり書き換えると、画像、リンク、会員のアクセスに影響するため、変更案をステージングで確かめます。

WordPressのWP_HOMEやWP_SITEURL、データベース上のURL、ロードバランサーのHostヘッダーが別々になっていないかも見ます。原因を調べずCOOKIE_DOMAINを追加・削除して偶然ログインできても、別のサブドメインやマルチサイトで新しい不具合を作ることがあります。まず元の設定と変更後の予想を記録し、担当者が差分をレビューします。

HTTPSを保ち、Secure属性を外さない

ログイン画面と管理画面はHTTPSに統一します。ブラウザーがHTTPSと認識していても、プロキシの後ろにいるPHPがHTTPとして扱っていると、URL生成やCookie属性が噛み合わない場合があります。ブラウザーのアドレス欄、Location応答、Set-Cookie属性、サーバーへ渡るHTTPS情報を対応づけて確認します。証明書の期限切れや混在コンテンツがあるなら、その解消を優先します。

「Cookieが保存されないからSecure属性を消す」「管理画面だけHTTPに戻す」という方法は避けます。認証Cookieを盗まれやすくするためです。正しいホストとHTTPSを設定し、CDN・プロキシ・オリジンの間で実際のスキームが一貫して伝わるよう修正します。ログイン不具合の解決と認証情報の保護は同時に満たすべき条件です。

キャッシュにログイン画面・管理画面を入れない

CDN、ホスティングのページキャッシュ、WordPressのキャッシュプラグイン、ブラウザーの四つを分けます。ログイン画面や管理画面、利用者ごとに内容が変わるページが共通キャッシュへ入ると、古いリダイレクトやCookieの扱いで問題が起きます。WordPressの標準的なログイン・管理画面は通常キャッシュ対象から除外します。ただし除外範囲をサイト全体に広げる前に、対象URLとCookie条件を確認します。

作業者は「キャッシュを削除したら直った」を最終原因にしないでください。どの層のキャッシュを消したのか、再発しない設定かを確認します。再び誤キャッシュが生成されるなら一時的な解消にすぎません。キャッシュの設定変更前後に、シークレットウィンドウの新規セッションと既存ログイン利用者の双方を試します。既存利用者のCookieだけ古いケースがあるためです。

PHPセッションとWordPress認証を混同しない切り分け

PHP更新をきっかけに「session.save_pathを変えればログインが直る」という情報を見かけるかもしれません。しかしWordPress標準の管理者ログインは認証Cookieとセッショントークンの仕組みで動きます。WordPress関数リファレンスでも現在のトークンをログインCookieから取得することが示されています。標準ログインだけが失敗するなら、最初にCookieと保存されるトークン、サイトURLを調べます。

標準ログインと拡張プラグインのセッションを区別する

会員サイト、ECのカート、フォーム、外部認証、独自PHPアプリは、PHPの標準セッションを使うことがあります。PHP公式のセッション設定には保存先、Cookie、失効時間などがあります。管理者ログインは正常だが会員カートだけ消える場合、標準認証よりプラグインやカートの状態管理を調べる方が合理的です。逆に管理画面ログインと会員機能が共に失敗しても、共通の原因とはまだ決まりません。別々の経路で検査します。

複数のサーバーノードを使う環境では、どのノードでCookieの検証とトークン保存をしたかも重要です。各ノードの認証キー・ソルトが異なる、オブジェクトキャッシュが不整合、時刻に大きなずれがある、ログイン処理後のアクセスが別設定のノードへ行く、などの可能性があります。安易にキーを表示して比較せず、配置元の構成管理で一致を確認します。秘密鍵の内容をメールやチャットへ貼り付けないでください。

認証キー・ソルトの変更は「全員ログアウト」の影響を伴う

認証キー・ソルトを再生成すれば既存Cookieは無効化されます。侵害が疑われ、全セッションを無効化したい時には意味がありますが、ログイン障害の原因切り分けとして無計画に繰り返すと、編集者や顧客を何度もログアウトさせます。管理者がログインできない状況をさらに悪化させる場合もあります。操作前にバックアップ、変更履歴、再ログイン案内、複数ノードへの同時配布、元へ戻す手順を決めてください。

WordPressの全セッション無効化関数は存在しますが、通常のCookie不一致を自動的に直す万能策ではありません。セキュリティ事故への対応で全員に再認証を求めるか、単一ユーザーの不具合を局所的に直すか、目的を明確に分けます。パスワード変更、多要素認証、管理者一覧の確認も、侵害疑いがある場合は同じ計画で扱います。

「headers already sent」が見えた場合

ログにCannot modify header information - headers already sentがある場合、Cookieやリダイレクトのヘッダーを送る前にどこかが出力を始めた可能性があります。WordPressのトラブルシューティングは、エラーメッセージに示された出力元のファイルと行を見ることを説明しています。wp-login.phpの行だけでなく、先に出力したプラグイン、テーマ、設定ファイルを特定します。ファイル先頭のBOM、余計な空白、デバッグ文、PHP警告表示なども候補です。

対応は、出力原因を取り除き、ヘッダーが正しく送れるようにすることです。警告を非表示にしただけで原因が残る場合、次の更新で再発します。公開サイトでエラー表示を有効にするとパスや内部情報が漏れるため、詳細はアクセス制限されたログへ記録します。WordPressのエラー表示に関するセキュリティ資料も、本番での表示を避けるよう勧めています。

ログとプラグイン競合を使って原因を確定する

「キャッシュを消す」「ブラウザーを変える」は切り分けには有効ですが、全員に起きている障害の最終解決にはなりません。発生時刻に近いサーバーのPHPエラーログ、Webサーバーの応答、WordPressのログイン関連ログ、WAFのブロック記録を照合します。ログイン失敗の中には正常な認証拒否も含まれるため、記録を読んだだけで障害とみなしません。対象URL、HTTP応答、リダイレクト回数、Cookie属性、利用者への影響を組み合わせます。

本番にエラーを出さず、ステージングで再現する

WordPressのデバッグ資料ではログ取得方法が説明されていますが、本番にデバッグ表示を開くことは推奨されません。まずホスティング会社が提供する非公開エラーログを見ます。必要なら、アクセス制限されたステージングで再現し、WP_DEBUGやログ設定を一時的に使います。公開ディレクトリのdebug.logを誰でも取得できる状態にしないでください。

収集するのは発生時刻、エラー種別、ファイル名、プラグイン名、PHP版、再現手順です。ログにCookie値、セッショントークン、メールアドレス、URLの秘密パラメーターが出るなら伏せて共有します。原因を特定した後は、不要なデバッグ設定と一時ファイルを取り除き、ログの保管期限を決めます。ログを放置すること自体が新しいリスクになります。

プラグインを一つずつ無効化する前に影響を確認する

ログインURL変更、二要素認証、シングルサインオン、セキュリティ、キャッシュ、会員管理の拡張は認証経路に関わります。プラグイン競合が疑わしいときは、まず更新履歴とPHP対応版を確認し、ステージングで一つずつ無効化して再現の変化を見ます。WordPress公式のログイントラブルシューティングも、原因調査時に環境情報とプラグイン等の切り分けを重視しています。

本番でセキュリティプラグインを無効化するなら、その間の防御が変わります。短時間の検証と代替保護、操作担当、戻し方を決めてから実施します。プラグインの全停止を「最初の手順」にしないでください。ログイン用の二要素認証を外したまま放置することも避けます。元の保護を維持できる修正版や設定変更があるなら、提供元へ問い合わせます。

リダイレクトループは一箇所ずつ追う

ログイン後にwp-adminへ進む途中でループする場合、ブラウザー、CDN、Webサーバー、WordPress、プラグインのどの層がLocationを返したかをネットワーク記録で追います。http://とhttps://を行き来する、wwwあり／なしが入れ替わる、認証後の戻り先パラメーターが古い、キャッシュされた301が残るなど、ループの形で手掛かりが得られます。設定を一度に複数変えると原因が分からなくなるため、ステージングで一項目ずつ検証し、本番では承認後に同じ変更を適用します。

安全に復旧する順番と停止条件

復旧作業には「ログインを戻す」だけでなく、「修正版PHPを維持する」「認証の保護を落とさない」「データを失わない」の三つの条件があります。PHP2Shell対策のために更新した環境を、原因未確認で脆弱な版へ戻して営業を続けるのは避けます。管理画面が使えなくても、ホスティング会社の管理機能、SFTP、復旧モード、保守担当の正規手順で調査できる場合があります。権限のない者が認証を回避する方法は使いません。

最初の30分：影響範囲とアクセス確保

担当者は時刻、対象ドメイン、ログインできない利用者の範囲、公開サイトへの影響を記録します。管理者全員が入れない場合、既存の管理セッションが残る別端末や、ホスティング会社の管理画面、WordPressの復旧メールを確認します。メールのリンクを使う場合は送信元と宛先、ドメインを確かめ、フィッシングと取り違えないようにします。同時に変更作業を止め、バックアップとサーバーログを保全します。

サイトが会員情報や注文を扱う場合、ログイン障害が一般利用者にも及ぶかを確認します。管理者だけの障害なら公開画面を維持しながら調査できるかもしれません。会員全体に及び、購入や個人情報確認に影響するなら、運営責任者が案内と代替窓口を決めます。顧客へ一律にパスワード再設定を求める前に、サイト側の障害かどうかを見極めます。

次の数時間：原因に合う最小変更

URL不一致なら正しいホストへ統一し、Cookie属性とリダイレクトを確認します。PHPエラーなら原因プラグイン・テーマ・独自コードの互換性を修正します。WAF誤検知なら安全な最小ルール調整を検討し、全体の保護を無効にしません。キャッシュならログイン・管理画面の除外規則を修正し、再発しないかを確認します。複数ノードのキー・ソルト不一致なら構成管理をそろえます。どの変更も、実行前の状態、期待結果、失敗時の戻し方を記録してから作業します。

複数の問題が重なる場合は、まずHTTP応答やfatal errorなど画面に届く前の失敗を直し、次に認証とCookie、最後に会員機能や追加プラグインの状態を確認します。一度にPHP設定、URL、プラグイン、WAFを変えると「直った」原因が分からず、再発時に同じ調査を繰り返します。変更窓口を一人に集約し、観測と作業の時刻を同じ基準で記録します。

復旧完了は複数の役割で判定する

管理者一人が入れただけでは完了にしません。新しいブラウザーでのログイン、既存セッションからの操作、管理画面のページ遷移、記事の保存、ログアウト、再ログイン、編集者など別ロール、必要な会員ログインを確認します。HTTPS、二要素認証、WAF、CookieのSecure/HttpOnly等の保護、修正版PHPの適用が維持されているかも点検します。個別プラグインが別のCookieを使う場合は、その機能もテストします。

復旧の責任者は、テスト項目と結果、未解決の症状、次の監視時刻を承認します。問題が再発した時の連絡先も共有します。サービスを早く戻す目的で一部機能を停止するなら、停止する範囲と利用者への案内を明確にします。パスワードや認証トークンの漏えいが疑われる場合は、単なる機能障害として扱わず、別のインシデント対応を始めてください。

よくある質問と再発防止の確認表

Cookieを全部削除すれば管理者全員の問題は解消しますか？

一人の端末で古いCookieが残っただけなら改善する場合があります。しかし複数人で同時に再発するなら、URL、HTTPS、キャッシュ、サーバー側設定を見直す必要があります。Cookie削除を依頼する際も、そのサイトのものだけを対象にし、他サービスのログイン状態にまで影響する一括削除を安易に勧めないでください。

PHPの`session.save_path`を変更すればWordPressログインが直りますか？

WordPress標準の認証はPHP標準セッションとは別の仕組みです。まずWordPressのCookieとセッショントークンを確認します。一方、独自プラグインや会員機能がPHPのセッションを利用するなら、その保存先や権限、失効条件の検証が必要です。どのコードがsession_start()を使っているかを開発担当が確認してから、対象を限定して設定を変えます。

PHP更新前へ戻すのが一番早いのでは？

脆弱性対策のための更新なら、古いPHPへ戻すことは安全な復旧とは限りません。先に修正版を維持したまま原因を切り分け、ホスティング会社やプラグイン提供元に相談します。公開サイトでの危険、顧客への影響、代替運用を比較し、セキュリティ担当と運営責任者が判断してください。単なる時間短縮だけで脆弱な状態へ戻さないことが大切です。

ログインできない間、二要素認証を解除してよいですか？

まず公式の復旧手段、バックアップコード、管理者の権限移譲、提供元サポートを確認します。二要素認証プラグイン自体に互換性障害がある場合でも、本番で無制限に解除して放置しません。やむを得ず一時変更するなら、実施者、対象アカウント、期限、代替保護、復帰時刻を記録し、作業後に保護が戻ったことを別担当が確認します。

確認項目	担当	完了の証拠
修正版PHPの実稼働	インフラ	ホスト通知とWeb実行環境
URL・HTTPS・Cookie属性	開発	テストのネットワーク記録
プラグイン・テーマの互換	開発	ステージング再現と修正記録
管理者・編集者のログイン	運営	別端末での操作結果
二要素認証とWAF	セキュリティ	設定と再認証テスト
会員・注文機能	サービス担当	代表シナリオの合格記録

最後に、障害の発生から復旧までの時間、最初の検知方法、切り分けで不要だった操作、次回の更新前に追加するテストを振り返ります。ログイン監視はパスワードを送る自動テストに限りません。ログイン画面のHTTP応答、認証後の限定された検証アカウント、リダイレクト異常、管理画面のエラー率など、権限と秘密情報を適切に管理した監視へ設計できます。監視用アカウントの権限は最小にし、結果を定期的に見直します。

架空例：管理者だけ「ログイン後に元へ戻る」

以下は説明用の架空例です。PHP更新の当日、管理者はログインボタンを押しても同じ画面へ戻りました。一方で一般会員は正常に利用できました。開発担当はブラウザーのネットワーク記録で、認証後の応答にCookieが含まれることを確認しました。しかし次のwp-adminへの要求ではCookieが送られていません。画面URLがwww付き、遷移先がwwwなしになっていたためです。PHP更新自体ではなく、同じ時間帯に入ったプロキシ設定変更が原因でした。

このケースでは「会員が入れるからCookie全体は正常」とも、「更新直後だからPHPが壊れた」とも判断できません。管理者と会員でCookie名、Path、Domain、遷移先が違うことを前提に検査します。正しいホストへ統一し、ステージングでログイン・ログアウト・管理画面の複数ページ遷移を確認してから本番へ適用します。修正後、旧URLへのアクセスが予期しないリダイレクトを起こさないかも見ます。

架空例：複数サーバーで「たまにログアウト」

別の架空例では、二台のWebサーバーの一方だけPHPを更新しました。最初のログインは成功しますが、ページ遷移のたびにログイン状態が不安定になります。開発担当は時刻と応答したノードを照合し、設定の差を見つけました。複数ノード環境では、PHP版だけでなくWordPressの認証キー・ソルト、オブジェクトキャッシュの共有方法、セッショントークンの保存先、サーバー時刻を整合させる必要があります。

この場合、ブラウザーCookieを消しても根本解決になりません。インフラ担当はノード単位の構成差と負荷分散の設定を比較し、修正版PHPをすべての対象へ適用してから再試験します。認証キーを一台だけ変えると余計にログアウトが増えるため、変更は構成管理で同期します。完了判定は一台だけを固定してログインできることではなく、通常の負荷分散下で複数回のページ遷移に耐えることです。

架空例：セキュリティ拡張だけ更新に追従していない

三つ目の架空例です。公開ページとWordPress標準のログイン画面は表示されるものの、二要素認証の入力段階でPHPエラーが出ます。サーバーログに特定の認証プラグインのファイルが示され、ステージングで提供元の更新版を適用すると再現しなくなりました。ここで本番の二要素認証を無期限に止めれば、ログインできる代わりに防御を失います。運営担当は提供元の互換情報と修正版を確認し、更新後に二要素認証が実際に要求されることを別アカウントで確かめます。

もし更新版がなく、管理者が全員入れないなら、ホスティング会社や保守契約先と復旧方法を相談します。一時的な機能停止を選ぶ場合も、IP制限、短い作業時間、強いパスワード、操作ログ、復帰の責任者をセットにします。障害の原因を特定できたことと、安全に公開運用できることは別の判定です。セキュリティ機能を戻した後、編集者など管理者以外の役割にも影響がないか確認します。

WithAIで、更新後の運用を学び直す

今回の障害対応を、担当者しか分からない手作業に戻さないことが重要です。WithAIでAIを業務に活用する知識を学び、ログの要約やチェック表の下書きを効率化できます。ただし、Cookie値、パスワード、秘密鍵、顧客情報をAIへそのまま入力しないでください。症状と時刻を匿名化し、修正の判断は公式資料と実環境の証拠に基づいて人が行います。

情報確認日：2026年10月23日。参考：PHP公式セキュリティ情報、WordPressログイン解説、WordPress Cookie解説、PHPセッション設定、WordPressデバッグ資料。