CMSのセキュリティ対策とは？リスクや自社の責任範囲も解説

MSのセキュリティ対策とは、Webサイトを構築・更新するためのシステムであるCMS（コンテンツ管理システム）を、不正アクセスや改ざん、情報漏えいから守るための取り組み全般を指します。サーバーやネットワークを守る対策と混同されがちですが、CMSの対策は、アプリケーション層に加えて、その土台となるサーバーや周辺ソフトの管理までを含みます。

「WordPressは危ないと聞くが、具体的に何が危ないのか分からない」「クラウド型のCMSに移せば安心なのか判断がつかない」という声は、Webサイトの運用に関わる方から多く聞かれます。CMSのセキュリティが難しいのは、対策の項目数が多いことよりも、どの穴を誰が塞ぐのかが見えにくいことにあります。

この記事では、CMSが狙われる理由、脆弱性が潜む5つの場所、実際の被害、CMSの種類別の責任範囲を解説。さらに、優先順位を付けた対策手順や確認項目、CMS選定時に確認する基準をご紹介します。

CMSのセキュリティ対策が必要な理由

CMSが攻撃の対象になりやすいのは、利用しているサイトが多いことと、攻撃者にとって効率の良い標的であることの2点に理由があります。前者はCMSの普及状況、後者は攻撃者側の事情からくるものです。

Webサイトの多くがCMSで作られている

Web技術の利用状況を継続調査している民間統計サイトW3Techsによると、2026年9月時点でWebサイト全体の40.7%がWordPressで構築されています。CMSを利用しているサイトに限れば、WordPressの割合は58.9%です（※1）。つまりCMS、とりわけWordPressは、世界中のWebサイトの共通基盤といえる存在です。

国内でも状況は同じです。同じW3Techsの集計では、日本語のWebサイトのうちCMSが判明しているものの82.9%をWordPressが占めています。大阪商工会議所も、国内のホームページの約8割がWordPressで作られているといわれると説明しています（※2）。企業の規模や業種を問わず、同じソフトウェアで動くサイトが大量に存在している状態です。

攻撃者にとって効率の良い標的になっている

同じソフトウェアが大量に使われていると、ひとつの脆弱性が見つかったとき、その穴を突く手口を大量のサイトに使い回せます。脆弱性とは、ソフトウェアの設計や実装上の欠陥で、攻撃に悪用される恐れがある弱点のことです。特定の企業を狙い撃つ攻撃もありますが、CMSを対象とした攻撃の多くは、自動化したプログラムで脆弱なサイトを手当たり次第に探す形で行われます。

オープンソース型のCMSは、ソースコードが公開されているため、攻撃者も内部の仕組みを調べられます。さらにプラグインと呼ばれる拡張機能は、CMS本体とは別の開発者が作っています。開発者ごとに品質や更新頻度にばらつきがあり、本体が安全でもプラグインが侵入口になるケースが後を絶ちません。

そのため、企業の規模は攻撃を受けるかどうかにほとんど関係しません。攻撃は自動化され、脆弱なサイトを手当たり次第に探しているからです。「うちは小さな会社だから狙われない」という前提は成り立ちません。

※1　参考：W3Techs│「Usage statistics and market share of content management systems」
※2　参考：大阪商工会議所│「大阪商工会議所・立命館大学『無料セキュリティ診断』第2弾！ ホームページ改ざんの危険性を無償診断！」

CMSのセキュリティリスクが潜む5つの場所

CMSの脆弱性は、本体、プラグインやテーマ、管理画面とアカウント、自社固有の実装や設定、サーバーや周辺ソフトウェアの5つの場所に分かれて存在します。場所ごとに攻撃の手口が異なり、塞ぐ方法と塞ぐ担当者も変わってきます。

CMS本体の公開済み脆弱性

CMS本体の脆弱性は、開発元やセキュリティ機関から公表され、修正版が配布されます。公表された脆弱性の多くにはCVEという世界共通の識別番号が付き、日本ではJPCERT/CCとIPAが運営するJVNというデータベースで日本語の情報が確認できます（※3）。公表と同時に攻撃の手口も広まるため、修正版を適用するまでの期間が最も危険です。

