Drupalサイトに認証不要の乗っ取り脆弱性、米政府が5月27日までの修正を命令

米政府が5月27日までの修正を命令、対応猶予はわずか5日

米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は5月22日、コンテンツ管理システム（CMS）のDrupalに見つかったCVE-2026-9082を「実際に攻撃されている脆弱性リスト」（KEV）に追加し、連邦機関に対して5月27日までの修正を命じました。開示からKEV追加までわずか2日、期限まではさらに5日しかありません。CISAがここまで短い対応猶予を切るのは、F5 BIG-IPのCVE-2025-53521以来の異例の対応です。

焦点になっているのは、Drupalのデータベース抽象化層（サイトとデータベースの間にいる、SQLを安全に組み立てるための部品）に潜んでいたSQLインジェクションです。SQLインジェクションは、攻撃者が入力フォームやURLパラメータから細工した文字列を送り込み、本来読めないはずのデータベースを直接いじる古典的な攻撃で、CMS界隈では「もうとっくに枯れたはずの問題」と扱われていました。それが、サイトのログイン画面やAPIに匿名のままアクセスするだけで成立する。しかも対象はDrupal 8.9から最新の11.3まで、ほぼ全バージョンに及びます。

幸い、影響を受けるのはデータベースにPostgreSQLを使っているDrupalサイトに限られます。多数派であるMySQL・MariaDB・SQLite運用のサイトは対象外です。とはいえ「PostgreSQLだけ」と聞いて安心するのは早く、政府・大学・大規模メディアといった「セキュリティ要件が厳しいからこそDrupalを選んだ」層は、ほぼPostgreSQL構成です。日本でもデジタル庁の政府統一Webサイトの構築基盤に採用されている系統で、無関係でいられる管理者はそう多くありません。

以下、KEV入りまでの数日で何が起きたか、攻撃の中身は何なのか、自社のDrupalがすでに踏まれていないかをどう確認するか、そして暫定対策と本格対策を順に書いていきます。CMSの運用に責任を持っているWeb担当者・インフラ担当者を念頭に置いた内容です。

パッチ公開からKEV入りまでに起きたこと

Drupal Security Teamが今回の対応で異例だったのは、本番のパッチを公開する2日前にあたる5月18日、「来週、高度クリティカルなセキュリティリリースを出す」という事前告知（PSA-2026-05-18）を流したことです。内容は伏せたまま「Drupal 10と11の全サポートブランチが対象」とだけ伝え、管理者にメンテナンス枠の事前確保を促しました。「金曜にパッチ出すから空けておけ」という、極めて緊張感の高い告知です。

5月20日、予告どおりにSA-CORE-2026-004が公開され、Drupal 10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10とサポート終了したDrupal 8.9・9.5向けの例外パッチが一斉に配布されました。Drupalが自社のリスクスケールで20/25（Highly Critical）を付けたのは数年ぶり。パッチdiffはGitHub上で誰でも閲覧でき、ここから「修正の差分を逆算すれば攻撃方法がわかる」という時計の針が動き始めます。

案の定、翌5月21日にはセキュリティ研究企業Searchlight Cyberが技術解説と動くPoC（攻撃を再現するための実証コード）を2種類公開。攻撃経路は2つに整理されました。1つはPOST /user/login?_format=jsonのJSONログインAPI経由（時間ベースの盲目SQLインジェクション）、もう1つはGET /jsonapi/node/article?filter[...]のJSON:APIフィルタ経由（エラー応答からの抽出）。後者にいたっては「GETリクエスト1本」で脆弱性の判定ができるため、攻撃者は深く考えず網羅スキャンに走れます。

この時点で「パッチを当てたかどうか」のレースが本格化し、CISAは5月22日付でCVE-2026-9082をKEVカタログに追加。CISA KEVカタログは「すでに実際の攻撃で使われている脆弱性」だけを集めた一覧で、連邦機関は通常2〜3週間以内の修正を求められます。それが今回は5月27日、開示からたった7日。CISAが過去にここまで短い期限を設定したのは、IvantiのCVE-2024-22024やF5のCVE-2025-53521といった「実害が観測されている」系の少数例だけで、本件もそこに並びました。

