WordPressのセキュリティ危機 — 年間11,334件の脆弱性と「5時間ルール」が示すリスク

数字を改めて整理します。2025年における新規脆弱性の数は11,334件。これを365日で割ると1日31.1件です。2024年の7,966件（1日22件、前年比34%増）から、さらに加速しています（SecurityWeek）。

Patchstackのデータベースには現在、累計で64,782件のWordPress関連脆弱性が蓄積されています。これは長年の「負の遺産」であり、パッチが当たっていない古いサイトはこの膨大な脆弱性プールへの扉を開けたままにしています。

2025年に発見された脆弱性のうち、36%（4,124件）が実際の脅威として評価され、17%（1,966件）が高深刻度（High/Critical）に分類されています。「見つかったからといってすべてが危険ではない」という反論もありますが、1日あたり5〜6件の「高深刻度の新規脆弱性」が生まれ続けているという現実は無視できません。

脆弱性のタイプ別分布を見ると、XSS（クロスサイトスクリプティング）が47.7%と最多で、次いでアクセス制御違反が14.19%、CSRF（クロスサイトリクエストフォージェリ）が11.35%となっています。XSSとCSRFは、サイト訪問者を巻き込む攻撃であり、サイトオーナーだけでなく顧客への被害に直結します。

Patchstackのデータで特に注目すべきは、脆弱性の発生源の内訳です。

• プラグイン：96%
• テーマ：4%
• WordPress本体：0%台

WordPress本体（コア）はセキュリティ面でよく管理されており、本体自体の脆弱性はほとんど発見されていません。問題はエコシステムの構造にあります。

WordPressの強みは豊富なプラグインです。現在、WordPress公式ディレクトリには58,000以上のプラグインが登録されており、さらに数万の有料プラグインが存在します。「ほしい機能はプラグインで実現できる」というエコシステムは、WordPressの普及を支えた最大の要因の一つです。

しかしこの強みが、セキュリティの弱点にもなっています。プラグイン開発者のセキュリティスキルは均一ではありません。小規模な開発者が作ったプラグインが人気を集め、数百万のサイトにインストールされた後、開発者がメンテナンスを放棄するケースも珍しくありません。「人気があるから安全」という前提は成立しません。

平均的なWordPressサイトには20〜30個のプラグインがインストールされています。これは「潜在的な攻撃経路を20〜30個作っている」ことと同義です。セキュリティは最も弱いリンクによって決まります。どれか一つのプラグインに脆弱性があれば、それがサイト全体の弱点になります。

2025年に特に深刻化したのが、脆弱性開示から悪用までの時間の短縮です。

Patchstackの調査によれば、2025年の脆弱性は開示から中央値5時間以内に悪用が始まるケースが報告されています。「パッチが公開されたら更新すればいい」という考え方が機能しない時代になりました。

なぜこれほど速いのでしょうか。脆弱性情報（CVE）が公開された瞬間、攻撃者はその情報を解析してエクスプロイトコードを作成します。そしてWordPressサイトは世界中に何百万も存在するため、自動化されたスキャンツールで脆弱なサイトを大量に特定できます。特定から攻撃までのプロセス全体が自動化されており、人間のオペレーターを必要としません。

WordPressサイトの管理者はメールで「プラグインのアップデートが利用可能です」という通知を受け取ります。しかしその通知を読んで、テスト環境で確認して、本番環境に適用するまでの間に、すでに攻撃が完了しているかもしれません。「パッチを当てる」という行為が、追いかけっこの構造的に不利な側になっています。

「Wordfence」や「Sucuri」「iThemes Security」などのセキュリティプラグインは、WordPressセキュリティの「応急処置」として広く利用されています。これらのプラグインが提供する機能（ファイアウォール、マルウェアスキャン、ログイン試行制限）には一定の価値があります。しかし根本的な問題を解決しているわけではありません。

セキュリティプラグインは「防御の層」を追加するだけ: 攻撃面（プラグインの数と種類）が減るわけではありません。盗難が多い地域で鍵を増やしても、窓の数は変わらないのと同じです。

セキュリティプラグイン自体が脆弱性の対象になる: 皮肉なことに、セキュリティプラグインも脆弱性を持つことがあります。広く使われているセキュリティプラグインに重大な脆弱性が発見された事例は過去に複数あります。「セキュリティを強化するためのソフトウェア」が攻撃経路になるという逆説です。

パフォーマンスへの影響: セキュリティプラグインはサイトのパフォーマンスを低下させる場合があります。速度改善のために別のプラグインを入れ、そのプラグインが新たなセキュリティリスクをもたらす — というコストのスパイラルが生まれます。

本シリーズの記事#3（WordPressの本当のコスト）では、このセキュリティ対策コストがTCO全体にどう影響するかを詳しく解説しています。

OS iXanagiはWordPressと根本的に異なるセキュリティアーキテクチャを採用しています。その核心はBoundary Model（境界モデル）です。

