Drupal SQLi脆弱性で米CISAが警告｜CVE-2026-9082 PostgreSQL利用サイト悪用確認とWAFルール対応

PostgreSQLバックエンドでDrupalを動かしているサイト管理者にとって、2026年5月下旬は緊張感のある一週間でした。
Drupalコアの「データベース抽象化API」にSQLインジェクション脆弱性が判明し、米CISAが2026年5月22日付で「悪用が確認された脆弱性カタログ（KEV）」に登録。米連邦政府機関には2026年5月27日までの対策を求める異例の短期期限が課されました。

この記事では、CVE-2026-9082（アドバイザリ番号: SA-CORE-2026-004）の技術的背景と、Drupal管理者・運用担当者・SOC側で何を優先すべきかを、攻撃者視点から逆算した防御の組み立て方として整理します。
「うちはMySQLだから関係ない」と思っている方も、依存先の関連サイト・予備環境にPostgreSQLが紛れていないか棚卸しする観点で読んでください。

CVE-2026-9082とは何か（概要と影響範囲）

CVE-2026-9082は、Drupalコアに含まれる「データベース抽象化API」のSQLインジェクション脆弱性です。
Drupalセキュリティチームは独自評価で「Highly Critical（25点満点中20点）」と判定し、NVDのCVSSv3.1ベーススコアは6.5となっています（出典: Tenable Blog）。
評価値だけ見ると中程度に見えますが、悪用が現に確認されている点と、認証なしでHTTPリクエスト経由で攻撃可能な点を踏まえると、現場での扱いは「最高優先度」一択です。

影響を受ける条件はシンプルで、DrupalコアがPostgreSQLをバックエンドDBとして使っている場合のみです。MySQL・MariaDB・SQLiteで運用している環境は本脆弱性の対象外と公表されています。
ただし、対象外データベースを使っているからといって油断するのは禁物です。なぜなら、組織内の別サイト・検証環境・古い予備系がPostgreSQLで動いている可能性があり、棚卸し漏れが攻撃面となるからです。

影響を受けるバージョンと、対応するパッチ版は以下のとおりです（出典: Aviatrix Threat Research / Tenable Blog）。

パッチは2026年5月20日に公開されています。サポート切れ系統（古い9.x など）はそもそも対象に含まれていないため、まずは現行サポート系統のパッチ適用が最優先となります。

攻撃者視点で読み解く脆弱性の仕組み

本脆弱性は、ユーザーが制御できるPHP配列のキー部分が、SQLプレースホルダ構築の経路でサニタイズされずに使われていた点に根本原因があります（出典: Aviatrix Threat Research）。
DrupalはEntityQueryという仕組みでDB問い合わせを抽象化していますが、PostgreSQL向けのEntityQuery condition handlerに、その配列キーがそのまま流れ込んでしまっていました。

攻撃者の発想で考えるとシンプルです。「ユーザーから来る値はバリュー側だけサニタイズしている開発者は多いが、キー側まで疑う実装は少ない」という人間心理の盲点を突いた攻撃面です。
クエリストリングやJSON本文の配列キー名に細工した文字列を仕込み、認証なしで送信するだけで、Drupalが組み立てるSQL文に攻撃者の意図する句が混ざるのが本筋です。

このタイプは、攻撃の試行コストが極めて低い特性があります。ペイロードがリクエストの可視部分に乗るため、攻撃者は自動スキャナで世界中のDrupalサイトに一斉に試打可能で、CISA KEV登録の根拠となる「実悪用」もこの自動化された試行から検出されています。

具体的なエクスプロイトコードはこの記事には載せません。防御に必要なのは「どんな経路でリクエストが来るか」「どこを監視すれば気づけるか」の2点であり、ペイロードそのものを共有するメリットより悪用助長リスクの方が大きいためです。

CISA KEV登録と「2026年5月27日期限」の意味

CISAは2026年5月22日付でCVE-2026-9082をKEVカタログへ追加し、米連邦政府機関（FCEB機関）に対して2026年5月27日までの対策実施を求めました（出典: Security NEXT）。
わずか5日間という短期期限は、CISA KEV対応BOD 22-01の通常運用ではかなり厳しい部類に入ります。それだけ「実環境での悪用が広く観測されている」と判断された証拠です。

日本国内の運営者にとっても、米連邦政府向けの期限が「自分たちには関係ない」とはなりません。CISA KEVは事実上の世界標準の優先度指標として機能しており、各国のセキュリティベンダー・SOC・脅威インテリジェンスサービスがKEV登録を即座に検知ルールへ反映するからです。
KEV登録から数日以内に、攻撃ツールキットやスキャナへの組み込みが進む傾向があり、未パッチサイトは時間との勝負になります。

つまり、日本のDrupal+PostgreSQL運用者にとっての実質的な期限も、CISA期限とほぼ同等の「KEV登録週内」と考えるのが安全側の判断です。
KEV登録の発表当日に対応が始められなかった場合でも、せめて1週間以内にはパッチ適用または明確な暫定緩和を完了させたいところです。

Drupal+PostgreSQL運用者がいま即実施すべきこと

