← 2026-04-14 の一覧へ戻るホーム
1 つ、30 の WordPress プラグインを購入し、それぞれにバックドアを埋め込まれた。

2026/04/14 2:54

1 つ、30 の WordPress プラグインを購入し、それぞれにバックドアを埋め込まれた。

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese 翻訳：

元サマリーの原文は明確で正確であり、高レベルの概要として十分に範囲内に収まっており、改行文筆は必要ありません。

本文

去週、私は WordPress プラグインの一つ「Widget Logic」を狙ったサプライチェーン攻撃の事例について書きました。信頼されるブランドでありながら新所有者に買収されたこのプラグインが、どうして悪意のあるものへと変貌したのか。そして今、そのパターンが再び現れ、その規模はさらに拡大しています。

31 個のプラグインが WordPress.org で閉鎖されたとのこと。 8 ヶ月： バックドアが有効になるまでの潜伏期間です。 6 桁の金額： ポートフォリオ（複数製品の束）を取得するために Flippa に支払われた費用です。

あるクライアントから、wp-admin 内に発見されたセキュリティ警告に関する報告がありました。Improve & Grow のリッキーが、顧客サイトの WordPress ダッシュボード上で表示されたアラートについて私たちにメールで連絡してくれました。その通知は、WordPress.org プラグインチームからのものであり、「Countdown Timer Ultimate」というプラグインには、第三者による不正アクセスを可能にするコードが含まれていると警告されていました。

私はそのサイトに対して包括的なセキュリティ監査を行いました。その時点では既に、WordPress.org がバージョン 2.6.9.1 という強制更新を行っており、これは状況を修復するためのものでした。しかし損害は既に起こっていました。マルウェアは wp-config.php に隠れていました。

そのプラグインの 

wpos-analytics
モジュールは、悪意のあるサーバー 
analytics.essentialplugin.com
に情報を送信し（「電話をかける」行為）、その後 
wp-comments-posts.php
という名前のバックドアファイルをダウンロードしました（このファイルは、コアファイルである 
wp-comments-post.php
に似せて作られており）それを介して、大量の PHP コードを wp-config.php へ注入していました。

注入されたコードはかなり洗練されています。コマンド＆コントロールサーバーからスパムリンク、リダイレクト、偽のページを取得し、それらを Googlebot 向けに表示するように仕組まれており、サイト管理者には見えないようにされていました。そして最も恐ろしい部分です：この C2（コマンド＆コントロール）ドメインの解決には、Ethereum のスマートコントラクトを介して公開ブロックチェーンの RPC エンドポイントからの照会が行われていました。従来のドメインの取り消しはこの攻撃には無効であり、攻撃者はいつでもスマートコントラクトを更新して新しいドメインへのポインターを設定することができたためです。

強制更新により wp-config.php の問題は解決しましたが、WordPress.org の v2.6.9.1 版のアップデートはプラグイン内の「情報送信」機構を無効にしただけで、wp-config.php には手を加えていませんでした。SEO スパムの注入により、Googlebot に向けられた隠されたコンテンツを提供する状態が継続していました。

私はフォレンジック手法を用いて、注入が行われた正確な時間軸を特定しました。CaptainCore では日々 restic バックアップを実施しており、wp-config.php を 8 つの異なるバックアップ時点から抽出し、バイナリサーチ法を用いてファイルサイズを比較を行いました。

[8 つのバックアップスナップショットにおける wp-config.php のファイルサイズ]

注入は 2026 年 4 月 6 日、UTC 時間で 04:22 から 11:06 の間に発生しており、合計約 6 時間 44 分というタイムウィンドウで完了しています。バックドアは、実際に有効になる 8 ヶ月前に植え付けられていました。

私はプラグインの履歴を 939 つのクイックスナップショットを通じて追跡しました。このプラグインは 2019 年 1 月から既にそのサイトに存在していました。

wpos-analytics
モジュールも常にあり、数年間、正当な分析サービスへのオプトインシステムとして機能していました。その後到来したのは、2025 年 8 月 8 日にリリースされたバージョン 2.6.7 です。変更ログには「WordPress バージョン 6.8.2 との互換性を確認してください」と記されていましたが、実際には PHP のシリアライズ化バックドアを含む 191 ライン分のコードが追加されていました。
class-anylc-admin.php
ファイルは 473 ラインから 664 ラインに増加しました。

