1. 今回、何が起きたのか

2026年10月21日（日本時間では21日深夜）、PHPの開発チームが緊急の修正版を公開しました。対象は「CVE-2026-109618」「CVE-2026-109619」という2つの脆弱性で、まとめて「PHP2Shell」と呼ばれています。

そもそもPHPって？

PHPは、Webサイトを動かすためのプログラミング言語です。DrupalもWordPressも、PHPで動いています。つまりPHPは、CMSを支える「土台」にあたる部分です。

どれくらい危険なの？

深刻度（CVSS v4.0）は10点満点中の9.2で、最も高い「Critical（致命的）」に分類されています。この脆弱性を悪用されると、ログインしていない第三者が、外からサイトのサーバーに勝手に命令を実行できてしまう可能性があります（これを「リモートコード実行（RCE）」と呼びます）。サイトの改ざんや情報の流出、乗っ取りにつながりかねません。

押さえておきたいポイント

  • 修正版より古いPHPは、すべて対象です。サーバーの種類（PHP-FPMやApacheなど）を問わず影響があり、とくにApacheのモジュールとしてPHPを動かしている構成（mod_php）は、危険度が高いとされています。
  • 修正版はPHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12です。お使いのバージョンに合わせて更新が必要です。
  • PHP 8.1以前には、公式の修正版がありません。7.4・8.0・8.1は、OSなどの提供元が配るパッケージや、PHPが公開した最小限の修正（ソースコード）で対応できる場合があります。7.3以前（PHP 5を含む）は修正されないため、新しいバージョンへの移行が必要です。
  • 公開の4日前（10月17日）には、攻撃の試行が確認されていました。AWS（Amazonのクラウド部門）の調査チームが報告しています。
  • OSやレンタルサーバーの提供元が、独自に修正を反映している場合があります。その場合、バージョン番号が古いままでも修正済みのことがあるため、番号だけで判断せず、提供元の案内も確認しましょう。
  • 研究者は、WordPress・Drupal・Joomla・Magentoでも攻撃が成立することを報告しています。

その後、状況は大きく動いています。2026年10月26日、アメリカのサイバーセキュリティ機関CISAが、この2つの脆弱性を「悪用が確認された脆弱性のリスト（KEVカタログ）」に追加しました。IPA（情報処理推進機構）も、10月27日にこの件を追記しています。なお、IPAは「国内での攻撃被害の事例については把握していない」としています（いずれも2026年10月28日時点）。被害が国内で確認されていないからといって、安心はできません。修正版が公開されると、攻撃する側もその内容を調べ始めるためです。

参考：IPA - PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)
CISA - CISA Adds Two Known Exploited Vulnerabilities to Catalog
Tenable - php2shell (CVE-2026-109618, CVE-2026-109619) FAQ
ITmedia NEWS - PHPに「緊急」レベルの脆弱性2件

2. 「CMSを最新にしていれば安全」ではありません

Webサイトの管理をしていると、まずCMS本体のバージョンを気にされる方が多いと思います。しかし今回、WordPressは「本体の更新は不要」、Drupalも同様でした。CMSを最新にしていても、土台のPHPが古ければ、サイトに侵入される可能性があるのです。

家にたとえると、どれだけ立派な家具（CMS）を揃えても、土台が壊れていたら安全とは言えませんよね。Webサイトは、次のような層が積み重なってできています（下から順に）。

  1. 実行環境：PHP、Webサーバー、OS、データベースなど
  2. CMS本体：Drupal、WordPressなど
  3. モジュール／プラグイン：CMSに機能を追加する部品や、自社で開発したプログラム
  4. コンテンツ・運用：ユーザーの権限設定、パスワード、公開範囲など

CMSを支える4つの層（実行環境・CMS本体・モジュール・運用）と、実行環境の脆弱性が全体に及ぶ様子を示した図

どの層に問題があっても、サイト全体の乗っ取りにつながる可能性があります。「CMS本体の更新」しか見ていないと、1層目（実行環境）と3層目（モジュール／プラグイン）が見えなくなってしまいます。

3. 同じ月に、Drupalでも重要な修正がありました

