1. 拡張機能は、どのCMSでも穴になりうる

2026年も、「サイトで使っていたソフトウェアの脆弱性を悪用され、約89万件の会員情報が持ち出された」（ソフトウェアの製品名は未公表）といった事案が報告されています。
CMSで作られたサイトの場合、そうした入口になりやすいのが拡張機能です。

セキュリティ企業Patchstackの2026年版レポートでは、WordPressのエコシステムについて次のような結果が出ています。

• 2025年に新たに見つかった脆弱性は11,334件（前年比42%増）
• そのうち91%がプラグイン
• 46%は、公表の時点で開発者の修正が間に合っていなかった
• 影響の大きい脆弱性の約半数は24時間以内に悪用され、攻撃の多さで重み付けした中央値では、最初の悪用までわずか5時間

これはWordPressだけの話ではありません。足した部品が穴になりうるのは、Drupalのモジュールも同じです。
そして、穴が公表されてから攻撃が始まるまでは、もう「日」ではなく「時間」の単位になっている、、、ということです。
だからこそ、情報流出を防ぐうえで大事になるのが、穴が見つかったときに、その情報をいち早く、確実に受け取れるかどうかなのです。

2. Drupalの「盾マーク」とは

drupal.orgでモジュールのページを開くと、盾のアイコンと一緒に「Stable releases for this project are covered by the security advisory policy.」という一文が表示されているものがあります。
これがセキュリティカバレッジです。本記事では「盾マーク」と呼びます。
※以下は、URLエイリアスを自動生成する定番モジュール「Pathauto」のページです（出典：drupal.org）

盾マークの付いたモジュールで脆弱性が見つかると、Drupal Security Teamの手順に乗って対応が進みます。
修正版が出ればセキュリティアドバイザリー（SA）として公式に告知され、直らなければ、後で説明する「サポート対象外」として告知されます。

盾マークが付く条件

盾マークは、モジュールの作者（メンテナー）が自分で申請する仕組みです。次の条件をすべて満たす必要があります。

• コードを更新する権限を持つメンテナーが、申請して「vetted（審査済み）」の役割を認められていること
• お試し用の「サンドボックス」ではなく、正式なプロジェクトであること
• 未解決のセキュリティ上の問題を抱えていないこと
• 新しく作られたプロジェクトは、作成から10日が経過していること

対象は「サポート中の安定版」だけ

見落としやすいのが、盾マークが効くのは、サポート中のブランチの安定版だけという点です。
開発版（-dev）、アルファ版、ベータ版、リリース候補版（RC）は、脆弱性が見つかってもセキュリティアドバイザリーが出ません。
先ほどの画像でも、安定版の8.x-1.15には盾アイコンが付いていますが、開発版の8.x-1.x-devには付いていませんよね。
※盾マークは「コードが安全だと保証する印」でも、「必ず直してもらえる約束」でもありません。Security Teamは、モジュールのコードを一つひとつ審査しているわけではないからです。盾マークが約束しているのは、穴が見つかったときに、決まった手順で利用者に告知されるということ。つまり盾は防具ではなく、告知の制度なのです。

3. 修正版と同時に公表する「協調開示」と、事前の予告

Drupal Security Teamは、協調開示（Coordinated Disclosure）という方針をとっています。
脆弱性を見つけた人には、それを公にせず、Security Teamへ非公開で報告するよう求めています。Security Teamはメンテナーと一緒に修正を進め、修正版ができた時点で、修正版とアドバイザリーを同時に公開します。

公開のタイミングも決まっている

セキュリティリリースは、公開される日時にも決まりがあります。

• モジュールなど：毎週水曜日
• Drupalコア：月1回の水曜日（通常は第3水曜日）
• 時間帯：16:00〜22:00（UTC）＝日本時間の木曜午前1時〜7時

さらに深刻なものは、PSA（公共サービスアナウンス）で事前に予告されることがあります。
たとえば2026年5月18日には「5月20日の17:00〜21:00（UTC）に、Highly criticalのコアのリリースを行う」という予告が出ました。内容は伏せたまま、「当日はリリースの時間帯に作業時間を確保してください」と呼びかけるものです。

4. 直らないモジュールは「サポート対象外」と宣言される

では、直らなかった場合はどうなるのでしょうか？
盾マークの付いたモジュールで脆弱性が見つかったのに、メンテナーが期限までに直さなかった場合、Security Teamはアドバイザリーでそのモジュールの無効化・アンインストールを推奨し、プロジェクトを「サポート対象外（unsupported）」にします。
修正版はありません。それでも、「直らないので外してください」という告知は届くわけです。

実例：企業サイト向けの「Disable Login Page」

「Disable Login Page」は、秘密のキーを知らない人にはDrupalのログイン画面を見せないようにするモジュールです。drupal.orgの説明には「企業サイトや個人ブログのように、一般ユーザーのログインが必要ないサイトに便利」とあり、1,438のサイトで使われています。
このモジュールは、2026年7月29日に「サポート対象外」になりました（SA-CONTRIB-2026-091）。
※以下は、そのときのセキュリティアドバイザリーです。いまは後から追記された「サポート対象に戻った」という案内も載っています（出典：drupal.org）

当時の危険度はCritical（16/25）で、内訳は「AC:Complex/A:Admin/…」、つまり「悪用には管理者権限が必要」という表示でした。
ところが、約1か月後の8月26日に修正版（1.1.4）が出て、脆弱性の中身が公表されると、話が変わります。
※以下は、中身が公表されたときのアドバイザリーです（出典：drupal.org）