新導入されたコードにより以下の 3 つの要素が追加されました：

  • fetch_ver_info()
    メソッド：攻撃者のサーバーに対して 
    file_get_contents()
    を呼び出し、そのレスポンスを 
    @unserialize()
    に渡すものです。
  • version_info_clean()
    メソッド：
    $this->clean($this->version_cache, $this->changelog)
    を実行し、すべての値は未シリアライズされたリモートデータから取得されます。
  • 認証不要な REST API エンドポイントで 
    permission_callback: __return_true
    を設定しています。

これは教科書的な任意の関数呼び出しです。リモートサーバーが関数名、引数、すべてを制御しています。このコードは 8 ヶ月間無効状態（潜伏）していましたが、2026 年 4 月 5 日〜6 日に有効化されました。

このプラグインは Flippa で売却されました。ここで事情が複雑になります。元々のプラグインは、インドを拠点とする Minesh Shah、Anoop Ranawat、Pratik Jain というチームによって構築され、2015 年頃より「WP Online Support」という名称で運営されていました。その後、「Essential Plugin」へとリブランディングし、プレミアム版を含む 30 つ以上の無料プラグインのポートフォリオを拡大しました。2024 年末までに収益は 35%〜45% 減少しており、Minesh は企業全体を Flippa にリストしました。SEO、暗号通貨、オンラインギャンブルマーケティングのバックグラウンドを持つ買い手（通称「Kris」と呼ばれる）が、6 桁の金額で全ての事業を買収しました。Flippa はこの売却について、2025 年 7 月にもケーススタディを公表していました。

  • 2015 年 2 月： wponlinesupport.com ドメインの登録。チームが WordPress プラグインの開発を開始。
  • 2016 年 10 月： anoopranawat 氏により「Countdown Timer Ultimate」が WordPress.org で公開。
  • 2021 年 8 月： essentialplugin.com ドメインの登録。企業名を「WP Online Support」から「Essential Plugin」へと変更。
  • 2024 年末： 収益が 35〜45% 減少。Minesh Shah が企業全体を Flippa にリスト。
  • 2025 年初め： 買い手「Kris」が Flippa を介して Essential Plugin を 6 桁の金額で購入。
  • 2025 年 5 月 12 日： 新しい essentialplugin WordPress.org アカウントの作成。
  • 2025 年 5 月 14〜16 日： 元の wponlinesupport アカウントでの最後のコミット。著者ヘッダーの変更。
  • 2025 年 8 月 8 日： essentialplugin アカウントによる最初のコミット。バージョン 2.6.7 で、
    unserialize()
    を用いた RCE バックドアが植え付けられる。変更ログは嘘をつき、「WordPress バージョン 6.8.2 との互換性を確認してください」と明記。
  • 2025 年 8 月 30 日： essentialplugin.com の WHOIS データがジュネーブ、スイスの「Kim Schmidt」に更新され、ProtonMail アドレスが使用される。
  • 2026 年 4 月 5〜6 日： バックドアが武器化され、このプラグインを実行しているすべてのサイトに対して Malicious Payloads（悪意のあるペイロード）の配信を開始。
  • 2026 年 4 月 7 日： WordPress.org プラグインチームが一括で Essential Plugin の著者の作成した全 31 個のプラグインを永久的に閉鎖。
  • 2026 年 4 月 8 日： WordPress.org がすべてのサイトに対してバージョン 2.6.9.1への自動更新を強制し、電話を送る機能を無効にする 
    return;
    ステートメントを追加するとともに、バックドア行 
    $this->clean()
    の直後に注釈コメントを追加。

買い手の最初の SVN コミット自体がバックドアでした。WordPress.org は一日で 30 個以上のプラグインを閉鎖しました。2026 年 4 月 7 日、WordPress.org プラグインチームは Essential Plugin の著者が作成した全てのプラグインを永久的に閉鎖しました。少なくとも 30 ものプラグインです。すべて同日中です。私が確認したものを以下にリストします：

  • Accordion and Accordion Slider
  • Album and Image Gallery Plus Lightbox
  • Audio Player with Playlist Ultimate
  • Blog Designer for Post and Widget
  • Countdown Timer Ultimate
  • Featured Post Creative
  • Footer Mega Grid Columns
  • Hero Banner Ultimate
  • HTML5 VideoGallery Plus Player
  • Meta Slider and Carousel with Lightbox
  • Popup Anything on Click
  • Portfolio and Projects
  • Post Category Image with Grid and Slider
  • Post Grid and Filter Ultimate
  • Preloader for Website
  • Product Categories Designs for WooCommerce
  • Responsive WP FAQ with Category (sp-faq)
  • SlidersPack – All in One Image Sliders
  • SP News And Widget
  • Styles for WP PageNavi – Addon
  • Ticker Ultimate
  • Timeline and History Slider
  • Woo Product Slider and Carousel with Category
  • WP Blog and Widgets
  • WP Featured Content and Slider
  • WP Logo Showcase Responsive Slider and Carousel
  • WP Responsive Recent Post Slider
  • WP Slick Slider and Image Carousel
  • WP Team Showcase and Slider
  • WP Testimonial with Widget
  • WP Trending Post Slider and Widget