代表的な攻撃手口には、データベースを不正に操作するSQLインジェクションや、閲覧者のブラウザで不正なスクリプトを実行させるクロスサイトスクリプティングがあります。どちらもIPA（独立行政法人情報処理推進機構）が「安全なウェブサイトの作り方」で長年注意を促してきた、Webアプリケーションの基本的な弱点です（※4）。

2026年7月には、IPAがWordPress本体のふたつの脆弱性について注意喚起を出しました。組み合わせると管理者権限などを要さずに遠隔からコードを実行される可能性があり、影響を受けるサイトには直ちに更新するよう求めています（※5）。この組み合わせによる遠隔からのコード実行の影響を受けるのは、WordPress 6.9.0から6.9.4と7.0.0から7.0.1で、修正版は6.9.5と7.0.2です。6.8.0から6.8.5は、2件のうちCVE-2026-60137のみの影響を受け、修正版として6.8.6が公開されています。6.8より前のバージョンは影響を受けないとされています。

この攻撃手法は「wp2shell」と呼ばれ、実証コードが公開されているほか、2026年7月21日（現地時間）には米国CISAの「悪用が確認された脆弱性カタログ（KEV）」にも掲載されました（※6）。WordPress.orgは影響を受けるバージョンに対して自動更新による強制更新を有効化しています。本体の脆弱性は、修正版が出た時点で対応の期限が始まると考えてください。

プラグインやテーマの脆弱性

プラグインとテーマは、CMS本体とは別に脆弱性を抱えています。開発者が個人や小規模チームであることも多く、脆弱性が見つかっても修正版が出ない、あるいは開発自体が止まっているプラグインも存在します。本体を最新にしていても、古いプラグインがひとつ残っていれば、そこが侵入口になります。

テーマも同じです。購入したテーマを制作会社が改修して使っている場合、改修部分は公開情報がなく、開発元の更新も当てはまりません。この部分は、次に示す自社固有の実装と同じ扱いになります。

管理画面とアカウントの弱さ

管理画面への不正ログインは、脆弱性を突かなくても成立する攻撃です。推測しやすいパスワード、外部から確認できるユーザー名、多要素認証の未設定が重なると、総当たり攻撃でパスワードを特定されます。多要素認証とは、パスワードに加えてスマートフォンの認証アプリなど別の要素でも本人確認をする仕組みです。

2025年には、体育器具メーカーの三英が、運用するCMSへの総当たり攻撃でパスワードを特定され、不正アクセスを受けました。同社の公表によると、問い合わせフォームに寄せられていた顧客の氏名や住所、電話番号、メールアドレスなどが流出した可能性があります（※7）。特別な攻撃技術ではなく、ログインの弱さだけで被害が成立した事例です。

自社固有の実装や設定の不備

問い合わせフォームのカスタマイズ、独自に作った会員機能、ファイルアップロードの設定、公開したまま放置された検証環境は、いずれも自社だけに存在する穴です。世界中で共有される脆弱性情報には載らず、CMSやプラグインを更新しても直りません。

この種の穴は、CMSやプラグインの更新では塞げず、外部から実際にサイトを調べる脆弱性診断や、ソースコードのレビューによって見つけるほかありません。CMSのセキュリティ対策を「アップデートすること」と理解していると、この領域が丸ごと抜け落ちます。公開済みの脆弱性は更新で塞ぎ、自社固有の脆弱性は診断で見つける、というふたつの層で考えてください。

サーバーや周辺ソフトウェアの更新漏れ

CMSはPHPなどのプログラミング言語やデータベース、Webサーバーソフトの上で動いています。これらのサポートが終了したバージョンを使い続けると、CMS側がいくら最新でも土台に穴が残ります。レンタルサーバーを利用している場合、PHPのバージョンは管理画面から確認と変更ができることが多いので、一度確認してみてください。

※3　参考：JPCERT/CC・IPA│「JVN（Japan Vulnerability Notes）」
※4　参考：IPA│「安全なウェブサイトの作り方」
※5　参考：IPA│「WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030：wp2shell)」
※6　参考：CISA│「Known Exploited Vulnerabilities Catalog」
※7　参考：株式会社三英│「個人情報漏洩の可能性に関するお詫びとご報告」

詳細はこちら

CMSが攻撃を受けたときに起こる被害

