Drupal Commerce Coreで悪用確認｜3.3.13への更新と注文監査を進める

Drupal Security Teamは2026年10月28日、Commerce Coreのアクセス制御を回避する脆弱性CVE-2026-118539を公表し、実環境で悪用されていると説明しました。対象サイトは修正版へ更新するとともに、注文の不整合を監査する必要があります。3系は3.3.13、従来の2系は8.x-2.41が告知の更新先です。Drupal本体だけを更新して対応済みにしないでください。

本稿は11月2日に公式告知と修正リリースを確認したニュース解説です。主題はCommerce Coreの更新と注文調査であり、特定店舗の侵害を報告するものではありません。以下の業務確認は本サイトの提案を含み、攻撃の再現試験や修正版の実機検証を行った結果ではありません。

買い物かごだけでなくAPIを使う構成も確認する

公式告知SA-CONTRIB-2026-254によると、Commerce Coreはショッピングカートやチェックアウトフォームに加え、APIを通じた分離型アプリケーションでも商品・サービスを販売するためのモジュールです。特定のルートとエンティティーのフィールドに対する保護が十分でなく、アクセス制御の回避が販売者へ金銭的な影響を及ぼす可能性があります。

公式評価はHighly criticalの21/25です。これはDrupal独自のリスク評価で、CVSSの21点や10点満点のスコアではありません。告知の評価には認証不要と実際の悪用が示されています。一方、具体的な被害店舗数、損失額、悪用開始日、攻撃者の属性はこの資料では説明されていません。

対象の管理名はcommerceです。見た目の購入画面を独自に作っていても、裏側でこのモジュールを利用している可能性があります。担当者は画面のブランド名だけで判定せず、稼働環境の依存パッケージと構成を確認してください。単にDrupalを使っているという理由で全サイトが同じ影響を受けると断定することも適切ではありません。

2系と3系で更新先とDrupalの要件を分ける

主題CVEの影響範囲は2.41未満、または3.0.0以上3.3.13未満です。境界に等号を付けて「2.41以下」「3.3.13以下」と書くと修正版まで含めてしまいます。公式の8.x-2.41という表記とComposerの2.41という版表記を、別製品として取り違えないようにします。

3.3.13のリリースページは対応するDrupalを^10.3または^11としています。8.x-2.41のページは^9.3または^10としています。既存サイトの系列、Drupal本体、他の拡張の制約を合わせて確認し、脆弱性対応の途中で根拠なくメジャー系列を変更しないでください。

3.3.13の公式掲載コマンドはcomposer require 'drupal/commerce:^3.3'、2系はcomposer require 'drupal/commerce:^2.41'です。ただし、これは依存制約の指定例です。実際にどの版が解決されたかは別に確認しなければなりません。既存のロックファイルや他の制約によって、コマンドを入力しただけでは目的の成果物へ切り替わらない場合があります。

本サイトの提案として、最初に稼働版、composer.jsonの制約、composer.lockの解決版、配信対象のリリースを対応付けます。開発端末の版と本番で読み込む版を別欄に記録すると、手元の更新だけで作業が終わることを防げます。依存競合が出た場合は競合する制約を特定し、変更範囲をレビューしてから解決してください。

同時修正の5件は成立条件が異なる

両修正リリースには主題のほかに5件の告知が結び付いています。一つの更新で対応できるからといって、すべてが認証不要で悪用中だと読み替えてはいけません。それぞれが扱うデータと入口を確認すると、更新後の受け入れ試験と過去の調査を具体化できます。

SA-CONTRIB-2026-255／CVE-2026-118540はJSON:APIを併用する構成で、公開商品にひも付く非公開の商品バリエーションへ、権限のない利用者がアクセスできる問題です。影響範囲は2.41未満または3.0.0以上3.2.0未満と記載され、3.3系はこの問題の影響を受けないと説明されています。主題CVEの範囲と同一ではありません。

SA-CONTRIB-2026-256／CVE-2026-118541は、自分のプロモーションだけを管理できる利用者が、別のプロモーションのクーポンを変更・削除できる問題です。JSON:APIまたはRESTを通じた書き込みを受け付ける構成が必要で、既定では有効になっていない条件とされています。APIを表示用に使う構成と書き込みも許可する構成を区別します。

SA-CONTRIB-2026-257／CVE-2026-118542は店舗の保存時のアクセス検査に関係します。店舗作成または自分の店舗の編集権限を持つ利用者が、自分の店舗を既定に設定し、本来受け取らない注文を受ける可能性があります。出店者自身が店舗を管理するマーケットプレイスなど、信頼できない利用者へ該当権限を付けるサイトが対象です。