1. 影響有無の確定（10分でできる切り分け）

最初に確定させるべきは「自社サイトが影響対象か」です。Drupal管理画面のステータスレポートからコアバージョンを、サーバ側でDB設定ファイル（settings.php）の `’driver’ => ‘pgsql’` 記述の有無を確認します。
Drupal Composer管理の環境であれば、以下のコマンドで一発で確認できます。

# Drupalコアバージョンの確認
drush status --field=drupal-version

# データベースドライバの確認
drush status --field=db-driver

`db-driver` が `pgsql` を返したら影響対象、`mysql`/`mariadb`/`sqlite` であれば本脆弱性の対象外です。対象外であっても、念のため複数のDrupalインスタンスを抱えている組織は全棚卸しを実施してください。

2. パッチ適用（最優先タスク）

影響対象が確定したら、即座に対応パッチ版へアップデートします。
Composer管理であれば、以下のように対象系統のパッチ版を指定して `composer update` を実行します。アップデート前にはDBバックアップとファイルバックアップを必ず取り、ステージング環境で動作検証してから本番投入が定石です。

# 例: 11.3系をパッチ版へ更新
composer require drupal/core-recommended:^11.3.10 \
                 drupal/core-composer-scaffold:^11.3.10 \
                 drupal/core-project-message:^11.3.10 \
                 --update-with-all-dependencies

# キャッシュクリアと整合性確認
drush cache:rebuild
drush updatedb

運用都合でパッチ適用が遅れる場合は、後述するWAFレイヤでの暫定緩和を必ず併用してください。「次のメンテ枠で対応する」という判断は、本件においては推奨しません。

3. WAFレイヤでの暫定緩和（パッチ適用までのつなぎ）

パッチ即時適用が困難な環境では、Web Application Firewall（WAF）で攻撃ペイロードの遮断を試みます。
本件は配列キー部分の細工が攻撃ベクタなので、WAFのSQLi検知ルールセット（OWASP CRSなど）を有効にしている環境であれば一定の遮断が期待できますが、過信は禁物です。配列キー側の検査がデフォルトで有効でないルールセットもあり、ルール条件次第ですり抜けが起きます。

暫定緩和の現実解としては、以下の3点を組み合わせるのが効果的です。

・OWASP CRSの最新版へ更新: 古いCRSは本攻撃面のカバレッジが不十分な可能性がある
・異常なクエリストリング長・配列キー名のブロックルール追加: SQLキーワード（UNION/SELECT/–など）を含むパラメータ名は拒否
・Drupal管理画面・APIエンドポイントへのアクセス元IP制限: 管理系URLは特定IPからのみ許可

これらはあくまで「パッチ適用までの時間を稼ぐ」措置です。WAFがあるからパッチ適用を後回しにできる、という解釈は本件では成立しません。

4. 侵害の事後検証（過去ログの確認）

パッチを当てて一段落、ではなく、過去にすでに攻撃を受けていないかも確認します。
本脆弱性は公開前から悪用されていた可能性が指摘されており（KEV登録の根拠）、ログを遡って異常リクエストを探す価値があります。

・Webサーバアクセスログの精査: クエリストリング・POST本文に `’` `–` `UNION` `SELECT` 等の異常パターンが含まれるリクエストを抽出
・Drupalのwatchdog（dblog）テーブル: 同一IPからの不自然なエラー連発がないか
・PostgreSQL側のクエリログ: 通常想定されないテーブル名・関数呼び出しが記録されていないか
・ユーザー権限・コンテンツの差分: 想定外の管理者ユーザー追加・ロール変更が起きていないか

侵害の痕跡が見つかった場合は、パッチ適用だけでなくフォレンジック調査・認証情報の総入れ替え・場合によっては環境の再構築まで視野に入れます。

SOC・検知運用での対応ポイント

運用者だけでなく、SOC・EDR・SIEMの運用側でも本件への対応が必要です。
WAFやIDSのシグネチャ更新だけに頼らず、自分たちのテレメトリで「攻撃試行と侵害成功の差分」を見極める検知ルールを組み立てます。

具体的な検知観点は以下です。

・Drupal+PostgreSQL構成のサイト一覧の最新化: アセット管理台帳の鮮度がそのまま検知精度に直結する
・WAFアラートの「ブロック」と「許可」の差分監視: ブロック数だけでなく、すり抜けた疑いのある異常なクエリも拾う
・PostgreSQL監査ログのSIEM取込: 通常運用では発生しないテーブル・関数呼び出しをアラート化
・Drupal管理者アカウントの作成・権限変更イベント: 侵害成功後のラテラルムーブメントの兆候として最重要

EDRやXDRを導入している環境では、Webサーバプロセスからの異常なシェル起動・外部通信もキャッチできます。CMSの脆弱性経由のリモートコード実行は「Webサーバプロセス→/bin/sh→外部HTTPS接続」の連鎖として観測されることが多く、この連鎖をルール化しておくと初動が速くなります。

「うちはMySQLだから無関係」と思った人ほど読んでほしい教訓

