この記事のポイント
- 脆弱性
- CVE-2026-103671
- 深刻度
MEDIUM5.3
- 対象
- EC-CUBE AmazonPayプラグイン
- 悪用状況
- 確認済み
- 情報の種類
- 二次情報のみ
- 公表日
目次
EC-CUBE4系向けの公式AmazonPayプラグインに、注文手続き中に任意のWebサイトへ転送される可能性がある脆弱性CVE-2026-103671が公表されています。JVNは、開発者による悪用確認を掲載し、転送の結果としてアカウント情報などが窃取される可能性を説明しています。ECサイト運営者は、決済方法の名前だけでなく、導入しているプラグインの版まで確認する必要があります。
情報確認日は2026年10月16日です。JVNとEC-CUBEの告知は10月14日の公表情報であり、16日に新たに発生した事件として扱うものではありません。本記事では、確認できた対象範囲と公式の対応案内を整理した上で、店舗側で実施する点検を本サイトの提案として示します。出典：JVN#43511918：EC-CUBE4系用AmazonPayプラグインの脆弱性、EC-CUBE公式：AmazonPayプラグインの脆弱性のお知らせ。
スポンサーリンク
何が公表され、何がまだ分からないのか
JVNで示されている分類は「不変と想定しているWebパラメータの外部制御」です。注文の途中で別のWebサイトへ転送される可能性と、その先でのアカウント情報窃取の可能性が示されています。一方、資料を読まずに、Amazon Pay全体のサービスが侵害された、すべての利用者の情報が流出した、と広げて説明することはできません。
今回の対象はEC-CUBE4系向けの特定の公式プラグインです。WordPressの決済プラグインや、別のEC基盤で同じ決済サービスを使っていることだけでは、今回の影響対象とは判断しません。また、悪用が確認されているという情報から、全店舗が侵害済みだとも言えません。公開資料で確認できない攻撃開始日、被害件数、具体的な攻撃者像は本記事では示しません。
JVNに掲載されたCVSS v4.0の基本値は5.3、CVSS v3.0の基本値は4.7です。数値だけを見ると最上位の深刻度ではありませんが、JVNは緊急情報として掲載し、開発者による攻撃の確認も記載しています。対応順序は点数だけで決めず、実際の悪用状況と自店舗の対象条件を合わせて判断します。出典：JVN#43511918：EC-CUBE4系用AmazonPayプラグインの脆弱性。
本体とプラグインのバージョンを別々に記録する
「EC-CUBEは4系」「Amazon Payは導入済み」という情報だけでは判定できません。EC-CUBE本体の系統と、AmazonPayプラグインのCV1・CV2の区分、プラグイン自体のバージョンを対応させます。JVNが掲載する影響範囲は次のとおりです。
| 区分・対応本体 | JVN掲載の対象バージョン |
|---|---|
| CV2版・4.0/4.1系 | v1.1.7〜v1.1.12、およびv1.0.0〜v1.1.6 |
| CV2版・4.2/4.3系 | v4.3.1のバンドル版 |
| CV2版・4.2/4.3系 | v4.2.3〜v4.3.1、およびv4.2.0〜v4.2.2 |
| CV1版・4.0系 | v1.3.0およびそれ以前 |
「バンドルされていたから別途確認しなくてよい」とは考えません。管理画面、導入時の資料、保守会社の台帳を照合し、どのファイルが実際に稼働しているかを確認します。独自の改修や過去の個別パッチがあるなら、表示上の番号だけで判断せず、保守担当と適用内容を確認してください。出典：JVN#43511918：EC-CUBE4系用AmazonPayプラグインの脆弱性。
スポンサーリンク
CV1の古い版は単純な更新を前提にしない
EC-CUBEの告知は、公式プラグインの最新版への更新による修正を案内する一方、CV1版のv1.2.9以前は最新版v1.3.1へバージョンアップできず、CV2版への移行を強く推奨しています。古い版を使っている店舗では、更新ボタンを一回押すだけの作業と見積もらず、移行の準備も含めて確認します。
また、同告知はクラウド版ec-cube.coについて修正済みと案内しています。これは公式が説明する対象サービスの状況であり、すべてのレンタルサーバー上のEC-CUBEが自動修正されるという意味ではありません。自社がどの提供形態を使っているかを確かめます。出典：EC-CUBE公式：AmazonPayプラグインの脆弱性のお知らせ。
具体的な適用ファイル、操作手順、適用可能な組み合わせは提供元の案内と保守契約先で確認してください。本記事は環境別のパッチ手順を検証したものではありません。公式告知から対応窓口や詳細案内へ進み、別系統向けのファイルを流用しないことを優先します。
リダイレクト先は見えない設定でも信頼しない
MITREのCWE-472は、hiddenフィールドなど、変更されないと思い込んでいる値が実際には外部から制御できる問題を説明しています。画面に入力欄が表示されていないことは、通信する値の完全性を保証しません。CookieやURL、フォームの値などを、サーバー側の判断でそのまま信用しないことが基本になります。出典：MITRE：CWE-472 外部から変更できるWebパラメータの問題。
一般的な説明用の仮想例として、購入完了後の戻り先をブラウザーから受け取り、そのまま転送する処理を考えます。画面が通常の購入ボタンしか表示していなくても、その裏で送られる値を変更できるなら、想定外の転送先へ進む可能性があります。これは問題の種類を理解するための例であり、今回のプラグインの具体的なパラメータ名や攻撃手順を再現したものではありません。
開発側では、戻り先をサーバー側の識別子から選ぶ、許可した送信先へ限定するなどの設計を検討します。単に「httpsで始まるか」を見るだけでは、自社とは無関係なHTTPSサイトも通ります。必要な外部決済先を含め、どの遷移を許可するかを業務フローと一緒に定義することを提案します。
スポンサーリンク
店舗側の最初の対応は影響判定と担当の確定
ここからは本サイトの実務上の提案です。最初に、本番と検証環境の両方で、対応本体、プラグインの区分・版、改修の有無、保守担当を一覧にします。店舗運営者にサーバー操作権限がない場合は、自分でファイルを置き換えるより、保守会社へ対象判定と修正方法を確認します。
作業の責任者と、決済を確認する業務担当を分けておくと、技術的な更新成功だけで完了扱いにしにくくなります。例えば、保守会社がファイル更新を担当し、店舗担当が注文管理と入金状態を確認する形です。移行や一時的な決済方法の停止が必要な場合は、その判断者と顧客への案内も決めます。
悪用確認の情報があるため、通常の改修待ちへ無期限に積むのは避けます。ただし、決済機能を無計画に止めると、注文の取り扱いや返金対応へ別の混乱を招きます。修正までの間に機能制限が必要かは、自環境の条件と公式・保守先の助言に基づき判断してください。
更新・移行前に現状と記録を残す
作業前に、現在のプラグイン情報、独自改修、設定、バックアップ、アクセスログなど、復旧と調査に必要な資料の保管状況を確認します。これは今回の公式な個別手順を代替するものではなく、本サイトが提案する変更管理の準備です。診断資料を公開ディレクトリへ置いたり、秘密の値を共有チャットへ貼ったりしないようにします。
本番と同等の構成を用意できる場合は、検証環境で修正や移行の影響を確認します。旧版の独自改修が新しい版で消えないか、注文メール、配送条件、会員情報とのつながりに変化がないかを見ます。検証環境へ実顧客の情報を無条件に複製せず、必要な範囲のテストデータを使います。
更新作業は環境に合った公式手順へ従い、実施日時、担当者、適用内容を記録します。作業後に不具合があったときも、脆弱な旧版への復元をそのまま長期運用の解決策にせず、保守先と安全な継続方法を相談します。
確認すべきは決済ボタンより注文の一連の状態
以下は適用後に組み込む確認項目の案です。提供元が指定する検証に加え、店舗固有の設定に応じてチェックします。自動化した結果だけでなく、実画面の遷移と管理側の状態も確認してください。
- 注文開始から決済、店舗への戻りまで、予定したドメインと経路で遷移すること。
- 成功した注文の金額・注文番号・決済状態が、店舗側と決済側で整合すること。
- キャンセル、戻る操作、通信中断の後に、注文が不正に完了扱いにならないこと。
- 同じ操作の再送や画面再読み込みで、意図しない重複注文・処理が起きないこと。
- 会員購入、ゲスト購入など、店舗が実際に提供する経路を確認すること。
これらは今回の脆弱性がすべての項目を直接引き起こすという主張ではありません。修正や版の移行に伴う回帰を見つけるための検証です。決済のテストは提供元が認めるテスト手段や環境で行い、実顧客のアカウントや実際の売上を安易に使わないようにします。
更新が済んだことと被害がなかったことを分ける
修正済みの状態へ変えたことは、過去の悪用がなかった証明にはなりません。想定外の遷移についての問い合わせや、身に覚えのないアカウント操作があった場合は、発生時刻と関係する記録を保全し、保守先・セキュリティ担当へ調査を依頼します。根拠のない被害件数や流出範囲を告知しないことも重要です。
反対に、一次資料に悪用確認とあるだけで、全顧客へ一律に情報流出が起きたと通知する根拠にもなりません。自店舗への影響、残された記録、顧客の申告などを整理した上で、対応が必要な範囲を決めます。パスワード変更などを案内する場合は、利用者が確認できる正規の窓口から行い、新たな不審リンクを踏ませない構成にします。
スポンサーリンク
今回の点検を今後のプラグイン管理へつなげる
今回の優先順位は、対象版の確認、環境に合う公式の修正・移行、注文と決済の動作確認、過去の影響の点検です。本体だけでなく決済プラグインの台帳を保ち、バンドル版も独立した確認対象へ入れます。CV1の古い版のように通常更新へ進めない条件は、運用の制約として早めに把握しておくと対応を組み立てやすくなります。
本記事で確認したのは公表資料の範囲であり、読者の店舗を診断した結果ではありません。攻撃開始日、全被害範囲、AI悪用の有無は確定していません。既存の情報と新しい案内を混同せず、最新の公式告知を確認しながら、影響判定と完了記録を残してください。
