何が起きたか

2026年4月、WordPressプラグイン開発会社「EssentialPlugin」が提供する30本以上のプラグインに悪意のあるコードが仕込まれていたことが判明した。被害を受けたプラグインの総インストール数は数十万に達する。

発端は、マネージドWordPressホスティング「Anchor Hosting」の創業者Austin Ginderへの内部情報提供だった。調査を進めたところ、すべての汚染がEssentialPluginが6桁の金額（数百万円規模）で新オーナーに買収された2025年8月以降に遡ることが分かった。

バックドアは数ヶ月間、完全に沈黙していた。そして最近になって突如「活性化」し、外部のコマンド＆コントロール（C2）サーバーへ接続して wp-comments-posts.php（正規の wp-comments-post.php に似せた名前）を取得。このファイルがWordPressのコア設定ファイル wp-config.php にマルウェアを注入する仕組みだ。

攻撃の巧妙さ——3つのポイント

1. イーサリアムベースのC2アドレス解決

通常のマルウェアはIPアドレスやドメインをハードコードするが、本攻撃ではEthereumブロックチェーンを使ってC2サーバーのアドレスを動的に解決する。ブロックチェーンは書き換えが困難なため、C2インフラをブロックされにくい。インフラのテイクダウンへの耐性が高く、検出・無効化がきわめて難しい設計だ。

2. Googlebot専用のスパム配信

注入されたコードは、スパムリンク・リダイレクト・偽ページをGooglebot（Googleの検索クローラー）にしか表示しない。サイトオーナーが自分のサイトを開いても何も見えないため、被害に長期間気づけない。SEOの毀損と検索順位の下落として静かに被害が積み上がる。

3. 「時限式」サプライチェーン攻撃

買収直後にバックドアを仕込み、しばらく休眠させてから一斉に活性化する手法は近年増加傾向にある。オープンソースプロジェクトやSaaS系サービスの「買収」を入口にする攻撃は、従来のコード審査やウイルス対策では検知が難しい。

WordPress.orgの対応と残る課題

WordPress.orgは報告を受けて迅速に動き、問題プラグインのリポジトリへのアクセスを閉鎖。強制アップデートを配布してバックドアの通信経路を無効化した。

ただし「強制アップデートは wp-config.php の汚染を修復しない」とWordPress.orgは明示している。データベース接続情報など重要な設定が記載された wp-config.php が汚染されたままの場合、バックドアの通信が止まっても攻撃者はすでにサイト情報を取得済みの可能性がある。

また、マルウェアの潜伏場所が wp-comments-posts.php だけとは限らず、他のファイルにも潜んでいる可能性があることも警告されている。

実務への影響——日本のエンジニア・IT管理者がいまやるべきこと

即時確認

  • 自社・顧客サイトでEssentialPlugin製品（旧称: WP Online Support）を使用していないか確認する
  • 対象プラグインのリストはPatchStackの調査記事で公開されている
  • wp-comments-posts.php（正規ファイルは wp-comments-post.php、末尾の s に注意）の有無を確認
  • wp-config.php の内容を直接確認し、不審なコードがないかチェック

中長期の対策

  • プラグインの購入・導入審査にサプライチェーンリスクの観点を加える: 「誰が所有しているか」「最近買収されていないか」をチェックするフローを設ける
  • File Integrity Monitoring（FIM）の導入: wp-config.php などのコアファイルに対する変更をリアルタイム検知する仕組みを入れる
  • 最小権限の原則: プラグインが持つファイル書き込み権限を必要最小限に絞る
  • Webアプリケーションファイアウォール（WAF）: Googlebot偽装のアウトバウンド通信をブロックするルール整備

筆者の見解

この事件が示すのは、「コードの品質チェック」や「脆弱性スキャン」だけではもはや十分でないという現実だ。攻撃者は合法的な手段（プラグインの正規買収）でサプライチェーンに侵入し、時間をかけて信頼を積み上げてから攻撃を発動する。8ヶ月間の潜伏期間中、このバックドアはどんな静的解析にも引っかかりようがなかった。

C2アドレスの解決にイーサリアムブロックチェーンを使うアプローチは、インフラのテイクダウン耐性という観点で技術的に興味深い。今後、同様の手法が他の攻撃でも使われることは間違いなく、ネットワーク層での検知戦略の見直しが急務だ。

Non-Human Identity（NHI）の観点からも示唆が多い。WordPress環境ではプラグインがサーバー上のファイルを読み書きし、外部APIと通信し、データベースに接続する——これらはすべてNHIとして管理されるべき「アクセス権」だ。「インストールしたら終わり」ではなく、「このプラグインがどのリソースに対してどんな権限を持ち続けているか」を継続的に把握する仕組みが求められる。

WordPress自体を使うかどうかという選択論に持ち込むのは生産的ではない。現実的には、既存サイトの大半はWordPressで動いており、完全移行は現実的でない。だからこそ「禁止」ではなく「安全に使い続けるための仕組みを作る」という発想で、FIMの導入・権限の最小化・サプライチェーンの定期的な棚卸しを着実に進めることが今できる最善策だ。

すでに wp-config.php が書き換えられている場合、強制アップデートで「通信は止まった」状態でも、攻撃者がDB接続情報を入手済みである可能性を捨てられない。このケースではパスワードローテーションとログの精査を最優先で実施してほしい。

出典: この記事は WordPress plugin suite hacked to push malware to thousands of sites の内容をもとに、筆者の見解を加えて独自に執筆したものです。