• 危険度：Moderately critical（13/25）
• 内訳：A:None（ログインしていない第三者でも悪用できる）
• 内容：ログイン画面を隠すための秘密のキーを、何度でも試せてしまう。総当たりで突破されうる
• 同じ日に、もう1件（SA-CONTRIB-2026-111）も公表。ログイン画面を隠す設定にしても、キャッシュに残った古いログイン画面が見えてしまう、というもの

点数そのものは下がりましたが、実際は「ログイン無しで突ける穴」だったわけです。
ちなみに、2026年にサポート対象外になった19件は、点数も内訳もすべて同じでした。サポート対象外の段階では中身が伏せられているので、表示されている点数から「管理者権限が必要だから急がなくていい」と判断するのは危険、ということですね。

中身を公表したSA-CONTRIB-2026-110には、報告者と修正した開発者に加えて、調整にあたったSecurity Teamのメンバー6人の名前も記載されています。ひとつのモジュールの穴にも、Security Teamがチームとして関わって、修正と公開が進められているわけです。

そしてこのモジュールは、修正版が出たことで、再び盾マークの付いたモジュールに戻りました。

※以下は、現在のDisable Login Pageのページです。1.1.4と1.2.1に盾アイコンが付いています（出典：drupal.org）

プロジェクトページにも警告が出る

サポート対象外のあいだは、drupal.orgのモジュールのページにも警告が表示されます。
※以下は、サポート対象外になったモジュールのページの例です（2026年7月にサポート対象外になった決済連携モジュール「Commerce Elavon」。出典：drupal.org）

オレンジの帯の付いた枠が「セキュリティアドバイザリーポリシーの対象外」、赤い枠が「メンテナーが修正しなかったセキュリティ上の問題により、サポート対象外」という警告です。
赤い枠には、それでも使いたい場合の選択肢が3つ書かれています。

1. 保守が続いている別のモジュールに切り替える
2. サポート対象外プロジェクト向けの手続きに従う
3. セキュリティバグの修正を誰かに依頼し、モジュールを再公開してサポート対象に戻す

Disable Login Pageは、実際に直されて、サポート対象に戻った例です。

ここで注目したいのは、サポート対象外の宣言から、中身の公表、盾マークの復帰まで、すべてがdrupal.org上で公開されていることです。
中身が伏せられているあいだも「外してください」という知らせは届き、直ったあとには何が問題だったのかまで確かめられる。穴があることを、うやむやにせず最後まで知らせる。この透明性こそがDrupalの強みと言えます。

数字で見るとどうか

2026年のモジュールなどのセキュリティアドバイザリーは、10月14日時点で217件。そのうち19件（約9%）が、修正版のないまま「サポート対象外」として公表されたものです。
そのうちサポート対象に戻ったと記録されているのは、10月16日時点でDisable Login Pageの1件だけです。ほかの18件には、サポート対象に戻ったという記録はありません。
それらのモジュールには、いまも「外してください」という告知が出たままです。

Drupalのサポート対象外は、CVE番号付きのアドバイザリーとして公開され、修正版が出たときと同じメール・RSS・SNSの経路で届きます。
大事なのは「直るかどうか」だけではなく、「直らないという情報まで、同じ形で届く」ことなのです。

※重要：この仕組みが働くのは、盾マークの付いたモジュールだけです。盾マークのないモジュールについては、アドバイザリーは出ません。だからこそ、入れる前に盾マークを確認することが大事になります。

5. 運用で押さえておきたいこと

モジュールを入れる前に

• drupal.orgのモジュールのページで、盾マークが付いているかを確認する
• 本番には安定版を入れる。メジャーバージョンの移行期などに、ベータ版やissueのパッチを当てて使う場合は、そのモジュールは盾マークの外にあると認識しておく
• 最終リリース日や課題（issue）への対応状況を見て、保守が続いているかを確認する
• そもそもコアの機能で代替できないかを考える。Drupalは、Views・Layout Builder・Media・多言語・承認フローなどがコアで揃うので、足すモジュールを減らしやすいCMSです

運用中に

• drupal.orgのセキュリティ情報（メール・RSS・SNS）を購読する
• PSAで予告が出たら、公開日の作業時間を先に確保する
• composer audit で、入っているパッケージに既知の脆弱性がないかを照合する（drupal.orgが公開しているアドバイザリーと突き合わせられます）
• 管理画面の「利用可能なアップデート」で、更新が必要なモジュールがないかを確認する
• サポート対象外になったモジュールは、アンインストールするか、別のモジュールに切り替える

自社の責任範囲

• 自社で開発したカスタムモジュールは、盾マークの対象外です。コードレビューや脆弱性診断は自分たちで行う必要があります
• コアをサポート中のバージョンに保つための、アップデートの費用と時間を、運用コストとして見込んでおく（サポート期間については Drupalのサポート期間について や Drupal 12で何が変わるのか でも解説しています）

最後に

拡張機能が攻撃の入口になりえるのは、どのCMSでも同じです。
それでもDrupalが強いと言えるのは、穴の情報が、うやむやにされず、公式に、決まった形で届くからです。盾マークで告知の対象になるモジュールを見分けられ、予告・修正版・告知が決まった流れで届き、直らないモジュールについてまで「外してください」と知らされます。
情報流出を防ぐために運用側がやるべきことは、その知らせを受け取って、計画して、当てることです。盾は防具ではなく告知の制度ですが、告知が確実に届くからこそ、運用で守り切れると言えるのではないでしょうか。
どうでしたでしょうか、モジュールを選ぶときに盾マークを見る、予告が出たら時間を確保する。それだけでも、穴への備え方はかなり変わってきます。
ぜひDrupalプロジェクトの際は参考にしていただけると幸いです！