セキュリティ最前線
WordPressの脆弱性と、CMSの選び方 — なぜ自治体・公的機関は「WordPress」を調達仕様書で排除するのか
著者：青山裕一（株式会社ガーディアン 代表取締役社長）
公開日：2026年10月20日
問題は「オープンソースかどうか」ではなく「誰が、どの頻度で、どう直すか」です。WordPressの脆弱性の7つのポイントと、自治体・公的機関が調達仕様書でWordPressを排除する理由を、一次資料から読み解きます。
この記事の要点
WordPressが狙われるのは品質が低いからではなく、シェア×プラグイン×運用者の掛け算による。2025年の新規脆弱性は11,334件で91%がプラグイン由来、悪用が確認された脆弱性は公開から悪用まで加重中央値5時間。問題はオープンソースかどうかではなく、誰が、どの頻度で、どう直すか。
この記事は、総合解説「サプライチェーン攻撃の起点は中小企業にある」の第8章・第9章を、独立したページにしたものです。
WordPressの脆弱性のポイントと、被害実績が多い理由、その危険性
WordPressは「世界で最も使われ、世界で最も攻撃されているCMS」です。2025年に新たに発見されたWordPress関連の脆弱性は11,334件。前年比42%増で、その91%がプラグイン由来です（Patchstack State of WordPress Security 2026）。私は15年間、クローズドソースの自社CMSでサイトを運用し（2026年10月時点で76,325サイト）、CMS・サーバー側の脆弱性を起点とする改ざん・侵入・情報漏えい事故を確認していません（当社が構築・運用するサイトを対象とした当社インシデント記録に基づく集計。過去の実績であり、将来の安全を保証する数値ではありません）。その立場から、WordPressの構造的な弱点を整理します。
数字で見るWordPress
| 指標 | 数値 | 出典 |
|---|---|---|
| 全世界のウェブサイトに占める割合 | 約43%（CMS利用サイトの59.8%） | W3Techs（2026年1月） |
| 日本語CMSサイトに占める割合 | 82.8% | W3Techs資料を基にした集計（2024年） |
| 日本のCMS利用サイトに占める割合（別集計） | 96.5%（201,355サイト調査） | wmtips（2026年10月7日集計） |
| 2025年の新規脆弱性 | 11,334件（前年比42%増）、うちプラグイン91%、コアは6件 | Patchstack 2026 |
| 高深刻度の割合 | 1,966件（17%） | 同上 |
| 公開時点で修正パッチがなかった割合 | 46% | 同上 |
| 悪用が確認された脆弱性の、公開から悪用までの時間（Patchstackの観測に基づく加重中央値。全脆弱性の平均ではない） | 加重中央値5時間。影響の大きい脆弱性の約半数が24時間以内に悪用 | 同上 |
| 従来型防御（ホスティングのWAF等）の遮断率 | 既知悪用済み脆弱性に対して12%、広範テストでは26% | 同上 |
| 無料プラグインの数 | 61,000以上 | WordPress.org |
脆弱性の7つのポイント
- プラグインが「穴」の91%を占める。本体（コア）は堅牢ですが、サイトの機能はプラグインで作ります。開発者は個人や小規模チームが多く、開発が止まったプラグインは脆弱性が永久に残ります。
- ソースコードが公開されている。防御側も攻撃側も同じコードを読めます。修正パッチの差分から攻撃コードを逆算するのが常套手段で、悪用が確認された脆弱性では公開から悪用までの中央値が5時間という観測につながっています。
- 管理画面の場所が全世界共通。/wp-login.phpと /wp-admin/ が初期設定のまま公開されているサイトは多く、当社調査では中小企業の38.6%がログイン情報を露出していました。
- ユーザー名が外から列挙できる。REST APIや投稿者アーカイブから管理者のIDが取得でき、あとはパスワードを総当たりするだけです。
- 更新すると表示が崩れる。テーマやプラグインの互換性問題を恐れ、制作会社が「更新しないでください」と案内する例が実際にあります。その瞬間、そのサイトは永久に脆弱になります。
- 公開サーバーに管理画面とデータベースが同居する。動的CMSの宿命です。管理画面が破られれば、その場で改ざん・DB閲覧・バックドア設置ができます。
- 責任の所在がない。オープンソースは「無保証」です。制作会社は納品で責任を終え、ホスティング会社はアプリ層に責任を負わず、運用者である中小企業が全責任を負います。
被害実績が多い理由 — 「シェア×プラグイン×運用者」の掛け算
WordPressが危険なのは、ソフトウェアの品質が低いからではありません。日本のCMSサイトの8割以上を占めるため、自動スキャナは「WordPressだけを狙えばよい」。プラグインが6万あるため、「毎日どこかに新しい穴が開く」。そして運用者の多くはセキュリティの専門家ではないため、「穴が開いたまま数か月放置される」。この3つの掛け算が、被害実績の多さを生んでいます。
2026年の事例一覧では、学研メディカルサポートがWordPressの脆弱性の悪用を公表しています。まちあい徳山は、更新されていなかったプラグインの脆弱性が原因と自社で説明しています。それ以外の事例は、公表資料に侵入原因としてWordPressが記載されていない限り、WordPress起因の被害とは扱っていません。公表資料のURLにWordPressの痕跡があることと、WordPressが侵入口であったことは別だからです。
危険性 — ホームページの事故で終わらない
WordPressの管理者権限を奪われた後に起きることは、改ざんだけではありません。問い合わせフォームの顧客情報窃取（ナカバヤシREVEX で3,631件）、採用応募情報の漏えい（セントラルコンサルタント）、フィッシングサイトの設置、サーバー内部への侵入と横展開、そして取引先への踏み台化。ホームページと基幹システムが同じサーバーにある中小企業では、WordPressの穴がそのままランサムウェアの入り口になります。
当社がクローズドソースの独自CMS「OWLet」を採用している理由は、この掛け算を成立させないためです。ただし、コードが公開されていないこと自体は安全の根拠になりません。当社が重視しているのは、第三者プラグインを入れない構成、管理画面の非公開、更新・監視・復旧を当社が担う責任分担です。15年間の無事故（当社集計）はこの運用の結果であり、将来を保証するものではありません。
なぜ自治体・公的機関・金融機関は、RFPで「WordPress」を排除するのか
公共性の高い組織の調達仕様書には、「オープンソースのCMSは不可とする」「WordPress等のツールは使用できない」という条項が実在します。ただし、その理由を一次資料で確かめると、「WordPressが危険だから」という単純な話ではなく、「継続的なアップデートを自前で回せない」「ベンダーの責任がない」「公開サーバーに管理機能を置きたくない」という構造への拒否であることが分かります。ここでは実在の仕様書と、それに対する公正取引委員会の見解の両方を示します。
本章で示す仕様書は、いずれも個別の調達における条項であり、自治体・公的機関全体の統一方針ではありません。金融機関については、WordPressを名指しで排除する公開の調達仕様書を確認できていません。金融庁ガイドラインが求めるパッチ期限・EOL管理・診断の水準を、プラグインに依存する無保証のソフトウェアで満たすのが難しい、という間接的な根拠にとどまります。
一次資料で確認できる「排除」の実例
| 発注機関・資料 | 条項（原文） | 資料が示す理由 |
|---|---|---|
| 中讃広域行政事務組合「ホームページ更新業務委託仕様書」（令和8年6月） | 「導入するCMSは、パッケージ（市販）化されたもので、開発ベンダーによるサポートが確立された製品であること。」「オープンソースのCMSは不可とする。」（3.2.1）「原則として、生成されるコンテンツは、すべて静的なものとする。」（3.2.2） | ベンダーサポートの確立、静的生成、脆弱性発見時のパッチ適用を受託者責任とする（6.1.1） |
| 横浜MICEサイト「CMS構築メモ」（令和4年7月12日） | 「継続的なアップデートが必要なMovable TypeやWordpressなどオープンソースのCMSは不可とします。」 | 継続的なアップデートが必要であること（名指しでWordPressを排除） |
| 沖縄総合事務局 北部国道事務所ホームページリニューアル特記仕様書（平成31年2月） | 「PHPやSQL等データベースは使用不可サーバーであるため、WordPress等のツールは使用できない。」 | 公開サーバーでPHP・DBを動かさないサーバー環境（名指しでWordPressを排除） |
| デジタル改革アイデアボックスへの投稿（2021年） | 「官公庁や地方自治体が仕様書に『オープンソースCMSを禁止』する文言を禁止するべき」 | 排除条項が広く存在することの傍証 |
根拠1：遵守すべき基準が「追従できない速度」を要求している
金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月4日）は、「システムの重要度、リスク又は脆弱性の深刻度に基づいたパッチ適用等の対応期限を設定」し、「プラットフォーム診断に加え、ウェブアプリケーション診断も実施」し、ハード・ソフトの台帳に「サポート終了予定日」を含め、SBOM（ソフトウェア部品表）の整備を求めています（金融庁）。経産省のSCS評価制度★3も「サポート中の製品のみ使用」「重大な脆弱性は公開後14日以内に適用」を求めます（★3要求事項4-4-4 の解説）。
61,000のプラグインが個々に更新され、脆弱性の46%がパッチなしで公開され、悪用された脆弱性の中央値が公開から5時間という環境で、「対応期限」「EOL管理」「SBOM」を守るのは、専任担当のいない組織には構造的に困難です。自治体も同様で、総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」（令和7年3月28日改定）と政府機関等の統一基準群に沿った脆弱性管理と改ざん対策が求められます（総務省）。
根拠2：責任の所在が説明できない
公的調達は「事故が起きたとき、誰が責任を負うか」を説明できなければなりません。中讃広域行政事務組合の仕様書が「開発ベンダーによるサポートが確立された製品」を求め、「CMSライセンス証書」の提出を求めているのはそのためです。官公庁・自治体の調達では、ライセンスの形態とサポート体制を明示でき、修正プログラムをベンダーが一元的に提供できる製品が選ばれやすいと解説されています（官公庁・自治体におけるCMS選定理由の解説）。
根拠3：公開サーバーに管理機能を置かないという設計思想
中讃の「静的なものとする」、北部国道事務所の「PHPやSQL等データベースは使用不可サーバー」は、いずれも「公開サーバーにはHTMLしか置かない」という思想です。象徴的なのはIPA自身の調達資料です。IPAのIMIサイトは内部CMSとしてWordPressを使っていますが、「CMSを直接公開はしていない」。社内環境でWordPressから静的HTMLを生成し、SFTPでDMZの公開Webサーバへ配置し、CMSサーバとDBサーバはイントラネット内でのみ管理しています（IPA IMIサイト運用・保守 入札説明書2026年2月2日、17～18ページ）。つまり公的機関の答えは「WordPressを使うなら公開サーバーに置くな」です。中小企業の標準的なWordPress構成は、この思想と正反対です。
根拠4：被害の「前例」が多すぎる
プラグインや本体の脆弱性を突いた大量改ざんは2017年のREST API脆弱性（JPCERT/CC・IPAが注意喚起、国内でも複数被害）以来、毎年繰り返されています（ScanNetSecurity）。2026年も学研メディカルサポート、まちあい徳山（同社は更新されていなかったプラグインの脆弱性が原因と自ら説明）の事例があります（まちあい徳山の解説記事）。調達担当者が前例のあるリスクを避けるのは合理的な判断です。
反対意見も示します — 公正取引委員会の見解（2022年6月30日）
公正取引委員会は、オープンソースではないCMSを情報セキュリティ対策上必須とする仕様書案を市町村に配付した2社の行為を、独占禁止法違反の疑いとして確約手続に付しました。そのうえで、「使用するソフトウェアがオープンソースソフトウェアであるか否かにかかわらず、適切に管理されたソフトウェアを使用して情報システムを構築すること及び構築後、使用するソフトウェアを最新版にアップデートしておくこと等の脆弱性を解消する運用・保守が欠かせない」「情報セキュリティ対策からオープンソースソフトウェアではないＣＭＳとしなければならない理由はない」との考えを示しました（違反認定ではありません。公正取引委員会）。
私はこの見解に同意します。問題は「オープンソースかどうか」ではなく「誰が、どの頻度で、どう直すか」です。WordPressを排除する仕様書の本当の意味は、「それを自前で回せる体制がない組織は使うな」です。IPA調査では、中小企業の約7割に組織的なセキュリティ体制がありません。
根拠5：サプライチェーン評価制度が「取引先の対策水準」を可視化する
経済産業省の「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」は、★3（専門家確認付き自己評価、26項目・81件）・★4（第三者評価、43項目）を発注者が取引条件として指定することを想定し、2027年1～3月頃の申請受付開始を予定しています（経産省 制度ページ、IPA FAQ）。★4の技術検証は「インターネット公開機器の脆弱性診断」です。一部の公的機関が仕様書で排除してきた「更新を自前で回せない構成」が、これからは一般企業の取引条件でも問われます。
中小企業への示唆
公的機関の一部が「自前で回せないものは使わない」と決めたものを、その取引先である中小企業が無防備に使っている。このギャップが、サプライチェーンの「最も弱い環」を作っています。WordPressを使い続けるなら、公的機関の仕様書や金融庁ガイドラインが求める水準の更新・診断・分離運用（理想はIPAと同じ「内部CMS＋静的HTML公開」）を自社で負う覚悟が必要です。それが難しいなら、CMSそのものを変えるか、少なくとも「今、穴が開いているか」を第三者に定期的に見てもらうべきです。
あなたの立場に合わせた、次の一歩
自社サイトの「今」を知ることが第一歩です。立場に合わせてお選びください。
あわせて読みたい
出典一覧（クリックで開く）
※統計の数値は各出典の公表時点のものです。