PHPの件の少し前、2026年10月中旬には、Drupalでも別の重大な脆弱性が修正されています。こちらも、外部からサーバーに命令を実行されてしまう可能性があるものです。

  • CVE-2026-108097：Drupal本体（コア）の「Field UI」モジュールの脆弱性です。現在サポートされているすべてのバージョンが対象です。
  • CVE-2026-108099：追加モジュール（contribモジュール）の「Entity List」の脆弱性です。
  • 修正版：Drupal 10.6.19 / 11.3.19 / 11.4.10、Entity List 3.0.10
  • Drupalのセキュリティチームは、「数時間〜数日で攻撃コードが作られる可能性がある」と警告しています。

ここで注目したいのは、Drupal本体だけでは悪用できず、追加モジュールや自社開発のプログラムが「攻撃の入り口」になるとされている点です。問題が本体、モジュール、実行環境のどこに潜んでいても、結果は同じ、サイトへの侵入です。

引用：BleepingComputer - Drupal patches critical RCE flaws, warns exploits may emerge soon

4. CMSごとの違いは？ それでもDrupalが優れている理由

どのCMSも、PHPで動く以上、今回のようなPHP本体の問題からは逃れられません。違いが出るのは、脆弱性が見つかったときに、どれだけ備えができていて、どれだけ素早く対応できるかです。この点で、私たちはDrupalが優れていると考えています。

Drupalが備えている「守りの仕組み」

  • セキュリティチームによる一元的な対応：Drupalには、本体と追加モジュールの脆弱性をまとめて調整・公開する公式のセキュリティチームがあります。今回の本体の修正でも、事前の告知があったうえで修正版が公開されました。
  • 危険度を正直に伝えてくれる：「数時間〜数日で攻撃コードが作られる可能性がある」と率直に知らせてくれるので、運用する側が、どれくらい急ぐべきか判断しやすくなります。
  • Drupal Steward（ドルーパル・スチュワード）：一部の既知の攻撃を、更新が間に合う前でも防いでくれる仕組みです（すべての攻撃を防げるわけではありません）。
  • Composer（コンポーザー）による管理：Drupal本体やモジュールのバージョンを、コードでまとめて管理できるツールです。「何がどのバージョンで動いているか」を把握しやすく、更新も手順どおりに進められます。
  • 当面の回避策が示される：今回も「field_ui モジュールを無効にする」という具体的な回避策が案内されました。

ノーコードツール・SaaSを使う場合に気をつけたいこと

プログラミングの知識がなくてもサイトを作れる「ノーコードツール」や、インターネット経由で使う「SaaS（サース）」型のサービスは、手軽なのが魅力です。たとえば、Wix（ウィックス）、Jimdo（ジンドゥー）、STUDIO（スタジオ）などが、Webサイト作成サービスとしてよく知られています。実行環境の更新を提供元が行ってくれる点は、利用する側にとっての利点でもあります。ただ、セキュリティの面では、次のような点に気をつけたいところです。

※ここで挙げたサービスに問題があるという意味ではありません。「自分で確認・管理できる範囲が限られる」という、この種のサービスに共通する特徴についてのお話です。

  • 自分で確認・コントロールできない範囲が増える：実行環境のバージョンや、修正がいつ適用されるのかがわからず、すべて提供元に任せることになります。
  • 「何を使っているか」の把握が難しくなる：部署ごとにツールが導入されると、会社全体で「何が、どこで動いているか」を把握しにくくなります。
  • 権限や公開範囲の管理がバラバラになる：ツールごとに設定が違うため、「必要な人だけに必要な権限を与える」といったルールを全体で徹底しにくくなります。

Drupalは、開発者があらかじめ安全で丈夫な土台を作り、使う人はその範囲の中で自由に、すばやくコンテンツを更新できる設計です。手軽さと管理のしやすさを両立したい企業サイトには、Drupalが優れた選択肢だと私たちは考えています。

どのCMSでも変わらないこと

ただし、PHP本体の問題はCMSの更新機能では解決できません。サーバー側（ホスティング会社や自社のインフラ）で対応する必要があります。「PHPの更新は誰の担当か」がはっきりしていないサイトほど、対応が遅れてしまいます。

つまり、Drupalの仕組みと、PHPを含む実行環境まで見ている運用体制の両方があって、はじめて守れるということです。

5. 今回の件から学べる、5つの運用ポイント

(1) 「何が、どのバージョンで動いているか」をすぐ答えられるようにする

緊急のときに最初に必要なのは、PHP・CMS・モジュール・OSのバージョン一覧です。これがないと、影響があるかどうかを調べるだけで数日かかってしまいます。バージョンの棚卸しは、何もない平常時にやっておく仕事です。

(2) サポート終了（EOL）の環境を放置しない