事前告知から期限までの流れ

事前告知から「攻撃15,000件観測」までの流れを時系列で並べると、たった9日間の出来事だとわかります。

← スワイプで移動

なぜPostgreSQLだけが狙われるのか

DrupalはMySQL・MariaDB・PostgreSQL・SQLiteなど複数のデータベースに対応するため、データベース抽象化層という共通インターフェースを挟んでいます。そこで「データベースごとの方言を吸収するための上書き処理」が用意されており、今回問題が出たのはPostgreSQL向けの上書きの一つでした。具体的には、IN演算子（「Aが指定した集合のどれかに当てはまるか」を判定するSQL）を大文字小文字を区別せずに処理するため、入力された配列をLOWER()に通して比較する処理が独自に書かれていました。

問題は、ここでPHPの配列キーがそのままSQLのプレースホルダ名（クエリ内で値を差し込む位置を示すラベル）として埋め込まれていたことです。Drupalの基本設計では「配列のキーは常に0、1、2…の整数」という前提があり、上書きコードもそのつもりで書かれていました。しかしJSON入力では攻撃者が好きな文字列をキーに指定できる。Searchlight Cyberの技術解説によれば、JSONログインAPIに対して次のような構造のリクエストを送ると、キー文字列がそのままSQLに混入します。

POST /user/login?_format=json
Content-Type: application/json

{
  "name": {
    "0": "drupal",
    "0||1/(SELECT CASE WHEN (SELECT name FROM users_field_data WHERE uid = 1) LIKE 'drupal' THEN 0 END)": "drupal"
  },
  "pass": "drupal"
}

2つめのキー文字列がそのままSQLに合流すると、PostgreSQLが「ゼロ除算」を起こすかどうかで条件の真偽が応答に出ます。真ならHTTP 500、偽ならHTTP 400。この差を見ながら1ビットずつ問い合わせを重ねれば、攻撃者は管理者ユーザー名・パスワードハッシュ・非公開ノード・APIキーといったあらゆるデータを順に抜き出せる。Horizon3.aiの解説でも、認証なしで届く2つの経路（JSONログインとJSON:APIフィルタ）のいずれかで完全な無認可データベースアクセスが成立すると整理されています。

パッチ自体は3行で済む単純なもので、配列をarray_values()に通してキーを整数に戻すだけ。長年「PHPは配列キーが任意の文字列を取れるから危険」と言われてきた典型例で、PostgreSQL固有のオーバーライドという目立たない場所に8年以上潜んでいたことになります。MySQL向けの処理パスでは同様のLOWER()処理が不要で配列キーを使っていなかったため、データベースの違いが防波堤になっていた格好です。

すでに65カ国・6000サイトに攻撃試行

CISAがKEV入りを判断する根拠になった「実害の観測」も、すでに各社から数字が出ています。CDNとWAFを提供するImpervaの観測レポートによれば、5月20日のパッチ公開以降、自社が守るインフラ全体で15,000件以上のCVE-2026-9082を狙った攻撃を確認。標的になったサイトは65カ国・約6,000サイトに及び、業種別ではゲーム業界と金融サービス業界で全攻撃の約50%を占めました。

観測されている攻撃の中身は、現時点では「探査と検証」が主流です。/jsonapi/node/articleへのGETリクエストに細工したfilter[t][condition][operator]=INを付けて応答コードの差を見るもの、"0), 0)) OR 1=1 --"のような配列キー注入、PostgreSQL関数を呼んで応答時間を測る時間ベース判定、UNION型の構文崩しなどが大半。本格的なデータ抜き取りや権限昇格に進む前の「どこが脆弱か」を探っている段階で、ここで露出に気付けないと攻撃者の名簿に乗ります。

