DrupalのField UIとEntity Listに重大な脆弱性｜認証不要の経路と更新対象を確認

Drupal本体と拡張を別々に更新する必要がある

Drupal Security Teamは2026年10月14日、Drupal本体のField UIと、拡張モジュールEntity Listについて、リモートコード実行につながる重大な脆弱性を公表しました。識別子はそれぞれCVE-2026-108097、CVE-2026-108099です。両告知は、他の拡張との組み合わせによる悪用経路があり、少なくとも一つの既知の経路では認証を必要としないと説明しています。

これは、Drupalを使う全サイトが同じ条件で直ちに侵害されるという意味ではありません。一方、「管理機能に見えるからログイン画面で守られている」と考えるのも危険です。本記事では対象の違い、更新先、暫定対策の範囲を確認し、実際に修正を本番へ届ける際の判断を整理します。

本記事の情報確認日は10月19日です。公式告知上の公表日は10月14日で、今日発見された脆弱性の速報ではありません。11.4.10のリリースページは更新時刻を10月14日16時28分UTCと記載しており、日本時間では10月15日未明に相当します。公表日、時差、記事の確認日を混同しないようにしてください。

出典：Drupal Security Team｜SA-CORE-2026-014

単体では直接悪用できないことを安全宣言にしない

Field UIの告知は、Drupalコアだけでは直接悪用できない一方、拡張モジュールを組み合わせた複数の深刻な経路があり、独自コードも問題の機能を外部へ露出させる可能性があるとしています。Entity Listについても、モジュール単体では直接悪用できず、他の拡張や独自コードが経路になり得るという条件が説明されています。

本サイトの提案として、確認対象を「本体の版」だけに絞らず、有効な拡張、独自モジュール、公開するルートまで広げます。公式がすべての危険な組み合わせを網羅して列挙しているわけではないため、聞いたことのある拡張がないという理由だけで対応を終えないでください。

仮想例として、画面の設定は管理者だけが行うものの、公開側の一覧生成処理が同じ内部機能を呼び出しているサイトを考えます。編集画面へのアクセス制御が正しくても、公開側の呼び出し元が別なら、確認すべき入口も別になります。これは仕組みを理解するための例であり、今回の具体的な攻撃手順を再現したものではありません。

組み合わせ条件を調べることは重要ですが、完全な経路解析が終わるまで修正を止める必要はありません。対象版であれば、更新作業を進めながら、影響範囲と業務上の試験対象を特定する考え方が実務的です。

出典：Drupal Security Team｜SA-CONTRIB-2026-218

対象版と修正先を取り違えない

Drupal本体とEntity Listは別の製品として管理します。次の表は各公式告知と修正リリースを照合したものです。既存サイトが使う系列を確認し、対象と異なるリリースを選ばないようにします。

利用する系列・対象	公式が示す修正先	識別子
Drupal 11.4.x	11.4.10	CVE-2026-108097
Drupal 11.3.x	11.3.19	CVE-2026-108097
Drupal 10.6.x	10.6.19	CVE-2026-108097
Entity List 3.0.10未満	3.0.10	CVE-2026-108099

コア告知の影響範囲は8.9.0以上10.6.19未満、11.0.0以上11.3.19未満、11.4.0以上11.4.10未満、12.0.0-alpha1以上12.0.0-beta2未満です。サポート終了系列を使う場合は、現在の系列のまま修正が提供されると考えず、サポート対象への移行も必要です。

出典：Drupal.org｜Drupal 11.4.10リリースノート

19/25はCVSSではなくDrupal独自の評価

両告知の評価はCritical、19/25です。これはDrupalのリスク評価であって、CVSSが19点という意味ではありません。本記事は確認した一次資料にないCVSS値を推測せず、構造化データにも独自尺度をCVSSとして保存しません。

また、認証不要の悪用経路が知られていること、攻撃コードが一般に公開されていること、実際の侵害が観測されていることは別です。今回参照した告知だけでは、現実の悪用状況や被害件数を確定できません。悪用が未確認だから低優先と決めず、対象機能の有無、外部からの到達性、扱う情報と業務影響を合わせて判断してください。

10月12日の事前告知は、修正公開後に短時間で攻撃手法が開発される可能性を念頭に更新時間を確保するよう求めていました。これは10月19日時点で攻撃が発生したという報告ではありません。事前のリスク予測を、確認済みの事件へ読み替えないことが重要です。

出典：Drupal Security Team｜10月14日の更新に関する事前告知

Field UIのアンインストールは範囲を理解して判断する

コア側の公式告知は、更新までの緩和策としてField UIモジュール（field_ui）のアンインストールを案内しています。この対策はField UI側の問題についての説明です。Entity List側のCVEまで、同じ操作で一括して解消できると告知されているわけではありません。

本サイトの提案は、アンインストールを本番で急いで試す前に、依存する拡張や構成変更への影響を確認することです。構成をバックアップし、検証環境で業務への影響を調べ、作業後に実際の有効状態を読み戻します。管理メニューを非表示にするだけの対応を、アンインストールと同じものとして扱わないでください。

更新が可能なら、暫定策の可否確認と並行して修正版の適用を優先します。機能を戻す時期も、更新が配信済みであることと、業務上の確認を条件に決めます。暫定的に使わなくしたことを、将来の保守を不要にする根拠にはしません。

Drupal Stewardについて、コア告知は一部の既知の攻撃経路を保護するものの、すべての悪用を覆うわけではないと説明しています。保護サービスの利用中でも更新は必要です。一般のWAFを使っているだけで同等の保護があるとも判断できません。

出典：Drupal Security Team｜SA-CORE-2026-014

依存関係の解決と本番への配信を分ける

本サイトが勧める最初の作業は、DrupalコアとEntity Listの導入版、有効状態、独自コードの管理場所を一つの対応票にまとめることです。Composerの管理情報と、実際にWebサーバーが読み込むファイルを対応付けます。制作会社と運用会社が分かれる場合は、依存関係を解決する担当と配信を実行する担当を明確にします。

公式のComposer更新文書は、開発・検証環境で更新した場合、composer.jsonとcomposer.lockを本番へ反映し、本番ではcomposer updateではなくcomposer install --no-devを使う流れを説明しています。必要なデータベース更新やキャッシュ再構築も別の工程です。コマンドは採用する構成と保守手順に合わせ、記事を見てそのまま本番で実行しないでください。

ここでの要点は、開発者の手元で依存関係が更新されたことと、利用者のリクエストを修正版が処理していることを区別することです。ロックファイルだけを更新して配信を忘れる場合や、修正済み成果物が別のドキュメントルートへ置かれる場合も、完了とはいえません。

依存関係の競合で更新できない場合は、何がどの版を固定しているかを調べます。原因が分からないまま広範な更新や制約の削除を行うと、変更が増えて検証が難しくなります。必要な変更と関連する互換性対応をまとめ、解消できない条件は責任者へ共有します。

出典：Drupal.org公式文書｜Composerによるコア更新

更新後は公開側と管理側の両方を試す

以下は本サイトによる受け入れ試験の提案です。まず管理画面のステータス情報と配信成果物の版を照合し、本体と拡張を別々に確認します。その後、匿名利用者、一般の認証済み利用者、編集者など、実際に運用する立場で主要な経路を確認してください。

Field UIを扱うサイトでは、フィールド管理に関係する必要な操作が正常かを確認します。Entity Listを使うサイトでは、一覧の表示、絞り込み、ページ送り、権限による表示の違いなど、そのサイトが採用する機能を試験します。ここで挙げた項目は業務確認の例であり、すべてのサイトが同じ機能を持つという意味ではありません。

検証では、正しい相手に表示されることと、表示してはいけない相手へ出ないことを対で確認します。管理者での成功だけでは匿名公開の問題を見逃し、トップページの成功だけでは独自モジュールの呼び出し失敗を見逃すためです。試験用の内容には個人情報や秘密情報を使わないでください。

複数台で配信する場合は、全台が同じ成果物へ切り替わったことも確認します。負荷分散の一度のアクセスで正常だったとしても、別の台に未修正版が残っていれば更新は完了していません。対応票には対象台、版、反映時刻、検証結果を残します。

不審な記録があっても更新だけで調査を終えない

本記事は、読者のサイトが侵害されたと診断するものではありません。ただし、不明なファイル変更、予定外の管理操作、説明できない外部通信などが既に見つかっている場合は、修正の適用とは別に調査が必要です。パッチは将来の悪用経路への対応であり、過去の変更や漏えいを自動的に取り消すものではありません。

本サイトの提案として、異常を見つけた時刻、対象ファイル、関連ログ、作業履歴を保全し、保守担当やインシデント対応担当へ引き継ぎます。原因を確認する前にログを消したり、全体を上書きして証拠を失ったりしないようにしてください。公開を止めるかは、利用者への影響と封じ込めの必要性を合わせて判断します。

更新後の不具合で切り戻す場合も、未修正版へ戻したまま公開を続けるかを改めて判断する必要があります。機能を一時的に縮小する選択肢や、閲覧用の案内へ替える選択肢を用意すると、危険な旧状態への復帰だけを選ばずに済みます。

今回の対応で残すべき結論

今回の2件は、Drupal本体のField UIと、別管理のEntity Listを区別して対応する必要があるニュースです。本体だけの更新、拡張だけの更新、管理画面の非表示のいずれか一つで、全体を確認したことにはなりません。対象と更新先、暫定対策の範囲を明確にしてください。

実施順序は、稼働構成の確認、修正版の準備、必要に応じた緩和策の検討、本番への配信、公開側・管理側の検証です。AIによる悪用や被害件数は今回の資料では確認していません。公式が示す重大性を正しく受け取りつつ、確認できない事実で不安を広げず、修正を実環境へ届けることを優先しましょう。