これら全てが永久に閉鎖されました。WordPress.org での著者検索では結果がゼロとなります。analytics.essentialplugin.com エンドポイントには 

{"message":"closed"}
と返答されます。

以前にもこうした事例がありました。2017 年、別名「Daley Tias」として知られる買い手が、「Display Widgets」プラグイン（インストール数 20 万）を 15,000 ドルで購入し、 payday loan スパムを注入しました。その買い手は、その後少なくとも 9 つのプラグインを同様の方法で乗っ取りました。Essential Plugin のケースは、より大規模なバージョンで同じ戦術です：30 個以上のプラグイン、数十万のアクティブインストール、公開マーケットプレイスを通じた正当な 8 年の歴史を持つ企業が買収され、数ヶ月以内に武器化されています。

私は手元のフルードにある影響を受けたすべてのプラグインをパッチ適用しました。WordPress.org の強制更新により「電話を送る」機能が無効になる 

return;
ステートメントが追加されました。これは応急処置です。
wpos-analytics
モジュールとそのコードはすべて残っています。私はバックドアモジュール全体を削除した修正版を作成しました。手元のフルード全体のスキャン結果では、22 の顧客サイトにおいて 26 つの Essential Plugin プラグインのうち 12 つがインストールされていることが判明しました。そのうち 10 つをパッチ適用しました（1 つはバックドアモジュールを持っておらず、もう 1 つはオリジナル著者による別の「プロ」バージョンでした）。修正版は以下の通りです。これらは永久に B2 にホストされています：

  • Countdown Timer Ultimate: 
    wp plugin install https://plugins.captaincore.io/countdown-timer-ultimate-2.6.9.1-patched.zip --force
  • Popup Anything on Click: 
    wp plugin install https://plugins.captaincore.io/popup-anything-on-click-2.9.1.1-patched.zip --force
  • WP Testimonial with Widget: 
    wp plugin install https://plugins.captaincore.io/wp-testimonial-with-widget-3.5.1-patched.zip --force
  • WP Team Showcase and Slider: 
    wp plugin install https://plugins.captaincore.io/wp-team-showcase-and-slider-2.8.6.1-patched.zip --force
  • WP FAQ (sp-faq): 
    wp plugin install https://plugins.captaincore.io/sp-faq-3.9.5.1-patched.zip --force
  • Timeline and History Slider: 
    wp plugin install https://plugins.captaincore.io/timeline-and-history-slider-2.4.5.1-patched.zip --force
  • Album and Image Gallery plus Lightbox: 
    wp plugin install https://plugins.captaincore.io/album-and-image-gallery-plus-lightbox-2.1.8.1-patched.zip --force
  • SP News and Widget: 
    wp plugin install https://plugins.captaincore.io/sp-news-and-widget-5.0.6-patched.zip --force
  • WP Blog and Widgets: 
    wp plugin install https://plugins.captaincore.io/wp-blog-and-widgets-2.6.6.1-patched.zip --force
  • Featured Post Creative: 
    wp plugin install https://plugins.captaincore.io/featured-post-creative-1.5.7-patched.zip --force
  • Post Grid and Filter Ultimate: 
    wp plugin install https://plugins.captaincore.io/post-grid-and-filter-ultimate-1.7.4-patched.zip --force

各修正版は、完全な 

wpos-analytics/
ディレクトリを削除し、メインプラグインファイルからローダー関数ブロックを除去し、バージョンヘッダーに 
-patched
を追加します。その結果、プラグイン自体は通常通り動作し続けます。

もし私がパッチ適用した Essential Plugin プラグインをお持ちであれば、ご自身でパッチ適用することも可能です。プロセスは Claude Code を使用すれば簡単です。この記事のコンテキストを指し示し、どのプラグインをパッチ適用すべきか指定すれば、私が行った同様の方法で 

wpos-analytics
モジュールを除去できます。Essential Plugin プラグインすべてにおいて以下のパターンが一致しています：

  1. プラグインから 
    wpos-analytics/
    ディレクトリを削除します。
  2. メインプラグイン PHP ファイルにおけるローダー関数ブロックを削除します（「Plugin Wpos Analytics Data Starts」または
    wpos_analytics_anl
    を検索）。
  3. バージョンヘッダーに 
    -patched
    を追加します。
  4. ZIP ファイルを作成し、
    wp plugin install your-plugin-patched.zip --force
    でインストールします。

