ハクソク

世界を動かす技術を、日本語で。

誰かが30個のWordPressプラグインを購入し、すべてにバックドアを仕込んだ

2026年4月14日原文(anchor.host)

概要

  • WordPressプラグイン「Essential Plugin」シリーズで 大規模なサプライチェーン攻撃 が発生
  • 30以上のプラグインが悪意あるコード により汚染され、WordPress.orgによって閉鎖
  • 攻撃は Flippaでの正規売却後に実行、8ヶ月潜伏してから発動
  • マルウェアは wp-config.phpに隠れてSEOスパム をGooglebotにだけ表示
  • WordPress.orgの 強制アップデートは完全な除去には不十分、手動パッチが推奨

Essential Pluginサプライチェーン攻撃の全貌

  • Widget Logic に続き、今度は Essential Plugin ポートフォリオで大規模な攻撃が発生
  • 30以上のプラグイン が汚染、 31本がWordPress.orgで閉鎖
  • Flippaで6桁の金額 で売却され、 新オーナー“ Kris ” が即座にバックドアをコミット
  • 8ヶ月間バックドアが潜伏 し、2026年4月5-6日に一斉発動
  • analytics.essentialplugin.com を介して各サイトにマルウェア配布
  • wp-config.php に6KB規模の悪意あるPHPコードを注入し、 GooglebotにだけSEOスパム を配信
  • C2サーバーのドメイン解決にEthereumスマートコントラクト を利用、従来のドメイン停止が無効化
  • WordPress.orgの強制アップデート（v2.6.9.1） は電話帰還機能を停止したが、 wp-config.phpのマルウェアは残存
  • CaptainCore のバックアップで侵入時期を特定、 2026年4月6日 04:22〜11:06 UTC の間に注入

攻撃の技術的詳細

  • wpos-analytics モジュールが正規機能を装い、 version 2.6.7でPHPのunserialize() RCEバックドア を追加
  • fetch_ver_info() で攻撃者サーバーからデータ取得し、 @unserialize() で実行
  • REST APIエンドポイント が認証不要で任意関数実行可能
  • 8ヶ月間機能せずに潜伏、2026年4月にC2サーバーがペイロード配信を開始

プラグイン売却と攻撃者の行動

  • WP Online Support （後のEssential Plugin）が Flippaで売却
  • 買収者“ Kris ”は SEO・暗号・ギャンブルマーケティング分野の人物
  • 買収後、 最初のSVNコミットでバックドア追加
  • 2026年4月7日、WordPress.orgが Essential Pluginの全プラグインを一斉閉鎖
  • 2026年4月8日、自動アップデートでバックドア機能を無効化
  • analytics.essentialplugin.com は現在{"message":"closed"}を返すのみ

被害プラグイン一覧（一部抜粋）

  • Accordion and Accordion Slider
  • Album and Image Gallery Plus Lightbox
  • Audio Player with Playlist Ultimate
  • Blog Designer for Post and Widget
  • Countdown Timer Ultimate
  • Popup Anything on Click
  • Portfolio and Projects
  • Preloader for Website
  • Responsive WP FAQ with Category
  • SP News And Widget
  • Timeline and History Slider
  • WP Blog and Widgets
  • WP Team Showcase and Slider
  • WP Testimonial with Widget
  • 他多数（全31本が閉鎖）

過去の類似事件と今回の特徴

  • 2017年のDisplay Widgets事件 と同様、 信頼されたプラグインの買収→バックドア挿入 という手口
  • 規模は過去最大級、 数十万サイトが影響
  • Flippa等マーケットプレイスでの売却が攻撃温床 となるリスク

対応策とパッチ手順

  • WordPress.orgの強制アップデートは応急処置 に過ぎず、 wpos-analyticsモジュール自体を削除推奨
  • CaptainCore で独自にパッチ済みバージョンを配布
    • 例:
      • Countdown Timer Ultimate: https://plugins.captaincore.io/countdown-timer-ultimate-2.6.9.1-patched.zip
      • Popup Anything on Click: https://plugins.captaincore.io/popup-anything-on-click-2.9.1.1-patched.zip
      • 他多数
  • パッチ方法
    • wpos-analytics/ ディレクトリを削除
    • メインPHPファイルからローダー関数（“Plugin Wpos Analytics Data Starts”やwpos_analytics_anlを検索）を削除
    • Version: ヘッダーに-patchedを追加
    • zip化してwp plugin install your-plugin-patched.zip --forceで再インストール
  • wp-config.phpの確認
    • require_once ABSPATH . wp-settings.php; の行末に不審なコードが追加されていないか確認
    • ファイルサイズが6KB以上増加していれば感染の可能性大
    • 感染時は プラグインパッチだけでなく、サイト全体の徹底クリーニングが必要

