WordPressプラグインのサプライチェーン攻撃：過去の事例とサイト運営者が学ぶべき教訓

WordPressの安全対策では、「信頼できる配布元からプラグインを入手し、更新を続けること」が基本です。しかし過去には、WordPress.orgの公式プラグインディレクトリで配布されるプラグインが改ざんされ、正規の更新を通じて不正なコードが届いた事件もありました。

このように、開発元や配布経路を悪用して利用者に被害を広げる手口を「サプライチェーン攻撃」といいます。

この記事では、2011年・2017年・2024年の代表的な事例を取り上げ、原因とサイト運営者ができる対策を整理します。紹介するのは当時の事件であり、名前が挙がったプラグインの現在の状態を一律に危険と評価するものではありません。

こちらも是非ご覧ください

まず始めに以下をご覧いただけますと、本記事の理解が深まるかと思います。

サプライチェーン攻撃は「信頼している更新」を悪用する

一般的な脆弱性攻撃では、サイトにあるプログラムの欠陥を突いて侵入します。一方、サプライチェーン攻撃では、プラグインを開発・配布する側に入り込み、利用者が受け取るプログラムに不正な処理を仕込みます。

例えば、次のような流れです。

1. 攻撃者が開発者のアカウントや更新権限を手に入れる。
2. プラグインに不正なコードを追加する。
3. 正規の更新として配布する。
4. 利用者が更新すると、不正なコードもサイトに取り込まれる。

利用者が怪しいサイトからファイルを入手しなくても、被害に遭う可能性がある点が、この攻撃の厄介なところです。

なお、公式ディレクトリに掲載されているプラグインを、すべてWordPress本体の開発チームが制作・保守しているわけではありません。「公式ディレクトリで配布されていること」と「WordPress本体の開発元が提供していること」は区別して考える必要があります。

事例1：人気プラグインへのバックドア混入【2011年】

2011年6月、WordPressチームは、AddThis・WPtouch・W3 Total Cacheに不審なコード変更が加えられていることを確認しました。追加されていたのは、外部から不正な操作を行うための侵入口となる「バックドア」です。

WordPress側は開発者本人による変更ではないと判断し、変更の取り消しと更新版の配布を実施しました。調査中はコードの登録先へのアクセスを停止し、予防措置としてWordPress.orgなどのパスワードを一斉にリセットしました。

当時の公式発表では調査が続いていたため、具体的な認証情報の流出経路まで断定することはできません。確認できるのは、開発者本人ではない者による変更が、正規の配布経路に入り込んだという点です。

この事件は、プラグインの機能だけでなく、開発者のアカウントや公開権限も利用者の安全に直結することを示しています。

事例2：Display Widgetsの所有権限の移行後にスパム機能を追加【2017年】

Display Widgetsは、ウィジェットの表示を制御するプラグインで、当時約20万サイトに導入されていました。

Wordfenceの調査によると、2017年の所有者変更後、バージョン2.6.1〜2.6.3に、外部からコンテンツを追加・変更・削除できるバックドアが含まれていました。この仕組みは、サイトに無断でスパムコンテンツを掲載するために使われました。

さらに、ログインしている利用者には不正なコンテンツを見せない処理もありました。管理者が普段どおり自分のサイトを確認しても、異常に気付きにくい仕組みです。

当時は掲載停止と再公開が繰り返され、不正なコードが残った版も配布されました。最終的にはWordPress.org側が不正なコードを取り除いた版を提供し、別のプラグインへの移行を勧めています。

原因は、プラグインの所有権と更新権限が、悪意ある相手に渡ったことでした。攻撃者はアカウントを盗まなくても、既存プラグインを買い取ることで、多くの利用者へ更新を届けられたのです。

長年の実績や高評価は参考になりますが、運営主体が変わった後の安全性まで保証するものではありません。

事例3：人気プラグインが外部からバックドアを取り込む【2017年】

2017年12月には、当時30万以上の有効インストールがあった「Captcha」でも、所有者変更後の不正な更新が確認されました。これは特定のプラグインの事件であり、CAPTCHA機能を提供するプラグイン全般の問題ではありません。

この事件では、公式ディレクトリで配布するコードに、外部サーバーから別のプログラムを取得し、自分自身を上書きする仕組みが追加されていました。取得先から配布されるファイルには、ユーザーID「1」として認証されるバックドアが含まれていました。

ユーザーID「1」は初期管理者であることが多いため、管理者権限を奪われる危険がありました。さらに、不正な処理の後でファイルを削除したり、公式配布版と同じ状態へ戻したりして、痕跡を隠す仕組みも確認されています。

この事件の特徴は、公式ディレクトリから入手したコードが、別の場所から不正なプログラムを取り込んだことです。最初の入手先に加え、その後の更新や追加コードの取得経路も安全性に関わります。

事例4：パスワードの使い回しで複数プラグインが改ざん【2024年】

2024年6月には、Social Warfare・Blaze Widget・Wrapper Link Element・Contact Form 7 Multi-Step Addonなど、複数のプラグインに不正なコードが追加されました。

不正なコードには、管理者アカウントを作成してその情報を外部へ送ったり、サイトへスパムを挿入したりする処理が含まれていました。なお、Contact Form 7 Multi-Step Addonは追加機能を提供する別のプラグインであり、Contact Form 7本体の改ざんではありません。