必ず 

wp-config.php
を確認してください。マルウェアは 
require_once ABSPATH . wp-settings.php;
と同じ行に自身を追加するため、一瞥ですぐに見逃す可能性があります。もしファイルが予想以上に大きい場合（注入されたペイロードは約 6KB の追加となります）、サイトはすでに積極的に乗っ取られており、プラグインのパッチ適用のみでは不十分で、完全なクリーンアップが必要です。

WordPress プラグインマーケットプレイスは信頼の問題を抱えています。2 週間で 2 度のサプライチェーン攻撃が発生しました。どちらも同じパターンを踏んでいました：確立されたインストールベースを持つ信頼できるプラグインを購入し、WordPress.org のコミットアクセスを引き継ぎ、悪意のあるコードを注入します。Essential Plugin の Flippa リストは公開されており、買い手の SEO とギャンブルマーケティングのバックグラウンドも公開されています。にもかかわらず、WordPress.org からの審査なしで買収が進みました。

WordPress.org にはプラグイン所有権移転をマークしたりレビューするための仕組みがありません。「支配権の変更」に関するユーザーへの通知もありません。新しいコミッターによる追加のコードレビューも発生しません。攻撃が発覚した後にプラグインチームは迅速に対応しましたが、バックドアが植え付けられた時点から検知されるまでには 8 ヶ月かかっていました。

WordPress サイトを管理されている場合は、上記のリストにある 26 つのプラグインスラッグを含むフルードを検索してください。見つかれば、パッチ適用するか除去してください。また 

wp-config.php
も必ず確認してください。

同じ日のほかのニュース

一覧に戻る →

2026/04/14 5:36

GitHub で積み上がったプルリクエストを処理する。

## Japanese Translation: 本テキストでは、「Stacked PRs（スタックされたプルリクエスト）」を紹介します。これは、大規模で管理が困難なプルリクエストによる問題、例えばレビューの難易度が高いこと、マージにかかる時間が長いこと、頻繁な衝突などを解決するために GitHub が実装した機能です。開発者は一度に巨額の変更を提出するのではなく、作業を注力し独立した層に分割し、それらが互いに縦方向に積み上げられ、最終的に main ブランチへマージされるまで進めます。 GitHub 本家はこのワークフローを、ナビゲーション用の可視化「スタックマップ（stack map）」UI でサポートしており、ブランチ保護規則がターゲットとなる最終ブランチに対して自動的に適用され、継続的統合（CI）システムが各層ごとに個別にテストを実行し、main ブランチへのマージを想定する manner で動作します。また、ユーザーはスタックの全て、または一部の PR をマージすることができ、残りの PR は自動的にリベースされ、スタック構造が維持されます。 このワークフローをローカル環境で管理するためには、開発者は `gh stack` CLI ツールを使用します。これは、拡張機能をインストール（`gh extension install github/gh-stack`）し、`gs init`、`gs add`、`gs push`、`gs submit` などのコマンドを用いてブランチを作成し、カスケードリベースを管理し、スタックをレビューまたはマージのためにオープン化することを意味します。将来的には、AI コーディングエージェントもこのスタックを自律的に処理できるように、特定のスキルパッケージ（`npx skills add github/gh-stack`）をインストールすることで教育できます。Ultimately（結果として）、Stacked PRs はチームが段階的なレビューを通じてコードの品質を向上させながら、大規模なコードベースを維持するために必要な手動作業を劇的に削減することを可能にします。

2026/04/14 0:31

『何事も起きない：スポーツ市場以外では常に「いいえ」と購入する Polymarket ボット』

