不安を煽るCMS移行の提案に惑わされず、本当に確認すべきこと
2026年10月21日、WebサイトやWebサービスで広く利用されているプログラミング言語「PHP」に、重大な脆弱性が公表されました。
今回公表された2件の脆弱性（CVE-2026-109618、CVE-2026-109619）は、その組み合わせが「PHP2Shell」と呼ばれており、悪用された場合、外部から不正なプログラムを実行される可能性があります。
PHP開発元をはじめ、IPA（情報処理推進機構）やJPCERT/CCなどのセキュリティ関連機関も、影響の確認と速やかな対策を呼びかけています。
まず、この問題は決して軽視してよいものではありません。
一方で、こうした問題が発生すると、必ずと言ってよいほど見られるのが、不安や危機感に訴えるサービスの販売促進です。
30年近くWeb業界に携わってきた経験からも、大きなセキュリティ問題や技術的な変化が起こるたびに、同じような動きを見てきました。
例えば、「WordPressは危険だから、別の高額なCMSに変更すべき」といった提案です。
もちろん、システムの刷新やCMSの移行が必要な場合もあります。しかし、十分な説明のないまま、特定の技術や製品を危険だと断定し、別のサービスへの移行を勧めることには注意が必要です。
今回の記事は、大規模なシステムや専任の管理担当者を持たず、日々の事業活動の中でWebサイトを運営している企業や個人事業主の皆様に向けたものです。
■ 問題はWordPressだけにあるのでしょうか
今回の問題は、WordPressそのものの脆弱性ではなく、PHPというプログラミング言語の実行環境に関わるものです。
PHPを使用するシステムであれば、WordPress以外のCMSや独自開発のWebアプリケーションでも影響を受ける可能性があります。
つまり、WordPressを別のPHP製CMSに変更しただけでは、今回の脆弱性に対する根本的な対策にはなりません。
一方、PHPを使用しないCMSや、静的なHTMLを公開する仕組みなどは、今回のPHPの脆弱性による直接的な影響を受けない構成にできます。
ただし、PHPを使用しないことが、Webサイト全体の安全性を保証するわけではありません。
CMSによってセキュリティ上の特徴やリスクが異なることは事実です。しかし、それだけで製品の優劣を決められるものではありません。
重要なのは、そのシステムがどのような環境で動き、どのように管理・保守されているのかということです。
■ Movable Typeでも2026年10月に重大な脆弱性が公表されています
WordPressとは異なる仕組みを持つCMSの例として、「Movable Type」があります。
Movable Typeは、静的なHTMLファイルを生成できることが特徴の一つで、PHPを使用しない構成でWebサイトを運営することも可能です。
静的HTMLを公開する構成では、閲覧者からのアクセスのたびにCMSのプログラムを実行する必要がないため、動的なWebサイトとは異なるセキュリティ上の利点があります。
しかし、Movable Typeについても、2026年10月7日に重大な脆弱性が公表されています。
今回公表された主な脆弱性は、以下の2件です。
- CVE-2026-96408：アップグレード用プログラム（mt-upgrade.cgi）において、外部から不正なコードやSQLが実行される可能性がある問題。
- CVE-2026-103668：サイト内検索用プログラム（mt-search.cgi）において、不正なSQLが実行され、非公開データを含む情報が出力される可能性がある問題。
これらは、対象となるバージョンや設置状況によっては、ログイン認証を必要とせずに悪用される可能性がある重大な問題です。
開発元のシックス・アパート株式会社は修正版を公開し、利用者にアップデートや緩和策の実施を求めています。
また、レンタルサーバー事業者のエックスサーバー株式会社も、10月9日に注意喚起を発表し、影響を受ける可能性のあるサイトに対して、対象プログラムへの外部アクセスを制限する暫定措置を案内しています。
参考：エックスサーバー「Movable Typeの脆弱性（CVE-2026-96408／CVE-2026-103668）に関する注意喚起について」
ここで重要なのは、今回のMovable Typeの脆弱性は、PHPの脆弱性とは別の問題であるということです。
つまり、PHPを使用しないシステムへ変更すれば、すべてのセキュリティ問題を回避できるわけではありません。
静的HTMLを生成する仕組みであっても、管理画面や更新用プログラムなどがサーバー上に存在し、外部からアクセスできる状態であれば、そこが攻撃の対象となる可能性があります。
もちろん、これはMovable TypeがWordPressより危険であるという意味ではありません。
逆に、WordPressの方が優れていると主張するものでもありません。
それぞれのCMSには異なる設計思想や特徴、利点と制約があります。
今回の事例からも分かるように、「WordPressだから危険」「別のCMSだから安全」といった単純な比較では、Webサイトのセキュリティを正しく判断することはできません。
さらに、ここでもう一つ考えておきたいのが、利用者数の違いによるセキュリティ情報の広がり方です。
WordPressは世界中で非常に多くのWebサイトに利用されています。2026年10月24日時点のW3Techsの調査では、CMSを判別できるWebサイトのうち、WordPressは58.3％を占めています。一方、Movable Typeは0.1％未満とされています。
もちろん、こうした調査にはCMSの検出方法などによる制約がありますが、両者の利用規模に大きな違いがあることは分かります。
利用者が多いということは、それだけ攻撃者から注目される可能性がある一方で、多くの開発者や技術者、保守会社、利用者が情報を共有し、問題が広く知られやすいという側面もあります。
今回のような大きなセキュリティ問題についても、多くの人が関心を持ち、情報を発信することで、専門知識を持たないサイト運営者にも注意喚起が届く機会が増えます。
反対に、利用者が比較的少ないCMSの場合、たとえ重大な脆弱性が公表されていても、その情報が一般の利用者の目に触れる機会は限られる可能性があります。
これは、利用者が少ないCMSほど脆弱性が発見されにくいと断定するものではありません。また、Movable Typeについても、開発元やセキュリティ関連機関、サーバー事業者などから適切に情報が公開されています。
問題は、そうした情報が実際のサイト運営者に届き、必要な対応につながるかどうかです。
利用者の多さは、セキュリティ上のリスクだけでなく、問題の可視化や情報共有の面で利点となる場合もあります。
一方で、どのCMSであっても、利用者自身が公式情報やセキュリティ情報を確認できる体制を整えることは欠かせません。
重要なのは、CMSの名称や開発言語、利用者数だけで安全性を判断するのではなく、その仕組みを理解したうえで、適切な情報収集と更新・管理が継続されることです。
■ まず確認すべきは、サーバー会社と運用体制の信頼性
例えば、弊社が運営するWebサイトでもWordPressを利用しています。
今回の問題に際して、弊社が利用しているサーバー会社は早い段階で情報を公開し、対策の進行状況についても継続的に発信していました。
問題が発生しないことが理想であるのは当然ですが、現実には、どれほど優れた技術やサービスであっても、脆弱性や予期しない障害が発生する可能性があります。
そのようなときに、適切な情報を発信し、必要な対策を速やかに講じ、利用者に状況を説明できることは、サービス提供会社を信頼するうえで重要な要素です。
一方で、今回の問題について具体的な案内が確認できないサーバー会社もあります。
もちろん、お知らせが掲載されていないことだけをもって、対策が実施されていないと断定することはできません。
しかし、過去のセキュリティ事故への対応や、障害発生時の情報発信、日常的な保守体制などを総合的に確認することは、利用するサーバー会社を選ぶうえで大切な判断材料になります。
なお、弊社がWordPressによるWebサイト構築の際に、お客様へ移行先として推奨してきたサーバー会社についても、今回のPHPの脆弱性に対して、速やかに予防措置と修正パッチの適用が実施されたことを確認しています。
2026年10月23日時点の公式発表では、同社が提供するPHP 5.6〜8.5について、対象となるすべてのレンタルサーバーへの修正パッチ適用が完了しています。
そのため、該当するPHP環境をご利用のお客様については、今回の脆弱性へのサーバー側の対応が完了していることをご報告するとともに、その点についてはご安心いただければと思います。
ただし、PHP 5.1〜5.5などの一部旧バージョンや、お客様自身でPHPを管理するVPSなどは対応状況が異なります。また、今回の修正によってWebサイト全体の安全性が保証されるものではなく、WordPress本体やプラグインなどの保守・更新は引き続き必要です。
参考：エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」（2026年10月22日公開・10月23日追記）
また、本記事では、関係する事業者への影響を考慮し、弊社が利用・推奨しているサーバー会社や、比較対象となる個別のサーバー会社名の本文中での明示は控えています。
なお、技術的な事実関係や対応状況を確認できるよう、公開されている事業者の注意喚起や対応報告については、参考資料として掲載しています。
これは特定の企業やサービスを評価・批判する意図によるものではなく、Webサイトを安全に運営するうえで、利用者が確認すべき点や、サービス選定における判断材料をお伝えすることを目的としています。
■ 構築後の保守・脆弱性対応の役割分担も確認しましょう
Webサイトの脆弱性対策については、構築を担当した会社が、必ずしもサーバーやCMSの保守運用まで継続して担っているとは限りません。
特に、初期構築を無償または限られた費用で行った場合、その後のサーバー保守、CMSやプラグインの更新、脆弱性への対応までが契約に含まれていないこともあります。
そのため、脆弱性が公表された際に、構築会社へ相談しても、契約内容や対応範囲によっては、すぐに対応してもらえない場合があります。
これは、構築会社が責任を放棄しているという意味ではなく、契約時に定められた役割や費用の範囲が異なるためです。
弊社でも、サーバーについてはお客様ご自身でサーバー会社と直接ご契約いただき、サーバー会社による保守・運用を受けていただく形を基本としています。また、CMSやプラグインの更新など、日常的な脆弱性対策についても、原則としてお客様側でのご対応をお願いしています。
これは、Webサイトの運用にかかる費用をできるだけ抑え、限られた予算の中でサイトを維持していただくための考え方です。すべての保守を制作会社に委託する場合には、その分の継続的な費用が必要になるためです。
今回のような問題が発生した際には、まず契約内容を確認し、サーバー会社、構築会社、サイト運営者のそれぞれが、どの範囲を担当するのかを整理することが大切です。
そのうえで、自社で対応するのか、サーバー会社や構築会社へ相談するのか、必要に応じて有償の保守サービスを利用するのかを協議し、現実的な対応方法を決めていくことが、最初の一歩になります。
■ 「セキュリティ万全なCMS」は存在しません
どのCMSを採用する場合でも、セキュリティリスクを完全にゼロにすることはできません。
WordPressであっても、別の商用CMSであっても、独自開発のシステムであっても同じことです。
CMSそのものの安全性に加えて、サーバー、データベース、ネットワーク、管理者のアクセス権限、ソフトウェアの更新、バックアップなど、複数の要素によってシステム全体の安全性が成り立っています。
今回のように実行環境に重大な問題が発生した場合、CMS自体に脆弱性がなくても影響を受ける可能性があります。
反対に、サーバー会社が適切に対策を行っていても、CMSやプラグインの更新が放置されていれば、別の脆弱性を突かれる可能性があります。
つまり、サーバーだけ、CMSだけ、あるいは特定のセキュリティ製品だけで安全性が成立するものではありません。
CMSの構造によって攻撃を受ける可能性や被害の範囲が異なるため、製品ごとのセキュリティ性能を比較すること自体は重要です。
しかし、「このCMSに変更すれば安全です」という説明だけでは十分とは言えません。
本当に確認すべきなのは、問題を未然に防ぐ仕組みと、問題が発生したときに対処できる運用体制の両方です。
さらに言えば、サーバー会社、Web制作会社、システム保守会社、サイト運営者の間で、どこまでが誰の管理責任なのかを明確にしておくことも重要です。
■ CMSの変更を勧められたら、確認してほしいこと
現在利用しているCMSが危険だとして、新しいシステムや高額なサービスへの移行を提案された場合は、次の点を確認してみてください。
1. 現在のサイトに、実際にどのような問題があるのか
一般論として危険だという説明ではなく、利用しているシステムやサーバー環境を確認したうえで、その危険性と必要な対策が具体的に説明されているでしょうか。
2. 新しいCMSは、どのような環境で動くのか
提案されているCMSがどのようなサーバーで動き、その実行環境を誰が管理するのか。CMSを変更することで、今回のような問題に対するリスクがどのように変化するのかを確認しましょう。
3. 問題が発生した際、誰が対応するのか
脆弱性が発見された場合の更新作業や緊急時の連絡、障害発生時の復旧対応などが明確になっているでしょうか。
4. Webサイトやデータを復旧できるのか
バックアップが存在するだけでなく、実際に復元できる仕組みが用意されているか。また、復旧に必要な期間や費用についても確認しておくことが大切です。
5. CMSを変更することで、何が改善され、何が制限されるのか
セキュリティ面のメリットだけでなく、日々の記事更新や固定ページの作成、機能追加の自由度、運用費用、将来的なデータ移行のしやすさなどについても確認しましょう。
特に、小規模な事業者や個人事業主にとっては、必要以上に高額なシステムを導入することが、必ずしも適切な選択になるとは限りません。
システムを変更すること自体が目的になってしまっては、本末転倒です。
事業の規模や目的に応じて、必要な機能とセキュリティ水準、運用のしやすさ、費用のバランスを考えることが大切です。
■ AIを利用したサービスにも同じことが言えます
これは、急速に普及しているAIサービスについても同様です。
AIによって業務が効率化され、これまで難しかったことが実現できるようになっています。
しかし、AIそのものの性能や機能ばかりに注目して、そのサービスが動作する環境や、停止した場合の対応まで十分に検討されているでしょうか。
AIサービスも、通信障害、システム障害、サービス仕様の変更、提供元の都合などによって、突然利用できなくなる可能性があります。
重要な業務をAIに任せるのであれば、正常に動くことを前提とするだけでは不十分です。
例えば、AIが停止したときに人が業務を引き継げるか、必要なデータを取り出せるか、別の方法でサービスを継続できるか。
また、AIが誤った処理を行った際に、それを検知し、修正できる仕組みがあるかどうかも重要です。
サービスの提供者が、こうした問題への対応まで具体的に説明しているかどうかを確認しておきたいところです。
便利な技術を導入することと、その技術に依存しすぎない仕組みをつくることは、両立させる必要があります。
これはAIに限らず、クラウドサービスや外部のデジタルサービスを利用する際にも共通する考え方です。
■ 今回の問題を受けた、弊社のセキュリティに対する考え方と今後の取り組み
今回の一連の脆弱性問題は、弊社にとっても、これまでのWebサイト運営におけるセキュリティの考え方を改めて見直す機会となりました。
これまでも、Webサイトの規模や用途、運用費用とのバランスを考慮しながら、必要と考えるセキュリティ対策をご案内してきました。
しかし、技術の進歩とともにサイバー攻撃の手法も変化しており、従来は十分と考えていた安全性の基準についても、継続的に見直していく必要があると認識しています。
例えば、WordPressにおいても、管理画面へのアクセス制御、多要素認証、WAF、脆弱性の監視、バックアップや復旧体制の強化など、さまざまなセキュリティ対策が利用できるようになっています。
これまで弊社では、サイトの運用規模や費用対効果を踏まえ、一部の対策については必要以上の負担になると判断することもありました。
しかし、今回の問題を通じて、これまで過剰と捉えていた対策についても、被害が発生した場合の影響や事業継続の観点から、改めて評価する必要があると考えるようになりました。
もちろん、すべてのWebサイトに高度なセキュリティ対策を一律に導入すればよいということではありません。
必要な対策は、サイトの規模、取り扱う情報、事業への影響、運用体制などによって異なります。
重要なのは、対策を増やすこと自体ではなく、リスクと費用のバランスを見極めながら、適切な安全性を確保することです。
今後、弊社としても、WordPressをはじめとしたWebサイトのセキュリティ強化について、どのような追加対策や保守サービスをご提供できるのか、改めて整理・検討してまいります。
その際には、対策によって期待できる効果だけでなく、費用、運用上の制約、対応範囲なども明確にし、お客様が必要に応じて選択できる形でご提案したいと考えています。
今回の問題から得た学びを、単なる注意喚起で終わらせるのではなく、弊社自身のサービス品質と、お客様に提供できる安心の水準を高める機会につなげていきたいと考えています。
■ 不安ではなく、適切な知識と情報に基づいた判断を
今回のPHPの脆弱性については、対象環境の確認と速やかな修正の適用が重要です。
また、同じ2026年10月に公表されたMovable Typeの脆弱性についても、対象バージョンを利用している場合には、速やかな対策が必要です。
これは先延ばしにすべき問題ではありません。
一方で、セキュリティ対策を理由として、十分な根拠のないまま高額なシステムへの変更を急ぐ必要もありません。
もちろん、現在のシステムがサポートを終了している場合や、十分な保守体制を確保できない場合には、別のシステムへの移行を積極的に検討すべきでしょう。
重要なのは、その判断に具体的な根拠があることです。
また、構築会社に対応を依頼する場合も、まずは契約内容と対応範囲を確認し、必要に応じて有償対応を含めた相談を行うことが大切です。無償で構築されたWebサイトであっても、継続的な保守や緊急対応までが無償で含まれるとは限りません。
自社で対応できる範囲、サーバー会社に任せる範囲、構築会社や専門業者へ依頼する範囲を整理することで、過度な負担や行き違いを避けながら、現実的な対策を進めることができます。
Webサイト運営やデジタルマーケティングに必要なのは、最新の技術を次々と導入することだけではなく、事業の目的や規模に合った技術を選び、適切に使い続けられる環境を整えることです。
そして、専門家やサービス提供会社には、利用者の不安を必要以上に煽るのではなく、何が危険で、何が対策済みで、何が未解決なのかを正確に説明する姿勢が求められます。
技術に詳しくない方ほど、サービスを勧められたときには、そのメリットだけでなく、リスクや制限、障害発生時の対応についても説明を求めてください。
本来、専門家の役割は、利用者の不安を利用して商品やサービスを販売することではなく、課題を正しく把握し、適切な選択肢を提示することにあると考えています。
これは弊社自身にも向けられるべき考え方です。
今回の問題を通じて得た知見を今後のサービスに反映し、必要な対策について適切に説明するとともに、お客様それぞれの状況に応じた選択肢を提供できるよう取り組んでまいります。
大切なのは、危険を恐れて技術を避けることではなく、リスクを理解し、適切に管理しながら、その技術がもたらす可能性を活用することです。
参考情報
PHPの脆弱性に関する公式情報
- PHP開発元：Security advisory – Critical remote code execution vulnerabilities
- IPA：PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619）
- JPCERT/CC：PHPにおける複数の脆弱性に関する注意喚起
Movable Typeの脆弱性に関する公式情報
- エックスサーバー：Movable Typeの脆弱性に関する注意喚起（2026年10月9日公開・10月14日更新）
- シックス・アパート：Movable Typeのセキュリティアップデート（2026年10月7日）
- IPA：Movable Typeにおける複数の脆弱性について（JVN#91153973）
サーバー事業者によるPHP脆弱性対応の参考情報
CMSの利用状況に関する参考情報
※本記事は2026年10月24日時点で確認できる情報に基づく当社の見解です。個別のWebサイトへの影響や必要な対策は、利用環境や設定、保守状況によって異なります。