CMSへの攻撃が成功すると、Webサイトの改ざん、個人情報の漏えい、サイト停止と取引先への波及という3種類の被害が起こります。どれかひとつで済むとは限らず、改ざんから漏えいへ、漏えいから取引停止へと連鎖する点に注意が必要です。

Webサイトの改ざん

改ざんは、サイトの内容を攻撃者が書き換える行為です。2025年8月、東京外国語大学は、附属研究所が研究業績の公開用に管理していたWebサーバの一部サイトが改ざんされていたことを確認し、同年9月19日に公表しました。

同大学の公表によると、原因はCMSの脆弱性を悪用した不正アクセスで、該当サイトにアクセスするとオンラインカジノのサイトへ誘導される状態になっていました（※8）。改ざんの影響が考えられる期間は2025年6月5日から8月8日までの約2か月間で、発覚まで相当の時間が経過していました。

改ざんには、見た目が変わらないものもあります。訪問者を別サイトへ飛ばすスクリプトや、不正なプログラムを配布する仕掛けを目立たない場所に埋め込む手口です。運営者が気付かないまま、自社サイトが訪問者を攻撃する加害者の側に回ります。検索エンジンから危険なサイトと判定され、検索結果に警告が表示されることもあります。

個人情報の漏えい

問い合わせフォームや採用応募フォームを設置しているサイトには、送信された個人情報がCMS内やデータベースに保存されています。三英の事例のように、管理画面に侵入されれば、その履歴が丸ごと持ち出される形です。会員機能やEC機能があるサイトでは、被害の範囲はさらに広がります。

サイバー攻撃による個人データの漏えいは、不正の目的をもって行われたおそれがある行為による漏えい等にあたるため、件数の多寡にかかわらず、個人情報保護委員会への報告と本人への通知の対象になります（※9）。報告は2段階で、速報は事態を知ってから概ね3〜5日以内、確報は不正の目的による場合は60日以内に求められます。対応にかかる工数と費用は、対策にかかる費用を大きく上回るのが通例です。

サイト停止と取引先への波及

被害の調査と復旧の間、サイトは停止します。問い合わせや採用応募の窓口が止まるだけでなく、サイト経由で商談を得ている企業では売上に直結します。データを消されて復旧できない場合、蓄積してきたコンテンツと検索順位も失います。

自社サイトが踏み台になり、取引先へ攻撃が及ぶ形をサプライチェーン攻撃と呼びます。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの脅威の第2位に「サプライチェーンや委託先を狙った攻撃」が挙げられています（※10）。取引先から見れば、自社は被害者ではなく攻撃の入口であり、取引の見直しにつながります。

※8　参考：東京外国語大学│「本学ウェブサイトの改ざんに関するお詫び」
※9　参考：個人情報保護委員会│「漏えい等報告・本人への通知の義務化について」
※10　参考：IPA│「情報セキュリティ10大脅威 2026」

CMSの種類別に見る自社の責任範囲

CMSはオープンソース型、商用パッケージ型、クラウド型の3種類に分かれ、種類によって自社が担う範囲が変わります。ただし、どの種類を選んでもアカウント管理と自社固有の実装は自社の責任として残る点は共通です。クラウド型なら何もしなくてよい、という理解が事故の原因になります。

オープンソース型は自社か委託先がすべてを担う

WordPressやDrupalなど、無償で使えるオープンソース型は、本体の更新からサーバーの管理まで、すべてを利用者が担います。WordPressの場合、初期設定で自動更新の対象になるのはマイナーリリース（メンテナンスとセキュリティのための更新）と翻訳ファイルのみで、メジャーバージョンの更新は既定では無効です。

また、運用している環境や設定によっては自動更新が有効になっていない、あるいは失敗している可能性もあるため、IPAも管理画面での確認と手動更新の検討を求めています。制作会社に保守を委託している場合、委託先が担っている範囲を契約書で確認してください。「サイトの保守」という言葉に、プラグインの更新や脆弱性への対応が含まれているとは限りません。

商用パッケージ型はサポートがあっても運用は自社

有償で販売されるパッケージ型は、開発元から修正版の提供とサポートを受けられます。一方で、自社サーバーに導入して運用する形態が多く、修正版を適用する作業やサーバーの管理は自社の仕事です。開発元がいくら早く修正版を出しても、適用が遅れれば意味がありません。