判明した原因は、開発者のパスワードの使い回しです。別のサービスから流出した認証情報がWordPress.orgでも使われており、攻撃者が更新権限を持つアカウントに侵入しました。WordPress.org側も、外部で漏えいした認証情報の再利用が原因であると説明しています。

一方、同じ攻撃で狙われたPodsでは、コードの登録後に公開を別途確認する「Release Confirmation」により、不正な版の配布が防がれたと報告されています。

この違いから、アカウントの保護に加え、実際に公開する段階でも確認を行うことが、被害を食い止める助けになると分かります。

事件から分かる、プラグイン管理の弱点

各事件の入り口は同じではありません。大きく分けると、次のような問題がありました。

問題	攻撃者に悪用された点
開発者アカウントの乗っ取り	正規の更新権限で、不正なコードを登録できる
パスワードの使い回し	別サービスの情報漏えいが、更新用アカウントへの侵入につながる
悪意ある相手への所有権の移転	プラグインの評判と既存利用者を引き継げる
外部から実行コードを取り込む仕組み	公式配布版とは異なるプログラムを利用者の環境に入れられる

WordPress.orgは対策の一つとして、2024年10月1日からプラグイン・テーマ作者に二要素認証を義務付ける方針を発表しました。あわせて、コードの更新に使うSVN専用パスワードも導入しています。

二要素認証は、パスワードに加えて認証アプリなどで本人確認を行う仕組みです。ただし、SVNへのコード登録そのものに二要素認証を直接適用する仕組みではなく、アカウント保護、専用パスワード、公開時の確認などを組み合わせる方針です。

サイト運営者が実践したい5つの対策

ここからは、過去の事件を踏まえた運用上の提案です。サイト運営者が開発者側の管理をすべて確認することは難しいため、日常的に続けられる確認と復旧の準備を組み合わせます。

① 導入後も、開発元や掲載状況の変化を確認する

プラグインを選ぶときだけでなく、導入後も開発元の告知、所有者変更、掲載停止、突然の機能変更などを確認しましょう。

ただし、所有者変更や掲載停止だけで危険と決め付けることはできません。変更の理由や対応状況を確認し、継続利用や代替への移行を判断することが大切です。

② 更新を続けながら、異常を見つける仕組みを用意する

更新経由の事件を知ると、「更新しない方が安全なのでは」と感じるかもしれません。しかし、更新を長期間止めると、すでに知られている脆弱性を残すことになります。

基本は更新を続け、そのうえでバックアップ、不正ファイルの検査、不審な管理者アカウントの確認を組み合わせることです。

重要なサイトでは検証環境での動作確認も役立ちますが、正常に動くことを確認しても、不正な処理がないと証明できるわけではありません。表示確認とセキュリティ上の確認は、目的が異なります。

③ WAFや管理画面へのログイン対策だけに頼らない

WAFは、不正な通信を検査して攻撃を防ぐ仕組みです。しかし、正規の更新として取り込まれる不正なコードは、WAFだけでは防ぎにくい場合があります。

また、サイトの管理画面を二要素認証で守っていても、それだけで開発元から届く不正な更新を防げるわけではありません。ファイルの検査や、アカウント・プラグインの不審な追加を見つける対策も組み合わせましょう。

④ 不正な版を使っていた場合は、更新に加えて被害を調査する

修正版への更新と、侵害されたサイトの復旧は、別の作業です。

不正な版を一度動かすと、プラグイン以外の場所にバックドアを追加されたり、不正な管理者を作られたりする可能性があります。2024年の事件でも、後の調査で、メール送信サービスの認証情報を盗む追加の不正プラグインが見つかりました。

対象の不正な版を使用していた場合は、公式の対応案内に従って更新や削除を行い、あわせて次の点を調べます。

• 身に覚えのない管理者やプラグインがないか。
• 他のファイルやデータベースに改ざんがないか。
• パスワードや外部サービスの認証情報が流出していないか。
• 復元に使うバックアップが、侵害前のものか。

侵害が疑われる場合は、ログなどの記録を残し、サーバー会社や復旧を扱う専門家に相談しましょう。見つかった不正なファイルを一つ消しただけで、復旧が完了したと判断しないことが大切です。

⑤ 不要なプラグインを減らし、復旧できる状態を整える

利用するプラグインが増えるほど、確認すべき開発元や更新経路も増えます。使っていないものは削除し、利用中のものについては、用途と提供元を把握しておきましょう。

バックアップは、ファイルとデータベースの両方を対象にし、複数世代を残すと、異常に気付くまで時間がかかった場合にも対応しやすくなります。保存だけで終わらせず、復元手順も確認しておくと安心です。

終わりに：正規の更新を使いながら、発見と復旧にも備える

過去の事件では、アカウントの乗っ取り、プラグインの買収、外部からのコード取得といった複数の経路が悪用されました。信頼されているプラグインでも、その更新権限や配布経路が悪用されれば、利用者に被害が及びます。

だからこそ、公式の配布元を使って更新を続けながら、開発元の変化や不審な動きに気付けるようにしておくことが大切です。

更新・監視・バックアップを組み合わせ、問題が起きたときに調査して復旧できる状態を作ることが、サイト運営者にできる現実的な備えです。