## Japanese Translation: 本書では、Polymarket でスポーツ以外の Yes/No マーケットにおける「NO」エントリを取引することを目的に特化して構築された非同期の Python ボット「Nothing Ever Happens」を معرفیしています。本プロジェクトは娯楽目的でのみ提供されるものであり、保証や免責事項は一切適用されません（as-is）として提供されます。ライブフラグが設定されていないデフォルト状態では `PaperExchangeClient` が採用され、シミュレーションテストが行われます。リアルな取引を実行するには、環境変数を明示的に設定する必要があるためです。具体的には、`BOT_MODE=live`、`LIVE_TRADING_ENABLED=true`、`DRY_RUN=false` などを設定することでリアル取引モードを有効化します。また、ライブオーダーの送信を有効にするには、`PRIVATE_KEY`、`FUNDER_ADDRESS`（署名タイプ 1 および 2 の場合）、データベース URL、および Polygon RPC URL などの特定のエントリが必要となります。 ボットのアーキテクチャはモジュール化されており、ランタイムロジック、取引所クライアント、ダッシュボード UI、回復ツール、そしてコア戦略モジュールである「nothing_happens」で構成されています。ローカルでのセットアップでは、`pip install -r requirements.txt` によって依存関係をインストールし、`config.example.json` を `config.json` にコピーして非機密設定をその中で構成し、秘密鍵やフラグは `.env` ファイル（パス：`strategies.nothing_happens`）に保存します。ローカル設定は意図的に git 無視されており、ユーザーは環境変数 `CONFIG_PATH` を通じてランタイムが参照する異なるパスを指定できるようにしています。 Heroku でのクラウドデプロイメントでは、特定のコマンドヘルパー（`alive.sh`、`logs.sh`、`kill.sh`）を使用して、アプリの状態を管理し、ライブ取引の有効化/無効化やロギングを行うことができます。デプロイには、bot モード、プライベートキー、RPC URL、データベースに関する環境変数を `heroku config:set` コマンドを用いて設定する必要があります。-production 環境では、誤って長時間実行タスクを実行してしまうのを防ぐためにワーカーダイノを除外し、ウェブダイノのみを使用するようにスケーリング構成されています。また、`db_stats.py`、`export_db.py`、`wallet_history.py`、`parse_logs.py` などのユーティリティスクリプトは、データベースの点検やログ分析を実行することなく市場の変動を意図的に引き起こさずにこれらの情報を可視化することを可能にするため、透明性を高めています。

2026/04/14 3:50

# フォアファイアのビルドを 17% 高速化する手順 Mozilla のビルド環境を最適化し、**17% のパフォーマンス向上**を実現するための手順をご紹介します： - ビルドシステムと依存関係を最新の状態に更新してください。 - `MOZ_MAKEFLAGS` を適切に設定して（例：`-j$(nproc)`）、並列ビルドプロセスを有効にしてください。 - `-O2` や `-O3` といった最適化されたコンパイラフラグを、状況に応じて使用してください。 - 不要な負荷を削減するために、古くなったビルドアーティファクトを削除してください。 - インクリメンタルビルドにおいては、プリビルドされたツールキットやキャッシュされたオブジェクトファイルの利用を検討してください。 これらの変更を加えることで、コード品質を損なうことなくコンパイル時間を大幅に短縮できます。

## Japanese Translation: このアップデートは、Firefox のビルドシステムへの重要な修正を導入し、Buildcache Lua プラグインシステムを介して WebIDL バインディングコードの生成に対して有効なキャッシュ化を実現します。歴史的に、この Python ベースのステップ（`python3 -m mozbuild.action.webidl`）は ccache や sccache のような標準的なコンパイラキャッシュと互換性がありませんでした。これは任意のコマンドを効果的にラップできないためです。修正内容は `dom/bindings/Makefile.in` に条件付きラッパーを追加するものであり、Buildcache を使用する際にのみ有効化されます（`MOZ_USING_BUILDCACHE` が定義されている場合）。これにより呼び出しは `buildcache python3 -m mozbuild.action.webidl ...` へと変換されます。Buildcache の Lua ラッパー (`webidl.lua`) は `.webidl` ファイルや Python スクリプトなどの入力を、および `file-lists.json` と `codegen.json` から出力を識別し、ハッシュ化には `direct_mode` を使用します。Linux におけるタイミング測定では、このラッパーがなかった場合に Buildcache が使用されなかった場合の約 3m27sに対して、ccache（約 3m21s）および sccache（約 2m49s）が以前より優れていました。Lua ラッパーを有効にすると、ウォームビルド時間は約 1m12s–1m27s に低下します。設定には、central を更新するか `buildcache-wrappers` をクローンし、`~/.buildcache/config.json` で `lua_paths` を構成する（または mozconfig を通じて `BUILDCACHE_LUA_PATH` を設定）ことを必要とします。構成には、Rust クレートからの大規模なエントリに対応するための 2.5 GB の `max_local_entry_size` が含まれています。現在では概念実証として機能していますが、この最適化は将来の Firefox 開発において大きな可能性を示しており、反復サイクルの加速とより高速なアップデートをもたらすとともに、他の確定論的コード生成ステップへの拡張の可能性もあります。

1 つ、30 の WordPress プラグインを購入し、それぞれにバックドアを埋め込まれた。 | そっか～ニュース