PHP 8.1以前には、公式の修正版がありません。「動いているから触らない」で何年も経ったサイトほど、いざというときに打つ手がなくなります。サポートが終わる前に、移行の計画を立てておくことが、いちばん確実な対策です。

(3) すぐ更新できる体制を先に作っておく

今回のPHPでは、公開前から攻撃の試行が確認されていました。Drupalでも「数時間〜数日」と警告されています。次のような体制があれば、緊急の更新も「大事件」ではなく「いつもの作業」になります。

  • 本番と同じ構成のテスト用サイト（ステージング環境）で確認してから、本番に反映する流れ
  • 緊急のときに、判断・承認できる連絡ルート
  • 更新後の動作確認チェックリスト
  • 万一に備えたバックアップと、元に戻す手順

(4) 当面の回避策は「時間稼ぎ」。根本的な解決は更新だけ

まず大切なことは、PHP開発チームも「完全な回避策はなく、更新が唯一の確実な対策」としていることです。すぐに更新できない場合の時間稼ぎとして、たとえば次のような方法がありますが、どれも一部の攻撃を防ぐだけで、サイトが安全になるわけではありません。

  • Drupal：使っていない field_ui モジュールを無効にする（Drupalが案内している回避策。こちらはPHPではなく、Drupalの別の脆弱性への対策です）
  • PHP：session.upload_progress.enabled=0 などの設定を変更する（一部の攻撃経路に対する軽減策として、PHP公式が案内しています。設定後はPHPの再起動が必要です）
  • WAF（Webサイトへの不審な通信を見張って遮断する仕組み）：Cloudflareなどが既知の攻撃を遮断するルールを提供していますが、あくまで一時しのぎで、その会社の仕組みを通る通信しか守れません
  • 更新できないサーバーは、外部からのアクセスを遮断する、または一時停止することも検討する（IPAも案内しています）

あくまで修正までの時間稼ぎとして、更新の予定とセットで行いましょう。

(5) 「1つ破られても致命傷にならない」ように多層で守る

どれだけ更新を徹底しても、修正版が出る前に悪用される脆弱性（ゼロデイ）までは防げません。だからこそ、「侵入されてしまった後」を想定した備えも大切です。

  • 管理画面にアクセスできる人や場所を制限する（IPアドレス制限・多要素認証）
  • 必要最小限の権限で運用する（Webサーバーやデータベースの権限を絞る）
  • 不審な動きを検知する仕組みを入れる（WAFや監視）
  • 定期的なバックアップと、復旧の訓練

6. 今すぐ確認したいチェックリスト

  • 本番環境のPHPバージョンを確認した
  • 修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 以降）、またはOS提供元の修正パッケージが適用されている
  • PHP 8.1以前の場合、移行の計画（または代わりの保護策）がある
  • 更新したあと、PHPを再起動した（PHP-FPMなど）
  • OSやレンタルサーバーを使っている場合、提供元が修正を反映しているか確認した（バージョン番号が古いままのこともあります）
  • CMS本体・モジュールが、最新のセキュリティ更新になっている
  • 10月17日以降のアクセスログやファイルの変更に、不審な点がない（AWSが確認した最初の試行が10月17日のため）
  • レンタルサーバーやクラウドを使っている場合、提供元の対応状況を確認した

7. まとめ

今回のPHP2Shellからわかったのは、セキュリティは「どのCMSを選ぶか」だけでは決まらないということです。

  • 脆弱性は、実行環境・CMS本体・モジュールのどこにでも潜んでいる
  • 公開から悪用までの時間は短く、「すぐ更新できる体制」がそのまま守りの強さになる
  • CMSの違いよりも、棚卸し・更新・多層防御といった運用の質が結果を左右する

そのうえで、セキュリティチームによる一元的な対応、Drupal Steward、Composerによる管理といった「守りの仕組み」を備えたDrupalは、守り続ける運用を支える土台として優れています。CMSの運用は「作って終わり」ではなく、「守り続ける」ことが大切です。

私たちは、Drupalを中心に、サイト公開後の保守やセキュリティ更新、PHPのバージョンアップ対応まで一貫してご支援しています。「自社サイトのPHPバージョンがわからない」「更新作業が特定の人に頼りきりになっている」「古い環境の移行を考えたい」といったお悩みも、お気軽にご相談ください。

参考：Unit 42 - Threat Brief: CVE-2026-109618, CVE-2026-109619
Rapid7 - CVE-2026-109618 and CVE-2026-109619