Drupal のセキュリティは、オープンソース CMS の世界で、公開されている手順そのものが評判より優れている数少ない領域のひとつです。Drupal セキュリティチームは決まった開示スケジュールを運用し、すべてのアドバイザリを文書化された数値尺度で採点し、コアと数万のコントリビュートプロジェクトにまたがる修正を調整しています。
現場での実績は、その手順が受けるに値する評価より悪いのが実情です。Drupal のサイトは実際に侵害されますが、その原因が誰も知らなかったことであるのは、ほとんどありません。アドバイザリは予定どおり、水曜日に公開されていました。パッチが本番に届いたのは翌週でした。この記事が扱うのはその隙間であり、堅牢化もファイアウォールもファイルパーミッションも、その隙間を生き延びられるものにするか、短くするために存在しています。
リスクを決めるのは、たまたま動かしているモジュールではなく、どれだけ速くパッチを当てられるかです。 コアのアドバイザリは毎月の水曜日の枠で、コントリビュートプロジェクトのアドバイザリは毎週水曜日に公開され、いずれも公開された尺度で 0 から 25 の点が付きます。きわめて重大なコアの欠陥は、開示から数時間のうちに悪用されてきました。2014年の SQL インジェクションのアドバイザリのあと、公式の指針は、7時間以内にパッチを当てていないサイトはすでに侵害されたものとして扱え、というものでした。コアのパッチを一営業日以内に展開できないサイトは、存在するリスクのほぼすべてを抱えています。
Drupal のセキュリティアドバイザリは実際どう運用されているのか
Drupal サイトを運用している人の多くは、この手順の文書を読んだことがありません。もったいない話です。どれだけの猶予が、どんな形で、どの曜日に与えられるのかが、そこにはそのまま書かれているからです。
リリースの枠
セキュリティチームはカレンダーに沿って公開します。コントリビュートプロジェクトのアドバイザリは毎週水曜日に出ます。コアは月の第1水曜日にバグ修正と機能リリースの枠を、第3水曜日にセキュリティリリースの枠を持ちます。セキュリティリリースの時期に関する文書に定められているとおりです。枠があることは、何かが出る約束ではありません。管理者がどの日を見張ればよいかを知るために存在しています。
事前の予告が出ることもあります。きわめて重大なコアリリースの前には、チームが公開の予告を、たいていは月曜日に出します。PSA-2026-05-18 は 2026年5月20日のリリースについてそれを行い、17:00 から 21:00 UTC という枠を示したうえで、まず自分のブランチの最新パッチリリースへ更新しておくよう所有者に伝えました。アップグレードの問題を早めに表面化させるためです。得られる猶予は、長くても二日です。
コアのアドバイザリとコントリビュートプロジェクトのアドバイザリ
この二つは、保証の異なる別々の仕組みです。コアのアドバイザリは、サポート対象のマイナーブランチを同時に二本、つまり最新とそのひとつ前を対象にします。実際にはコアのリリーススケジュールにより 11.4.x と 11.3.x が該当し、Drupal 10 が 2026年12月9日にサポート終了を迎えるまでは 10.6.x も対象に残ります。2026年9月初旬の時点で、最新リリースは 11.4.5、11.3.16、10.6.15 です。Drupal 12.0.0 と 11.5.0 は 2026年12月7日の週に予定されており、その時点で 11.3.x と 10.6.x のサポートは終わります。
コントリビュート側の対象範囲は任意加入で、条件付きです。アドバイザリが出るのは、セキュリティアドバイザリの手続きと権限に関するポリシーのもとで、メンテナが申請して承認を受けたプロジェクトの、サポート対象メジャーブランチにおける安定版リリースだけです。アルファ版、ベータ版、リリース候補版のモジュールはこの仕組みの外にあり、メンテナが一度も申請しなかったモジュールも同じです。どちらの事実も、サイトが平常どおり動いているかぎり管理画面からは見えません。
本当の負担は件数です。2026年8月26日水曜日、チームは一日でコントリビュートプロジェクトのアドバイザリを10本公開し、いずれも中程度に重大でした。60本のモジュールを動かしているサイトなら年に何度も名指しされることになり、その流れは時間がたつほど、コアの緊急事態より大きな費用になります。
リスクスコアと、それが CVSS ではない理由
すべてのアドバイザリには 25点満点の数値が付きます。この尺度は NIST の Common Misuse Scoring System、すなわち NISTIR 7864 に基づいており、セキュリティリスクレベルの定義ページに文書化されています。六つの指標が入力になります。攻撃の複雑さ、必要な認証、機密性への影響、完全性への影響、既知のエクスプロイトの有無、そして対象の分布です。区分は、重大ではないが 0 から 4、軽度に重大が 5 から 9、中程度に重大が 10 から 14、重大が 15 から 19、きわめて重大が 20 から 25 となります。
対象の分布がスコアに入るため、まれな構成でしか成立しない欠陥は、CVSS で付くはずの値より低く出ます。2026年6月17日の SA-CORE-2026-005、CVE-2026-55803 として追跡されている PHP オブジェクトインジェクションの問題は 18 点で、まさにその理由から、きわめて重大ではなく重大と評価されました。
コントリビュートモジュールがサポート対象外になるとき
セキュリティチームは、ボランティアのメンテナに修正を強制できません。メンテナが応答しなくなった場合、文書化された手順では、繰り返し連絡を試みたうえでプロジェクトをサポート対象外と表示します。以後、プロジェクトページはサイト所有者に対して、活発に保守されている代替を選ぶか、誰かに費用を払って不具合を直させ、モジュールを再公開できるようにするよう警告します。
その助言は正しく、そして高くつきます。モジュールがサポート対象外と表示される頃には、たいていそれは基幹部品になっており、置き換えにはデータ移行、テンプレートの変更、そして回帰テスト一式が伴うからです。安く動ける瞬間は、放棄される一つ前のリリース、つまりメンテナが静かになったが何もまだ壊れていない時点であり、そのときに見ている人はほとんどいません。
Drupal 7 はサポート終了で、延長サポートは安全と同じ意味ではない
Drupal 7 は 2025年1月5日にサポート終了を迎えました。PSA-2025-01-06 で告知されたとおりです。その日以降、セキュリティチームは Drupal 7 のコアと、そのコントリビュートモジュールおよびテーマに対する支援とアドバイザリの提供をやめました。告知は、Drupal 7 のセキュリティ上の問題が今後は調整なしに公開されうること、そしてゼロデイが起こりうることを明示していました。
商用の延長サポート市場は存在します。Drupal Association は Extended Security Support Provider Program のもとで、HeroDevs や Tag1 Consulting を含むベンダーを認定しており、実際にパッチを出しています。何もないよりは良いのですが、サポートされていることと同じではありません。ベンダーは、自ら対象と決めたコアと一定範囲のモジュールを、自らの日程で、料金を払う顧客のために修正します。サイトが依存している残りのエコシステムは範囲外です。
サポートの切れた CMS は、取引先のセキュリティ質問票に答えるときにも、事故のあと保険会社に説明するときにも弁明しにくくなります。Drupal 移行の費用、選択肢、期限を扱った解説で、出口にかかる費用をまとめています。
歴史が示した型、Drupalgeddon とその後
パッチの速さについての共同体の考え方は、三つの事件が形づくりました。いずれもコアのインジェクションまたはリモートコード実行の欠陥であり、いずれも数時間から数日のうちに自動化された大規模な悪用を招きました。
2014年10月の七時間
最初の Drupalgeddon は SA-CORE-2014-005 で、2014年10月15日に公開されました。CVE-2014-3704 は Drupal 7 のデータベース抽象化層にあった SQL インジェクションの欠陥で、匿名ユーザーから悪用でき、25点満点の25点が付きました。7.32 より前のすべての Drupal 7 サイトが影響を受けました。
これを画期的な事件にしたのは、その後の続報です。PSA-2014-003 は、告知から数時間のうちに自動化された攻撃が未パッチのサイトの侵害を始めたこと、そして公開の7時間後にあたるその日の 23:00 UTC までにパッチを当てていないサイトは侵害されたと考えるべきだと所有者に伝えました。侵害されたかもしれない、ではありません。侵害された、です。攻撃者がすべてのデータを持ち出し、バックドアを設置した可能性があるとも警告しており、これこそがパッチの問題をインシデント対応の問題に変えるものです。
Drupalgeddon 2 と 3
2018年3月28日に公開された SA-CORE-2018-002 は CVE-2018-7600 で、Drupal 7 と Drupal 8 の複数のサブシステムにまたがるリモートコード実行の欠陥であり、25点中24点でした。Drupal 7.0 から 7.57 まで、および 8.5.0 までの 8.x ブランチが影響を受け、公開のエクスプロイトはおよそ二週間で現れました。
その四週間後、2018年4月25日に SA-CORE-2018-004 が出ました。CVE-2018-7602 は関連するコードにあったもうひとつのリモートコード実行の問題で、25点中20点、しかもアドバイザリはすでに実際に悪用されていると述べていました。教訓はその間隔にあります。3月にパッチを当てたあと注意を払うのをやめたサイトは、4月に再び無防備になりました。
2026年5月と、変わっていないこと
この型は過去の話ではありません。SA-CORE-2026-004 は 2026年5月20日に公開されました。CVE-2026-9082 は PostgreSQL を使うサイトに影響する SQL インジェクションの欠陥で、25点中23点のきわめて重大と評価され、8.9 から 11.3.9 までのすべてのブランチが対象でした。5月22日の 04:30 UTC、アドバイザリは実際の悪用の試みが検知されたことを記録するよう改訂されました。公開から観測された攻撃までは48時間を切っています。
以上のどれも、セキュリティチームへの批判ではありません。二日の予告を出し、告知した枠のうちに出荷し、状況が変わればアドバイザリを更新しました。破綻するのは運用する側です。アドバイザリからパッチ適用済みの本番環境まで、練習された経路がないのです。
Drupal のセキュリティが実際に破れる場所
見出しを取るのはコアですが、それは最も小さな部分です。私たちが監査するサイトで問題になる発見が、パッチの当たっていないコアリリースであることはめったにありません。コアの更新は管理画面に現れ、誰かが気づくからです。露出は別の場所にあります。
誰も持っていないモジュールの台帳
中規模の典型的な Drupal サイトは 40 から 80 のコントリビュートモジュールを動かしており、それぞれ別のメンテナが別の周期で面倒を見ています。その場で誰も答えられない問いは、そのうちどれに今も活動中のメンテナがいるのか、どれがアドバイザリの方針の対象なのか、そしてどれが二年間ひとつもコミットされていないのか、です。その一覧を作るのに要するのは、午後の数時間です。
誰も持ち主のいないカスタムモジュール
最もよくある深刻な発見は、すでに離れた業者が書いたカスタムモジュールです。たいていは連携めいたことをしています。CRM への送信、専用のフォーム処理、決済のコールバックといったものです。古い API に対して書かれ、テストがなく、それが何を検証しているのかチームの誰も説明できません。カスタムコードは、定義からしてアドバイザリの仕組みの外にあります。そこに SQL インジェクションがあると水曜日のメールが教えてくれることはなく、ステータスレポートはすべて最新と表示します。ほかのソフトウェア開発の仕事と同じレビューの規律が必要です。
Drupal の下にあるスタック
Drupal は PHP であり、PHP のバージョンは独自の日程でサポート終了を迎えます。CMS の階層では完全にパッチが当たっていても、一年前にセキュリティ修正が止まった PHP バージョンの上で動いていることはありえます。ホスティングが保守の話題に一度も入っていなかったからです。ファイルパーミッションと所有権に関する指針は、ウェブサーバーが自分の実行するファイルを書き換えられてはならないという原則に立っていますが、デプロイスクリプトが簡単になるという理由で、書き込み可能なコードディレクトリのまま動いているサイトは少なくありません。
Drupal サイトは本来どう更新されるべきか
答えは退屈で、だからこそ実装されないままになります。アドバイザリから本番までの練習された経路を不要にするツールは存在せず、それを一度作る費用は、最初の緊急事態より安く済みます。
Composer のワークフロー
Drupal 8 以降はすべて Composer プロジェクトです。コアのパッケージを依存関係ごと更新し、そのあとデータベース更新を適用してキャッシュを再構築します。
1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild
Drush は update.php に置き換えられます。前後にステータスレポートを確認してください。大事なのはコマンドそのものではなく、それを本番以外のどこかで先に実行することです。
本当に複製になっているステージング
ステージング環境が役に立つのは、それが本番を写しているときだけです。同じモジュール構成、同じ PHP バージョン、そして最近のサニタイズ済みデータベース。古びたステージングサイトは、何の意味もない緑色の結果を出します。それは自信を製造する分だけ、ステージングがないより悪いのです。
手順は、本番をステージングへ落とし、更新を適用し、データベース更新を実行し、商業的に意味のあるページとフォームを一通り歩いてから、本番へ展開する、というものです。動くパイプラインがあれば 45 分から 90 分。なければ一日半かかります。
自動化と、その限界
依存関係の自動更新がいちばん効くのは、件数が多く深刻度の低い側、つまりコントリビュートモジュールの流れです。モジュールの更新ごとにプルリクエストを一本開き、それぞれに対してテストを走らせるボットは、毎月の手作業の一掃をレビュー待ちの列に変えます。コアも同じ方向へ進んでおり、Automatic Updates の取り組みは Package Manager モジュールの上に作られています。このモジュールはコアに同梱されていますが、まだ実験的です。
現実的な時間の予算
保守されている Drupal サイトには、日常的なモジュール更新でおおよそ月に半日、加えて該当するコアのセキュリティリリースごとに 1 時間から 3 時間かかります。年に 1 本か 2 本ある、その晩のうちに対応しなければならないきわめて重大なリリースのための余裕も足してください。ほとんどの社内チームが予算化してこなかったのがこの数字であり、だからこの作業は後回しになります。
パッチ適用の先にある堅牢化
堅牢化はパッチ適用の代わりにはなりません。公開された脆弱性のうち、自分の環境で実際に悪用できるものの数を減らし、パッチをすぐ出せないときに時間を稼ぎます。Drupal 固有の項目は安く、そして一度やれば残ります。
信頼するホストとファイルシステム
信頼するホストのパターンを設定してください。Drupal は Symfony の trusted host の仕組みを使い、settings.php の trusted_host_patterns 設定に、サイトが応答するドメインに一致する正規表現として書きます。それ以外の Host ヘッダーを持つリクエストは 400 で拒否されます。設定がないと、攻撃者は偽造したヘッダーでパスワード再設定リンクやキャッシュされた絶対 URL を汚染できます。
公開して読まれては困るものにはプライベートファイルシステムを使い、公開ファイルディレクトリの中で PHP が実行されないようにしてください。Drupal は Apache 下で実行を止める .htaccess ファイルを同梱していますが、nginx には相当する置くだけのファイルがなく、規則をサーバー設定に手で書く必要があります。何年も前に Apache から nginx へ移ったサイトは、この保護を音もなく失っていることが多くあります。
そのうえで所有権のモデルを適用します。ディレクトリは 750、コードファイルは 640、ファイルディレクトリはウェブサーバーだけが書き込め、settings.php は所有者だけが読める状態です。
権限、管理経路、そして見直しの一巡
管理経路を制限してください。編集者が三つのオフィスから働くサイトで、ログインと管理のパスがインターネット全体から到達できてよい理由はありません。IP の許可リストか認証プロキシがあれば、資格情報を狙う攻撃の一群を取り除けます。
次に権限の表を監査します。モジュールを入れるたびに表は育ち、見つかるものはほぼいつも同じ形です。テキストフィルタを管理できる編集者ロール、あるいは任意の PHP を実行できるロール。どちらも、盗まれた編集者パスワードをリモートコード実行に変えます。つまりフィッシングメールがサーバーの侵害になります。
何かを議論する前に、まず Security Review モジュールを走らせてください。手でやると面倒な確認を自動化してくれます。ファイルシステムの権限、安全でないテキストフォーマット、コンテンツ内の PHP や JavaScript、エラー表示の露出、アップロード可能な拡張子、失敗したログイン、危険な権限、そして信頼するホストの設定です。2026年1月に公開されたバージョン 3.1.3 は、Drupal 11 に加えて Drupal 10.3 以上に対応します。
ファイアウォールが買えるものと、買えないもの
ウェブアプリケーションファイアウォールは仮想パッチであり、Drupal Association がセキュリティチームとともに運営する有料サービス Drupal Steward も、まさにそう位置づけられています。特定のきわめて重大なコアの脆弱性にネットワーク層で緩和を当て、アドバイザリから展開までの隙間のあいだサイトを守ります。公開されている価格は、月に 100万 HTTP リクエストを処理するサイトで 20 米ドル未満、1000万 を超える規模で 100 米ドル未満です。
限界はプロジェクト自身が述べています。すべての問題をこの方法で緩和できるわけではなく、仕組みが覆うのはウェブサーバーへのリクエストを通じて悪用される脆弱性だけです。ファイアウォールは、侵害された管理者パスワードにも、悪意あるモジュール更新にも、自分たちのコードの欠陥にも何もしてくれません。パッチ適用の窓を広げる理由ではなく、その窓に対する保険として扱ってください。WordPress セキュリティ強化チェックリストでも、同じ見方をとっています。
侵害の費用と、復旧の実際
Drupal の侵害からの復旧はパッチではありません。攻撃者がコード実行にたどり着いた時点で、作業上の前提は、ファイルが書き込まれ、資格情報が持ち出され、永続化の仕組みが設置された、というものになります。2014年にセキュリティチームが Drupal 7 の所有者に伝えたのが、まさにこれです。侵害されたサイトをその場で掃除するのは、修復の装いをまとった当て推量です。
弁明できるやり方は、バージョン管理から新しいホスト上にコードベースを作り直し、検査したうえでコンテンツとアップロードされたファイルだけを戻し、サイトが保持していた資格情報をすべて更新し、侵害されたディスクイメージを削除せずに保全することです。最後の一手は、圧力の下で人が省いてしまうものであり、そして何が起きたのかを示す唯一の証拠です。
商業的な費用は、作り直しの部分であることはめったにありません。停止時間、フォレンジック作業、顧客への説明、そして規制上の手続きです。インシデント下での作り直しは、通常 5,000 から 20,000 ポンドのエンジニアリングであり、たいてい合計の中でいちばん小さな項目になります。
英国のデータ保護上の義務
個人データにアクセスされた、あるいはその可能性がある場合、UK GDPR の時計は、調査を終えたときではなく、認識した時点から動き始めます。ICO の侵害に関する指針は、届出が必要な侵害を不当な遅滞なく、認識してから 72 時間以内に報告することを求めており、それより長くかかった場合は理由を示さなければなりません。侵害が個人の権利と自由に高いリスクをもたらす可能性が高い場合には、その個人にも不当な遅滞なく知らせる必要があります。
ICO は、全体像がつかめていないことは期限に間に合わなくてよい理由にならないと明言しています。分かっていることを報告し、あとから補うのです。求められたときに届け出なかった場合、最大で 870万ポンド、または全世界売上高の 2 パーセントの制裁金が科されることがあります。
この時計こそ、フォレンジックの問いが重要になる理由です。ログがなく、どのバージョンが動いていたかの記録もないサイトは、どのデータにアクセスされたかを言えないので、結局は最悪の場合を報告することになります。これが、事故のあとではなく事故の前にウェブサイトセキュリティ監査を行うべき理由です。
Drupal のセキュリティ保守契約に含めるべきもの
更新を適用すると約束するだけの保守契約は、買う価値がありません。更新を適用するのは、簡単な方の半分だからです。お金を払って手に入れるのは、きわめて重大なアドバイザリが出た日の対応経路であり、それが機能することを示す成果物はリハーサルです。
払う価値のある範囲は、自分のモジュール構成に合わせたアドバイザリの監視、ステージングとテストとロールバック計画を伴う月次のパッチ周期、きわめて重大なコアリリースに備えた時間外対応の合意された枠、放棄されたモジュールの四半期ごとの見直しと代替の費用見積もり、PHP とプラットフォームのバージョン追跡、そして年次の設定レビューです。
英国では、監視だけの取り決めはおおむね月 250 から 450 ポンドです。ステージング、テスト、デプロイまで含む中規模サイト向けの保守契約は月 600 から 1,500 ポンドに近く、モジュール数とカスタムコードの量に応じて上下します。どちらの回でどれだけ回帰テストが必要になるかを決めるのが、その二つだからです。制作会社の日額 600 から 900 ポンドに対して、その帯の上端はエンジニア二日分ほどを買うことになります。Drupal 開発者の単価と見極め方に、その数字をまとめています。
隙間を閉じる
Drupal は、比較しうるほぼどのプラットフォームより多くの予告と構造を与えてくれます。アドバイザリは日程どおりに出て、きわめて重大なリリースは二日の予告を伴って届きます。一行のパッチを展開するのに二週間かかるサイトには、そのどれも効きません。
Mecanik は、Drupal のパッチ適用と堅牢化をウェブサイトセキュリティ監査と継続的なソフトウェア開発の仕事の一部として扱っています。最初の関わりはたいてい修正ではなく棚卸しです。自分のモジュールのどれが今もサポートされているかを言えないサイトが、ほとんどだからです。プラットフォームそのものを検討しているなら、2026年の Drupal ウェブ開発ガイドがその話を扱っています。
よくある質問
Drupal のセキュリティ更新はどのくらいの頻度で出ますか。 コントリビュートプロジェクトのアドバイザリは毎週水曜日に公開され、Drupal コアは毎月第3水曜日にセキュリティリリースの枠を持ちます。ただし枠があることはリリースを保証しません。きわめて重大なコアリリースの前には、通常およそ二日前に公開の予告が出され、日付と時間の枠が示されます。
Drupal のセキュリティリスクスコアが 25点中20点とは、どういう意味ですか。 Drupal は NIST の Common Misuse Scoring System に基づく仕組みで、すべてのアドバイザリに 0 から 25 の点を付けます。攻撃の複雑さ、必要な認証、機密性と完全性への影響、既知のエクスプロイトの有無、そして影響を受けるサイトの多さを組み合わせたものです。20 から 25 はきわめて重大であり、その日のうちにパッチを当てるべきという意味になります。
Drupal 7 は 2026年でもまだ安全に運用できますか。 できません。Drupal 7 は 2025年1月5日にサポート終了を迎え、Drupal セキュリティチームはそのコア、コントリビュートモジュール、テーマに対するアドバイザリを発行しなくなりました。したがって欠陥は、調整された修正のないまま公開されえます。商用の延長サポートはベンダーの条件で定められた範囲のコードだけを対象とし、移行のあいだは助けになりますが、サポートされていることと同じではありません。
攻撃者はどのくらい速く Drupal の脆弱性を悪用しますか。 最悪の場合は数時間です。2014年10月の SQL インジェクションのアドバイザリのあと、Drupal セキュリティチームは、7時間以内にパッチを当てていないサイトはすでに侵害されたと考えるよう所有者に伝えました。2026年5月には、きわめて重大なコアの SQL インジェクションに対する悪用の試みが、公開から二日足らずで実際に検知されています。
ウェブアプリケーションファイアウォールがあれば、Drupal のパッチ適用は不要になりますか。 なりません。Drupal Steward のようなファイアウォールは、ウェブリクエストを通じて悪用される特定のきわめて重大なコアの欠陥に仮想パッチを与え、展開までの時間を稼ぎます。盗まれた管理者パスワード、侵害されたモジュール、自分たちのコードの欠陥には対処できないため、隙間のリスクを減らすものであって、隙間を閉じるものではありません。
コメント