Drupal Commerce Coreに悪用中の脆弱性 更新と注文の点検を

Drupal本体を最新にしていても、この脆弱性は残ります。

Drupalのセキュリティチームは10月28日（日本時間29日未明）、拡張モジュール「Commerce Core」の脆弱性を公表しました。番号はCVE-2026-118539（SA-CONTRIB-2026-254）で、攻撃にすでに悪用されているとも書きました。区分は5段階で最も高いHighly critical。ログインなしでアクセス制御を回避できます。

名前に「Core」とあるので紛らわしいのですが、これはDrupal Commerceの土台となるモジュールで、Drupal本体（Drupal core）とは別物です。Adobe Commerce（Magento）とも関係ありません。ECサイトをDrupal Commerceで動かしている会社は、今日のうちに修正版へ上げ、そのあと注文の記録まで点検することになります。

修正版は3.3.13と8.x-2.41

影響するのは8.x-2.41より前と、3.0.0以上3.3.13未満です。上げ先は、いま使っている系統で決まります。

サイト数はDrupal.orgの利用統計（10月18日の週）で、世界全体の自己申告です。表に入れていない3.xの5サイトを含めて合計42,002。国内の数は公表されていません。

気がかりなのは2系です。8.x-2.41は、前の8.x-2.40（2024年8月22日）から2年2カ月ぶりのリリースでした。長く更新の知らせがなかった系統なので、保守の予定から外れたままのサイトもあるでしょう。

Drupal 8の上で動くサイトは8.x-2.41の動作条件に入らないため、本体のアップグレードが先に要ります。Drupal 9は動作条件に入りますが、10月14日の本体のRCEの修正が出ていない版なので、モジュールを上げても本体の脆弱性は残ります。

悩ましいのは7.x-1.xです。全体の約28%が残っているのに、告知の影響範囲は「2.41より前」とあるだけで、Drupal 7向けの1.xを含むのか明記がありません。Drupal 7のサポートは2025年1月5日に終わり、セキュリティチームは、それ以降は本体にも拡張モジュールにも告知を出さないと予告していました。つまり、告知に名前がないことは「影響しない」という意味になりません。当たらないと確認できないまま動かし続けるより、移行か停止を検討する段階だと編集部はみています。

21点の内訳、攻撃のしやすさは満点

Drupalの点数は25点満点で、読み方は10月7日の告知の記事に書いたとおりです。今回は10月の重い2件と並べると、特徴がはっきりします。

差は1点ずつです。でも、中身は逆でした。被害の広さならBlock AJAXと本体のほうが上で、Commerce Coreが3件の中で最も高い点になったのは、攻撃に手間がかからず、攻撃コードがすでに出回っているからでした。

TD:Allは、どの設定のサイトでも当たるという意味です。つまり、設定変更でしのぐ余地がありません。告知が示す対処も、修正版への更新だけです。

満点に届かない4点は、CIとIIが「Some（一部）」の分です。ただ、公式が注文の監査を求めている以上、その「一部」に注文まわりが入るとみるのが自然でしょう。

CVSSもKEVも、まだ教えてくれない

「CVSSが9以上から」「KEVに載ったら急ぐ」。そんな基準で優先度を決めている会社ほど、この件は後回しになりかねません。

CVEの記録によると、告知の公開は世界標準時で10月28日16時54分、記録そのものの公開は30日3時9分で、約34時間の差がありました。その記録にCVSSの点数はありません。10月29日版のKEVにも載っておらず、10月30日に確認した時点でEPSSの値もありませんでした。KEVにあるDrupalの項目は本体の5件だけで、拡張モジュールは1件もないのが実情です。

優先順位の記事で書いた「悪用されるか × 自社にあるか」で言えば、悪用は公式が認めています。残る問いは自社にあるかどうかだけで、数字がそろうのを待つ理由はありません。

管理画面の通知にも頼らないほうがよさそうです。同じ版で修正されるSA-CONTRIB-2026-258は、Commerceの管理画面にある受信箱のCSRFで、細工したページを管理者に開かせると、セキュリティ更新の知らせも含むお知らせを全管理者の画面から消せます。受信箱が空でも、更新が要らない理由にはなりません。

注文の点検で見るところ

公式の告知は、更新と並べて1文で注文の監査を求めました。

Sites should audit their orders for inconsistencies as this vulnerability is being actively exploited.

ただ、何を見るかは示していません。どのルートが狙われるかも明かしておらず、CVEの記録にある手口の型はForceful Browsing、つまりリンクのないURLを直接たたく型というところまでです。これでは、アクセスログの検索語を作れません。

では、どこから見ればよいのでしょうか。手がかりは告知の2つの表現です。原因を「certain routes and entity fields」（一部のルートとエンティティのフィールド）の保護不足とし、影響を「販売側に金銭的な影響が出るおそれ」と書いています。

