更新の通知が来たらできるだけ早く当てる。WordPressサイトを預かる立場では長く正しい習慣として語られてきましたし、その前提はいまも変わりません。ただ2026年に入ってから表面化したいくつかの事例は、その習慣が暗黙に置いている「配信されてくる更新そのものは信頼できる」という部分に、これまでとは違う角度から光を当てました。
狙われたのはプラグインのコードに残っていた穴ではなく、プラグインが利用者の手元に届くまでの経路のほうです。脆弱性を探して突くのではなく、正規の更新に紛れ込んで入ってくる。防ぐ側から見ると、注意を向ける場所が一段ずれる話になります。
所有者が変わったあとに仕込まれた休眠コード
4月初旬に問題になったのは、Essential Pluginという作者名で公式ディレクトリに並んでいた30本あまりのプラグインでした。カウントダウンタイマー、クリックで開くポップアップ、お客様の声の表示といった、小規模サイトで気軽に足される種類のものが並んでおり、合計の稼働数は数十万件規模とされています。
経緯として報じられているのは、この一群がまとめて売買され、開発者が交代していたという点です。WordPress.orgのプラグインは、作者が変わっても配布の枠組みはそのまま引き継がれます。利用者側の管理画面には、以前と同じ名前のプラグインに更新が来たようにしか見えません。
不正なコードが加えられたのは2025年8月、互換性対応をうたった版でした。そこから約8か月のあいだ、そのコードは何もしないまま眠っていたと分析されています。動き出したのは2026年4月上旬で、外部から指示を受け取って処理を実行する経路が有効になり、検索エンジンのクローラーに対してだけ表示されるスパムや転送が仕込まれました。WordPress.orgのプラグインチームは4月7日に該当する全プラグインの配布を停止し、翌日には強制的な更新で通信部分を無効化しています。
公式ディレクトリの外でも同じ形が起きた
6月には別の形の事例が公表されました。ShapedPluginという開発元の有償版プラグイン、具体的にはWooCommerce向けの商品スライダー、お客様の声、投稿一覧表示の三製品で、開発元自身のビルドと配信の仕組みが侵害されていたというものです。
こちらで問題になったのは、公式ディレクトリに置かれている無償版ではなく、開発元のサーバーから直接配信される有償版のほうでした。つまり影響を受けたのは、対価を払って正規に自動更新を受けていた利用者だけということになります。混入は5月下旬、利用者からの報告が上がり始めたのが6月上旬、開発元が事実を認めたのが6月中旬という流れでした。
盗み出されたとされる情報は、管理者のログイン情報、二段階認証の秘密鍵、データベースの接続情報、メール送信サービスの認証情報、そして受注データにまで及びます。セキュリティメディアの報道では、一連の侵害はCVE-2026-10735として整理されています。有償版だから安全、公式ディレクトリだから安全、という単純な線引きが成り立たないことを、二つの事例は逆方向から示した形です。
気づくまでに時間がかかる理由
Essential Pluginの件で目を引くのは、仕込まれてから発覚するまでのおよそ8か月という長さです。仕込む側からすれば、加えた直後に動かす必要はありません。しばらく普通に動く版を配り、更新が行き渡り、疑いが薄れたころに起こせばよい。監視する側の目線に合わせて時間をずらされると、更新直後の挙動を見るだけでは捕まえられなくなります。
もうひとつは、公式ディレクトリに所有者交代を扱う仕組みが用意されていないという構造の問題です。プラグインが売買されて委譲されても、利用者に通知が飛ぶわけではなく、新しい担当者による最初の更新に追加の審査が入るわけでもありません。稼働数の多いプラグインは、それ自体が売り物として価値を持ちます。数万件のサイトに更新を届けられる立場が、市場で取引できてしまうという事実のほうが、個々の脆弱性より扱いが難しい部分かもしれません。
被害の出方が静かであること
今回のような侵害でやっかいなのは、サイトを見ている限り異変がわからないところです。Essential Pluginの件で配られたスパムは検索エンジンのクローラーにだけ見せる作りで、運営者が自分のサイトを開いても、いつも通りのページが表示されます。気づく糸口は検索結果の見え方や、Search Consoleの警告、ホスティング側からの連絡といった、サイトの外から届く信号のほうになります。
認証情報の窃取はさらに静かです。抜かれた時点では何も起きず、しばらく経ってから別の入口として使われます。管理画面のログイン履歴に見覚えのないものが混ざる、送信していないメールが自社ドメインから出ている、といった形で後から現れることが多く、そのころには最初の原因までたどるのが難しくなっています。
運用側でできる現実的な備え
まず効くのは、入れているプラグインの数を減らすことです。装飾のために一つ、フォームのために一つ、と足していった結果として、10本20本と並んでいるサイトは珍しくありません。一本ごとに、その開発元の更新経路を信頼するという判断が積み上がっていると考えると、使っていない機能のために枠を空けておく理由はあまりありません。
次に、自動更新をどこまで任せるかの線引きです。本体のマイナー更新は自動に任せるとして、プラグインについては稼働数の多いもの、更新頻度の高いものほど、当てる前に一拍置く運用にも意味があります。ただし更新を止めれば安全という話ではなく、既知の脆弱性を放置するほうが確率としてははるかに危ないので、遅らせるとしても数日という幅に留めるのが現実的でしょう。
加えて、更新の中身を軽く確かめる習慣も持っておきたいところです。プラグインの更新画面には変更内容へのリンクが並んでいますし、公式ディレクトリなら開発の記録も公開されています。毎回すべてを読む必要はありませんが、しばらく静かだったプラグインに突然大きな更新が来た、作者名の表示が変わっている、といった違和感は、目を通していれば引っかかります。今年の二件も、外形的な変化としては読み取れる材料が残っていました。
三つ目は、変化に気づける状態を作っておくことです。ファイルの改変を検知する仕組み、wp-config.phpや読み込み処理の周辺に見慣れない記述が増えていないかの確認、そして管理者アカウントの棚卸し。侵入を完全に防ぐ前提ではなく、入られたあと早く気づく前提で組んでおくほうが、この種の攻撃には噛み合います。
依存の数を意識するという話
WordPressの強みは、必要な機能をプラグインで足していける柔軟さにあります。制作会社としてもその恩恵は受けてきましたし、ゼロから作るより速く安く仕上げられる場面はいくらでもあります。ただ、その柔軟さは同時に、他人が書いたコードを自動で受け取り続ける関係を何本も抱えることでもあります。
プラグイン単体の良し悪しだけでなく、誰が作っていて、どういう経路で更新が届いていて、その開発元がいまも同じ人たちなのか。ここまで気にして選ぶのは手間ですが、今年の二件はその手間が無駄ではないことを示しています。次に一本足そうとしたとき、それが本当に必要かどうかを一度考えてみる。当たり前のようでいて、いちばん効く判断はそのあたりに残っている気がします。