はじめに
2026 年 10 月 28 日、Drupal Security Team は EC 機能を提供する Commerce Core について 6 件のセキュリティアドバイザリを公開しました。このうち CVE-2026-118539 は Drupal の深刻度評価で最上位の Highly critical とされ、実環境での悪用が公式に確認されています。
一方で、6 件の深刻度や成立条件はそろっていません。JSON:API の有効化や、信頼できないユーザーへの店舗管理権限の付与が条件になるものもあり、「6 件すべてが認証不要で悪用済み」と捉えると対応の優先度を誤ります。また、修正版への更新は今後の悪用リスクを下げる対策であり、更新前に注文データが不正に操作されていなかったかは別に確認する必要があります。
- CVE-2026-118539 を含む Commerce Core の脆弱性 6 件の違いと成立条件
- 自社サイトが影響対象かを判断するための確認ポイント
- Commerce Core 3.3.13 / 8.x-2.41 への更新手順と Drupal 本体の互換条件
- 悪用確認を受けた注文データと決済記録の調査方法
結論として、Commerce Core を導入している EC サイトは、3.x 系は 3.3.13、8.x-2.x 系は 8.x-2.41 へ速やかに更新し、更新後に過去の注文データの不整合を監査する必要があります。Commerce Core を導入していない Drupal サイトは、今回の 6 件の対象ではありません。
Drupal Commerce の脆弱性 6 件とは
今回の 6 件はいずれも、コントリビュートモジュールである Commerce Core(プロジェクト名 commerce)に関するものです。まず公式発表の位置付けと、最重要の CVE-2026-118539 を整理します。
2026 年 10 月 28 日の公式発表
Drupal Security Team は同日、コントリビュートプロジェクト向けに SA-CONTRIB-2026-254 から SA-CONTRIB-2026-292 までのアドバイザリを公開しました。Commerce Core に関するものは SA-CONTRIB-2026-254〜259 の 6 件で、修正はすべて Commerce Core 3.3.13 と 8.x-2.41 に含まれています。
同日には Commerce Stripe、Commerce Shipping、Commerce License など、Commerce 関連の別プロジェクトのアドバイザリも公開されています。これらは今回の 6 件とは別の脆弱性です。Commerce Core とあわせて導入しているモジュールがあれば、コントリビュートプロジェクトのアドバイザリ一覧で個別に確認することをおすすめします。
CVE-2026-118539 の概要と悪用確認
CVE-2026-118539(SA-CONTRIB-2026-254)は、Commerce Core が一部のルートとエンティティフィールドを十分に保護していないことによるアクセス制御回避です。公式アドバイザリは、販売事業者に金銭的な影響を及ぼすおそれがあること、そしてこの脆弱性が実環境で悪用されていることを明記しています。
深刻度の読み方には次の注意点があります。
- 「21 / 25」は Drupal 独自のリスク評価であり、CVSS のスコアではありません。
- 評価文字列は
AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:Allです。A:Noneは攻撃に認証が不要(匿名ユーザーを含む)という評価上の条件を示します。 E:Exploitは悪用コードが実環境に存在すること、TD:Allはすべてのモジュール構成が影響を受けることを示します。- 対象のルート、フィールド、攻撃手順は公式アドバイザリで公開されていません。
公式情報は「一部のルートとエンティティフィールドのアクセス制御が不十分」という範囲にとどまっています。商品価格の改ざん、管理者権限の取得、リモートコード実行などが確認済みの攻撃内容として示されているわけではありません。また、実環境での悪用が確認されたことは、影響バージョンを使用するすべてのサイトが侵害されたことを意味しません。自社サイトの状況は、後述するように注文データ、決済記録、アクセスログなどを組み合わせて調査します。ただし、調査で異常が見つからなくても、侵害がなかったとは断定できません。
Drupal 本体と Commerce Core の違い
今回の脆弱性は Drupal 本体(Drupal core)ではなく、追加で導入するモジュールに存在します。影響判定では両者を区別してください。
- Drupal 本体(Drupal core)
-
CMS の基盤です。Composer パッケージは
drupal/coreで、セキュリティアドバイザリは SA-CORE として公開されます。今回の 6 件は Drupal 本体の脆弱性ではありません。 - Commerce Core(Drupal Commerce)
-
カート、チェックアウト、注文、プロモーション、店舗管理などの EC 機能を追加するコントリビュートモジュールです。Composer パッケージは
drupal/commerceで、今回の 6 件はこのモジュールが対象です。
6 件の脆弱性と攻撃成立条件
6 件のうち、実環境での悪用が確認されているのは CVE-2026-118539 の 1 件です。ほかの 5 件は、API の書き込み設定や権限設定など、特定の構成で成立する問題です。
| CVE | Drupal 深刻度 | 主な成立条件 | 悪用状況 |
|---|---|---|---|
| CVE-2026-118539 | 21 / 25 | 影響バージョンのすべての構成(認証不要) | 実環境で悪用 |
| CVE-2026-118540 | 12 / 25 | JSON:API 利用、未公開バリエーションあり | 確認なし |
| CVE-2026-118541 | 9 / 25 | JSON:API または REST で書き込み可 | 確認なし |
| CVE-2026-118542 | 10 / 25 | 店舗管理権限を信頼できないユーザーに付与 | 確認なし |
| CVE-2026-118543 | 12 / 25 | 管理権限を持つユーザーが細工ページを閲覧 | 確認なし |
| CVE-2026-118544 | 11 / 25 | JSON:API が有効 | 確認なし(PoC 手法あり) |
「悪用状況」は各アドバイザリのリスク評価文字列の E の値に基づきます。CVE-2026-118544 の E:Proof は概念実証の手法が存在するという評価であり、実環境での悪用確認を示すものではありません。
CVE-2026-118539 を最優先にする理由
CVE-2026-118539 は、認証不要、操作の複雑さなし(AC:None)、すべての構成が対象、悪用コードが実在、という条件がそろっています。ほかの 5 件と異なり、特定のモジュール設定を変更することで回避できるとは案内されていません。Drupal 公式が提示する修正策は、影響する系列の修正版への更新です。
JSON:API・REST の利用が条件になる 3 件
CVE-2026-118540 と CVE-2026-118544 はどちらも未公開の商品バリエーションに関する情報漏えいですが、仕組みと影響範囲が異なります。
- CVE-2026-118540
-
JSON:API と組み合わせた場合に、未公開の商品バリエーション自体に権限のないユーザーがアクセスできる問題です。公開済みの商品と未公開のバリエーションが存在するサイトに限られ、Commerce Core 3.3.x は対象外です。確認事項は JSON:API の有効化状況と、販売前・販売終了のバリエーションを未公開のまま保持していないかです。
- CVE-2026-118544
-
エンティティクエリの結果が閲覧可能なバリエーションに絞り込まれないため、繰り返しのリクエストによって、未公開のバリエーションや未公開商品のバリエーションの特定のフィールド値を推測できる問題です。データを直接取得する 118540 に対し、118544 は応答の違いから値を割り出す点が異なります。条件は Drupal 本体の JSON:API モジュールが有効であることで、3.3.x も対象に含まれます。
- CVE-2026-118541
-
プロモーションとクーポンの関連付けに対するアクセス確認が不十分で、自分のプロモーションのみ管理できるユーザーが、ほかのプロモーションに属するクーポンを変更・削除できる問題です。JSON:API または REST で書き込みを受け付けるサイトに限られ、この設定は既定では有効になっていません。プロモーション管理を外部の担当者や出店者に委ねている場合は、その権限範囲を確認してください。
権限設定とマルチストア構成が関係する 2 件
- CVE-2026-118542
-
店舗の保存時にアクセス確認が不十分で、店舗を作成できるユーザー、または自分の店舗を編集できるユーザーが、自分の店舗をサイトの既定店舗に設定できる問題です。その結果、本来受け取らない一部の注文がその店舗に割り当てられます。公式アドバイザリは、出店者が自分の店舗を管理するマーケットプレイスのように、信頼できないユーザーへこれらの権限を与えているサイトのみが対象としています。
- CVE-2026-118543
-
Commerce ダッシュボードの受信箱(Drupal Commerce プロジェクトからのお知らせ)のルートが CSRF トークンを確認しないため、「access commerce administration pages」権限を持つユーザーを細工されたページへ誘導すると、通知を非表示にできる問題です。受信箱は全ユーザーで共有されるため、1 人の管理者が誘導されると、セキュリティ更新の通知を含むメッセージがすべての管理者から見えなくなります。評価上は攻撃者の認証が不要(
A:None)ですが、成立には権限を持つ利用者の操作が必要です。
参考: Drupal.org(SA-CONTRIB-2026-258)
“The inbox is also shared by all users”
(受信箱は全ユーザーで共有されています。)
https://www.drupal.org/sa-contrib-2026-258
CVE-2026-118543 の影響は通知の非表示にとどまりますが、今回のように更新を急ぐ場面で通知に気付けなくなるため、管理画面の通知だけに頼らず、アドバイザリの一次情報を直接確認する運用が有効です。
影響バージョンと修正版
修正版は 3.x 系が 3.3.13、8.x-2.x 系が 8.x-2.41 です。ただし、影響バージョンの範囲は CVE ごとに一部異なります。
Commerce Core 3.3.13 / 2.41 の影響範囲
| CVE | 8.x-2.x 系の影響範囲 | 3.x 系の影響範囲 | 修正版 |
|---|---|---|---|
| CVE-2026-118539 | 2.41 未満 | 3.0.0 以上 3.3.13 未満 | 8.x-2.41 / 3.3.13 |
| CVE-2026-118540 | 2.41 未満 | 3.0.0 以上 3.2.0 未満(3.3.x は対象外) | 8.x-2.41 / 3.3.13 |
| CVE-2026-118541〜118544 | 2.41.0 未満 | 3.0.0 以上 3.3.13 未満 | 8.x-2.41 / 3.3.13 |
CVE-2026-118540 は、影響バージョン欄が「3.2.0 未満」である一方、解決策の欄では「3.2.x 以下は 3.3.13 へ更新」と案内されています。3.2.x の扱いは公式表記の範囲で断定できませんが、3.3.13 へ更新すれば解消されます。いずれにしても CVE-2026-118539 により 3.3.13 未満の 3.x 系はすべて更新対象です。
Drupal 本体との互換性
修正版のリリースページに記載された対応バージョンは次のとおりです。
| 修正版 | 対応する Drupal 本体(Works with Drupal) | リリースページ記載の Composer 指定 |
|---|---|---|
| Commerce Core 3.3.13 | ^10.3 || ^11 | drupal/commerce:^3.3 |
| Commerce Core 8.x-2.41 | ^9.3 || ^10 | drupal/commerce:^2.41 |
緊急対応では、現在使用している系列の修正版へ更新することを推奨します。2.x 系から 3.x 系への移行はメジャーバージョンの変更であり、Drupal 本体の要件も変わるため、脆弱性対応とは切り分けて計画することをおすすめします。3.x 系を使用していて Drupal 本体が 10.3 未満の場合は、3.3.13 の要件を満たさないため、Drupal 本体の更新を含めた対応が必要です。
影響判定の考え方


