セキュリティ情報漏洩のニュースサイトセキュリティ対策Labの運営とBtoB マーケティングコンサル支援|合同会社ロケットボーイズ

Drupal coreに、CVE-2026-9082として管理されるHighly criticalのSQLインジェクション 脆弱性が公開されました。PostgreSQLを利用するDrupalサイトでは、匿名ユーザーから悪用される恐れがあり、Drupal 11.3.10／11.2.12／10.6.9／10.5.10などへの更新が必要です。 この記事のサマリー Drupal coreに、CVE-2026-9082として管理されるSQLインジェクション脆弱性が公開されました。 Drupal Security Teamのリスク評価はHighly critical 20/25です。 影響を受けるのはDrupal 8.9.0以降の複数バージョンですが、SQLインジェクションの影響はPostgreSQLを利用するサイトに限定されます。 この脆弱性は匿名ユーザーから悪用可能とされています。 悪用された場合、情報漏えい、権限昇格、リモートコード実行などにつながる可能性があります。 Drupal 11.3.10、11.2.12、11.1.10、10.6.9、10.5.10、10.4.10への更新が案内されています。 Drupal 8・9はEOLですが、深刻度を踏まえ、Drupal 8.9および9.5向けの手動適用パッチがベストエフォートで提供されています。 SQLインジェクションの影響を受けない構成でも、同時にSymfonyとTwigのセキュリティ更新が含まれるため、Drupal coreの更新が推奨されます。 何が起きたか Drupal Security Teamは、Drupal coreのセキュリティアドバイザリSA-CORE-2026-004を公開しました。 このアドバイザリでは、Drupal coreにSQLインジェクションの脆弱性があり、CVE-2026-9082として管理されていることが示されています。リスク評価はHighly critical 20/25です。 Drupal coreには、データベースへ発行するクエリを適切に無害化し、SQLインジェクションを防ぐためのデータベース抽象化APIが含まれています。今回の脆弱性はこのAPIに存在し、攻撃者が細工したリクエストを送ることで、PostgreSQLを利用するDrupalサイトで任意のSQLインジェクションを引き起こせる可能性があります。 脆弱性の概要 項目 内容 アドバイザリ SA-CORE-2026-004 CVE CVE-2026-9082 製品 Drupal core 脆弱性種別 SQLインジェクション リスク評価 Highly critical 20/25 影響条件 PostgreSQLデータベースを利用するDrupalサイト 悪用条件 匿名ユーザーから悪用可能 想定影響 情報漏えい、権限昇格、リモートコード実行、その他攻撃 Drupal 7 影響なし 修正版 Drupal 11.3.10、11.2.12、11.1.10、10.6.9、10.5.10、10.4.10 Drupal Security Teamは、このSQLインジェクション脆弱性はPostgreSQLを利用するサイトにのみ影響すると説明しています。ただし、今回のリリースにはSymfonyとTwigのセキュリティ更新も含まれるため、PostgreSQLを利用していないサイトでも更新が推奨されています。 影響を受けるバージョン Drupal Security Teamが示した影響バージョンは以下です。 系統 影響バージョン Drupal 11.3 11.3.10より前 Drupal 11.2 11.2.12より前 Drupal 11.1 / 11.0 11.1.10より前 Drupal 10.6 10.6.9より前 Drupal 10.5 10.5.10より前 Drupal 10.4以前 10.4.10より前 Drupal 9 EOL、Drupal 9.5向け手動パッチをベストエフォートで提供 Drupal 8.9 EOL、Drupal 8.9向け手動パッチをベストエフォートで提供 Drupal 7 影響なし Drupal 11.1.x、11.0.x、10.4.x以前はすでにEOLであり、通常はセキュリティカバレッジの対象外です。ただし、今回の問題の深刻度を踏まえ、Drupal Security TeamはこれらのEOLブランチ向けにも修正版やパッチをベストエフォートで提供しています。 一方で、EOLバージョンには今回修正されない既知の脆弱性が残っている可能性があります。Drupal 8や9、古いDrupal 10系を使い続けている場合は、今回の応急対応だけでなく、Drupal 10.6または11.3などサポート対象ブランチへの移行計画が必要です。 PostgreSQL利用サイトが特に危険な理由 今回のSQLインジェクション脆弱性は、DrupalサイトがPostgreSQLを利用している場合に影響します。 DrupalはMySQL、MariaDB、PostgreSQLなど複数のデータベース構成で利用されることがあります。多くのWebサイトではMySQL系が使われる一方、公共機関、大学、研究機関、エンタープライズ環境ではPostgreSQLが選ばれているケースもあります。 Drupal Security Teamは、攻撃者が細工したリクエストを送ることでPostgreSQL利用サイトに任意SQLインジェクションを発生させられると説明しています。さらに、この脆弱性は匿名ユーザーから悪用可能とされているため、ログイン不要で攻撃対象になり得ます。 SQLインジェクションが成立すると、データベース内の情報閲覧、管理者情報の取得、権限昇格、データ改ざん、場合によってはリモートコード実行へつながる可能性があります。特に、問い合わせフォーム、会員情報、注文情報、採用応募、自治体・大学・医療機関の公開サイトなどでDrupalを利用している場合、影響範囲の確認を急ぐ必要があります。 SymfonyとTwigの更新にも注意 今回のDrupal coreリリースには、Drupal本体のSQLインジェクション修正だけでなく、SymfonyとTwigのセキュリティ更新も含まれます。 Drupal Security Teamは、サポート対象ブランチであるDrupal 11.3、11.2、10.6、10.5のリリースに、SymfonyとTwigのセキュリティ更新が含まれると説明しています。サイト構成やcontribモジュールの利用状況によっては、これらの上流プロジェクトの脆弱性の影響を受ける可能性があるため、SQLインジェクションの影響を受けない構成でも更新が強く推奨されています。 また、Drupal Security Teamは、Viewsやcontribモジュールを通じてTwigテンプレートを更新できるユーザー権限を確認することも推奨しています。これは、テンプレート更新権限を持つロールが過剰に付与されている場合、別のセキュリティ問題と組み合わさって影響が広がる可能性があるためです。(Drupal.org) Drupal Steward利用サイトについて Drupal Security Teamは、今回の問題がDrupal Stewardによって保護されているとも説明しています。 事前告知では、Drupal Stewardを利用しているサイトは既知の攻撃経路からすでに保護されているとされています。ただし、追加の攻撃経路が見つかる可能性があるため、近い将来アップグレードすべきとも案内されています。 つまり、Drupal Stewardは緩和策として有効な場合がありますが、Drupal core本体を更新しなくてよい理由にはなりません。WAFやマネージド保護はあくまで時間を稼ぐための対策であり、根本対応は修正版への更新です。 即時対応：情報システム・Web運用担当が確認すべきポイント Step 1：Drupal利用サイトを棚卸しする まず、自社や委託先が運用しているDrupalサイトを洗い出してください。 確認対象は、本番サイトだけではありません。以下も確認対象です。 確認対象 見落としやすいポイント コーポレートサイト 外部制作会社が保守している場合がある 採用サイト 別サーバ・別CMSで運用されている場合がある 会員サイト 個人情報や認証情報を保持している可能性 自治体・大学・研究機関サイト PostgreSQL構成の可能性 キャンペーンサイト 期間終了後も古いDrupalが残る場合 検証・ステージング環境 外部公開されたまま忘れられる場合 委託先管理サイト 自社台帳に載っていない可能性 Step 2：Drupalのバージョンを確認する 対象サイトでDrupal coreのバージョンを確認してください。 composer show drupal/core また、Web管理画面やcomposer.lock、デプロイ履歴、ホスティング事業者の管理画面でも確認できます。 grep -A 5 '"name": "drupal/core"' composer.lock 複数環境を運用している場合、本番、ステージング、開発、バックアップ復元環境でバージョンが異なることがあります。 Step 3：データベースがPostgreSQLか確認する 今回のSQLインジェクション脆弱性はPostgreSQLを利用するDrupalサイトに影響します。 Drupalの設定ファイルや環境変数でDBドライバを確認してください。 grep -R "driver" sites/*/settings.php grep -R "pgsql\|postgres" sites/*/settings.php Composerやコンテナ構成、Kubernetes Secret、.env、ホスティング管理画面も確認してください。 grep -Rni "pgsql\|postgres\|POSTGRES" . 2>/dev/null ただし、PostgreSQLではない場合でも、SymfonyとTwigの更新が含まれるため、Drupal coreの更新は必要です。 Step 4：修正版へ更新する Drupal Security Teamは、以下の修正版への更新を案内しています。 利用中のバージョン 更新先 Drupal 11.3.x Drupal 11.3.10 Drupal 11.2.x Drupal 11.2.12 Drupal 11.1.x / 11.0.x Drupal 11.1.10 Drupal 10.6.x Drupal 10.6.9 Drupal 10.5.x Drupal 10.5.10 Drupal 10.4.x以前 Drupal 10.4.10 Drupal 9 Drupal 9.5向けパッチを手動適用 Drupal 8.9 Drupal 8.9向けパッチを手動適用 Composer管理のDrupalでは、検証環境で以下のように更新します。 composer update drupal/core-recommended drupal/core-composer-scaffold drupal/core-project-message --with-dependencies その後、DB更新とキャッシュクリアを実施します。 drush updatedb drush cache:rebuild 本番反映前には、フォーム、検索、ログイン、管理画面、Views、contribモジュール、Twigテンプレート、API連携の動作確認を行ってください。 Step 5：EOLバージョンは応急対応後に移行計画を立てる Drupal 8とDrupal 9はEOLです。Drupal Security Teamは今回の深刻度を踏まえて手動パッチを提供していますが、これはベストエフォートであり、正常動作や他の脆弱性修正を保証するものではありません。 Drupal 8または9を利用している場合は、次の順番で対応してください。 優先度 対応 1 外部公開状況とDB種別を確認 2 可能であればDrupal 10.6以降へ移行 3 すぐに移行できない場合は手動パッチを検証環境で確認 4 WAFやDrupal Stewardなどの緩和策を確認 5 EOL環境の廃止・移行計画を期限付きで作成 Step 6：悪用の兆候を確認する PostgreSQLを利用しているDrupalサイトでは、更新とあわせて悪用の兆候を確認してください。 確認対象 見るべき内容 Webアクセスログ 不審なクエリ文字列、異常なPOST、短時間の大量リクエスト Drupalログ SQLエラー、例外、未確認の管理者操作 PostgreSQLログ エラー、異常なSQL、権限エラー、大量SELECT 管理者アカウント 不審なログイン、権限変更、新規ユーザー作成 ファイルシステム 不審なPHPファイル、Webシェル、改ざん コンテンツ 不審なページ、リダイレクト、外部スクリプト挿入 SQLインジェクションはログに分かりやすく残らない場合があります。脆弱な状態で外部公開されていたサイトでは、更新後も管理者アカウント、設定変更、ファイル改ざん、DB内の不審なユーザーやロールを確認してください。 CI/CD・ホスティング環境で確認すべき設定 DrupalをComposer、CI/CD、コンテナ、マネージドホスティングで管理している場合、更新漏れが発生しやすいポイントを確認してください。 項目 確認内容 Composer drupal/coreだけでなくcore-recommendedも更新されているか composer.lock 修正版がロックされているか CI/CD 本番デプロイ前にテストとDB更新が実行されるか コンテナ 古いイメージがレジストリやPodに残っていないか ステージング 本番だけ更新し、検証環境が古いまま残っていないか ホスティング 自動更新対象か、手動対応が必要か WAF SQLインジェクション検知ルールが有効か バックアップ 更新前バックアップと復元手順が確認済みか Drupalサイトは外部制作会社や保守ベンダーが管理していることも多いため、情シス側で「誰がいつ更新するか」「PostgreSQL構成か」「更新後の確認結果を誰が承認するか」を明確にしてください。 参考情報・出典 Drupal.org：Drupal core - Highly critical - SQL injection - SA-CORE-2026-004

ブログ