クラウド型でもアカウントとコンテンツは自社の責任

サービスとして提供されるクラウド型は、本体の更新やサーバーの管理を事業者が担います。このように、事業者と利用者で責任を分け合う考え方を責任共有モデルと呼びます。それでも、ログイン情報の管理、利用者ごとの権限設定、公開するコンテンツやフォームの設定は自社の責任です。

総務省のガイドラインも、責任の範囲や内容は一律に決まるものではなく、サービスの内容や利用条件ごとに両者で合意し、契約で明示することが重要だとしています（※11）。契約時に事業者の責任範囲を文書で確認しておくことが、あとの認識違いを防ぎます。

表の「自社または委託先」の欄は、誰が担うのかを自社で決めて契約に落とし込む必要がある項目です。決まっていない項目は、実質的に誰も担っていない状態になっています。

※11　参考：総務省│「クラウドサービス提供における 情報セキュリティ対策ガイドライン（第３版）」

CMSのセキュリティ対策を優先順位で進める手順

CMSの対策は、今日から始められる管理画面と権限の見直し、1か月以内に決める更新ルールと通信の保護、体制として整える脆弱性情報の収集と診断、という3段階で進めると無理がありません。すべてを同時に始めようとして手が止まるより、段階を分けて着実に進める方が結果的に早く進みます。

今日から始める管理画面と権限の見直し

最初に手を付けるのは管理画面です。パスワードは推測されにくい長いものに変え、多要素認証を有効にしてください。ログインの試行回数を制限する機能や、管理画面へのアクセスを社内や委託先のIPアドレスに限定する設定も、多くのCMSやサーバーで利用できます。

アカウントの棚卸しも今日できる作業です。退職者や過去の制作会社のアカウントが残っていないか、管理者権限を持つ人が必要以上に多くないかを確認します。使っていないプラグインは無効化ではなく削除してください。無効化しただけではファイルが残り、攻撃の対象になり得るからです。

バックアップの有無と保存場所の確認も、この段階に含まれます。サーバーと同じ場所にしか保存されていない場合、サーバーごと侵害されると復旧できません。

あわせて、どの時点まで遡れるかも確認してください。改ざんが数か月間気付かれない例があるように、直近のバックアップがすでに改ざん後の状態になっていることがあります。世代をいくつ保持しているかまで見ておく必要があります。

1か月以内に決める更新ルールと通信の保護

次に、CMS本体、プラグイン、PHPの更新を誰がいつ行うかを決めます。更新の通知を誰が受け取り、検証環境で確認してから本番に適用するまでの流れを文書にしておくと、担当者が変わっても続きます。更新でサイトの表示が崩れる不安から適用を先延ばしにする例が多いため、検証環境の用意が更新を止めないための条件です。

通信の暗号化は、すべてのページと管理画面がhttpsになっているかを確認します。あわせて、WAFの導入を検討してください。WAFはWebアプリケーションへの通信を監視し、既知の攻撃パターンに一致する通信を遮断する仕組みです。修正版を適用するまでの間の防御として有効ですが、未知の手口や自社固有の実装の欠陥をすべて防げるわけではありません。WAFを入れたから更新や診断は不要、という判断は避けてください。

体制として整える脆弱性情報の収集と診断

最後に、継続的な体制を整えます。脆弱性の情報は、JVNや利用しているCMSの公式のセキュリティ告知、プラグインの更新通知から入手できます。情報を受け取ったあとは、深刻度を示すCVSSスコアと、実際に攻撃に悪用されているかどうかを見て、対応の優先順位を決めます。悪用されているかどうかは、米国CISAが公開する「悪用が確認された脆弱性カタログ（KEV）」で確認できます。

公開済みの脆弱性は、この情報収集と更新で対応できます。一方、脆弱性が潜む場所のうち、自社固有の実装や設定の穴は外部からの診断でしか見つかりません。診断には、ツールによる自動診断と専門家による手動診断があります。自動診断は既知のパターンの検出には向いていますが、問い合わせフォームの業務的な処理や権限の設計上の欠陥は、画面の意味を理解しなければ検出できません。この領域は、専門家が実際に操作して確かめる手動診断の役割です。