- Commerce Core(
drupal/commerce)が導入されていなければ、今回の 6 件の対象外です。 - 導入されていて 3.3.13 未満の 3.x 系、または 2.41 未満の 2.x 系であれば、CVE-2026-118539 の対象として更新が必要です。
- あわせて JSON:API・REST の利用状況と、店舗やプロモーションの管理権限を誰に与えているかを確認し、ほかの 5 件の該当可否を把握します。
- CVE-2026-118539 の対象であった場合は、更新後に注文データの監査を実施します。
Drupal Commerce の確認・更新手順
ここでは Composer と Drush で管理しているサイトを前提に、Drupal 公式の「Updating Modules and Themes using Composer」に沿った手順を示します。コマンドは公式ドキュメントと Drush のコマンドリファレンスに基づくもので、筆者の環境で実行検証したものではありません。
更新前の確認(変更を加えないコマンド)
次のコマンドはサイトのコードやデータベースを変更しません。Drupal のプロジェクトルートで実行します。
Commerce 関連モジュールの有効化状況を確認します。
drush pm:list --type=module --status=enabled --filter='name*=commerce'Commerce Core と Drupal 本体の導入バージョンを確認します。
composer show drupal/commerce
composer show drupal/core更新可能なパッケージとセキュリティ情報を確認します。composer audit は Drupal 以外の PHP ライブラリも対象に含みます。
composer outdated "drupal/*"
composer audit実際の更新内容を事前に確認するには --dry-run を付けます。修正版まで上がらない場合は、composer why-not でバージョン制約の原因を確認します(3.x 系の例)。
composer update drupal/commerce --with-all-dependencies --dry-run
composer why-not drupal/commerce 3.3.13composer.json でバージョンが固定されている場合など、通常の composer update では修正版まで上がらないことがあります。その場合はリリースページ記載の指定(drupal/commerce:^3.3 または drupal/commerce:^2.41)で制約を見直します。
バックアップと更新
本番環境では、ステージング環境で同じ手順を先に実施してから適用することを推奨します。次の手順はサイトに変更を加えます。
CVE-2026-118539 は実環境での悪用が確認されているため、証拠となる記録の保全は、更新前または更新作業と並行して開始することを推奨します。手順 1 のデータベースバックアップは更新前の注文データの記録にもなるため、切り戻し用とは別に、変更を加えない調査用の複製として保管します。アクセスログの複製は更新担当とは別の担当者が並行して進めると、更新を待たせずに済みます。詳細な調査は更新後に実施できるため、調査の完了を待って緊急更新を遅らせる必要はありません。
公式ドキュメントは、更新前に drush sql:dump でデータベースをバックアップするよう求めています。あわせて composer.json、composer.lock、アップロードファイルのディレクトリ(既定は sites/default/files)も保存します。
drush sql:dump --result-file=../backup/pre-commerce-update.sqlこのコマンドは次の前提で記載しています。実行前に確認してください。
- 相対パス
../backup/は、Drupal のプロジェクトルートでコマンドを実行することを前提としています。実行するディレクトリによって出力先が変わるため、基準となるディレクトリを確認するか、絶対パスで指定してください。 - 出力先のディレクトリは事前に作成し、コマンドを実行するユーザーに書き込み権限があることを確認します。
- 出力先が Web サーバーの公開領域(ドキュメントルート配下)に含まれないことを確認します。データベースのダンプには顧客情報や注文情報が含まれます。
現在の系列の範囲で drupal/commerce を更新します。
composer update drupal/commerce --with-all-dependencies公式ドキュメントでは、Composer による更新とデータベース更新の 2 段階を実施する必要があると明記されています。Drush 9 以降では、データベース更新中にメンテナンスモードが自動で有効になります。構成管理を運用している場合は、更新で追加された設定を drush config:export --diff で確認し、構成ディレクトリへ反映します。
drush updatedb
drush cache:rebuildcomposer show drupal/commerce で 3.3.13 または 8.x-2.41 になっていることを確認し、更新後の composer.lock をバージョン管理へコミットします。
参考: Drupal.org(Updating Modules and Themes using Composer)
“Always perform a database backup (drush sql:dump) before running updates.”
(更新を実行する前に、必ずデータベースのバックアップ(drush sql:dump)を取得してください。)
https://www.drupal.org/docs/updating-drupal/updating-modules-and-themes-using-composer
切り戻しは、更新前の composer.lock とデータベースのバックアップで旧バージョンへ戻す方法になります。ただし、切り戻すと悪用が確認されている CVE-2026-118539 の影響状態へ戻ります。不具合が出た場合も、原因を特定して修正版のまま対処する方針を基本とし、切り戻しは短時間の暫定措置にとどめることをおすすめします。
更新後の動作確認
公式ドキュメントは、データベース更新後に管理画面で「Broken/Missing」のハンドラーが表示されていないかを手動で確認するよう求めています。EC サイトでは、あわせて次の業務フローを確認します。
- 商品の表示、カートへの追加、数量変更
- チェックアウトと決済(決済事業者のテスト環境やテストモードを利用)
- 注文確認メールの送信と、管理画面での注文表示・ステータス変更
- プロモーションとクーポンの適用
- JSON:API や REST を利用する外部連携やヘッドレスフロントエンドの応答
今回の修正にはアクセス制御の強化が含まれるため、API 連携で従来取得できていたデータが取得できなくなる可能性も考慮し、連携先のエラーログもあわせて確認することをおすすめします。
悪用確認を受けた Drupal Commerce の注文調査
修正版への更新で防げるのは、更新後の悪用です。CVE-2026-118539 の対象バージョンを運用していた期間に注文データが操作されていなかったかは、更新とは別に調査する必要があります。
参考: Drupal.org(SA-CONTRIB-2026-254)
“Sites should audit their orders for inconsistencies”
(サイトは注文データに不整合がないか監査すべきです。)
https://www.drupal.org/sa-contrib-2026-254
調査の前提と対象期間
公式アドバイザリは、悪用の開始時期、対象のルートやフィールド、ログに残る特徴を公開していません。そのため、以下に示す確認項目は公式に確認された攻撃手法ではなく、アクセス制御回避による影響を調べるための運用上の確認例です。
対象期間は、影響バージョンを運用していた期間のうち、ログや決済記録を保持している範囲で、少なくとも修正版の適用時点までとすることを推奨します。特に 2026 年 10 月 28 日の公開前後は、攻撃の試行が増える可能性を考慮して重点的に確認します。
注文内容と決済データの照合
Drupal 側の注文データだけで判断せず、決済事業者の管理画面や売上データなど、Drupal の外にある記録と突き合わせることが重要です。
| 確認観点 | 照合する記録 | 確認するポイント |
|---|---|---|
| 商品価格 | 商品・バリエーションの価格設定と注文明細 | 注文時の単価が当時の販売価格と一致しているか |
| 割引・クーポン | プロモーション設定、クーポンの利用履歴 | 想定外の割引率、対象外商品への適用、利用上限を超えた使用がないか |
| 注文合計と決済金額 | 注文合計、決済事業者側の取引記録 | 注文ごとの金額が一致しているか、決済記録のない「支払済み」注文がないか |
| 注文ステータス | 注文のステータス変更履歴 | 通常の業務フローにない遷移や、担当者が把握していない変更がないか |
| 店舗の割り当て | 注文の店舗情報、既定店舗の設定 | 注文した店舗と割り当て先の店舗が一致しているか(マルチストア構成の場合) |
| アクセス記録 | Web サーバー、WAF、ロードバランサー、Drupal のログ | 匿名ユーザーからの通常と異なる注文関連リクエストや、短時間の集中アクセスがないか |
店舗の割り当ての不整合は、CVE-2026-118542 の影響でも生じ得ます。マルチストア構成では、既定店舗の設定が意図せず変更されていないかもあわせて確認してください。
ログの保全と関係部門との連携
更新前に保全を始めた記録も含め、次の記録を確保します。注文データだけでは判断できない操作もあるため、アクセスログなどと組み合わせて調査できる状態にしておきます。
- Web サーバー、WAF、ロードバランサー、CDN のアクセスログを、ローテーションで消える前に別の保管場所へ複製します。
- Drupal のログ(Database Logging モジュールや syslog の出力)と、更新前のデータベースバックアップを変更せずに保管します。
- 決済事業者の取引記録を、調査対象期間分エクスポートして保管します。
- 保全した日時、取得者、取得方法を記録し、原本を直接編集せずに複製で分析します。
不整合が確認された場合は、経理部門と注文・決済の照合結果を共有し、決済事業者への問い合わせ、顧客対応、返金や追加請求の判断を進めます。顧客情報の閲覧が疑われる場合は、個人情報保護法に基づく報告の要否を法務部門と確認することをおすすめします。
確認項目で不整合が見つからなかったことは、悪用がなかったことの証明にはなりません。ログの保持期間を超える期間や、照合元の記録がない操作は調査できないため、調査範囲と結果を記録として残しておくことをおすすめします。
まとめ
Commerce Core の脆弱性 6 件のうち、CVE-2026-118539 は認証不要で全構成が対象となり、実環境での悪用も確認されています。影響環境では修正版へ速やかに更新し、更新後に過去の注文データを監査することが対応の要点です。
- 対象は Commerce Core を導入した Drupal サイトに限られる。
- 修正版は 3.x 系が 3.3.13、8.x-2.x 系が 8.x-2.41 です。
- 悪用が確認されているのは CVE-2026-118539 の 1 件のみ
- ほかの 5 件は JSON:API や権限設定など特定の構成で成立する。
- 21 / 25 は Drupal 独自の評価で、CVSS とは別の指標です。
- Drupal 本体の要件を確認し、現行系列の修正版へ更新する。
- 更新後は注文と決済記録を照合し、ログを保全する。
以上、最後までお読みいただきありがとうございました。