SA-CONTRIB-2026-258／CVE-2026-118543はCommerceダッシュボードの受信箱に関するCSRFです。必要な管理権限を持つ利用者を細工したページへ誘導すると、通知を非表示にでき、共有される受信箱のため他の管理者からもメッセージが見えなくなります。セキュリティ更新の通知も含まれます。通知がないことだけを未対応案件がない証拠にしないでください。

SA-CONTRIB-2026-259／CVE-2026-118544はエンティティークエリーが返す商品バリエーションの制限に関係します。コアのJSON:APIが有効な場合、繰り返し要求によって非公開バリエーションなどの特定フィールド値を推定できると説明されています。118540の直接的なアクセスと同じ説明へまとめず、別の確認項目として扱います。

更新作業と注文監査を並行して進める

主題告知は、実際に悪用されているため注文の不整合を監査するよう明記しています。更新は今後の悪用経路を修正する作業で、過去に保存された注文を正常に戻す作業ではありません。修正済み版の適用を待ってから調査を始める必要はなく、技術担当と受注・経理担当で並行して進めることを提案します。

監査の具体的な着眼点として、本サイトでは注文の明細、合計、割引、決済記録、店舗への割り当てを、通常の業務記録と照合することを提案します。これらすべてが今回の攻撃で変更されると公式が確認したという意味ではありません。注文監査という公式要請を、自社が保存する情報で実行するための確認例です。

例えば受注管理上の金額と決済事業者側の記録が一致しない場合、キャンセル、部分返金、担当者による正規の訂正などをまず区別します。不一致だけで侵害と断定せず、注文ID、変更時刻、正規の作業履歴と関連付けます。差異の理由を追跡できるようにすると、修正すべき注文と説明できる差異を分けられます。

調査開始日の根拠も記録してください。10月28日は公表日であり、攻撃が始まった日だとは説明されていません。その日以後だけを機械的に対象にせず、自社のログ保持期間、導入履歴、異常の兆候に応じて調査範囲を決めます。必要な記録が残っていない期間は、確認済みの期間と分けて報告するのが適切です。

本番反映後は注文の流れと権限を確認する

更新前にはデータベース、設定、配信成果物の復旧手順を確認し、調査に必要なログや注文データを保全します。作業中に注文を受け続ける構成では、バックアップ後に増えた取引をどう扱うかも決めます。古いスナップショットへ戻すだけでは、新しい正規注文まで失うおそれがあるためです。

受け入れ試験は検証環境とテスト用データで行うことを提案します。匿名購入、会員購入、割引、決済連携、注文確認、キャンセルなど、利用中の経路を選びます。更新が成功しても、独自コードや外部サービスとの連携が同じように動くとは限らず、管理者でトップ画面を開けたことだけでは判断できません。

同時修正に対応する確認として、非公開の商品情報が公開側へ出ないこと、出店者が他者のクーポンや店舗設定へ干渉できないこと、必要な管理通知を確認できることを試験項目にします。攻撃用の要求を本番へ送るのではなく、自社が想定する役割と操作で許可範囲を確認してください。API経由の購入を使う場合は、画面側とは別にその経路も試験します。

複数台のWebサーバーや別のAPI配信環境がある場合は、すべてへ修正版が反映されたことを確認します。切り戻しで未修正版へ戻す必要が生じたら、公開継続の判断もやり直します。更新完了、受け入れ試験完了、注文監査完了を分けて記録すると、技術対応だけで調査まで完了したと誤認することを防げます。

Drupal本体の別の更新については、Field UIとEntity Listの記事で扱っています。今回のCommerce Coreとは対象も識別子も異なり、先行記事の修正を適用済みでもCommerceの確認は残ります。まず自社のcommerceの版を確定し、更新担当と注文監査担当を決めることが出発点です。

保守会社へ依頼する際は「Drupalを最新にしたか」だけでなく、Commerce Coreの系列と解決版、本番反映時刻、注文監査の担当・対象期間・未確認範囲を回答してもらいます。修正作業の完了報告と業務データの調査報告を別に受け取ることで、担当の境目に未処理の確認が残ることを避けられます。

調査結果は「異常なし」「異常を確認」「記録不足で判断できない」に分けて残します。注文が正常に見える場合でも、調査できた期間や照合に使った決済記録を添えることで、後日追加の不整合が判明した際に同じ範囲を最初から調べ直す負担を減らせます。