WordPressのセキュリティは「できることをすべて許可し、問題のあるものをブロックする」という「ブラックリスト方式」に近い設計です。対してOS iXanagiは「宣言された操作のみを実行できる」というホワイトリスト方式を採用しています。

Pledge（誓約）とObligation（義務）の仕組み: OS iXanagiでは、システムが実行できる操作はすべてPledgeとして事前に宣言されています。ユーザーやAIエージェントが何かを実行しようとすると、その操作が宣言済みのPledgeに合致するかどうかが検証されます。宣言されていない操作は、そもそも実行できません。

この設計が意味することは明確です。攻撃者がXSSやSQLインジェクションを試みても、その操作はPledgeとして宣言されていないため、カーネルレベルで拒否されます。セキュリティプラグインが「悪意ある操作を検知してブロック」する後手のアプローチとは根本的に異なります。

プラグインに依存しない機能設計: OS iXanagiでは機能追加をプラグインとして外部から取り込む設計をとっていません。代わりに、7つのCore Domain（Demand/Commitment/Fulfillment/Value/Financial/Relationship/Insight）という意味論的な設計で、すべての機能が統合されています。外部コードを取り込む経路そのものが、構造的に制限されています。

fail-closed原則: OS iXanagiの設計原則の一つが「fail-closed」です。何か不明な操作が要求された場合、デフォルトで実行を拒否します。エラーが「とりあえず実行してしまう」ことを防ぎ、セキュリティの境界を維持します。

これはセキュリティを「追加する」のではなく、設計の中に組み込むアプローチです。

Q1. セキュリティプラグインを入れていれば安全ではないのですか？

セキュリティプラグインは有用ですが、それだけでは不十分です。セキュリティの根本的な問題は「攻撃面の広さ」にあり、プラグインを追加するほど攻撃面は広がります。WordPressのセキュリティプラグインは、既知の脅威パターンへの防御は提供しますが、未知の脆弱性（ゼロデイ）や「5時間ルール」のような短いウィンドウ内での悪用には対応が困難です。

Q2. 更新を定期的にしていれば安全を保てますか？

更新は重要ですが、完全な解決策にはなりません。理由は2つあります。第一に、脆弱性が公開されてから悪用開始までが5時間以内という現実では、「定期更新」は間に合わないケースがあります。第二に、更新が互換性の問題を引き起こすことがあり、更新をためらう原因になります。更新しなければ脆弱性が残り、更新すれば別の問題が起きる可能性があるという、どちらに転んでもリスクがある構造です。

Q3. 被害が出てから対応するのでは遅いのですか？

はい、多くのケースでは遅すぎます。まず、サイトへの侵入は即座にビジネス上の損害（顧客データの漏洩、SEOペナルティ、サイトダウン）をもたらします。また、攻撃者がバックドアを仕掛けた場合、侵入の事実に気づかないまま数週間から数カ月が経過することがあります。Googleによってマルウェア配布サイトと判定されてからの信頼回復には、平均で数週間から数カ月を要します。

Q4. WordPressのコアセキュリティは問題ないと聞きましたが？

WordPressのコアコード自体は、専任のセキュリティチームによって比較的よく管理されています。問題はコアではなく、コアの上に乗るプラグインとテーマのエコシステムです。「安全な核心」を「安全でない外側」が覆っている構造と理解してください。コアが安全であることは、プラグインが引き起こすリスクを軽減しません。

Q5. 小規模なサイトでも攻撃ターゲットになるのですか？

はい、むしろ小規模サイトは標的にされやすいです。自動化されたスキャンツールは規模を選ばずに脆弱なサイトを探します。小規模サイトはセキュリティ対策が薄い傾向があり、攻撃のコストパフォーマンスが良いため、踏み台（フィッシングサイトやマルウェア配布）として利用されます。「うちのサイトは小さいから攻撃されない」という認識は誤りです。

御社のサイトは今日も、インストールしたプラグインの数だけ攻撃面が広がっています。

1日31件の新規脆弱性という現実の中で、セキュリティプラグインを追加し続けることは、穴の開いたバケツに水を注ぎ続けることと変わりません。根本的な解決策は、実行できる操作を「宣言されたものだけに限定する」設計にあります。

OS iXanagiのBoundary Modelは、Pledge/Obligationの宣言によって操作の境界をアーキテクチャレベルで定義します。セキュリティは「後から追加するもの」ではなく「設計の核心にあるもの」です。

「御社のAIには、憲法はありますか？」— まずはWordPress移行の診断から始めましょう。

• Patchstack. "WordPress Vulnerability Report 2026." Patchstack Security. 2026.
• SecurityWeek. "WordPress Security Statistics 2024." SecurityWeek. 2024.
• Patchstack. "State of WordPress Security Report 2025." Patchstack Security. 2025.
• WPScan. "WordPress Vulnerability Statistics." WPScan Database. 2025.
• Wordfence. "WordPress Attack Report 2025." Wordfence Intelligence. 2025.
• National Vulnerability Database (NVD). "CVE Statistics 2025." NIST. 2025.
• Kinsta. "WordPress Security: The Definitive Guide 2025." Kinsta Blog. 2025.