本件で最も忘れがちな観点は、「自社の本番サイトが影響対象でなくても、関連サイトやテスト環境は別の話」という現実です。
組織内には、本番・ステージング・開発・サンドボックス・買収先サイト・キャンペーン用予備系など、複数のDrupalインスタンスが分散しているのが普通です。

そして、これらのうち1つでもPostgreSQL構成で放置されていれば、そこが攻撃者の侵入口になります。
Drupalの本体は別件で言えばWordPress・Joomla等にも置き換え可能な普遍的な教訓であり、「メイン環境のパッチ運用」だけでなく「組織全体のCMSインスタンス棚卸し」が本質的な防御です。

中小企業の情シスにとっては、CMS資産台帳の整備こそが今回の最大の学びかもしれません。攻撃者は「メインサイト」を狙うとは限らず、棚卸しから漏れた古いキャンペーンサイトを足がかりにすることが多いのが実態です。

関連する脅威動向と本記事のまとめ

本件のような「データベース抽象化レイヤの脆弱性」は、フレームワーク・CMSの世界で定期的に発見されます。
共通する教訓は、「フレームワークが守ってくれているはず」という前提が時として裏切られること、そして「自前のサニタイズ層」と「フレームワーク層」の二重防御が結局のところ最も信頼できるという点です。

Linuxサーバ側での権限分離・ファイル所有権・SELinuxプロファイル設計といった基礎の積み重ねが、CMS脆弱性悪用時の影響範囲を限定する最後の砦になります。サーバ側の堅牢化については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

クラウド環境でDrupalを運用している場合は、WAF・IAM・VPCセキュリティグループの組み立て方が暫定緩和の実効性を左右します。クラウド側の設計観点については姉妹サイトCloudMaster.JPも参考にしてください。

よくある質問（FAQ）

Q1. パッチ適用後、何を確認すれば「対策完了」と言えますか？
A. Drupalコアのバージョンが対応パッチ版以降であること、`drush updatedb` 完了、キャッシュ再構築完了、管理画面ステータスレポートで赤エラーがゼロ、過去ログに異常リクエストの痕跡がないこと、の5点を満たせば「対策完了」と判定できます。

Q2. PostgreSQL利用ですがDrupal管理画面に外部からアクセスできない構成です。それでも危険ですか？
A. 危険です。本脆弱性は認証なしで悪用可能なため、Drupalの公開ページ側のエンドポイントから攻撃が成立します。管理画面の保護だけでは防げません。

Q3. WAFがあればパッチを後回しにしてもよいですか？
A. 推奨しません。WAFは攻撃面の一部しかカバーできず、新しい亜種・回避ペイロードが出れば検知漏れが起きます。WAFはあくまで「パッチ適用までのつなぎ」です。

Q4. Drupalサポート切れの古いバージョンを使っています。どうすればいいですか？
A. サポート切れ系統は本脆弱性の対象外として扱われますが、それは「修正パッチが提供されない」ことを意味します。本件以外にも未修正の脆弱性を抱えている可能性が高く、サポート対象系統への移行が根本対策です。

Q5. 自社にDrupalがあるか把握できていません。どう棚卸しすればいいですか？
A. 外部からは「サイトのHTML中のmetaタグ（generatorタグ）」「特定のJS/CSSのパス（/sites/default/files等）」「特定のレスポンスヘッダ」で簡易判定できます。内部資産管理台帳と社内DNSレコードを突き合わせ、外向きスキャンと合わせて棚卸しするのが定石です。

Q6. パッチ適用後にサイトが壊れることはありますか？
A. マイナーバージョン内のセキュリティパッチであれば後方互換性は基本維持されますが、カスタムモジュール・テーマがコアのprivate APIに依存している場合は影響を受けることがあります。必ずステージング環境で検証してから本番適用してください。

Q7. 本脆弱性の悪用兆候を24時間体制で監視する人員がいません。どう対応すればいいですか？
A. ログをSIEMやセキュリティ運用代行サービス（マネージドSOC）に送り、検知ルールを共有するのが現実解です。中小企業向けにも比較的安価なマネージドSOCサービスが増えており、自前24時間体制よりも費用対効果が高いケースが多いです。

本記事のまとめ

CVE-2026-9082は、PostgreSQLを使うDrupal環境を直撃する高クリティカルなSQLインジェクション脆弱性です。
CISA KEV登録から短期間で攻撃ツールキットへの組み込みが進む傾向があり、対策の優先度は最上位として扱うべき案件です。

運用者は、影響範囲の棚卸し、即時パッチ適用、WAFでの暫定緩和、過去ログでの侵害確認、の4ステップを最短経路で進めてください。
SOC・SIEM運用者は、Drupal+PostgreSQL構成資産の最新化と、Webサーバプロセスからの異常挙動の検知ルール整備が当面の焦点です。

本件のような「フレームワーク内部の抽象化レイヤの脆弱性」は、防御側にとって発見コストが高い性質を持ちます。だからこそ、外形からの攻撃面棚卸しと、内部からの権限分離・監視の両面で備える基本動作が、結局のところいちばん効きます。