注意したいのは、Impervaの数字はあくまで「同社のWAFを通った範囲」での観測値だという点です。WAFを置いていないDrupalサイトに対する直接スキャンは別経路で進んでおり、実際の攻撃試行は表に出ている数字より相当多いと見ておくべきでしょう。The Hacker Newsの報道でも、PoC公開からの24時間で大規模なスキャン活動が確認されたことが伝えられています。

自分のサイトが対象かどうかを確認する

最初に判断すべきは「データベースがPostgreSQLかどうか」です。Drupalの管理画面から確認するなら、管理メニューの「レポート」→「ステータスレポート」を開き、Database項目の表示を見ます。「PostgreSQL」と書かれていれば対象。MySQL・MariaDB・SQLiteであれば今回は無関係です。サーバーに直接ログインできるなら、Drupalのルートディレクトリでdrush statusを実行すれば「Database driver」の行で同じ情報が拾えます。

PostgreSQL構成だった場合、次に確認すべきはDrupalのコアバージョンです。drush status --field=drupal-versionまたは「ステータスレポート」のDrupal Version欄で確認できます。前述のとおり、10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10未満であれば該当します。Drupal 8.9・9.5系も最終サポート切れですが、SA-CORE-2026-004に例外パッチへのリンクがあり、サポート終了済み環境にも適用可能です。