WordPressプラグインマーケットの課題

  • プラグインの所有権移転時の審査や監視体制が未整備
  • Flippa等での売却情報や買収者の素性が公開されていても、WordPress.org側でチェック機能なし
  • 信頼できるプラグインの買収→悪用 というサプライチェーン攻撃が今後も増加する懸念

まとめ・推奨アクション

  • Essential Plugin製プラグインの利用者は即時パッチ適用・wp-config.phpの確認を推奨
  • 所有権移転時のセキュリティ監査や自動警告システムの導入が急務
  • WordPress.orgやユーザー側での多層的な監視・バックアップ体制の強化が必要

Hackerたちの意見

ウェブプロジェクトを見るたびに、「npm install」から始まって、文字通り何十ものライブラリがダウンロードされるんだよね。プロジェクトの作者たちは、自分たちのプロジェクトにどんなライブラリが必要かすら分かってないと思う。多くは間接依存関係だからね。サプライチェーン攻撃について、そのライブラリを確認した可能性はゼロだよ。

└

プロジェクトの作者たちは、自分たちのプロジェクトにどんなライブラリが必要かすら分かってないと思う。多くは間接依存関係だからね。サプライチェーン攻撃について、そのライブラリを確認した可能性はゼロだよ。だから、依存関係をプロジェクトにバンドルするんじゃなくて、ユーザーが直接npmからインストールする方がいい理由だよね。

└

理由があるんだ。これまでの一般的な考え方は「車輪を再発明するな」ってこと、またはHN以外の言い方で「それ用のアプリがある」ってことだよね。みんなが自分で暗号を作るべきだとは全く思わないけど、それとフォントの色を選ぶライブラリの間には健全な中間点があるはずだよ。

└

ほとんどのパッケージマネージャーはこれをやってるよ。すべてのパッケージを検査してたら、仕事が進まないからね。renovateやdependabotのようなサービスは、js開発者にとってコストなしでこの作業をしてくれるし、多分もっと上手くやってるよ。

└

これってmavenやpython、rubyのプロジェクトにも同じことが言えるんじゃない？ウェブだけの問題とは思えないな。

└

それとも、もっと悪いのは「sudo curl URL | bash」かな。

└

これは、ピアレビューやキュレーションなしでパッケージを公開することの重要な脆弱性だね。無制限で即時に誰でも公開できるのを許すんじゃなくて、もっと多くの自動化された行動コードカバレッジ分析と人間のレビュアーが必要だよ。

└

彼らがそのライブラリをサプライチェーン攻撃についてチェックした可能性はゼロだよ。たとえチェックしたとしても、プロジェクトがすべての依存関係をgitハッシュに固定していない限り、1つの更新で全てが台無しになるからね。だからDependabotみたいなのは素晴らしいんだ。

└

ほとんどは、良いSASTツールとプロセスで管理できるよ。

└

Rustもそんな感じだよね。Rustプロジェクトを開くたびにCargo.lockを見て、何百もの再帰的な依存関係があるのを見て、マジで頭おかしくなる。従来のCやC++プロジェクトと比べると、もう狂気の沙汰だよ。

└

だからこそ、ソフトウェアを書くときは外部パッケージを使わないようにしてるんだ。例えば、最近Pythonで天気観測データをローカルデータベースに同期するツールを書いたんだけど、[1] Pythonの標準ライブラリを使ってダウンロードを管理するのにちょっとだけ手間がかかったけど、Requestsみたいな外部パッケージを使うよりも、Pythonに付属しているもの以外の依存関係がなくなったんだ。隠れた依存関係の木がいつかトロイの木馬を抱えるかもしれない心配をしなくて済むのは、心の平穏が得られていいよね。[1] https://github.com/tmoertel/tempest-personal-weather [2] https://pypi.org/project/requests/

その攻撃はどうやって攻撃者に「収益」を生み出すつもりだったの？どんな情報を手に入れたんだろう？

Hacker Newsで議論の続きを見る