WordPressのmu-pluginsに潜むPopCashマルウェアを見つけて削除する方法
WordPressサイトで意図しないタブが勝手に開くポップアンダー攻撃が続く場合、通常のプラグインではなく mu-plugins フォルダにマルウェアが隠れている可能性が高い。全プラグインを無効化しても症状が消えないなら、必須プラグイン領域とテーマ内の偽 JavaScript ファイルを点検し、該当ファイルを削除したうえで Thrive Architect を最新版へ更新する。
なぜマルウェアはプラグイン無効化後も残るのか
mu-plugins フォルダは「必須プラグイン」とも呼ばれ、/wp-content/mu-plugins/ に置いた PHP ファイルは自動的に読み込まれる。WordPress 管理画面からプラグインを一括停止しても、このフォルダの中身は対象外になるため、攻撃者はここにファイルを置くと症状を消さずに済む。
今回確認された手口では、テーマフォルダ内の js ディレクトリに PHP ファイルが置かれ、JavaScript として配信されていた。拡張子が .php のまま配信時の形式だけを JavaScript に偽装し、テーマの script タグから読み込まれる形を装う。
この PHP ファイルは外部の api-js.popcash.net にサーバー間通信でアクセスし、得たコードを訪問者のブラウザへそのまま流す。ローカルファイル自体には難読化や eval がなく、「広告ネットワークの API を呼び出すだけのコード」に見える。これが Wordfence や Sucuri などのスキャナーに検出されない理由だ。
設定にはポップアンダーを有効にする pop_fback というオプションが含まれる。さらに curl、shell_exec、file_get_contents へ順に切り替えるフォールバックを持つため、サーバー側の関数制限が厳しくても動き続ける。
mu-pluginsに潜む感染ファイルを見つける手順
調査は FTP または SSH でファイルを直接確認するのが確実だ。感染ファイルは管理画面から見えない場所に置かれるため、ブラウザ上のプラグイン一覧だけでは発見できない。
感染ファイルを検出する調査フローを4ステップで示す。以下で各手順を詳しく説明する。
mu-pluginsフォルダ内の全ファイルを確認する
FTP アプリや SSH で /wp-content/mu-plugins/ を開き、ファイル名を目視で確認する。今回確認が取れているのは wp-ppck-assets.php という名前だが、同じ攻撃ツールは qtt-ppck-core.php や qtt-ajax-core.php といった別名でも置かれる。通常のサイト運営で作った覚えのない .php ファイルが1つでもあれば、削除候補として控えておく。
暗号めいた名前をキーワード検索する
ppck、qtt-、popcash といった文字列がファイル名やディレクトリ名に含まれていないか検索する。一見無害な英数字列に変えられたケースもあるため、名前だけで安全と判断せず、中身と更新日時も確認する。
テーマフォルダ内でPHPファイルが.jsとして呼ばれていないか確認する
テーマディレクトリの js フォルダや assets フォルダに、拡張子が .php のファイルが script タグで読み込まれる形跡がないか確認する。JavaScript の置き場所に PHP があること自体が不自然だ。今回のペイロードは qtt-ppck-core.php という PHP ファイルがテーマの js フォルダに置かれ、外部 API から取得したスクリプトを訪問者へ配信していた。
findコマンドで直近に変更されたPHPファイルを洗い出す
SSH が使える環境なら find コマンドで直近60日以内に変更された PHP ファイルを一覧化する。攻撃者は設置後に修正日時を偽装していないことが多いため、この一覧は感染日の特定に有効だ。
find /path/to/wordpress -type f -mtime -60 -name "*.php"マルウェア本体とドロッパーを完全に削除する
感染ファイルを特定したら、本体だけでなく侵入に使われたアップローダーも削除しなければ再感染する。ここでは削除対象と優先順位を整理する。
感染時に存在した不要ファイルと削除後の状態を対比する。削除対象は本体だけに留めない。
最初に該当ファイルをすべて削除する
mu-plugins 内の wp-ppck-assets.php と、テーマ内の qtt-ppck-core.php を削除する。同じツールキットは qtt-ajax-core.php や wp-tmp-up.php、_w10_up.php といった別名でも設置されるため、検索でヒットした全ファイルを対象にする。削除前には必ずバックアップを取り、削除後はサイトの表示と管理画面へのログインが正常にできることを確認する。
ルート直下の検証用テキストファイルも削除する
攻撃者は任意のファイル書き込みが可能か確認するために、WordPress のルートディレクトリへランダムな英数字20文字の .txt ファイルを置くことがある。今回の例では 52faade47ac664d8d0d3.txt というファイルが確認されており、削除対象になる。同様の .txt が残っていれば侵入テストの痕跡として除去する。
バックドアのパターンを全PHPから検索する
ファイルを消しただけでは、別の場所に置かれたバックドアが残る可能性がある。eval(、base64_decode(、gzinflate(、shell_exec(、assert( などの危険な関数が含まれる PHP を全検索する。正規のプラグインが使っている場合もあるため、検索結果はファイルの出所と更新日時を確認しながら判定する。
grep -Rl -e "eval(" -e "base64_decode(" -e "shell_exec(" /path/to/wordpressThrive Architectの脆弱性を塞ぐアップデート手順
今回の感染経路は Thrive Architect のクロスサイトスクリプティング脆弱性だった。プラグインを更新するだけでは設置済みのマルウェアは消えないため、削除作業の後に必ず更新する。
CVE-2026-66694の影響範囲
2026年8月6日に公開された CVE-2026-66694 は、Thrive Architect バージョン10.9.3.1以前に存在する未認証のクロスサイトスクリプティングと任意コード入力の脆弱性だ。自動化されたボットが未パッチのサイトをスキャンし、ファイル書き込み権限を取得してマルウェアを展開した。対象バージョンを使い続けると、同様の侵入が繰り返される。
最新版への更新と注意点
管理画面の更新画面または公式の入手経路から Thrive Architect をバージョン10.9.3.2以降へ更新する。更新によって脆弱性は塞がるが、すでにアップロードされたドロッパーやバックドアは自動的に削除されない。必ず先に感染ファイルの除去を行い、その後で更新する順番を守る。更新後は改めて不審な PHP が増えていないか確認する。
感染後の再発防止と全パスワード変更
マルウェアの削除と脆弱性対策が完了しても、攻撃者が別の認証情報を持っていれば再侵入される。認証情報の変更とログの確認まで行って、初めて駆除は完了する。
全パスワードを必ず変更する
WordPress の管理者、FTP や SFTP、データベース、ホスティングコントロールパネルの全パスワードを変更する。特に FTP や SFTP の認証情報が流出していた場合、管理者パスワードを変えただけでは再侵入を防げない。使い回しのパスワードは避け、二要素認証が使える場所では必ず有効化する。
WordPress本体と全テーマ・プラグインを更新する
WordPress コア、テーマ、すべてのプラグインを最新版にする。使用していないプラグインやテーマは削除する。海賊版や未更新のテーマは既知の脆弱性を多く含むため、公式に配布されている正規品だけを使う。更新後は管理画面と公開ページの動作を確認する。
サーバーログで侵入日時と経路を確認する
アクセスログには攻撃者の痕跡が残っている。今回の例では、任意ファイル書き込みの検証としてルート直下にランダムな .txt が作成され、約30分後に隠しアップローダーへ POST が送られ、その3秒後に curl でペイロードの動作確認が行われていた。ログを感染日の前後で精査すると、同じ手口で侵入されていないか、他に不審なリクエストが残っていないかを確認できる。
よくある質問
mu-pluginsとは何か、普通のプラグインと何が違うのか
mu-plugins は WordPress の必須プラグインフォルダで、手動で .php ファイルを置くと自動的に読み込まれる。管理画面から停止できないため、すべてのプラグインを無効化する操作の対象にならない。普段使わない環境なら中身が空であることが多いが、攻撃者はこの盲点を狙って設置する。
なぜWordfenceやSucuriは検出できなかったのか
マルウェア本体が外部 API を呼び出すだけのシンプルな構成で、eval や base64_decode などの典型的な攻撃パターンを含まないため、シグネチャ検出に引っかからなかった。ローカルファイル自体は無害に見え、危険なコードは外部から動的に取得される。このため、手動でのファイル名確認と日時調査が欠かせない。
Thrive Architectを更新すればマルウェアは自動で消えるか
消えない。アップデートで脆弱性は塞がれるが、すでに書き込まれたドロッパーやバックドアはそのまま残る。先に怪しいファイルを削除してから更新し、更新後にも再検査する順番が重要だ。
FTPが使えない場合はどう調べればよいか
ホスティングのファイルマネージャーやSSHを使う。SSHが利用できるなら find コマンドで直近に変更された PHP を一覧化できる。レンタルサーバーによっては管理画面からファイルマネージャーが提供されるため、まずサーバー管理パネルを確認する。
パスワードを変更するだけでも大丈夫か
不十分だ。ファイルを削除して脆弱性を塞ぎ、バックドアを検索し、ログを確認するまでが一連の駆除になる。パスワード変更は侵入経路を断つ一部であり、単独では再侵入を防げない。
この記事のポイント
- mu-pluginsフォルダは管理画面のプラグイン停止の対象外なので必ず手動で確認する
- ppckやqtt-を含む不審なPHPファイルとテーマ内の偽.jsファイルを削除する
- ドロッパーや検証用txtファイルも含めてバックドアを全検索する
- Thrive ArchitectのCVE-2026-66694対策として最新版へ更新する
- WordPress管理画面とFTPやデータベースの全パスワードを変更して二要素認証を有効化する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Google Cloudが2029年までに耐量子暗号へ完全移行。PQCロードマップの全容と企業が取るべき3ステップ
Google Cloudが2026年8月11日、2029年までに耐量子暗号（PQC / Post-Quantum Cryptography）へ完全移行するためのロードマップを公開した。量子コンピュータによる将来の暗号解読リスクに備え、APIエンドポイントやロードバランサーの対応はすでに始まっている。
今回の発表では、移行戦略の3つの重点領域、2026年に完了した基盤整備、2027年から2028年にかけてのドメイン別計画が示された。企業が今すぐ着手すべき3つのステップも提示されている。
量子コンピュータが実用化されれば、現在広く使われているRSAやECDSAなどの公開鍵暗号は解読可能になる。その影響はクラウドサービス全体に及ぶ。本記事では、Google CloudのPQCロードマップの全容と、企業に求められる対応を整理する。
PQC移行の全体像と2029年目標
Google CloudのPQC移行戦略は「セキュアバイデザイン」を基本方針とする。設計段階から量子安全を組み込むアプローチであり、単なる後付けの対策ではない。Google Quantum Threat Modelという独自の脅威モデルを土台に、3つの重点領域で保護を進める。
SNDLリスクとは何か
SNDL（Store Now, Decrypt Later）は「今保存して後で復号する」攻撃だ。攻撃者が現在の暗号化通信を傍受してデータを蓄積しておき、量子コンピュータが実用化された時点で一括して復号する。今日の暗号化データが将来の量子コンピュータで解読されるリスクは、すでに現実のものとなっている。
これがPQC移行を急ぐ最大の理由だ。機密データの保存期間が数十年に及ぶ場合、現在の暗号化方式のままでは将来の解読リスクを抱え続けることになる。特に金融機関や政府機関、医療機関では、このリスクへの対応が喫緊の課題だ。
このデモはSNDL攻撃のリスクとPQCによる防御の違いを示している。攻撃者がどれだけデータを蓄積しても、量子安全な鍵交換を使っていれば将来の解読は不可能になる。
Googleが定める3つの重点領域
Google CloudがPQC移行戦略で優先するのは、以下の3領域である。
- SNDLリスクの緩和。現在の暗号化データが将来の量子コンピュータで解読されることを防ぐ。
- 偽造に対する完全性の確保。デジタル署名を強化し、データやIDの偽造を防ぐ。
- 暗号アジリティの基盤強化。暗号標準の進化に合わせて、新しい方式を最小限の工数で採用できる柔軟なシステムを構築する。
3番目の「暗号アジリティ」は特に重要だ。暗号標準は今後も進化し続ける。特定のアルゴリズムに依存せず、新しい標準が出たら容易に切り替えられる仕組みがあれば、将来の移行コストを大幅に抑えられる。Googleはこの基盤への投資を戦略の中核に置く。
Google Cloudは規制期限を待たずに、内部インフラと顧客向けサービスのPQC移行を前倒しで進めている。2029年の完全対応を目標に、Sovereign Cloudの取り組み（Google Cloud DedicatedやGoogle Distributed Cloud）にもPQCソリューションを展開中だ。
2026年に完了した基盤整備
2026年時点で、すでに複数の基盤的マイルストーンが達成されている。これらは顧客に対して即座の保護を提供するものだ。
APIエンドポイントとロードバランサーの対応
Google CloudのAPIエンドポイントは、量子安全な鍵交換に対応した。google.comと*.googleapis.comの両方が、NIST標準化済みのML-KEM（FIPS 203）をハイブリッドモードで実装している。ハイブリッドモードとは、従来の暗号とPQCを併用する方式だ。互換性を保ちながら量子安全性を確保できる。
アプリケーションロードバランサーとプロキシロードバランサーも、TLS 1.3における量子安全ハイブリッド鍵交換（X25519MLKEM768）をサポートする。当初はオプトイン方式で提供され、顧客は既存アプリケーションへの影響を最小限に抑えながら検証を進められる。
さらに、ChromeとCloudflareが進めるMerkle Tree Certificatesの実験にも参画している。PQC署名をWebPKIに適用する際の課題（署名サイズの肥大化など）に対処する取り組みだ。
Cloud KMSのPQCアルゴリズム一般提供
Cloud KMSでは、NIST標準化済みのPQCアルゴリズム（ML-KEM、ML-DSA、SLH-DSA）が一般提供（GA）に達した。暗号化鍵と署名鍵の両方で量子安全なアルゴリズムを利用できる。
これは企業にとって大きな意味を持つ。既存のCloud KMS利用者は、新しいPQCアルゴリズムを試すために特別な準備をする必要がない。すでに一般提供されているため、本番環境での利用も可能だ。
ドメイン別ロードマップ（2027〜2028年）
Google Cloudは2029年の完全対応に向けて、リスクベースのアプローチで3つのドメインを定義した。各ドメインには目標完了時期が設定されている。サービスによって個別のタイムラインは調整される可能性があるが、大多数のサービスは目標時期に合わせて移行を完了する見込みだ。
このタイムラインは、Google CloudのPQC移行が段階的に進むことを示している。2026年の基盤整備から始まり、2027年には通信経路の保護、2028年には署名と鍵管理、2029年に全体の収束を目指す。
ドメイン1 SNDL対策（2027年目標）
ドメイン1は非対称暗号の脆弱性に対処する。将来の量子コンピュータが今日の暗号化データを復号するリスクを防ぐのが目的だ。対象となるのは以下の3つの経路である。
- 顧客ワークロードの保護。Google Cloudサービスとロードバランサーに量子機密TLS 1.3ハンドシェイクを提供する。
- 管理者・開発者フローの保護。Cloud VPNやInterconnectを含む管理者経路をSNDLから守る。開発者向けにはクライアントライブラリ、SDK、オープンソース暗号ライブラリのTinkを対応させる。
- データパイプラインの保護。分析・ストレージプラットフォームのデータ転送を保護し、機密情報が傍受・蓄積されても将来復号されないようにする。
このドメインの特徴は、通信経路の保護に焦点を当てている点だ。特にTinkの対応は重要である。TinkはGoogleが開発したオープンソース暗号ライブラリで、多くの開発者が利用している。TinkがPQCに対応することで、開発者はアプリケーションレベルで量子安全な暗号を容易に導入できる。
ドメイン2 完全性と否認防止（2028年目標）
ドメイン2はデジタル署名と証明の量子対応を扱う。量子コンピュータによる偽造攻撃からデータの完全性と信頼性を守る。3つの主要分野がある。
1つ目はソフトウェアサプライチェーンの保護だ。Binary Authorization、Cloud Build、Assured Open Source Softwareなどのサービスで、量子耐性のある証明（アテステーション）を導入する。信頼できる変更されていないイメージだけが本番環境で実行されることを保証する。
2つ目は量子安全な証明書の発行だ。内部および外部の認証局（CA）をML-DSA証明書に対応させる。状況に応じてSLH-DSA証明書もサポートする。IETF（Internet Engineering Task Force）の標準化に積極的に貢献しており、大規模な署名サイズ問題にはMerkle Tree Certificatesなどの新しいアプローチを検証中だ。
3つ目はIDとアクセスの保護である。サービスアカウントキーやトークン（JWT / OAuth）を量子偽造に対して耐性のある方式に移行する。
ドメイン3 基盤と鍵管理（2028年目標）
ドメイン3はPQC移行の土台となる暗号アジリティを扱う。ここでの投資が、ドメイン1と2の実現を支える。
基盤となる鍵管理とライブラリでは、Cloud KMSとBoringSSL、Tinkを通じてNIST承認アルゴリズムを有効にする。Cloud KMSはすでにML-KEM、ML-DSA、SLH-DSAの一般提供を開始しており、量子安全な鍵のインポートも準備中だ。
ハードウェアが関わる部分では、Confidential ComputingとCloud HSMにPQCを組み込む。量子的なルートオブトラストを確立し、物理的な基盤を保護する。OpenTitanやCaliptra v2.1、TPM 2.0 v185などのオープンソースシリコン基盤もPQC対応を進めている。
Google Workspaceのクライアントサイド暗号化（CSE）と外部鍵マネージャー（EKM）にもPQCオーケストレーションを導入する。オンプレミスの鍵プロバイダーとの連携も進める計画だ。
量子安全における共有責任モデル
量子安全はGoogle Cloudと顧客の共同作業である。クラウドセキュリティの共有責任モデルがPQCにもそのまま適用される。
この図は責任の境界を明確にしている。重要なのは、Google Cloud側のPQC対応が完了しても、顧客がクライアントソフトウェアを更新しなければ量子安全な接続は確立しない点だ。
Google側の責任範囲
Googleはサーバー、ネットワーク、転送中の暗号化、グローバルフロントエンド、ALTSプロトコルのPQC移行を一括して管理する。ハードウェアの移行は、積極的な交換と自然な機器更新サイクルを組み合わせて段階的に進める。物理コンポーネントの中には2029年を超えて移行が続くものもあるが、安定性を優先したフェーズドアプローチを取る。
顧客側の責任範囲
顧客は自社アプリケーションの管理に責任を持つ。クライアントソフトウェアをPQCハンドシェイク対応に更新すること、非対称鍵のライフサイクル管理、Google Cloudサービスの設定変更が含まれる。
ここが最も見落とされやすいポイントだ。インフラ側がPQC対応しても、クライアント側が古い暗号方式で接続すれば、量子安全性は確保されない。企業のセキュリティチームは、自社のクライアントソフトウェアがPQC対応済みかどうかを確認する必要がある。
企業が今すぐ着手すべき3つのステップ
Google CloudはPQC移行の第一歩として、企業が即座に着手できる3つのステップを提示している。どれも実務に直結する具体的なアクションだ。
- 棚卸し（Inventory）。Cloud Asset InventoryやWizなどのツールを使って、鍵や証明書などの暗号資産を特定する。組織全体の暗号リソースをマッピングし、移行バックログの優先順位を定義する。
- 更新（Update）。開発チームとSREチームが使うソフトウェアが、BoringSSL、Chrome、SDKなどPQCアルゴリズムに対応していることを確認する。エッジで量子安全接続が有効化された際に、社内ワークフローが準備できている状態を作る。
- 検証（Validate）。Google Cloudの量子安全APIとロードバランサーを使って既存アプリケーションの挙動をテストする。本番環境に影響が出る前に、アーキテクチャ上のボトルネックを特定できる。
この3ステップは、PQC移行を「待つ」のではなく「準備する」アプローチだ。特に検証は重要である。量子安全なTLS接続は従来よりオーバーヘッドが大きい場合があり、アプリケーションのパフォーマンスに影響を与える可能性がある。事前のテストで課題を洗い出しておけば、本番移行時のリスクを大幅に減らせる。
この記事のポイント
- Google Cloudは2029年までにPQC完全対応を目指し、ロードマップを公開した
- SNDLリスク（今保存して後で復号）は企業にとって喫緊の課題である
- 2026年時点でAPIエンドポイント、ロードバランサー、Cloud KMSのPQC対応が完了している
- 3つのドメイン（SNDL対策、完全性確保、鍵管理基盤）で2027〜2028年に移行を進める
- 企業は棚卸し、更新、検証の3ステップで今すぐ準備を開始できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressに勝手にインストールされるwp-flareマルウェアの感染経路と駆除方法
WordPressに「wp-flare」という身に覚えのないプラグインがインストールされていた場合、それはマルウェアによる不正侵入の痕跡だ。感染したプラグインファイルとデータベース上の登録を削除し、侵入経路を特定して塞ぐことが根本対策になる。
wp-flareマルウェアの感染経路はどこにあるのか
wp-flareは正規のプラグインディレクトリには存在しない、攻撃者が設置する不正なプラグインだ。このプラグインがインストールされるということは、すでに何らかの方法でサイトの管理者権限を奪われている、またはファイルを書き込む経路を確保されていることを意味する。
感染経路として最も多いのは、使用しているプラグインやテーマに存在する脆弱性の悪用だ。すべてのプラグインが最新版でも、サポートが終了した古いプラグインや、公式ディレクトリにない野良プラグインに脆弱性が残っているケースがある。攻撃者はこうした穴を突いて任意のファイルをアップロードし、不正なプラグインを設置する。
次に疑うべきは、管理者パスワードの漏洩や総当たり攻撃の成功だ。二段階認証（2FA）を導入していても、XML-RPC経由の認証試行や、別サイトから流出した同じパスワードを使い回している場合は突破されることがある。
複数サイトが同時期に感染する理由
異なるホスティングの複数サイトが同時期に感染する場合、共通して使っているプラグインやテーマ、管理ツールが感染源になっている可能性が高い。たとえば、同じ開発元が配布するプラグインの配布元が改ざんされていたり、管理用のパソコン自体がマルウェアに感染してFTPやSSHの認証情報を窃取されているケースもある。
感染経路の特定には、各サイトのファイル更新日時とアクセスログを突き合わせるのが有効だ。wp-flareのファイルが設置された日時を調べ、その前後に不審なPOSTリクエストやログイン試行がないかを確認する。
上の図は感染に至る典型的な3つの経路を示している。どの経路であっても最終的にはwp-flareという不正プラグインが設置される点が共通している。
感染したサイトで最初に確認すべき症状
wp-flareに感染したサイトでは、管理画面のプラグイン一覧に「wp-flare」という名前の見慣れない項目が表示される。ただし攻撃者がプラグインの表示名を偽装している場合もあるため、一覧に表示されないこともある。
そのほか、以下のような症状が現れることがある。すべてに該当する必要はなく、1つでも当てはまれば感染を疑うべきだ。
- サイトが知らないURLにリダイレクトされる
- 検索結果に表示されるタイトルや説明文が書き換えられている
- 管理画面の動作が急に重くなった
- 見覚えのない管理者ユーザーが追加されている
- サーバーに身に覚えのないファイルが増えている
最も確実なのは、サーバーのプラグインディレクトリ（wp-content/plugins/）を直接確認することだ。wp-flareという名前のフォルダが存在する場合は、マルウェア感染と断定してよい。
wp-flareマルウェアを駆除する手順
wp-flareの駆除は、プラグインファイルの削除だけでなく、データベース上の不正な登録や、設置されたバックドアの除去まで行う必要がある。以下の手順で進める。
この手順は上から順に実施する。途中でサイトが表示できなくなっても復旧できるよう、STEP 1のバックアップは必ず最初に行う。
wp-flareのプラグインフォルダを削除する
FTPソフトまたはホスティングのファイルマネージャーにログインし、wp-content/plugins/wp-flare ディレクトリを丸ごと削除する。管理画面からプラグインを「削除」しようとしても、プラグイン自体が無効化を妨害する仕組みを持っている場合があるため、ファイルシステム上から直接削除するのが確実だ。
削除後、管理画面のプラグイン一覧に「wp-flare」が表示されなくなることを確認する。もしプラグイン一覧にまだ表示される場合は、データベース側に登録が残っている可能性が高い。
データベースから不正な登録を削除する
WordPressのプラグイン情報は、データベースの wp_options テーブルにある active_plugins という項目で管理されている。不正プラグインがここに登録されていると、ファイルを削除しても管理画面に残り続ける。
phpMyAdminなどのデータベース管理ツールで wp_options テーブルを開き、option_name が active_plugins の行を探す。その値の中に wp-flare や wp_flare を含む文字列があれば、その部分を削除する。操作前にデータベースのバックアップを取得しておくこと。
バックドアの痕跡を全ファイルから探す
wp-flare本体を削除しても、攻撃者が別の場所にバックドア（再侵入用の隠しファイル）を設置している場合がある。主に以下の場所を確認する。
- テーマディレクトリ内の見覚えのないPHPファイル
- アップロードディレクトリ内のPHPファイル（画像のはずなのに拡張子がPHPになっているもの）
- WordPress本体の
wp-adminやwp-includes内の改ざんファイル - サイトのルート直下に置かれた小さなPHPファイル
ファイル数が多い場合は、サーバー上で find コマンドを使って直近に変更されたファイルを抽出すると効率的だ。感染が確認された日時以降に更新されているPHPファイルを重点的に調べる。
find /path/to/wordpress -name "*.php" -mtime -30このコマンドは、指定したWordPressディレクトリの中で過去30日以内に更新されたPHPファイルを一覧表示する。感染が判明した時期に合わせて日数を調整する。
全パスワードと認証情報を変更する
駆除が完了したら、侵入経路に関係なく以下の認証情報をすべて変更する。感染中に窃取されていた可能性を考慮し、同じパスワードの使い回しは避ける。
- WordPress管理画面の全ユーザーのパスワード
- FTP・SSHの接続パスワード
- データベースの接続パスワード
- ホスティングのコントロールパネルのパスワード
- メールアカウントのパスワード
再発を防ぐためのセキュリティ対策
wp-flareを駆除しても、感染経路を塞がなければ再び同じ被害に遭う。特に複数サイトが同時期に感染した場合は、サイト単体の対策だけでなく、管理環境全体の見直しが必要だ。
使用中のプラグインとテーマを棚卸しする
すべてのサイトで使用しているプラグインとテーマの一覧を作成し、以下に該当するものがないか確認する。これらが感染源になっている可能性が高い。
- 配布元が公式ディレクトリではないプラグイン
- 更新が1年以上停止しているプラグイン
- サイトの機能上不要になったプラグイン
- 正規の配布元ではないサイトから入手したテーマ
不要なプラグインは削除し、更新が停止しているプラグインは代替品への移行を検討する。どうしても使い続ける必要がある場合は、開発元のセキュリティ情報を定期的に確認する。
管理用パソコンのマルウェアスキャンを行う
複数のサイトが同時期に感染した場合、サイトではなく管理用のパソコンが感染源になっている可能性がある。FTPやSSHの接続情報を保存しているFTPソフトの設定ファイルから認証情報が窃取され、攻撃者に悪用されるケースがある。
管理用パソコンで信頼できるアンチウイルスソフトのフルスキャンを実施し、FTPソフトやパスワード管理ソフトの保存データが漏洩していないか確認する。スキャン後は、保存済みのパスワードもすべて変更するのが安全だ。
FTPソフトにパスワードを保存する機能は便利だが、マルウェア感染時には認証情報の流出経路になる。可能であれば、接続のたびにパスワードを入力する運用に切り替えるとリスクを減らせる。
ファイル変更の監視を導入する
感染の早期発見には、サーバー上のファイル変更を監視する仕組みが有効だ。WordPressのセキュリティプラグインには、ファイルの改ざんを検知して通知する機能を持つものがある。プラグインの新規インストールや、想定外のファイル変更があった場合にメールで知らせる設定にしておくと、被害が拡大する前に対処できる。
XML-RPCを無効化する
XML-RPCはWordPressの外部連携機能だが、総当たり攻撃やSSRF攻撃の入口として悪用されることが多い。外部サービスとの連携で使っていない場合は、無効化するのが効果的な対策になる。
セキュリティプラグインの多くにXML-RPCを無効化するオプションがある。もしくは、以下のコードをテーマの functions.php に追加する方法もある。
add_filter( 'xmlrpc_enabled', '__return_false' );ただし、このコードは子テーマの functions.php に追加するのが基本だ。親テーマを直接編集すると、テーマ更新時にコードが消えるため注意する。
よくある質問
wp-flareは公式プラグインディレクトリに存在しないのか
存在しない。wp-flareはWordPress公式ディレクトリに登録されておらず、攻撃者が独自に設置する不正なプラグインだ。プラグイン一覧に表示される名前が同じでも、正規のプラグインと混同しないよう注意する。
管理画面からwp-flareを削除できない場合はどうするのか
管理画面からの削除ができない場合は、FTPまたはファイルマネージャーでサーバーに直接アクセスし、プラグインディレクトリからフォルダを削除する。削除後もプラグイン一覧に表示される場合は、データベースの active_plugins に残っている登録を手動で削除する必要がある。
感染したサイトのバックアップは復元に使えるのか
感染前のバックアップが確実に存在する場合は、バックアップからの復元が最も確実な駆除方法になる。ただし、バックアップ自体が感染後に取得されたものであれば復元しても意味がない。取得日時を必ず確認し、感染前のものを使う。
wp-flare対策に有効なセキュリティプラグインはあるのか
定期的なマルウェアスキャン、ファイル変更の監視、ログイン試行の制限、XML-RPCの無効化などを提供するセキュリティプラグインが有効だ。ただし、プラグインを導入するだけで完全に防げるわけではない。プラグインの棚卸しやパスワード管理など、運用面の対策と組み合わせることが重要になる。
同じパスワードを複数サイトで使い回してもよいのか
避けるべきだ。1つのサイトでパスワードが漏洩すると、同じパスワードを使うすべてのサイトが連鎖的に感染する原因になる。サイトごとに異なるパスワードを設定し、パスワード管理ソフトで一元管理するのが安全な運用だ。
この記事のポイント
- wp-flareは攻撃者が設置する不正なプラグインだ
- 感染経路はプラグインの脆弱性、パスワード漏洩、FTP認証情報の窃取が主な候補になる
- 駆除はファイル削除とデータベースの掃除、バックドア除去まで行う
- 複数サイトが感染した場合は管理用パソコンのマルウェアスキャンも必要だ
- 再発防止にはプラグインの棚卸しとファイル変更の監視が有効だ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
admin-ajax.phpへのボット大量アクセスでCPUが100%になる時の遮断と対策
admin-ajax.php へのボットの大量リクエストでサーバーの CPU 使用率が 100% に張り付く場合は、一括遮断ではなく攻撃対象の AJAX アクションをログから特定し、不要な処理を止めた上で正規アクセスを通すレート制限を導入するのが現実的な対策だ。
なぜボットは admin-ajax.php を集中的に叩くのか
admin-ajax.php は WordPress が全 AJAX リクエストを受け付ける入口にあたるファイルだ。フォーム送信、商品カートの更新、ハートビート API による自動保存など、フロントエンドと管理画面の両方で使われている。
ボットがここを狙う理由は、ログイン不要でアクセスできる公開エンドポイントでありながら、リクエストごとに WordPress 全体を読み込んで PHP を実行するため、少ないリクエスト数でもサーバー負荷を大きくできる点にある。
URL に action パラメータを付けて呼び出す構造になっており、たとえば問い合わせフォームの送信処理、EC サイトのカート更新、管理画面の自動保存など、あらゆる AJAX 処理がここを通る。ボットはこれを悪用し、処理の重い action を何度も叩いてサーバーを圧迫する。
攻撃対象の AJAX アクションをログから特定する
対策の最初の一歩は、どの action が攻撃されているのかをアクセスログで確認することだ。闇雲に遮断ルールを増やしても、正規のフォームを巻き込むだけで根本解決にはならない。
アクセスログで action パラメータを調べる
Apache なら /var/log/apache2/access.log、nginx なら /var/log/nginx/access.log にリクエスト履歴が残っている。admin-ajax.php を含む行を抽出し、action= の後ろに続く値を集計すると、攻撃対象が見えてくる。
サーバー管理画面からログをダウンロードできる場合も多い。Cloudflare を利用しているなら、分析画面のセキュリティイベントから admin-ajax.php 宛てのリクエストを絞り込み、クエリ文字列を確認する手もある。
攻撃対象を特定せずに全リクエストを遮断すると、問い合わせフォームが動かなくなる原因になる。必ずログ調査から始めるのが安全だ。
代表的な攻撃対象を把握しておく
攻撃対象になりやすいのは、外部から呼び出せる未ログインユーザー向けの AJAX アクションだ。問い合わせフォームの送信処理、ハートビート API の更新処理、EC サイトのカート更新などが代表例になる。自分のサイトに不要なプラグインが残した action がしばしば悪用される。
正規のフォームを壊さずにレート制限する
すべての admin-ajax.php リクエストにチャレンジ（CAPTCHA や JS チャレンジ）を適用すると、ブラウザ内の JavaScript が裏で送る AJAX リクエストまで巻き込まれ、フォームが正常に動作しなくなる。これが一括チャレンジ方式が失敗する理由だ。
有効なのは、攻撃対象の action だけを条件にしたレート制限だ。単位時間あたりのリクエスト数を IP アドレスごとに制限し、上限を超えたら一時的にブロックする。正規ユーザーのフォーム送信は頻度が低いため、まず引っかからない。
レート制限の閾値は、通常のフォーム送信頻度を大きく上回る値に設定する。たとえば同一 IP から 1 分間に 30 回を超える admin-ajax.php へのリクエストを制限する場合、正規ユーザーが 30 回もフォームを送ることはない。
WordPress側で不要な AJAX アクションを無効化する
攻撃対象のアクションが自分のサイトで使われていないなら、WordPress のフックを使ってそのアクション自体を止めてしまうのが最も確実だ。リクエストが届いても処理が実行されず、サーバー負荷は大きく下がる。
未ログインユーザー向けのアクションを止める
wp_ajax_nopriv_ から始まるフックは未ログインの訪問者からの AJAX 処理を担当する。使っていない action を特定したら、テーマの functions.php に下のコードを追加して 403 を返すようにする。
add_action('admin_init', function() {
if (defined('DOING_AJAX') && DOING_AJAX) {
$action = isset($_REQUEST['action']) ? $_REQUEST['action'] : '';
if (in_array($action, array('unused_action_1', 'unused_action_2'), true)) {
wp_die('403 Forbidden', 'Forbidden', array('response' => 403));
}
}
}, 1);action 名はログで特定した値に置き換える。これで、その action へのリクエストは WordPress の初期化直後に拒否され、プラグインのコードが呼ばれる前に処理が終わる。
ハートビート API の負荷を下げる
管理画面や投稿編集画面で自動保存・ロック通知のために heartbeat が一定間隔で動く。編集画面を開きっぱなしにするボットがいると負荷がかさむ。管理画面を普段使わないサイトなら、heartbeat の頻度を下げるか停止する手もある。
add_filter('heartbeat_settings', function($settings) {
$settings['interval'] = 300;
return $settings;
});interval の単位は秒だ。300 にすると編集画面の自動保存間隔が 5 分になり、サーバーへの負荷が大きく減る。完全に止めるのは編集画面のロック機能に影響するため、まず間隔を延ばすところから始めるとよい。
サーバー設定でボットを直接遮断する
Cloudflare やサーバーレベルの設定でも、条件付きの遮断やレート制限を入れられる。正規のフォームを止めずにボットだけを弾くには、リファラー情報やリクエスト頻度を条件に使うのがポイントだ。
リファラーを条件に弾く
正規の AJAX リクエストは、自分のサイトのページから送られるため Referer ヘッダーに自ドメインが入る。一方、ボットは Referer なしや偽装した値で送ることが多い。Apache なら .htaccess で Referer を条件に遮断できる。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} /wp-admin/admin-ajax.php
RewriteCond %{HTTP_REFERER} !^https?://example.com/ [NC]
RewriteRule ^ - [F,L]
</IfModule>これは自ドメイン以外からの Referer を持つ admin-ajax.php リクエストを 403 で拒否する設定だ。example.com の部分は自分のドメインに置き換える。ただし一部のブラウザ設定で Referer が送られないケースもあるため、完全な遮断には向かない。あくまで補助的な対策として使う。
nginx でレート制限する
nginx を使っているなら limit_req ディレクティブで admin-ajax.php 専用のレート制限を定義できる。サーバーブロックに以下の設定を追加する。
limit_req_zone $binary_remote_addr zone=ajax:10m rate=1r/s;
location = /wp-admin/admin-ajax.php {
limit_req zone=ajax burst=20 nodelay;
limit_req_status 429;
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
include fastcgi_params;
}この設定では、同一 IP から 1 秒あたり 1 リクエストを超えると、バースト（突発的な超過）が 20 回まで許容される。超過分は 429（Too Many Requests）で拒否される。正規ユーザーのフォーム送信はこの制限内に収まるが、ボットの連打はすぐに上限を超える。
よくある質問
すべての admin-ajax.php リクエストを遮断してもよいか
やめておいたほうがよい。問い合わせフォーム、カート更新、検索機能など、多くのサイトで admin-ajax.php が使われている。全遮断すると重要な機能が動作しなくなる。
Cloudflare の Bot Fight Mode だけでは不十分なのか
Bot Fight Mode は既知のボットを自動判定して弾く基本的な防御で、未知のボットや単純なスクリプトには効果が薄い。特定のエンドポイントを狙う攻撃には、レート制限やアクション単位の対策を組み合わせる必要がある。
アクセスログの場所がわからない場合はどうするか
レンタルサーバーの管理画面にアクセスログの閲覧機能があることが多い。わからなければサーバー会社のサポートに問い合わせるか、Cloudflare の分析画面でリクエスト履歴を確認するとよい。
ボット対策プラグインだけでも解決できるか
Wordfence や Limit Login Attempts Reloaded のようなセキュリティプラグインは総合的な保護を提供するが、admin-ajax.php への大量アクセスには専用のレート制限やサーバー設定のほうが効果的な場合が多い。プラグインとサーバー設定の併用が望ましい。
この記事のポイント
- admin-ajax.php は公開エンドポイントで、ボットが少ないリクエスト数でも負荷をかける
- まずアクセスログで action パラメータを集計し、攻撃対象を特定する
- 一括チャレンジは正規フォームを壊すため、action 単位のレート制限を使う
- 使っていない AJAX アクションは functions.php から 403 で拒否する
- サーバー設定（.htaccess や nginx）でも Referer 条件や limit_req で守れる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WPForms Liteにバックドア疑惑、セットアップウィザードが管理者権限を外部に渡す仕組み
WordPressプラグイン「WPForms Lite」にバックドアが仕込まれているという疑惑が、2026年8月にX（旧Twitter）上で提起された。発端はSEOプラグイン「The SEO Framework」の開発者Sybre Waaijer氏の投稿だ。同氏はWPForms Liteのバージョン2.0.0に含まれるセットアップウィザードが、1時間有効の管理者トークンを外部に渡し、ユーザーのサイトにプラグインをインストールできる状態を作り出していると指摘した。
Search Engine Journalの著者Roger Montti氏が実際にWPForms Liteをインストールしてテストしたところ、セットアップウィザードがユーザーを外部サイトに誘導し、気づかぬうちに追加プラグインのインストールを強制するという実態が明らかになった。この記事では疑惑の内容、テスト結果、そしてこれが本当にバックドアと呼べるのかを検証する。
WPForms Liteにバックドア疑惑、発端はThe SEO Framework開発者の投稿
2026年8月、Sybre Waaijer氏がX上でWPForms Liteにバックドアが仕込まれていると投稿した。WPForms LiteはAwesome Motive社が開発する無料のフォーム作成プラグインで、500万以上のサイトにインストールされている。Waaijer氏は、バージョン2.0.0で追加されたセットアップウィザードが、管理者権限を持つ1時間有効のトークンを発行し、Awesome Motiveのサーバーに渡す仕組みになっていると指摘した。
問題となったコードは「wpforms-lite/src/SetupWizard/Bridge.php」というファイルに含まれているという。セットアップウィザードを起動すると、ユーザーのブラウザはWPFormsの外部サイトにリダイレクトされ、そこで管理者トークンが発行される。このトークンを使ってAwesome Motive側は、ユーザーに代わってプラグインのインストールや有効化、さらにはフォームの送信データを自社サーバーに送る設定の有効化まで可能になるとされる。
この概念図はWaaijer氏の主張を簡略化したものだ。ユーザーがセットアップを進めると、知らないうちに自サイトの管理者権限が外部に渡り、プラグインが追加される流れになる。
インストール可能なプラグインの一覧
Waaijer氏の投稿によると、この仕組みでインストール可能なプラグインは以下の13種類だ。驚くべきことに、競合するコンタクトフォームプラグインであるContact Form 7やNinja Forms、Pirate Formsも含まれており、同氏はこれを「おそらくバグ」と指摘している。
- WP Mail SMTP
- WPConsent
- Uncanny Automator
- AIOSEO（All In One SEO）
- Universally
- Duplicator
- Reviews Feed
- OptinMonster
- MonsterInsights
- ActiveLayer
- Contact Form 7（競合プラグイン、バグの可能性）
- Ninja Forms（競合プラグイン、バグの可能性）
- Pirate Forms（競合プラグイン、バグの可能性）
また、WPFormsのアドオンやPro版を自社サーバーから直接プルすることも可能で、これらのサーバーはWordPress.orgのモデレーションを受けないため、悪意あるコードをプッシュするリスクもあるとWaaijer氏は警告している。
コミュニティからの反論とWaaijer氏の立場
Waaijer氏の投稿に対して、WordPressコミュニティからは「Awesome Motiveは10年にわたり信頼されてきたプラグイン開発者であり、公に非難するのは不公平だ」という意見が上がった。ユーザー@BuildInBitsは「これは非公開で議論すべき内容であり、公開で非難するのは行き過ぎだ」と投稿している。
しかしWaaijer氏は、Awesome Motiveが自らの競合であると明かした。同氏が開発するThe SEO Frameworkは、Awesome Motiveが提供するAll In One SEO（AIOSEO）と直接競合するSEOプラグインだ。Waaijer氏は「彼らは意図的に管理者権限の第二チャネルを構築し、オープンソースに見せかけている。WPBeginnerは10年以上にわたり、チュートリアルの最終着地点が常に自社スタックに誘導するファネルだった」と批判している。
本当にバックドアなのか、異論も
一方で、Waaijer氏の「バックドア」という表現に対しては異論も出ている。Xユーザー@marckranatは「これは従来の意味でのバックドアではない。ベンダーが自発的にアクセスを開始する経路はなく、認証バイパスも隠しリスナーも存在しない。ログインした管理者がウィザードを起動する必要がある」と指摘した。
米国立標準技術研究所（NIST）の定義によれば、バックドアとは「コンピューターシステムにアクセスするための文書化されていない手段」であり、セキュリティリスクになり得るものだ。しかしWPForms Liteのケースでは、管理者が自らセットアップウィザードを起動しなければ外部からの操作は始まらない。つまり、外部から一方的に侵入される経路が存在するわけではないという視点も成り立つ。
この比較からわかるように、WPForms Liteの仕組みは厳密な意味でのバックドアとは異なる。しかし管理者が認識しないまま外部に権限を渡す点は、透明性の観点で問題があると指摘されている。
Search Engine Journal著者が実際にテスト、セットアップウィザードの実態
Search Engine JournalのRoger Montti氏は、この疑惑を検証するためWPForms Liteを実際にインストールした。Montti氏はすでに別のサイトで同プラグインを使用していたが、テスト用のサイトに新規インストールしたところ、セットアップウィザードが表示されたという。
注目すべきは、セットアップウィザードの最初の画面がすでにWPFormsの外部サイト（wpformsapi.com）に切り替わっていた点だ。Montti氏は「自分のサイトにいると思っていたが、すでに別のサイトに移動していた」と述べている。URLバーを注意深く見ていなければ、気づかないレベルの遷移だったという。
Montti氏が実際に体験したセットアップの流れは上図のとおりだ。同氏は「Install and Continue」をクリックしてしまったが、これが自サイト内の操作だと信じていたと振り返っている。
2つのプラグインが強制インストール、オプトアウト不可
セットアップウィザードの途中には「Select Your Features」という画面が表示され、「AI Form Generation」と「Privacy Compliance」のチェックボックスが最初からオンになっており、外せない状態だった。さらに画面下部には、無料の「WPConsent」プラグインがインストールされる旨の通知があり、これも拒否できなかった。
結果として、Montti氏のテストサイトにはWP Mail SMTP、WPConsent、そしてWPForms Liteの3つのプラグインがインストールされた。同氏はその後プラグインをアンインストールし、同じワークフローを再現しようとしたが、2回目以降は発生しなかったという。
バックドア疑惑の本質とWordPressサイト運営者が取るべき対応
WPForms Liteのセットアップウィザードが外部サイトに誘導し、管理者トークンを発行して他プラグインをインストールする仕組みは、Montti氏のテストでも確認された。これは「密かに不正アクセスを可能にする」典型的なバックドアとは異なるが、管理者が認識しないままサイトの変更を許す点で、透明性に問題がある。
NISTの定義に照らせば「文書化されていない手段」には該当し得る。しかし実際にはセットアップウィザードの一部として動作し、管理者がトリガーを引く必要があるため、「バックドア」という表現は強すぎるという見方もある。とはいえ、ユーザーが外部サイトに移動したことに気づかないまま、プラグインが追加される体験は、セキュリティ意識の高いサイト運営者にとって懸念材料だ。
この問題の核心は「バックドアかどうか」の定義論争よりも、プラグインのセットアッププロセスにおける透明性の欠如にある。500万以上のサイトに影響を与え得る仕様だけに、開発者側の説明責任が問われている。
この記事のポイント
- WPForms Lite 2.0.0のセットアップウィザードが、外部サイトで管理者トークンを発行し、ユーザーに無断でプラグインをインストールできる状態を作る
- Search Engine Journalのテストで、WP Mail SMTPとWPConsentが強制インストールされ、AI機能もオプトアウト不可だった
- 「バックドア」という表現には異論もあるが、管理者が気づかないまま外部サイトに誘導される点は透明性に問題がある
- サイト運営者はプラグインインストール時のURL確認と、定期的なプラグイン一覧のチェックを習慣化すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Wordfence 8.2.2 で前台に preg_replace() 非推奨エラーが出た時の対処
Wordfence 8.2.2 を導入した WordPress 7.0.3 のサイトで、前台ページやログイン画面に Deprecated: preg_replace() から始まる非推奨（デプリケーション）エラーが表示される場合、まず WP_DEBUG 設定を確認して本番環境でのエラー表示を抑制し、次に Wordfence 本体を最新版へ更新する のが最短の対策だ。
なぜ本番サイトの前台に非推奨エラーが表示されるのか
非推奨エラー（Deprecated 通知）は、PHP の将来のバージョンで廃止される古い書き方を使っている場合に発生する。Wordfence 8.2.2 内部のルール処理ライブラリ wf-waf が preg_replace() 関数に null を渡しており、PHP 8.1 以降でこの挙動が非推奨となったことが直接の原因だ。
本来このレベルの通知は、本番サイトでは表示されないよう WordPress が抑制する仕組みになっている。しかし 何らかの理由でデバッグモードが有効になっているか、エラー報告レベルが高く設定されている と、前台に生の PHP エラーメッセージが露出してしまう。これが今回のケースの本質的な問題だ。
さらにこのエラーが「headers already sent」という警告を誘発し、ログイン処理や Cookie 設定などの HTTP ヘッダー操作が失敗する二次被害も報告されている。前台の表示崩れや管理画面へログインできないトラブルに発展するため、早期の対応が欠かせない。
すぐに前台からエラー表示を消す応急処置
更新を待つ前に、まずは本番環境でエラーが一般人に見えている状態を解消する。手順は以下の3ステップだ。
wp-config.php で WP_DEBUG を確認・修正する
FTP クライアントやサーバーのファイルマネージャーで WordPress をインストールしたルートディレクトリにアクセスし、wp-config.php を開く。WP_DEBUG が true になっていれば、以下のように false へ変更する。
define( 'WP_DEBUG', false );開発用途でデバッグログだけは残したい場合は、WP_DEBUG_LOG と WP_DEBUG_DISPLAY を併用する。これで前台にはエラーを表示せず、ログファイルにだけ記録できる。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // /wp-content/debug.log に記録
define( 'WP_DEBUG_DISPLAY', false ); // 画面には表示しないファイルを上書き保存したら、サイトをリロードして前台からエラーメッセージが消えたか確認する。
Wordfence を最新版に更新する
この preg_replace() の非推奨問題は、Wordfence 開発チームが認識して修正に取り組んでいる可能性が高い。管理画面にアクセスできるなら「プラグイン」→「インストール済みプラグイン」で Wordfence の更新を確認し、最新版がリリースされていれば即座に適用する。
管理画面すらエラーで開けないという報告も多い。その場合は FTP で /wp-content/plugins/wordfence/ ディレクトリを一時的にリネーム（例 wordfence_old）して無効化し、管理画面へアクセスできる状態にする。管理画面に入れたら、改めて Wordfence を最新版に更新して再有効化すればよい。
キャッシュを全削除して状態を確定させる
PHP 設定やプラグインを変更しても、キャッシュが残っていると古いエラー画面が表示され続ける。以下のキャッシュを徹底的にクリアする。
- WordPress のキャッシュプラグイン（WP Rocket や W3 Total Cache など）の全キャッシュ削除
- サーバー側の OPcache や Nginx FastCGI Cache のクリア
- CDN を利用している場合は CDN のキャッシュもパージ
それでも改善しない場合の追加対応
上記の手順を実行してもエラーが消えない、あるいは管理画面にまったく入れない状況が続くなら、次の手を試す。
Wordfence を手動で最新 ZIP に上書きする
WordPress 管理画面から更新できない場合、WordPress.org の Wordfence 公式ディレクトリから最新の ZIP ファイルをダウンロードし、FTP で展開する。手順は次のとおり。
- 現在の
/wp-content/plugins/wordfence/をリネームして退避 - ダウンロードした ZIP を解凍し、
wordfenceディレクトリをアップロード - 管理画面から Wordfence を有効化し、WAF の最適化を再実行
PHP のエラー報告レベルを一時的に緩和する
レンタルサーバーのコントロールパネルや php.ini で error_reporting を E_ALL & ~E_DEPRECATED に設定すれば、非推奨通知をまとめて抑制できる。ただしこの方法は問題の先送りになるため、あくまで Wordfence 更新が間に合わない場合の緊急措置と位置づける。
別のセキュリティプラグインへ一時的に切り替える
サイトのセキュリティを完全に落とせない事情があるなら、Wordfence を無効化している間だけ、別の軽量ファイアウォール系プラグインで防御を維持する手もある。ただし切り替えの手間と、切り戻し時に設定がリセットされる可能性は考慮が必要だ。
よくある質問
Wordfence を無効化したまま運用しても大丈夫か
無効化中はファイアウォールとマルウェアスキャンがすべて停止するため、できるだけ数時間以内に最新版へ更新して再開するのが望ましい。どうしても長引く場合は、サーバー側の WAF 機能や .htaccess によるアクセス制限で最低限の防御を維持する。
PHP バージョンを下げればこのエラーは消えるのか
PHP 7.4 など古いバージョンに戻せば preg_replace() の非推奨警告は出なくなるが、PHP 本体のセキュリティサポートが切れているバージョンを使うことは推奨しない。Wordfence の更新で根本対応し、PHP は 8.1 以降のサポート対象バージョンを維持するのが安全な選択だ。
他のプラグインで同様の Deprecated エラーが出た場合の対処は
まず該当プラグインが最新版かを確認する。最新で出るなら、開発元のサポートフォーラムに PHP バージョンとエラー全文を添えて報告する。本番環境では WP_DEBUG_DISPLAY を false にしつつ WP_DEBUG_LOG で記録を取る運用が基本だ。
Wordfence の代わりになる無料プラグインはあるか
無料で総合的な防御を提供する代替としては、Solid Security（旧 iThemes Security）や Sucuri Security が挙げられる。ただし機能や設定項目が異なるため、移行前に必ずテスト環境で動作検証を済ませる必要がある。
この記事のポイント
- 前台に PHP 非推奨エラーが出る原因は WP_DEBUG 設定とプラグインの対応遅れ
- まず wp-config.php で WP_DEBUG を false または WP_DEBUG_DISPLAY false にする
- Wordfence を最新版に更新すれば preg_replace() 問題は解消に向かう
- 管理画面に入れない場合は FTP でプラグインをリネームして緊急アクセスを確保する
- PHP のエラー報告レベル操作はあくまで緊急避難であり恒久対応ではない
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce更新後に注文編集ができない場合の権限設定と解決手順
WooCommerce のアップデート後に、注文の編集やステータス変更ができなくなった場合は、該当するユーザーロールに WordPress の基本的な権限である edit_posts を割り当てることで解決する。WooCommerce 9系と HPOS の組み合わせでは、カスタム権限だけでは注文管理画面を表示できなくなる仕様変更が起きている。
WooCommerce アップデート後に注文を編集できなくなった原因
WooCommerce 10.9.4 以降、特に HPOS（高パフォーマンス注文ストレージ）を有効にし、互換性モードを無効化している環境でこの問題が発生しやすい。これまでは edit_shop_order や edit_others_shop_orders といった WooCommerce 固有の権限だけで注文管理ができていた。だが、内部的な権限チェックが強化され、注文画面を表示するために汎用的な edit_posts 権限も必須になった。
この変更は、WordPress のコア機能と WooCommerce の注文データの整合性を高めるためのものだ。「このサイトで重大なエラーが発生しました」といったメッセージではなく、単に「権限がありません」と表示されたり、注文一覧ページ自体が空欄になるといった症状が現れる。PublishPress Capabilities や User Role Editor などのプラグインで、注文管理だけに特化したカスタムロールを作成している場合に特に影響を受ける。
– edit_shop_order
– edit_others_shop_orders
– edit_posts なし
– edit_shop_order
– edit_others_shop_orders
– edit_posts（新たに追加）
edit_posts 権限を追加して問題を解決する具体的な手順
解決策はシンプルだ。注文管理を担当するユーザーロールに edit_posts 権限を付与する。この操作によって、注文以外の「投稿」や「固定ページ」へのアクセス権も与えたくない場合は、後続の「より厳密な権限制御を行うための注意点」のセクションで紹介する追加の調整が必要になる。
現在のユーザーロールの権限を確認する
まず、どのロールに問題が起きているのかを特定する。ユーザーが複数のロールを持っている場合、権限は加算される仕組みだ。管理者権限で問題が起きている場合は、プラグインの競合など別の原因を疑う必要がある。
PublishPress Capabilities の無料版を使っていれば、管理画面の「Capabilities」メニューから各ロールの権限一覧を確認できる。画面上部の「Select Role to View / Edit」ドロップダウンで、問題のロールを選択し、権限の一覧を表示させよう。
edit_posts 権限を該当ロールに割り当てる
権限の一覧画面で「Core」タブを開き、「Posts」セクションを探す。その中にある「edit_posts」のチェックボックスにチェックを入れ、画面下部の「変更を保存」ボタンをクリックする。これで、指定したロールに汎用的な投稿編集権限が付与され、WooCommerce の注文画面にもアクセスできるようになる。
User Role Editor を使っている場合も手順はほぼ同じだ。管理画面の「ユーザー」→「User Role Editor」を開き、対象ロールを選択して、権限リストから「posts」をフィルタリングし、「edit_posts」にチェックを入れて保存する。
より厳密な権限制御を行うための注意点
edit_posts を付与すると、デフォルトでは「投稿」と「固定ページ」の編集画面にもアクセスできるようになる。これは、WordPress の権限システムが投稿タイプごとに細かく権限を分けていないことに起因する。注文だけを管理させたいロールには、これは望ましい状態ではないだろう。
投稿や固定ページへのアクセスを制限するには、別の方法で管理画面メニューを非表示にする必要がある。よく使われるのは「Admin Menu Editor」プラグインだ。このプラグインを使えば、特定のユーザーロールに対して不要なメニュー（投稿、固定ページ、コメントなど）を非表示にできる。メニューを隠すだけでは直接URLを入力されるとアクセスできてしまうため、完全にブロックしたい場合は、current_user_can() 関数を使ったカスタムコードを functions.php に追加する方法もある。
よくある質問
管理者権限でも注文を編集できなくなった場合はどうするのか
管理者はデフォルトで edit_posts を含むすべての権限を持っているため、今回の原因とは別の問題だ。まずはすべてのプラグインを停止し、テーマをデフォルトに戻して競合の有無を確認する。HPOS 互換モードを一時的に再有効化して症状が改善するかもテストする価値がある。
edit_posts を追加してもアクセスできない場合は他に何を確認すべきか
WooCommerce の注文には、edit_shop_orders や view_admin_dashboard といった権限も必要になる。後者が不足していると、管理画面自体へのアクセスが制限される可能性がある。また、キャッシュ系プラグインやセキュリティプラグインが権限チェックに干渉しているケースもあるため、これらの設定も見直す。
HPOS の互換モードを再有効化すれば解決するのか
一時的な回避策としては機能する可能性が高い。しかし、HPOS の互換モードは将来的に廃止される予定の過渡的な機能だ。根本解決のためには、ここまでに説明した権限の適切な設定を行い、HPOS を有効化した状態で動作させることが推奨される。
コードを使って権限を自動付与する方法はあるか
特定のロールに対してテーマやプラグインの有効化時に権限を追加したい場合、WP_Role クラスの add_cap() メソッドを使う。たとえば、functions.php やカスタムプラグイン内で、get_role('shop_manager')->add_cap('edit_posts') のように記述する。このコードは一度だけ実行すればよいが、権限の変更を明確にするために、プラグインのアクティベーションフックで実行することが望ましい。
この記事のポイント
- WooCommerce の更新後、注文の編集ができない原因は
edit_posts権限の不足にある - 権限管理プラグインで該当ロールに
edit_postsを割り当てるだけで問題は解決する - 不要な投稿画面へのアクセスは、Admin Menu Editor などのプラグインで個別に制限する必要がある
- 管理者権限での同様の症状は、プラグイン競合といった別の原因を疑う
- HPOS 互換モードの再有効化は一時しのぎに過ぎず、権限設定による根本解決が推奨される
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce Stripeに緊急セキュリティアップデート。バージョン10.8.5へ即時更新を
WooCommerceは2026年8月6日、公式決済プラグイン「Stripe for WooCommerce」のセキュリティアップデートをリリースした。影響を受けるのはバージョン9.7.0から10.8.4まで。すべてのストア管理者は直ちにバージョン10.8.5または各リリースラインのパッチ版へ更新する必要がある。
今回の問題はAutomattic社内のプロアクティブなセキュリティテストで発見された。現時点で悪用された証拠はなく、顧客情報や決済データへの不正アクセスも確認されていない。しかし、特定の条件下でストアが利用不能になる可能性があるため、迅速な対応が求められる。
影響範囲とパッチバージョン
今回の脆弱性はStripe for WooCommerceプラグインのバージョン9.7.0から10.8.4に存在する。9.7.0より前のバージョンは影響を受けないが、それらは古いリリースのため、最新のサポート対象バージョンへの移行が推奨される。
WooCommerceチームは、影響を受けるすべてのリリースラインに対してパッチを用意した。理想は最新の10.8.5に更新することだが、何らかの事情ですぐにメジャーバージョンを上げられない場合は、以下のパッチ版を適用すればよい。
更新手順と確認ポイント
管理画面からの手動更新
自動更新を設定しているストアでも、念のためバージョンを直接確認することが重要だ。管理画面の「プラグイン」→「インストール済みプラグイン」から「WooCommerce Stripe Payment Gateway」または「Stripe for WooCommerce」を探し、更新が利用可能な場合は「今すぐ更新」をクリックする。更新後は必ず決済テストを実施し、Stripe決済手段が正常に表示されることを確認しておきたい。
自動更新とインフラストラクチャ対応
WordPress.orgプラグインチームと連携した自動更新の配信も進められている。Automatticの管理下にあるストアや、プラグインの自動更新を有効にしている環境では、すでにパッチが適用されている可能性がある。しかし、複数ストアを管理する開発者や代理店、ホスティング事業者は、実際のバージョンを直接確認することを怠ってはならない。
今回の脆弱性の内容と影響
最も深刻な問題は、特定の条件下でストア自体が利用不能になるというものだ。顧客のクレジットカード情報や購入履歴といった機密データにアクセスされる性質のものではないが、サイトが停止すれば売上機会の損失に直結する。WooCommerceは今回の脆弱性を悪用した実例は確認されていないとしている。
このアップデートでは、利用不能を引き起こす可能性のある問題に加えて、関連するセキュリティ上の問題点も修正されている。具体的な脆弱性の手順は、多くのストアが更新を完了するまでは公開されない方針だ。未パッチのサイトを狙った攻撃を防ぐためであり、詳細な技術情報は安全が確認され次第、アドバイザリに追記される予定である。
7月14日のアップデートとの違いに注意
今回のリリースは、2026年7月14日に公開されたStripe for WooCommerceの決済検証パッチとは別のアップデートである。7月のアドバイザリ対応でバージョン10.6.2、10.7.1、10.8.4に更新したストアも、重ねて今回のパッチを適用しなければならない。両方の修正を含んだ最新版は10.8.5だ。
困ったときのサポート窓口
更新作業に手詰まりを感じたら、WooCommerceの公式サポートに問い合わせるのが確実だ。ストア管理者はWooCommerceサポートページからチケットを発行できる。プラグイン開発者やホスティング事業者など、技術的な質問がある場合は、WooCommerce Community Slackの利用が案内されている。
この記事のポイント
- Stripe for WooCommerce 9.7.0〜10.8.4にセキュリティ脆弱性。全ストアで即時更新が必要
- 推奨更新先は10.8.5。各リリースラインにパッチ版あり
- ストアが利用不能になる可能性があるが、決済データ等へのアクセスはない
- 7月のパッチとは別のアップデート。両方の修正を含む最新版への移行が必須
- 自動更新環境でも必ず手動でバージョンを確認し、テスト購入を行う
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
functions.phpが自己修復するマルウェアに感染 WordPressの持続的再感染を完全に駆除する方法
functions.php に SC_TH_BEGIN 〜 SC_TH_END で囲まれた難読化コードが注入され、完全削除したはずなのに数週間後に自己修復して再出現する感染は、単一ファイルの削除では解決しない。この種のマルウェアは、複数の隠れた感染拠点から自己を再生し、クリーンアップの試みを検知して適応する高度な仕組みを持つ。根本的な駆除には、侵入経路の遮断と全ファイルの網羅的スキャンが欠かせない。
SC_TH_BEGIN型マルウェアの感染メカニズムと自己修復の仕組み
この手の持続的感染は、単純なワンライナーではなく、組織化されたキャンペーンの一環として設計されている。コードは functions.php の末尾に注入され、SC_TH_BEGIN と SC_TH_END という独自タグで囲まれる。内部にはバージョン番号とハッシュ値が含まれ、これが改ざん検知と自己修復のトリガーになる。
感染のライフサイクルは次の3段階で進行する。まず初期侵入時に、難読化された本体コードが mu-plugins ディレクトリに隠しファイルを書き込む。このファイルがバックドアとして機能し、定期的に functions.php の状態を監視する。次に、functions.php から感染コードが削除されると、mu-plugins の隠しファイルがハッシュ不一致を検知し、自身のロジックで functions.php を再感染させる。さらに、アップロードディレクトリには一見無害なアーカイブファイルが置かれ、これが外部からの指令受け取り口や、別の復旧ポイントとして機能する。
/* SC_TH_BEGIN v2.1 a3f8c... */
$abc = base64_decode('UEhO...');
eval($abc);
/* SC_TH_END v2.1 a3f8c... */// functions.php のクリーンな終了
/* SC_TH_BEGIN v3.0 b7d2e... */ // this file previously had malicious content but it's been removed and is safe now /* SC_TH_END v3.0 b7d2e... */
3つの感染拠点のうち、最も見落とされやすいのは mu-plugins の隠しファイルだ。このディレクトリはプラグイン管理画面に表示されないため、手動での確認が必須になる。また、コメント行だけが残る偽装パターンは、マルウェアがクリーナーの動作を学習し「おとり」として置いている可能性が高い。
自己修復するマルウェアを根本から除去する駆除手順
単に functions.php から感染コードを削除するだけでは、裏で動く監視機構が再び書き込んでしまう。以下の手順では、感染のサイクルを断ち切るために、すべての拠点を同時に無効化する。
全ファイルのバックアップと感染範囲の特定
サーバー全体のファイルをローカルにダウンロードし、安全な環境でスキャンする。この段階ではまだサーバー上のファイルには手を加えず、何がどこに潜んでいるかを把握することが目的だ。隠しファイルは先頭にドット（.）が付くものや、ランダムな文字列のファイル名になっていることが多い。
mu-plugins ディレクトリの全ファイルを精査する
wp-content/mu-plugins/ に存在するファイルのうち、自身で設置した覚えのないものはすべて疑う。特に、ファイル名が意味不明な文字列だったり、PHP ファイルでありながらプラグインヘッダーがないものはマルウェアの可能性が高い。正常な mu-plugin も一時的に退避させ、ディレクトリを空にしてから必要なものだけ戻す方法が確実だ。
アップロードディレクトリ内の不審なアーカイブとPHPファイルを削除する
wp-content/uploads/ 以下に .zip や .tar.gz などのアーカイブファイルが存在した場合、それが正規のバックアップやプラグイン由来でない限り削除する。PHPファイルも画像などに偽装されて存在することがあるため、拡張子に関係なくファイルの先頭数行を確認し、PHPタグが含まれていないか検査する。
テーマとプラグインを公式ソースと比較して復元する
改ざんの可能性があるテーマやプラグインは、公式リポジトリからダウンロードしたクリーンなファイルで上書きする。子テーマの functions.php だけが標的になっていたとしても、親テーマや他のプラグインに仕込まれたバックドアが感染を再開させることがあるため、疑わしい拡張機能はすべて置き換える。
クリーンアップ後に再感染を防ぐための恒久対策
ファイル改ざん監視を導入する
WordPress のコアファイルやテーマ、プラグインの変更をリアルタイムで検知するセキュリティプラグインを導入する。改ざんが発生した瞬間に通知を受け取れるため、感染の早期発見につながる。ファイル整合性チェック機能を持つものを選び、既知のクリーンな状態との差分を定期的に比較する設定にしておく。
書き込み権限の厳格化
functions.php や mu-plugins ディレクトリに対して、Web サーバーの実行ユーザーが書き込みできないようにパーミッションを設定する。通常、PHP ファイルは 644、ディレクトリは 755 が基本だが、特に標的になりやすいファイルは 444 に設定して変更を防止する。ただし、テーマやプラグインの自動更新を利用している場合は、更新時に権限を一時的に戻す運用が必要になる。
使用していないプラグインとテーマの完全削除
無効化されているだけのプラグインやテーマも、ファイル自体がサーバー上に残っていれば攻撃の入り口になる。WordPress の管理画面から完全に削除し、ディレクトリごと消去する。休眠中の拡張機能は更新が止まっていることが多く、既知の脆弱性を放置することになる。
よくある質問
functions.php の感染コードを手動で削除するだけではなぜダメなのか
感染コード自体が別の場所にバックドアを設置しており、そのバックドアが functions.php の状態を監視しているためだ。削除を検知すると自動的に再書き込みが行われ、さらにバージョン番号を上げて「対策済み」を装うケースもある。感染コードの削除と同時に、すべてのバックドアを無効化しなければ根本的な解決にはならない。
mu-plugins ディレクトリに心当たりのないファイルがあるが、削除しても問題ないか
mu-plugins は「マストユースプラグイン」と呼ばれ、有効化操作なしで自動的に読み込まれる特殊なディレクトリだ。正規のファイルはプラグイン名や機能がわかる名前になっていることが多い。ランダムな文字列や .php 以外の拡張子を持つファイルはマルウェアの可能性が高い。まずすべてを退避させ、サイトが正常に動作することを確認してから、必要なものだけ戻す手順が安全だ。
アップロードディレクトリ内の .zip ファイルはすべて削除すべきか
自身でアップロードした覚えのないアーカイブファイルは削除する。正規のプラグインやテーマが生成するバックアップファイルもあるが、マルウェアがアーカイブを設置する場合、ファイル名が日付とは無関係な文字列だったり、設置日時が不自然に新しいことが多い。不安な場合は、ファイルをダウンロードして中身を確認し、PHPコードや難読化されたスクリプトが含まれていないか検査する。
感染を完全に駆除したかどうかをどう確認すればいいか
セキュリティスキャナーを複数かけ、感染の痕跡が検出されないことを確認する。さらに、functions.php のハッシュ値を記録し、1週間後、2週間後と定期的に比較して変化がないことを検証する。サーバーのアクセスログも確認し、不審な POST リクエストや、管理画面外からの PHP ファイルへの直接アクセスがないかを監視する。
SC_TH_BEGIN タグは特定のマルウェアファミリーの特徴か
このタグは、標的のサイトを識別し、感染状況を管理するためのキャンペーン固有のマーカーと考えられる。バージョン管理とハッシュ検証の仕組みから、手動での駆除を想定した設計になっている点が特徴的だ。未知のマルウェアファミリーである可能性もあり、一般的なマルウェアスキャナーの定義ファイルが追いついていない場合がある。
この記事のポイント
- functions.php だけの削除では自己修復型マルウェアの再感染を防げない
- mu-plugins の隠しファイルと uploads 内のアーカイブが感染の復旧ポイントになる
- 全テーマ・プラグインを公式ソースで上書きし、バックドアを一掃する
- パーミッションの厳格化とファイル改ざん監視で恒久的な防御を敷く
- 駆除後はハッシュ値の定期比較で再感染の兆候を早期発見する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.0.3が緊急リリース。深刻なXSS脆弱性など12件を修正、早急な更新を
WordPressのセキュリティアップデート「7.0.3」が2026年8月6日に公開された。このリリースでは12件の脆弱性が修正され、特に認証前の反射型クロスサイトスクリプティング（XSS）が深刻度8.9と評価されている。
当該のXSS脆弱性は、攻撃者が細工したサイトを経由してログイン画面にアクセスさせることで、リモートコード実行（RCE）に発展する可能性がある。全バージョンのWordPressに影響し、過去のブランチにまでパッチがバックポートされた点からも、緊急性の高さが伺える。
本記事では、修正された脆弱性の詳細と、ユーザーがすぐに実践できる対策をまとめた。
今回修正された12件の脆弱性の概要
WordPress 7.0.3では、以下の12件の脆弱性が修正された。公式発表では深刻度などの情報が最小限に留められているが、いずれも実運用に影響を与え得るものだ。
- 投稿日付ブロックでのContributor+保存型XSS
- 投稿コンテンツブロックでのContributor+保存型XSS
- 最新コメントブロックにおける情報開示（パスワード保護された投稿のコメントが露出）
- メールアドレス確認フローのバイパス
- Author+による安全なCSS属性フィルターのバイパスを介したCSSインジェクション
- 絵文字設定要素を介したContributor+保存型XSS
- マルチサイトネットワークでの権限昇格（ユーザー登録が有効な場合、新規サイト作成が可能）
- URL検証におけるSSRF（サーバーサイドリクエストフォージェリ）により、リンクローカル範囲へのリクエストが可能
- ログイン画面における認証前の反射型XSS（PHPコード実行の可能性あり）
- コメントフィードでのノート開示
- 投稿スラッグの列挙
- 多数のユーザーが存在するサイトでのクイック編集におけるContributor+保存型XSS
特に注意が必要な3つの深刻な脆弱性
修正された12件のうち、以下の3つは危険度が突出して高い。中でもログイン画面のXSSは、リモートコード実行に繋がる恐れがあり、深刻度は10点満点中8.9と評価された。
パスワード: ********
パスワード: ********
上のデモは、ログインエラーメッセージにスクリプトが紛れ込むケースを簡略化したものだ。修正前は悪意のあるコードがそのまま実行されてしまうが、修正後は出力が適切にエスケープされ、安全なテキストとして表示される。
ログイン画面の反射型XSS（深刻度8.9）
この脆弱性は、認証前（Pre-auth）の反射型XSSに分類される。攻撃者は特別に細工した悪意のあるWebサイトを用意し、標的ユーザーをそこへ誘導する。ユーザーがそのサイトを経由してWordPressのログイン画面にアクセスすると、不正なスクリプトが実行される可能性がある。
公式のGitHubセキュリティリポジトリによると、この脆弱性を悪用するとリモートコード実行（RCE）にまで発展する恐れがあるという。ただし、攻撃を成立させるにはソーシャルエンジニアリングが必須であり、標的ユーザーが意図的にアクションを起こす必要がある点が緩和要因となっている。
セキュリティ企業Patchstackのオリバー・シルド氏はSearch Engine Journalの取材に対し、「ソーシャルエンジニアリングが必要なため、ハッカーがこのXSSを積極的に悪用する可能性は低いと考えている」とコメントしている。同社では開示時点で緩和ルールを顧客に提供済みだ。
SSRF（サーバーサイドリクエストフォージェリ）による内部情報露出
SSRFとは、サーバーが内部ネットワークに対して不正なリクエストを送信させられる脆弱性だ。今回の事例では、リンクローカルIP範囲（サーバー内のプライベート通信で使われるアドレス）へのリクエストが可能になる。
これにより、本来外部からアクセスできない内部の機密情報が漏洩するリスクがある。公式発表では詳細が明かされていないが、仮想ホスト環境やクラウドインスタンスのメタデータサービスなどが標的になる可能性がある。
マルチサイト環境での権限昇格（新規サイト作成）
ユーザー登録が有効なマルチサイトネットワークにおいて、権限を持たないユーザーが新たなサイトを作成できる脆弱性だ。大学や企業のポータルサイトのような大規模マルチサイト環境では、悪意のあるサイト作成によってブランド毀損やフィッシングサイトの設置などに悪用される恐れがある。
単一サイトの運営者には影響しないが、WPMU（WordPress Multisite）を利用している管理者は直ちにアップデートを適用する必要がある。
XSSの危険性を正しく理解する
今回のリリースで最も注意を集めている脆弱性が反射型XSSだ。クロスサイトスクリプティングは、古くから存在する攻撃手法でありながら、依然として多くのWebアプリケーションで発見される。
OWASP（Open Worldwide Application Security Project）は、XSSを「悪意のあるスクリプトが、信頼された正規のWebサイトに注入される攻撃」と定義する。攻撃者は、ユーザーの入力を適切に検証・エンコードせずに出力することで、任意のスクリプトを実行させる。
実行されたスクリプトは、Cookieやセッショントークンといった機密情報にアクセスできるため、アカウントの乗っ取りや個人情報の窃取に直結する。WordPressのログイン画面でこの攻撃が成立すれば、サイト全体の管理者権限を奪取されるリスクもゼロではない。
WordPressユーザーが取るべき具体的な対策
自動更新が有効か確認する
WordPress 7.0.3はセキュリティリリースのため、自動更新がデフォルトで有効になっている環境では速やかに適用される。管理画面の「ダッシュボード」→「更新」から、現在のバージョンを確認しておこう。
手動更新が必要な場合の手順
何らかの理由で自動更新が失敗した場合は、手動での更新を推奨する。FTP/SFTPでWordPressファイルを上書きする方法が一般的だが、事前にデータベースとファイルの完全バックアップを取得しておくことが鉄則だ。
マルチサイト運営者は特に注意を
ユーザー登録を許可しているマルチサイトネットワークでは、権限昇格の脆弱性が悪用される前に即座に更新する必要がある。また、新規サイト作成の監査ログを確認し、不審なサイトが作成されていないかも点検すべきだ。
この記事のポイント
- WordPress 7.0.3では12件の脆弱性が修正され、ログイン画面の反射型XSSは深刻度8.9
- SSRFやマルチサイト権限昇格も深刻で、特にマルチサイト運営者は早急な対応が必要
- 攻撃にはソーシャルエンジニアリングが必要だが、RCEに繋がる可能性があるため軽視できない
- 自動更新の確認と、全バージョンへのパッチ適用を今すぐ実施すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験