WordPressの脆弱性の歴史｜15年間の主なハッキング事例と教訓

WordPressの脆弱性は、特定の1つの事件ではなく、15年にわたって断続的に起きてきた出来事の積み重ねです。2026年7月には、REST APIの処理ミスとSQLインジェクションを連鎖させる「wp2shell」（CVE-2026-63030・CVE-2026-60137）が公表され、CISAの既知の悪用済み脆弱性（KEV）カタログにも追加されました。本記事では、より長い時間軸で振り返り、繰り返されているパターンと、そこから今の運用に活かせる教訓を整理します。

01.まず結論：15年の歴史から見える3つのパターン

本題に入る前に、この年表全体から読み取れることを先に示します。WordPressの脆弱性は、攻撃者から見た「入り口」の種類によって大きく3つに分類できます。

まれにしか起きないコア本体の脆弱性が最も深刻な理由と、日常的に起きるプラグイン起因の脆弱性にどう向き合うべきかは、08章・09章で改めて整理します。まずは個別の事例を年表で見ていきます。

02.なぜWordPressは脆弱性の的になりやすいのか

WordPressはW3Techsの調査によれば全世界のWebサイトの4割超（2026年7月時点で41.2%）で使われている、圧倒的なシェアを持つCMSです。加えて、公式プラグインディレクトリには6万を超えるプラグインが登録されており、有料・非公式のものまで含めるとその数はさらに膨らみます。

この規模の大きさ自体が、脆弱性が発見・報告される絶対数を押し上げます。WordPress本体はコアチームが一元的に品質管理していますが、プラグインとテーマはそれぞれ独立した開発者・企業が作っています。1つのサイトが、開発元も更新頻度もバラバラな数十の部品を組み合わせて動いていることが、次章で見る事例に共通する背景です。これは「WordPressのコードの質が低い」ということではなく、圧倒的なシェアと開放的な拡張エコシステムが持つ、規模ゆえの構造的な特性です。広く使われる拡張可能なプラットフォームであれば、程度の差こそあれ同じ構図が生じます。

03.主要インシデントの年表（2011〜2026）

ここからは、公開範囲・被害規模が大きく、かつ後述する3つのパターンを代表する6つの事例を年表で見ていきます。左側がインシデント名、右側が脆弱性の種類と規模です。

04.プラグイン・テーマに同梱された第三者コードの脆弱性

15年間で最も繰り返されてきたのが、プラグインやテーマの中に組み込まれた第三者コードの脆弱性です。利用者は自分がその部品を使っていることに気づかないまま、被害を受けます。

TimThumb（2011年）

TimThumbは、画像をサムネイル用にリサイズするための小さなPHPスクリプトで、多くのWordPressテーマ・プラグインに同梱されていました。Sucuriによれば、このスクリプトは外部URLからの画像取得先の検証が不十分で、攻撃者が任意のPHPコードを画像ファイルに見せかけてアップロードし、そのまま実行できてしまう脆弱性（CVE-2011-4106）を抱えていました。修正版が公開された後もアップデートされずに放置されたサイトが大量に残っていたことが被害拡大の一因で、被害サイト数は120万を超えました。

深刻だったのは、使っていないテーマ・プラグインの中に眠ったままのTimThumbも攻撃対象になった点です。有効化していないテーマでも、ファイルがサーバー上に存在するだけで攻撃者からアクセスできてしまうため、「使っていないから安全」という思い込みが通用しないことを示した最初の大規模事例でした。

SoakSoak / RevSlider（2014年）

2014年12月には、人気の高いスライダー表示プラグイン「Slider Revolution（RevSlider）」の脆弱性を突いた「SoakSoak」というマルウェアが拡散しました。被害サイトは10万を超え、Googleは日曜の朝だけで1万1千を超えるドメインをブラックリストに登録しました。

この事例が象徴的なのは、脆弱性の修正版自体は2014年2月から存在していたにもかかわらず、10か月後に大規模な被害が出た点です。RevSliderは単体でも販売されていましたが、多くの場合「Avada」など人気テーマの一部として同梱されており、購入者はテーマの中にこのプラグインが含まれていることに気づかないまま、更新の機会を逃していました。パッチが存在することと、そのパッチが実際に適用されることは別問題だと示した事例です。

05.レガシー機能の悪用：XML-RPC pingback（2015年〜）

WordPressには、他サイトからの更新通知や外部アプリからの投稿を受け付ける「XML-RPC」という古い仕組みが標準で有効になっています。2015年、セキュリティ企業Sucuriは、このXML-RPCのsystem.multicall機能を悪用し、1回のHTTPリクエストで数百通りのパスワードを試せてしまう「ブルートフォース増幅攻撃」を報告しました。通常のログイン画面を狙うブルートフォース攻撃を検知するツールでは、この手口を見つけにくいことが問題でした。