診断の頻度に公的な基準はありません。ただし、実施の間隔だけで考えるのは現実に合わなくなってきています。前述のwp2shellのように、公表から実証コードの公開、実際の悪用までが数日で進む事案が増えているためです。

現実的なのは、期間と出来事の両方を引き金にする運用です。サイトの改修やCMSの大型バージョンアップ、フォームや会員機能など入力を受け付ける仕組みの追加といった変更のたびに診断を行い、そのうえで変更がない期間についても定期的に実施します。この2つを組み合わせると、変更に起因する穴と、時間の経過で顕在化する穴の両方に対応できます。

あわせて、被害を検知したときの連絡先と初動の手順を決めておいてください。

費用の目安は相対的な比較であり、具体的な金額はサイトの規模や委託先によって変わります。

自社のCMSの現状を確かめる10の確認項目

自社のサイトがいまどの状態にあるかは、10の項目で確認できます。大阪商工会議所と立命館大学が2023年に行った共同調査では、WordPressで作られた中小企業等のホームページ192件のうち、ユーザーリストとログインページの双方が外部から見える状態になっていたものが66%を占めました（※12）。ユーザーリストとは、サイトの管理や編集ができるユーザーの情報のことです。このふたつが見えていると、総当たり攻撃の前提となるユーザー名と入口の両方を攻撃者に渡していることになります。

該当しない項目が3つ以上ある場合は、制作会社や保守委託先に現状を尋ねるところから始めてください。項目2や項目10のように自社だけでは確認しにくいものは、診断を受ける理由として委託先に伝えると話が進みやすくなります。WordPressを利用している場合は、より細かい18項目のチェックリストを次の記事で確認できます。

関連記事：WordPress脆弱性診断｜自社サイトの対策漏れを見つける18項目チェックリスト
※12　参考：大阪商工会議所・立命館大学│「中小企業等のホームページ脆弱性診断 調査結果」

セキュリティの観点でCMSを選ぶときに確認する点

リニューアルでCMSを選ぶときは、更新と告知の状況、標準で備わる防御機能、責任範囲の明文化の3点を、ベンダーへの質問という形で確認します。機能の一覧表だけでは、運用が始まってからの負担は見えてこないからです。

更新と告知については、セキュリティに関する修正版がどの程度の頻度で出ているか、脆弱性が見つかったとき利用者にどう知らせるかを尋ねます。修正版は出ていても告知が公式サイトの片隅にしかない製品では、情報を見逃します。

あわせて、各バージョンのサポート期間と、終了時期をどれくらい前に告知するかも確認してください。サポートが終了したバージョンには修正版が出ないため、この記事で挙げたサーバーや周辺ソフトの更新漏れと同じ状態が、CMS本体で起きることになります。

防御機能については、多要素認証、利用者ごとの権限設定、操作ログの記録が追加費用なしで使えるかを確認してください。あとからプラグインで補う前提の製品は、そのプラグインが新たな穴になります。

責任範囲については、事業者が守る範囲と自社が守る範囲を書いた文書があるか、脆弱性診断を受ける場合に事業者の許可や手続きが必要かを聞いておきます。クラウド型では、利用者が勝手に診断できない契約になっていることがあり、契約前に知っておく必要があります。

まとめ：CMSのセキュリティ対策は責任範囲の把握から始まる

CMSのセキュリティ対策で押さえるべき点は3つです。脆弱性は本体だけでなく、プラグイン、管理画面、自社固有の実装、サーバーの5か所に分かれて存在すること。どの種類のCMSを選んでも、アカウントと自社固有の実装は自社の責任として残ること。公開済みの脆弱性は更新で塞げるが、自社固有の脆弱性は専門家による診断でしか見つからないことです。

次の一歩として、10の確認項目を埋め、該当しなかった項目について委託先と役割分担を話し合ってください。その話し合いの中で「自社のサイトに固有の穴があるかどうか分からない」という結論に至ったら、それが脆弱性診断を受ける時期です。ユービーセキュアでは、専門の診断員が実際にサイトを操作して弱点を確かめる手動の脆弱性診断とペネトレーションテストを提供しています。CMSで構築したサイトの診断についても、まずはご相談ください。