侵害有無の手がかりとして、Webサーバーのアクセスログを/user/login?_format=jsonや/jsonapi/node/へのアクセスで検索してください。とくにfilter[とoperator=INまたはconditionを含むGETリクエストが大量に並んでいる場合、CVE-2026-9082の探査スキャンを受けている可能性が高い。リクエスト元IPが短期間で大量に叩いている場合は遮断対象になります。

データベース側では、users_field_dataテーブルやkey_valueテーブルへの異常な参照、PostgreSQL本体のログに残るSQLSTATE[HY093]（無効なパラメータ番号）の連続発生が確認指標になります。攻撃者が成功側に振れていれば、新規ユーザーの追加・管理者ロール付与・user__rolesテーブルへの不自然なINSERTが残るので、最近の変更履歴を直接覗いておくのが堅実です。

恒久対策と「今すぐできる暫定処置」

恒久対策はパッチを当てる以外にありません。SA-CORE-2026-004に従って、自分の系列に対応した最新版（10.4.10 / 10.5.10 / 10.6.9 / 11.1.10 / 11.2.12 / 11.3.10）にアップグレードします。Composer管理であればcomposer update drupal/core --with-all-dependenciesのあとdrush updatedb -yで1〜2分作業です。ステージング環境を持っていない本番1台運用の場合は、データベース・コードの両方を必ずバックアップしてから実施してください。

事情があって即時パッチを当てられない場合、暫定的な穴埋めとして検討できるのは次の3点です。1つめはJSON:APIの無効化。JSON:APIモジュールを業務で使っていないなら、管理画面の「Extend」から無効化することで主要な攻撃経路の一つを塞げます。2つめはJSONログインAPIの無効化。/user/login?_format=jsonを含むRESTのlogin resourceを使っていないなら、RESTモジュール側で停止します。3つめはWAFでの遮断で、/user/login?_format=jsonと/jsonapi/node/へのリクエストでJSONボディやfilter[パラメータに非数値キーが含まれるものを拒否すれば、現在観測されている攻撃の大部分は止まります。

ただし、いずれも応急処置です。Tenableの分析でも、JSON以外の経路（コンタクトフォーム経由など）で同じ脆弱性が成立する可能性に触れており、「APIさえ閉じれば安全」と判断するのは危険です。WAFも、攻撃者がエンコーディングを変えればすぐに迂回されることが知られています。最低でも翌週の業務時間内にパッチ適用枠を確保しておくことが必要です。

国内では政府・大学・大規模メディアが採用

Drupalは日本国内では大規模組織ほど採用率が高いCMSです。最も大きい採用例はデジタル庁が推進する「政府統一Webサイト」で、各省庁のサイトを共通基盤で構築する取り組みの土台にDrupalが選ばれています。奈良市が公開しているデジタル庁の取材記事でも、Drupalがアクセシビリティ・多言語・セキュリティ要件のバランスから採用された経緯が紹介されています。

大学では沖縄科学技術大学院大学（OIST）をはじめ、海外と接続性が高い研究機関でDrupalの採用例が多く、国内導入事例の一覧からも教育・研究機関の利用が確認できます。海外では米ホワイトハウス、マサチューセッツ州、カナダ政府の25%程度がDrupalサイトを運用しており、「セキュリティ要件が厳しい組織が選ぶCMS」という色合いが強いプロダクトです。だからこそ、今回PostgreSQL構成のDrupalで認証不要のSQLインジェクションが見つかったのは、影響範囲こそ限定的でもインパクトは小さくありません。

本件について、日本国内では5月23日時点ではてなブックマーク・Zenn・Qiitaなどで日本語の解説記事はまだ確認できません。JPCERT/CCやIPAからの正式注意喚起も本記事執筆時点では出ておらず、対応はサイト管理者自身が一次情報（Drupal.orgとCISA KEV）を直接確認する必要があります。「英語情報の到達が遅い」「PostgreSQL構成は国内シェアが低い」という油断で、KEV期限後に踏まれるパターンが最も危険です。

CISA期限の意味と、これから1週間で見ておくこと

CISA KEVの対応期限は、形式上は「米連邦機関向け」のものです。しかし実際には、サイバー保険の査定・米欧の取引先からのセキュリティ問診・将来発生したインシデントの責任分界点といった場面で、KEV期限を過ぎても放置していたかどうかは強い意味を持ちます。期限後に侵害された場合、「業界が一斉に対応している脆弱性を放置した結果」と判定されるリスクがある。5月27日というデッドラインは、連邦機関以外にとっても「動かない理由を説明できる側に立つか、放置した側に立つか」の分水嶺になります。

これから1週間で見ておくべき指標は、(1) 大手CDN・WAFベンダー（Imperva、Cloudflare、Akamai）からの追加観測レポート、(2) 国内CSIRT（JPCERT/CCとIPA）からの注意喚起の有無、(3) サポート終了済みDrupal 7サイトに対する別経路の発掘可能性、の3点です。とくに(3)について、Drupal 7は「PostgreSQL対応コードが今回のパスとは別構造」と説明されていますが、攻撃者が類似の論理を別経路で見つける可能性は捨てきれません。Drupal 7サイトを抱えているなら、これを機にDrupal 10系への移行を検討する潮目だと考えてよいでしょう。

繰り返しになりますが、本件で対象になるのは「Drupal 8.9以降、かつデータベースがPostgreSQL」のサイトだけです。条件に当てはまる管理者は、5月27日までにパッチ適用、当てられない事情があるなら本記事の暫定処置のいずれかを必ず入れること。当てはまらないサイト管理者も、自分のCMSがどのCVEで攻撃されうるかを管理画面のステータスレポート1ページで把握できる体制を持っているか、この機会に確認しておく価値があります。

参照元

• Drupal core - Highly critical - SQL injection - SA-CORE-2026-004 | Drupal.org
• PSA-2026-05-18: Upcoming Highly Critical Release on May 20, 2026 | Drupal.org
• NVD - CVE-2026-9082
• CISA Known Exploited Vulnerabilities Catalog
• Keys to the Kingdom: Anonymous SQL Injection in Drupal Core (CVE-2026-9082) | Searchlight Cyber
• CVE-2026-9082 | Drupal PostgreSQL SQL Injection | Horizon3.ai
• Imperva Customers Protected Against CVE-2026-9082 in Drupal Core | Imperva
• Highly Critical Drupal Core Flaw Exposes PostgreSQL Sites to RCE Attacks | The Hacker News
• CVE-2026-9082: Critical Drupal Core SQL Injection Vulnerability | Tenable
• Drupal Core SQL Injection Vulnerability CVE-2026-9082 | UC Berkeley Information Security Office
• 政府統一Webサイト、暫定版を12月までに公開 製作事業者決定 | ITmedia NEWS
• Drupalの政府・公的機関における導入事例 | ANNAI