このsystem.multicallを使った増幅攻撃そのものは、WordPress 4.4（2015年12月リリース）以降は悪用できなくなっています。ただし、XML-RPCのpingback機能を悪用したDDoS踏み台やSSRF（サーバー側リクエスト偽造）のリスクは、機能自体を無効化しない限り今も残ります。特定のCVE番号を持つ「1回限りの事件」ではなく、使っていない機能を有効なまま放置するリスクを象徴する、息の長い事例です。

06.コア本体で起きた無認証の脆弱性

プラグイン・テーマの脆弱性に比べ、WordPress本体（コア）の脆弱性は発生頻度こそ低いものの、標準構成のサイトすべてが対象になるため、影響範囲が最大級になります。15年間で特に深刻だった2つの事例を見ていきます。

REST APIコンテンツインジェクション（2017年）

2017年1月20日、セキュリティ企業Sucuriのマーク・アレクサンドル・モンパ氏が、WordPress 4.7／4.7.1のREST APIに、ログインなしで任意の投稿・固定ページの内容を書き換えられる脆弱性（CVE-2017-1001000）を発見・報告しました。WordPress公式（Make WordPress Core）によれば、コアチームは1月26日に修正版4.7.2をサイレントリリースしたうえで、Cloudflare・SiteLock・Incapsulaなどのセキュリティ企業やホスティング事業者と連携し、自動更新とWAFでの防御が行き渡るのを待ってから、2月1日に脆弱性の詳細を公表するという判断をしました。

それでも、Sucuriの報告では、詳細公表から24〜48時間のうちに複数の改ざん集団が攻撃を開始し、20の集団によって150万ページを超えるコンテンツが改ざんされました。事前に対策の時間を用意しても、公表後の悪用までの速さを完全には止められなかった点は、後の事例にも共通する教訓です。

wp2shell（2026年）

直近では、2026年7月17日に公表された「wp2shell」があります。REST APIバッチ処理のロジックの誤り（CVE-2026-63030）と、WP_Queryのパラメータを狙うSQLインジェクション（CVE-2026-60137）を連鎖させ、標準構成のサイトでも認証なしでコードを実行できる脆弱性です。CISAは同年7月21日、既知の悪用済み脆弱性（KEV）カタログに両CVEを追加しました。

2017年のREST API脆弱性との違いは、対応のスピードです。2017年は自動更新とWAF対策が行き渡るのを待ってから1週間かけて詳細を公表しましたが、WordPress公式のリリースノートによれば、2026年はWordPress.org側が深刻度の高さから自動更新を即座に強制適用する措置を取りました。仕組み・タイムライン・対応手順の詳細は、以下の記事で解説しています。

07.プラグインの緊急RCE：WP File Manager（2020年）

2020年8月、ファイル管理プラグイン「File Manager」に、CVSSスコア10.0（最高値）の脆弱性（CVE-2020-25213）が見つかりました。Tenableによれば、原因はプラグインが内部で使うオープンソースのファイル操作ライブラリ「elFinder」のサンプルファイルが、実行可能な形式のまま残されていたことでした。認証なしで任意のファイルをアップロードし、そのまま実行できる状態だったため、概念実証（PoC）コードが公開されると、数時間のうちに実際の悪用が始まりました。当時、有効化されているインストールの71.5%が脆弱なバージョンのままだったと報告されています。

TimThumbやRevSliderが「気づかれないまま放置される」問題だったのに対し、このケースは脆弱性の存在と深刻さが広く知れ渡っていたにもかかわらず、パッチ適用が悪用の速さに追いつかなかった事例です。公表から悪用までの時間が、年を追うごとに短くなっている流れを示しています。

08.15年間で変わったこと・変わらないこと

6つの事例を並べると、技術的な中身は変化しても、根底にある構図はほとんど変わっていないことが分かります。

唯一かつ最も重要な不変の教訓は、公表から悪用までの猶予がほとんど無いということです。15年前も直近も、パッチが出てから実際に狙われ始めるまでの時間は数時間〜数日単位でした。次章では、この教訓を日々の運用にどう落とし込むかを整理します。

09.今の運用に活かす教訓

過去の事例から得られる教訓は、突き詰めると「いかに早く、漏れなく更新を反映するか」に集約されます。

これらは特別な技術力を必要とする作業ではなく、「誰が・いつ・どこを確認するか」を運用として決めているかどうかの違いです。この観点をチェックリスト形式でまとめた記事もあわせてご覧ください。

10.よくある質問（FAQ）

11.まとめ

WordPressの脆弱性は、2011年のTimThumbから2026年のwp2shellまで、プラグイン同梱コード・レガシー機能・コア本体と形を変えながら15年間繰り返されてきました。共通するのは、プラグイン・テーマ経由の攻撃が最も多いこと、パッチは公開されるだけでは意味がないこと、そして公表から悪用までの期間が一貫して短いことです。過去の事例が示す教訓は今も色あせておらず、自動更新の有効化・不要な機能や部品の棚卸し・更新反映の目視確認という、地道な運用の積み重ねに帰着します。

こうした運用を自社の体制だけで継続するのは、技術者がいない場合はとくに負担になりがちです。弊社では、AIをフル活用したWordPress運用の保守・監視・改善までを伴走支援しています。