hCaptcha 5.2.0更新後にログインできない時の対処法とダウングレード手順
hCaptcha プラグインを 5.2.0 に更新した直後からログイン画面に「Bad hCaptcha signature!」と表示され、管理画面へ入れない場合は、5.1.0 へのダウングレードと全キャッシュの削除で解決する。この不具合は 5.2.0 の署名検証リグレッションが原因で、サイトキーやシークレットキーの設定ミスではない。
なぜhCaptcha 5.2.0への更新後にログインエラーが起きるのか
hCaptcha 5.2.0 はログイン時の署名形式を変更している。署名とは、データが改ざんされていないことを証明する値のことだ。この変更が原因で署名検証フローにリグレッション（回帰不具合、以前は正常だった機能が更新によって壊れること）が混入した。
WordPress のログイン統合と別のログイン統合が、同じ wp-login.php エンドポイントを通じて送信される際に署名の検証が失敗する。複数のプラグインがログイン画面に同時に作用する構成で、この問題が顕著に現れる。
「Bad hCaptcha signature!」というエラーは、プラグインがローカルで生成している。hCaptcha API にリクエストを送る前の段階で発生するため、サイトキーとシークレットキーの検証が成功していてもエラーが消えない。この点が原因の切り分けを難しくしている。
「ログイン試行前のhCaptcha」の設定値を 0 にしている場合、この不具合はすべてのログイン試行で発生する。0 に設定すると署名検証を回避する余地がなくなり、毎回エラーに遭遇する。
ログイン不能な状態から管理画面へ入る手順
管理画面に入れない状態でも、FTP や SSH でサーバーへ接続すれば hCaptcha プラグインを一時停止できる。プラグインを停止するとログイン経路が確保されるため、その後は通常どおり管理画面へアクセスできる。
この手順で管理画面へ入り、ダウングレードの準備を整える。
FTPまたはSSHでプラグインを停止する
FTP クライアントでサーバーへ接続し、wp-content/plugins ディレクトリへ移動する。hcaptcha というフォルダを見つけたら、フォルダ名を「hcaptcha-disabled」のように変更する。WordPress はプラグインを読み込まなくなるため、ログイン画面からキャプチャが消えて通常のログインフォームが表示される。
SSH を使える環境なら、wp-content/plugins ディレクトリで mv コマンドを実行する方法が速い。コマンドラインでの操作に慣れている場合は、この選択肢が確実だ。
管理画面に入ったらhCaptcha設定を確認する
プラグインを停止してログインできたら、WordPress 管理画面の「プラグイン」を開く。hCaptcha が停止状態になっていることを確認し、これから行うダウングレードに備えて現在の設定メモを残しておくとスムーズだ。
hCaptcha 5.2.0を5.1.0へダウングレードする手順
管理画面へ入れるようになったら、hCaptcha 5.2.0 を削除して 5.1.0 をインストールする。設定データは削除しても保持されるため、サイトキーとシークレットキーを再入力する必要はない。
5.1.0 へ戻すと署名検証の不具合が解消され、ログインできるようになる。
5.2.0を削除して5.1.0をインストールする
WordPress 管理画面の「プラグイン」から hCaptcha 5.2.0 を削除する。削除しても設定はデータベースのオプションテーブル（デフォルトでは wp_options）に残るため、サイトキーやシークレットキーが消えることはない。
次に 5.1.0 の ZIP ファイルを公式リポジトリなどから入手する。「プラグイン」メニューの「新規追加」を開き、「プラグインのアップロード」から ZIP ファイルを選択してインストールする。インストール完了後に有効化する。
サイトキーとシークレットキーを再確認する
インストール後、hCaptcha の設定画面を開き、サイトキーとシークレットキーに値が入っていることを目視で確認する。5.2.0 から戻しても設定は残っているはずだが、念のため両方のフィールドをチェックしておく。
キーの検証ボタンを押して成功すれば、API との通信自体は正常ということだ。ただしこの不具合は通信前にローカルで発生するため、検証成功の表示が出ても油断はできない。あくまでキーの有効性を確認するだけの操作だと理解しておく。
モードをLiveに設定して保存する
設定画面でモードが Live になっていることを確認し、変更があれば保存する。サイズが invisible になっているかも確認する。設定を保存したら、次のキャッシュ削除の手順へ進む。
キャッシュを削除してエラーを完全に解消する
バージョンを 5.1.0 に戻しただけではエラーが残ることがある。5.2.0 が署名形式を変更した影響で、以前のバージョンが生成したログイン HTML が各種キャッシュに残っていると、同じエラーが引き続き表示される。
ページキャッシュとサーバーキャッシュを削除する
使用しているキャッシュプラグイン（WP Super Cache や W3 Total Cache など）の管理画面を開き、ページキャッシュとオブジェクトキャッシュを削除する。サーバー側のキャッシュ機能（Varnish や LiteSpeed Cache など）が有効な場合も、同じく削除操作を行う。
CDNのキャッシュを削除する
Cloudflare やその他の CDN を利用している場合、CDN の管理画面からキャッシュをパージする。ログインページの HTML がエッジサーバーに残っていると、WordPress 側の設定が正しくても古い署名形式のページが配信され続ける。
プライベートウィンドウで動作確認する
キャッシュ削除後、通常のブラウザタブではなくプライベートウィンドウ（シークレットウィンドウ）でログインページを開く。ブラウザのローカルキャッシュや Cookie も残っていると、修正後のページを正しく読み込めないことがある。
プライベートウィンドウでログインを試み、キャプチャを通過して管理画面に入れればダウングレードは成功だ。通常のブラウザタブでまだエラーが出る場合は、ブラウザのキャッシュと Cookie を個別に削除して再試行する。
自動更新を止めて再発を防ぐ
修正版がリリースされるまで、自動更新で 5.2.0 に戻らないようにしておく。プラグインの自動更新は個別に無効化できるため、hCaptcha だけ更新を止めておくのが安全だ。
hCaptchaの自動更新を無効化する
WordPress 管理画面の「プラグイン」一覧で hCaptcha の行を確認し、自動更新を無効にする。プラグインごとの自動更新設定はプラグイン一覧画面から切り替えられる。WordPress 本体の自動更新とは別の設定なので、本体は更新を継続したまま hCaptcha だけを固定できる。
修正版のリリースを確認する方法
プラグインの公式ページやリポジトリを定期的に確認し、5.2.1 以降の修正版がリリースされたかをチェックする。修正版が出るまでは 5.1.0 のまま運用し、更新前には必ずテスト環境でログイン動作を確認する。
本番環境へ修正版を適用する際も、まずステージング環境でログイン、キャプチャ表示、ユーザー登録、パスワードリセットの一連の動作を検証してからリリースするのが安全だ。
よくある質問
プラグインを削除するとhCaptchaの設定は消えますか
いいえ、消えない。プラグインを削除しても設定はデータベースに保持される。アンインストール時にデータを削除するクリーンアップ設定を事前に有効化していた場合のみ、削除される仕組みだ。ダウングレードでサイトキーを再入力する必要はない。
ダウングレード後に「インストールが不正です」と表示されます
5.2.0 から 5.1.0 へ手動で戻す際、WordPress が古いバージョンのインストールを「不正」と判定することがある。この場合は一度 5.2.0 を完全に削除してから 5.1.0 を新規インストールする。設定が残っているため、再設定の手間はかからない。
サイトキーとシークレットキーの検証は成功するのにエラーが続きます
「Bad hCaptcha signature!」は、プラグインが API へリクエストを送る前のローカル段階で生成される。キーの検証は API との通信が正常であることを示すだけで、署名検証の不具合とは無関係だ。そのためキーが正しくてもエラーは消えない。
ログイン時にキャプチャテストが表示されるのは正常ですか
「サイズ」を「invisible」に設定しているにもかかわらず画像選択テストが表示される場合、設定が正しく反映されていない可能性がある。ダウングレード後にキャッシュを削除し、プライベートウィンドウで再度確認するとよい。それでも表示される場合は、ログイン試行前の設定値や他のログイン系プラグインとの競合を調べる。
自動更新で勝手に5.2.0に上がるのを防げますか
防げる。WordPress 管理画面の「プラグイン」一覧から hCaptcha の自動更新を個別に無効化できる。また、複数のプラグインを一元管理している場合は、更新ポリシーで hCaptcha を除外する設定を行う。
この記事のポイント
- 5.2.0 の署名検証リグレッションがログインエラーの原因
- エラーはAPI通信前のローカル処理で発生する
- 5.1.0 へのダウングレードが確実な対処法
- プラグイン削除後も設定データは保持される
- 全キャッシュ削除とプライベートウィンドウでの確認が必須
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
プラグイン更新後に WordPress ログイン不能になる「Cookie がブロックされました」エラーの直し方
CF7 Google Sheet Connector バージョン 5.2.1 へのアップデート直後から、WordPress の管理画面にまったくログインできず、ログインページで「Cookie は予期しない出力のためにブロックされました」というエラーが表示されるなら、直接の原因はそのプラグインの不具合にある。FTP を使ってプラグインフォルダをリネームし、強制的に無効化すればログイン機能をすぐに回復できる。
プラグイン更新後に WordPress へログインできなくなる根本原因
WordPress のプラグインやテーマは、PHP の開始タグを閉じずにファイルを記述するのが一般的だ。しかし、何らかの原因でファイルの末尾に余分なスペースや空行が紛れ込んだり、意図しない echo や print が実行されたりすると、WordPress 本体が HTTP レスポンスを送信する前に「予期しない出力」が生まれる。
この予期しない出力は、ログイン機能で使われるセッション Cookie や setcookie() 関数の動作を妨げる。PHP は一度でも出力が行われると、後から HTTP ヘッダーを書き換えられないため、WordPress が正しく Cookie を発行できなくなり、結果として「重大なエラー」画面や「Cookie は予期しない出力のためにブロックされました」というエラーメッセージを返すようになる。
このデモが示すのは、問題のプラグインが WordPress のログインプロセスに割り込んでしまう仕組みだ。CF7 Google Sheet Connector 5.2.1 をはじめ、ごく一部のバージョンでこの現象が発生するケースが海外フォーラムでも報告されている。根本的には、プラグイン開発者が PHP ファイルの末尾やインクルード処理に余計な出力を残してしまうヒューマンエラーに起因する。
「Cookie がブロックされました」はなぜ起こるのか── unexpected output の詳細
「Cookie は予期しない出力のためにブロックされました」は、WordPress のログイン時でなくても、プラグインの有効化画面で「このプラグインは有効化中に 3 文字の予期しない出力を生成しました」といった警告文とともに現れる。この警告は、まさに PHP が <?php の開始タグよりも前やファイル末尾に余計な空白文字を出力している証拠だ。
コンタクトフォームの送信自体は成功し、Google スプレッドシートへのデータ転送も動いているのに、ログインだけが機能しなくなるのは、フォーム送信とログイン認証で通る PHP の実行経路が異なるためだ。フォーム送信時にはセッション Cookie を新たに発行する必要がないため、表面上は問題が表面化しにくい。しかし wp-login.php や管理画面の認証周りでは、必ず Cookie のセットが行われるので、エラーが必ず検出される。
FTP で問題のプラグインを無効化する具体的な手順
管理画面にログインできない状態では、ブラウザ上の操作だけではプラグインを停止できない。ここで必要なのが、契約しているレンタルサーバーの FTP アカウントを使った直接のファイル操作だ。FTP クライアントやサーバー管理画面のファイルマネージャー機能を利用して、次の手順を実行する。
/wp-content/plugins/ ディレクトリに移動するcf7-google-sheet-connector）を探し、リネームする（末尾に _disable などをつける）/wp-admin/ にアクセスし、通常通りログインできるか確認するリネームはフォルダ名の先頭や末尾に「_」を付けるだけでも十分であり、WordPress がそのプラグインを認識できなくなる。ログインが回復したら、管理画面の「プラグイン」一覧から、無効化された状態の当該プラグインを確認できる。ここで「削除」を選べば、問題のバージョンは完全に取り除かれる。
プラグインを以前のバージョンに戻して再発を防ぐ
CF7 Google Sheet Connector を使い続ける必要があるなら、安定していた旧バージョンに戻すか、開発元が修正パッチを公開するのを待つことになる。WordPress 管理画面からプラグインを再インストールする際は、あえてバージョン 5.2.1 を避け、プラグインページ下部の「以前のバージョン」セクションや、WP Rollback のようなロールバック専用プラグインを使って前のバージョンにダウングレードできる。
また、問題が発生したプラグインをどうしても最新で使い続けたいのであれば、プラグインのサポートフォーラム（WordPress.org 内）で「バージョン 5.2.1 で unexpected output が発生しログイン不能になる」という事象を報告し、修正を促すのが建設的だ。開発者が原因を把握すれば、比較的早期に新しいバージョンがリリースされる可能性が高い。
よくある質問
FTP アカウント情報がわからない場合はどうすればいいか
契約しているレンタルサーバーの管理画面（コントロールパネル）に、FTP アカウントの設定やファイルマネージャー機能が用意されているケースが多い。cPanel なら「FTP アカウント」メニューから新規作成やパスワード再設定が可能だ。サーバー会社のサポートに問い合わせれば、FTP 接続情報を再発行してもらえることもある。
プラグインを無効化してもログインエラーが直らない
同様の症状が他のプラグインやテーマでも発生する可能性がある。全プラグインを無効化し、標準テーマ（Twenty Twenty-Five 等）に切り替えた状態で症状が消えるかどうかを確認する。それでも直らない場合は、サーバーの PHP エラーログを調べ、別の致命的エラーが起きていないか検証する必要がある。
プラグインの更新を止める方法はあるか
WordPress の標準機能では特定プラグインの自動更新だけを選択的に止めることはできないが、プラグイン「Easy Updates Manager」を使うと、プラグイン単位で自動更新を無効化できる。問題のあるバージョンを避けつつサイトを安全に保つには、ステージング環境で事前に更新テストを行うのが最も確実だ。
フォームのデータが送信されていれば問題ないのか
フォームが動いているからといって放置するのは危険だ。ログイン不能はサイト全体の管理を妨げるだけでなく、同じ予期しない出力が他の機能（RSS フィードや REST API）にも影響を及ぼす恐れがある。できる限り早急に原因のプラグインを停止し、サイト全体の健全性を取り戻す必要がある。
プラグインを手動で削除してもデータは残るのか
CF7 Google Sheet Connector の場合、コンタクトフォームの設定や Google スプレッドシートとの認証情報はデータベースに保存される。そのため、プラグインフォルダを削除しても設定情報は消えない。再度同じプラグインをインストールすれば、以前の連携設定を引き継げる可能性が高いが、念のためデータベースのバックアップを取ってから削除するのが安全だ。
この記事のポイント
- CF7 Google Sheet Connector 5.2.1 では unexpected output によりログイン不能になる不具合が報告されている
- 「Cookie がブロックされました」は PHP の予期しない出力が原因で、FTP を使ったプラグイン無効化で回復する
- 管理画面にログインできなくても、FTP やファイルマネージャーからプラグインフォルダをリネームすれば強制停止可能
- 旧バージョンへのダウングレードや開発元へのフィードバックで再発を防止できる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
プラグイン更新後にログイン不可「ユーザー名またはパスワードが間違っています」と表示される原因と直し方
プラグインの更新後、正しいユーザー名とパスワードを入力しているにもかかわらずログインできず「ユーザー名またはパスワードが間違っています」というエラーが表示されるなら、その原因は特定のプラグインが認証フローに干渉したことによる競合だ。特にログインフォームをカスタマイズするプラグインと、追加のセキュリティ認証（Cloudflare Turnstileなど）を組み合わせている場合に発生しやすい。
なぜ正しいパスワードなのに「間違っています」と表示されるのか
WordPressは通常、ログイン認証を「wp-login.php」を通じて処理している。ここにプラグインが独自のログインフォームを追加したり、認証前にCAPTCHAや追加認証を挟むと、データの送信順序や検証の流れが変わる。プラグインのバージョンアップでこの処理順序が微妙に変わった結果、正しい認証情報がバックエンドの判定に渡る前に「誤り」と判定されるケースが起きる。
典型的なパターンとして、会員制サイト用のプラグイン（Ultimate Memberなど）が生成する独自ログインページと、追加のボット対策機能（Cloudflare TurnstileやreCAPTCHA）が衝突する問題が挙げられる。どちらか一方が先にフォームの値を検証し、もう一方に正しい情報を渡せなくなることが原因だ。
まず試す緊急回避策 管理画面に入れない場合の対処
ログインできない状態では管理画面からプラグインを停止できない。次のいずれかの方法でプラグインを一時的に無効化し、管理画面に再アクセスできるようにする。
FTPやファイルマネージャーでプラグインフォルダの名前を変更する
レンタルサーバーのファイルマネージャーやFTPソフトでサイトのファイルにアクセスし、「/wp-content/plugins/」ディレクトリを開く。問題を起こしているプラグインのフォルダ名を一時的に「_（アンダースコア）」を付けるなどして変更する。WordPressは存在しないプラグインディレクトリを無効化するため、余分な認証処理が外れて本来のログインフローが復活する。
具体的な対象は、直近で更新したプラグインか、ログインフォームをカスタマイズしているプラグインだ。Ultimate Memberのような会員制プラグインや、Cloudflare Turnstileを追加しているプラグインが該当する。
wp-config.phpでプラグインを一括無効化する
FTPでWordPressのルートディレクトリにある「wp-config.php」をダウンロードし、次の一行を「/* 編集が必要なのはここまでです ! */」の直前に追加する。
define('DISABLE_PLUGINS', true);この状態でファイルを上書きアップロードすると、すべてのプラグインが一時的に無効化される。管理画面にログインできたらこの行を削除し、原因のプラグインだけを停止してから他のプラグインを再有効化する。ただし、この定数は非公式の回避策で、すべての環境で動作するとは限らない点に注意する。
原因となったプラグインの特定と恒久対応
管理画面にログインできたら、プラグイン一覧画面で「直近更新されたプラグイン」を順に停止し、問題が再現するか確認する。特に次の組み合わせに心当たりがあれば、真っ先に疑うべきだ。
- 独自のログインフォームを提供するプラグイン（Ultimate Memberなど）
- Cloudflare TurnstileやreCAPTCHAなどの認証機能をログイン画面に追加するプラグイン
旧バージョンに戻す方法
プラグインの以前のバージョンは、WordPress公式プラグインディレクトリの「以前のバージョン」セクションからダウンロードできる。プラグインページの下部にある「詳細を見る」→「開発」→「以前のバージョン」の順に進むと、過去のすべての安定版がzipで入手可能だ。管理画面のプラグイン新規追加から手動でアップロードし直すか、FTPで「/wp-content/plugins/」に解凍して上書きすれば戻せる。
Cloudflare Turnstileをそのまま使いたい場合の設定見直し
TurnstileのWidget Modeを「Managed」から「Non-interactive」に変更するか、ログインページだけ設定を除外する方法を試すと競合が緩和されることがある。Cloudflareのダッシュボード側で該当サイトの「Security → Bots → Turnstile」から、Fail-open動作（認証失敗時にアクセスを通す）を有効にするのも有効な回避策だ。
根本原因を理解して今後の更新に備える
この問題の本質は、WordPressの認証フック（authenticateフィルター）に対して複数のプラグインが非標準的な順序で割り込んだことにある。WordPressのコア認証は、ユーザー名とパスワードが一致したらWP_Userオブジェクトを返す。しかし追加認証を挟むプラグインは、認証が成功しても「null」を返したり、エラーオブジェクト（WP_Error）に差し替えたりする。バージョンアップでこのフィルターの優先度（priority）が変わると、突然認証が通らなくなるというわけだ。
将来的に同様のトラブルを避けるには、本番環境の更新前にステージング環境で動作確認することが最も確実な対策になる。また、会員制プラグインとセキュリティ認証プラグインの両方を使用している場合は、片方のログイン機能をオフにしてWordPress標準のログインページに一本化するのも安定性を高める選択肢だ。
よくある質問
Ultimate Memberのログインフォームだけエラーになるのはなぜか
Ultimate MemberはWordPress標準の認証処理を大きくカスタマイズし、独自の認証フックを追加している。ここにCloudflare Turnstileのような外部検証が割り込むと、UM側で生成したnonce（ワンタイムトークン）やセッション情報が検証前に消費されたり、書き換えられてしまう。UMはバリデーションが1つでも失敗すると「認証情報が間違っている」と一般化して表示する設計のため、実際のパスワードは合っていてもエラーになる。
プラグインを旧バージョンに戻したがサイトが脆弱にならないか
旧バージョンに戻すことは一時的な対処であり、修正が適用された最新版に更新できるまでの猶予と考えるべきだ。緊急回避の間は、WAF（Webアプリケーションファイアウォール）のルールを厳しくする、ログイン試行回数の制限をかける、IP制限を追加するなど、他の手段で防御を補強しておく。該当プラグインのサポートフォーラムで同様の報告がないか確認し、解決パッチを待つか、開発元に直接報告するのが安全な進め方だ。
Cloudflare Turnstileを完全に外す以外の選択肢はあるか
Cloudflare側の設定で「アクション」を「管理モード」から「監視モード」に変更し、認証を可視化せず裏側でリスク評価だけさせる手がある。また、一部のプラグインでは特定のページ（wp-login.phpなど）だけ検証をスキップするフックが用意されている場合がある。プラグインのドキュメントやフックリファレンスに「bypass turnstile on specific page」の情報がないか探してみるとよい。
管理画面にすら入れない場合、データベースから直接プラグインを無効化できるか
可能だ。phpMyAdminなどでWordPressのデータベースにアクセスし、「wp_options」テーブルの「active_plugins」レコードを編集する。このレコードには有効化されているプラグインの一覧がシリアライズされた配列で保存されている。該当プラグインのパスを削除して保存すれば、そのプラグインだけが無効化される。ただしシリアライズされたデータの文字数カウントを修正する必要があるため、FTPでのフォルダ名変更のほうが手軽で安全だ。
この記事のポイント
- 正しいパスワードでログインエラーになるのは、認証フックに割り込むプラグインの競合が原因
- FTPで問題のプラグインフォルダをリネームするか、wp-config.phpで全プラグインを一時停止して管理画面に入る
- Cloudflare TurnstileやreCAPTCHAの設定をオフにするか、旧バージョンへのダウングレードで即座に解決する
- 恒久対応は、開発元への不具合報告と、ステージング環境での更新前検証の徹底
- 同種のプラグインを併用する場合は、WordPress標準ログインページへの統一も検討する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている