2026.10.23 セキュリティ

Drupal 脆弱性SA-CORE-2026-014：影響版の確認と更新・回避の手順

Q: 実際の攻撃や悪用は確認されていますか？

勧告の評価で攻撃コードの状況は「Theoretical（理論段階）」です。2026年10月23日時点で、 JPCERT/CCの注意喚起一覧 （10月22日更新）にもDrupalの項目はありません。とはいえ公表前のPSAは攻撃手法が数時間から数日で作られうると警告しており、修正の差分から経路を割り出される前に更新を終えるのが筋です。

Drupal 脆弱性SA-CORE-2026-014：影響版の確認と更新・回避の手順

Drupalのセキュリティチームは2026年10月14日（日本時間15日未明）、コアのField UIモジュールにリモートコード実行の脆弱性があるとして、勧告SA-CORE-2026-014（CVE-2026-108097）を公表しました。リスク評価は25点中19点のCriticalで、寄稿モジュールとの組み合わせ次第では認証なしで突かれます。この記事では、drushとリリース履歴XMLを使った影響版の判定、composerでの更新手順、更新までの間にfield_uiを外す暫定回避と設定同期の落とし穴、同じ日に出たEntity Listの勧告までを順に整理しました。内容は2026年10月23日時点の公開情報にもとづきます。

まとめ：10.6.19・11.3.19・11.4.10未満は即更新、無理ならfield_uiを外す

影響を受けるのは8.9.0以降のDrupalのうち、10.6.19・11.3.19・11.4.10より古い版です。サポート中の系列はその版以上へ上げれば修正されます。11.2以前と10.5以前、Drupal 8・9は修正版が出ないため、サポート中の系列へ上げるしかありません。

当日中に更新できないサイトは、コアのField UI（field_ui）をアンインストールすれば更新までの間をしのげます。取り外し後に設定のエクスポートまで済ませる必要があるのは、次のデプロイで元に戻るためです。Drupalを含む公開サイトの版と露出をまとめて点検したい場合は、脆弱性診断・セキュリティ診断で棚卸しすると見落としが減ります。

SA-CORE-2026-014の中身：Field UIのRCEと19点の評価、同日の勧告

まず勧告に書かれている事実と、書かれていないことを分けて押さえます。

Field UIのRCEがコア単体で成立せず寄稿モジュールで認証不要になる理由

SA-CORE-2026-014によれば、脆弱性はコアのField UIモジュールの中にあります。Field UIは、管理画面でコンテンツタイプにフィールドを足したり表示を並べ替えたりする画面を提供するモジュールです。

勧告は「コアだけでは直接悪用できない」としつつ、寄稿モジュールと組み合わせると深刻な悪用経路が複数あり、少なくとも1つは認証が要らないと書いています。自社で書いたカスタムコードが同じ機能を外へ出している場合も対象です。どの寄稿モジュールが経路になるかは公表されていません。つまり「うちは管理画面をログイン必須にしている」は安全の根拠になりません。

リスク19/25の内訳と10月12日の事前告知から評価が変わった2項目

Drupalは独自のリスク計算で深刻度を25点満点で付けます。本件は19点で、15〜19点のCriticalの上限です。勧告の評価は次の6項目でした。

項目	事前告知（10月12日）	勧告本文（10月14日）
攻撃の難しさ（AC）	Complex	Basic
必要な認証（A）	None	None
機密性への影響（CI）	All	All
完全性への影響（II）	All	All
攻撃コードの状況（E）	Theoretical	Theoretical
影響を受けるサイト（TD）	All	Default

事前告知PSA-2026-10-12と比べると、攻撃の難しさは「Complex」から「Basic」へ下がり、対象は「全サイト」から「既定の構成のサイト」へ狭まりました。合計は同じ19点です。攻撃コードは公表時点で理論段階ですが、PSAは「数時間から数日で攻撃手法が作られうる」と警告していました。CVSSでの値は勧告に載っておらず、点数の読み方はCVSSv3の計算式とスコアの目安とは別物として扱ってください。

同日のEntity List（SA-CONTRIB-2026-218）とXSS勧告2件

同じ10月14日には、寄稿モジュールEntity Listにもリモートコード実行のSA-CONTRIB-2026-218（CVE-2026-108099）が出ています。評価は本件と同じ19点で、3.0.10より前の全版が対象です。説明文もほぼ同じ構造で、モジュール単体では悪用できず、他の寄稿モジュールと組み合わさると認証不要の経路があるとされています。Entity Listを入れているサイトは3.0.10へ上げます。

コアではほかに、NavigationモジュールのSA-CORE-2026-015（12点）とLinkモジュールのSA-CORE-2026-016（13点）の2件のXSSが同時に直っています。修正版は本件と同じなので、必要な更新作業は1回だけです。なお10月21日にも寄稿モジュールの勧告が十数件まとめて出ており、報道の「Drupalの脆弱性」がそちらを指す場合もあります。

影響版の確認：drush statusとリリース履歴XMLで版と系列を判定する

判定に必要なのは、導入中のコアの版と、その版の属する系列がまだサポートされているかの2つです。

drush statusとcomposer showで版とField UIの有無を確認

サイトのルートで次を実行します。書式はcore:statusとpm:listのドキュメントにもとづきます。

# 導入中のコアの版（例: 11.4.9）
drush status --field=drupal-version

# composer が把握している版（drush が無い環境でも使える）
composer show drupal/core | grep versions

# Field UI と Entity List が有効か（何も出なければ無効）
drush pm:list --status=enabled --field=name | grep -E "^(field_ui|entity_list)$"

2つの版が食い違う場合は、composer側の更新後にcoreのファイルが入れ替わっていない可能性があります。Field UIは標準インストールで有効になるため、多くのサイトで1行目に出ます。出なければ本件の直接の影響は受けません。ただし更新は別途必要です。

リリース履歴XMLでInsecure判定とサポート系列を確かめるPython

Drupal.orgはコアの全リリースをリリース履歴XMLで配っています。各版に「Insecure」「Security update」などの分類が付き、サポート中の系列も載っています。標準ライブラリだけで判定するなら次のとおりです。

import sys
import urllib.request
import xml.etree.ElementTree as ET

URL = "https://updates.drupal.org/release-history/drupal/current"

installed = sys.argv[1]  # 例: 11.4.9（drush status の Drupal version）
req = urllib.request.Request(URL, headers={"User-Agent": "Mozilla/5.0"})
root = ET.fromstring(urllib.request.urlopen(req, timeout=30).read())

branch = ".".join(installed.split(".")[:2]) + "."
supported = root.findtext("supported_branches").split(",")
releases = root.find("releases").findall("release")

def terms(rel):
    return [t.findtext("value") for t in rel.iter("term")]

mine = next((r for r in releases if r.findtext("version") == installed), None)
latest = next((r.findtext("version") for r in releases
               if r.findtext("version").startswith(branch)
               and "-" not in r.findtext("version")), None)

print("導入版:", installed, "／分類:", terms(mine) if mine is not None else "不明")
print("同じ系列の最新版:", latest)
print("サポート中の系列か:", branch in supported, supported)

2026年10月23日に実行した結果は次のとおりです。11.4.9は分類に「Insecure」が付き、同じ系列の最新は11.4.11でした。11.2.14は系列がサポート外と出ます。サポート中の系列は10.6・11.3・11.4と、ベータ段階の11.5・12.0でした。台帳の版をこのスクリプトに流せば、複数サイトの判定を一度に回せます。

composer auditで0件でも本件は対象外と言えない10月23日時点の事情

composer auditは、既定でPackagistの勧告データと照合して脆弱なパッケージを報告するコマンドです。CIに組み込んでいる開発チームも多いはずです。

ただし2026年10月23日時点で、Packagistの勧告APIにあるdrupal/core向けの勧告は5月20日のCVE-2026-9082が最新で、本件は入っていませんでした。このため本件については、composer auditが何も報告しなくても安全の証明になりません。CVE-2026-108097はNVDにもまだ登録がありません。判定は上のリリース履歴XMLか、Drupal.orgの勧告を正にしてください。

更新手順：composer updateからupdatedb・設定エクスポートまでの流れ

Composerで管理しているサイトは、Drupal公式の更新手順に沿って進めます。

バックアップと保守モードを入れてdrupal/core-*を上げる7つの工程

開発環境で先に通し、同じ composer.lock を本番へ持ち込む順番にします。

# 1. バックアップ（DBとファイル）
drush archive:dump

# 2. 保守モードに入れる
drush state:set system.maintenance_mode 1
drush cache:rebuild

# 3. コアを同じ系列の最新へ（まず --dry-run で差分を見る）
composer update "drupal/core-*" --with-all-dependencies --dry-run
composer update "drupal/core-*" --with-all-dependencies

# 4. DB更新とキャッシュ再構築
drush updatedb
drush cache:rebuild

# 5. 設定管理を使っているなら書き出してコミット
drush config:export

# 6. 版を確かめる（10.6.19 / 11.3.19 / 11.4.10 以上か）
drush status --field=drupal-version

# 7. 保守モードを解除
drush state:set system.maintenance_mode 0
drush cache:rebuild

本番では composer install –no-dev のあとに drush updatedb を流します。Entity Listを入れているサイトは、3の段階で composer update drupal/entity_list も一緒に流します。

10.5以前・11.2以前のEOL系列から上げるときの二段構えの判断

勧告のとおり、11.2.x以前と10.5.x以前は修正版が出ません。たとえば11.2.14のサイトは、11.3.19以上か11.4.10以上へマイナー版を上げる必要があります。マイナー版の更新は依存パッケージの要件も動くため、composer.jsonの制約を書き換えてから上げます。

ここで判断を分けます。マイナー版の更新が1日で終わらないと見込むなら、先に後述のfield_uiの取り外しで穴をふさぎ、更新は試験を通してから入れる二段構えにします。逆に、試験の時間を理由にfield_uiも外さず待つのは避けてください。Drupal 8・9のサイトは系列ごと移行が必要で、短期に済む作業ではありません。

10月21日の11.4.11など後続版とPHPの臨時更新との関係

リリース履歴XMLでは、10月21日に11.4.11・11.3.20・10.6.20が「Bug fixes」として出ています。いずれも本件の修正を含む版の後続なので、これから更新するサイトはそちらへ上げて構いません。

同じ10月21日には、DrupalのセキュリティチームがPHPの臨時セキュリティ更新（PSA-2026-10-20）も告知しています。PHPを自分で管理しているサーバーは、コアの更新と同じ保守時間でPHPも上げると停止が1回で済みます。

更新できない間の暫定回避：field_uiを外す手順と設定同期の落とし穴

勧告は、更新までの間の緩和策としてField UIのアンインストールを挙げています。

drush pm:uninstall –simulateで依存モジュールを事前確認

pm:uninstallは、指定したモジュールに依存するモジュールもまとめて外します。いきなり実行せず、–simulateで道連れになるものを確かめます。

# 外れるモジュールの一覧だけを表示（実際には外さない）
drush pm:uninstall --simulate field_ui

# 問題が無ければ実行
drush pm:uninstall field_ui -y
drush cache:rebuild

Field UIが提供するのは管理画面だけで、フィールドの定義や入力済みのデータは消えません。失うのは「フィールドの管理」「フォーム表示の管理」「表示の管理」のタブです。更新後に drush pm:install field_ui で戻せば、サイト構築の作業も再開できます。一覧に業務で使っている寄稿モジュールが出た場合は、そのモジュールの停止が業務に与える影響と比べて判断します。

config:exportを忘れると次のデプロイでField UIが戻る仕組み

設定管理（drush config:import）でデプロイしているサイトでは、有効なモジュールの一覧が core.extension.yml に入っています。本番でfield_uiを外しただけだと、次のデプロイでこのファイルを取り込んだ時点でField UIが再び有効になります。

開発環境でも同じようにfield_uiを外し、config:exportで書き出した core.extension.yml をコミットしてください。修正版を入れたら、同じ手順でfield_uiを戻して書き出し直します。戻し忘れは実害が少ない一方、外し忘れは穴が開いたままになるので、作業票には両方の工程を書いておきます。

Drupal StewardやWAFで防げる範囲と防げない範囲の線引き

勧告によれば、本件はDrupal Steward（ホスティング側で既知の攻撃をはじく有償の仕組み）の保護対象です。ただし勧告自身が「既知の攻撃経路の一部しか防げない」と明記しており、Steward利用サイトも更新が前提です。

手元のWAFのルールで止める案も、経路となる寄稿モジュールが公表されていない以上、狙うべきリクエストの形が決まりません。WAFは更新までの時間を稼ぐ補助で、field_uiの取り外しか更新のどちらかは必ず行います。

対応の優先順位：寄稿モジュール構成と系列で更新の期限を決める基準

複数のDrupalサイトを抱えている場合の順番を、条件ごとに言い切ります。

匿名ユーザーに機能を開いた寄稿モジュールがあるサイトは当日中に対処

最優先は、匿名ユーザーが使える寄稿モジュールの機能を持つサイトです。たとえば会員登録しない利用者が投稿できるフォームや、外部へ公開しているAPIです。JSON:APIでヘッドレス構成にしているサイトも、外から届く入口が広いのでここに入れます。勧告は認証不要の経路を明言しているため、これらは更新かfield_uiの取り外しを当日中に済ませます。

次が、ログインした利用者だけが寄稿モジュールを使う会員サイトです。最後が、寄稿モジュールをほとんど入れていない小さな広報サイトで、これは週内の更新でよいと判断します。ただし「寄稿モジュールが少ない」を理由に更新そのものを見送るのは誤りです。経路が公表されていない以上、手元の構成が安全だと証明する手段がありません。

Drupal 8・9のまま残るサイトは移行か閉鎖まで今月中に決める

Drupal 8.9以降のサイトは影響範囲に入っており、8と9には修正版がありません。Drupal 9は2023年11月にサポートを終えています。field_uiを外せば本件はしのげますが、終了後に公表された他の脆弱性は残り続けます。

このようなサイトは、今月中に「10.6以降へ移行する」「別のCMSへ移る」「閉鎖する」のどれかを決めてください。移行先の選び方はCMSの種類と選び方、同じ月に起きた別のCMSの対応例はMovable Typeの脆弱性CVE-2026-96408の版確認とCGI遮断が参考になります。改修範囲や費用の見積もりから始めたい場合は、脆弱性診断の進め方と外注時の判断基準で整理しています。

Drupal SA-CORE-2026-014の対応でよくある質問と回答

SA-CORE-2026-014の対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

Field UIをアンインストールするとフィールドや記事のデータは消えますか？

消えません。Field UIはフィールドを編集するための管理画面を提供するモジュールで、フィールドの定義と保存済みのデータは別のモジュールが持っています。外している間は管理画面から新しいフィールドを足せなくなるだけです。修正版を入れたあと drush pm:install field_ui で戻せば、元の画面が使えます。設定管理を使うサイトは、外すときと戻すときの両方で config:export を忘れずに行ってください。

Drupal 7のサイトも今回の勧告の対象になりますか？

勧告の影響範囲は8.9.0以降で、Drupal 7は記載されていません。Drupal 7はコミュニティのサポートを2025年1月に終えており、Drupal.orgの勧告の対象外です。延長サポートを契約している場合は提供元の案内に従います。たとえばPantheonのリリースノートは、同社のDrupal 7向け延長サポートで対応すると案内しています。

CVSSのスコアは何点で、NVDには登録されていますか？

Drupal.orgはCVSSでなく独自の計算で19/25と評価しており、CVSSの値は勧告にありません。一部の報道に出ているCVSS 9.8は公式の値ではないので、社内報告では勧告の19点を使います。CVE-2026-108097は、2026年10月23日にNVDのAPIで確かめたところ未登録でした。登録されるとCVSSが付く可能性がありますが、対応の判断を待つ理由にはなりません。

実際の攻撃や悪用は確認されていますか？

勧告の評価で攻撃コードの状況は「Theoretical（理論段階）」です。2026年10月23日時点で、JPCERT/CCの注意喚起一覧（10月22日更新）にもDrupalの項目はありません。とはいえ公表前のPSAは攻撃手法が数時間から数日で作られうると警告しており、修正の差分から経路を割り出される前に更新を終えるのが筋です。

マネージドホスティングを使っていれば自動で修正されますか？

Drupalのコアはサイトのコードの一部なので、多くのホスティングでは利用者が更新します。Pantheonもダッシュボードのワンクリック更新での適用を案内しており、自動では入りません。ホスティングがDrupal Stewardに参加していれば一部の攻撃ははじかれますが、勧告のとおり全経路は防げません。契約先の案内を確かめ、自分で更新する前提で計画してください。