どのフィールドかは不明ですが、注文の単価や届け先のような項目が書き換えられる形もありうるでしょう。編集部は、お金に関わる項目から順に見るのがよいと考えます。次は、その推測にもとづく案です。

• 決済代行会社の売上データと注文の合計を、注文番号で突き合わせる。金額の差と、入金のない注文が出ないかを見る
• 支払いがないのに完了や発送へ進んだ注文を探す
• 商品の価格やクーポンの設定と、注文の単価を比べる。0円や極端に安い明細に注意する
• 注文のあとで届け先やメールアドレスが変わったものを見る
• 信頼できない利用者に店舗の作成や編集を許しているサイト（マーケットプレイスなど）では、既定の店舗が変わっていないかと、注文の店舗の割り当ても見る。これは別の脆弱性（SA-CONTRIB-2026-257）の点検です

同じ日のCommerce Stripeの告知（SA-CONTRIB-2026-263）は、支払いなしで注文が「支払い済み」になる例を挙げています。別の脆弱性ですが、不整合がどんな形で出るかの参考になります。

さかのぼる期間の目安もありません。悪用の始まりが分からないので、入金の差の確認は、経理の月次の突き合わせが済んだ月の翌日から始めるのが現実的でしょう。ただ、単価を下げられたあとで決済された注文は、合計も入金も一致します。単価や届け先の確認は、月次の範囲より前にもさかのぼっておくと安心です。

Commerce Logモジュールを入れていれば、注文の画面に操作の履歴が残ります。ただ、公式の手引きが挙げる記録はカートの追加と削除、状態の変更、受領メールで、金額の書き換えは例に入っていません。だから、履歴がきれいでも、決済データとの突き合わせは省かないほうが安心です。

この点検は、情シスだけでは終わりません。MagentoのBlockStrapの記事で修正が遅れたストアに勧めた点検は裏口の有無で、頼む先は保守会社でした。今回の相手は注文と入金で、データを持っているのはECの担当や経理のはずです。

決済と配送のモジュールも同じ日に修正

Commerce Coreだけ上げても、足りないかもしれません。Drupalが10月28日に出した拡張モジュールの告知は39件で、そのうち13件がCommerce Coreと周辺のモジュールでした。Commerce Core自身の6件は3.3.13と8.x-2.41で修正され、うち3件はJSON:APIかRESTを使うサイトに関係します。ほかの7件は、モジュールごとの対応が要ります。

Stripeを使うサイトは、Webhookの署名シークレットの欄も見ておくと安心です。公式によると、何か値が入っていれば、この件の不正な処理は防げます。Commerce Licenseで「update own commerce_license」の権限を与えているサイトには、ロールライセンスに想定外のロールがないかの確認と、管理者ロールを持つ利用者の見直しも求めています。

Drupal本体だけのサイトは対象外

影響するのは、Commerce Coreの修正版より前を入れているサイトです。画面を別に作り、APIだけでCommerceを使う構成も含みます。Drupalを使っていてもCommerceを入れていないサイトや、Adobe Commerceは対象外です。

気づきにくいのは、台帳に「Drupal」としか書いていないサイトでしょう。たとえば、制作会社に任せたキャンペーンの販売ページや、海外の子会社の通販が当てはまるかもしれません。

今日のうちに進める手順

1. 自社と委託先のDrupalサイトを洗い出し、composer show drupal/commerceか、管理画面の「Reports」→「Available updates」で版を確認します。委託先には、Commerce Coreと周辺モジュールの版を聞きます。本体が10月14日の修正版以降かも、あわせて見ます。
2. 点検の材料として、データベースとアクセスログの写しを取ってから修正版へ上げます。composer update drupal/commerce --with-dependenciesのあと、update.phpでデータベースを更新します。保守モードにするなどの流れは10月7日の告知の記事と同じです。
3. 上げられないサイトは、ここが分かれ道です。7.x-1.xとDrupal 8のサイト、今日は更新できないサイトについて、販売を止めるか、移行や更新の日を決めるかを今日のうちに判断します。公式に回避策はないので、動かし続けるなら経営の了承を取り、その日付を記録します。
4. ECの担当や経理に頼み、決済代行会社のデータで注文の点検を始めます。
5. 食い違いが出たら、注文番号と金額、時刻を記録して決済代行会社に知らせます。注文者の情報を見られた跡があれば、漏えいのおそれとして個人情報保護委員会に報告します。ガイドラインでは、速報は知った時点から概ね3〜5日以内が目安で、不正の目的のおそれがある事態の確報は、知った日から60日以内です。

Coreという名前に安心して、本体の更新表に「済み」と書いて閉じる。この件でいちばん避けたいのは、その形です。