2026.10.16 セキュリティ

EC-CUBE AmazonPayプラグインの脆弱性とは？修正版の確認SQLと侵害調査の手順

EC-CUBE 4系で使われている公式「AmazonPayプラグイン」に、注文手続き中の購入者を任意のサイトへリダイレクトさせられる脆弱性 CVE-2026-103671 が見つかりました。2026年10月14日にJVNとイーシーキューブが公表し、開発者は悪用を確認しています。この記事では、影響を受けるプラグインのバージョンと修正版、自社の店舗が対象かをSQLで確かめる手順、不正な管理者アカウントとリダイレクト被害を探す調査のコマンド、更新しにくいCV1版を使っている店舗の判断までを、実装者の目線で整理します。記載内容の基準は、2026年10月16日時点で公開されている情報です。

まとめ：AmazonPayプラグインはv4.3.2・v1.1.13へ更新し管理者を総点検

対象はAmazon Pay V2プラグインの4.2/4.3系v4.3.1以前（EC-CUBE 4.3.1同梱のバンドル版を含む）、4.0/4.1系v1.1.12以前、そして旧CV1版のv1.3.0以前です。EC-CUBEストアのリリースノートでは、4.2/4.3系はv4.3.2、4.0/4.1系はv1.1.13がリダイレクト処理を直した版にあたります。CV1版の最新はv1.3.1です。

更新だけでは終わりません。イーシーキューブは危険度を「高」とした理由に、不正な管理者アカウントを登録されて管理画面にログインされる点を挙げています。プラグインを上げる前後で、管理者アカウントの一覧とアクセスログを確認してください。

CV1版のv1.2.9以前はv1.3.1へ上げられず、公式はCV2版への移行を強く推奨しています。決済まわりの改修を伴うため、自社で手当てできない場合は早めに開発会社へ相談する前提で計画を立てます。

EC-CUBE AmazonPayプラグイン脆弱性の内容と公表経緯

JVN#43511918の題名は「EC-CUBE4系用プラグイン『AmazonPayプラグイン』における不変と想定しているWebパラメータの外部制御の脆弱性」です。報告は開発者自身がJPCERT/CCへ行い、JPCERT/CCが調整して公表に至りました。

CWE-472の意味と注文手続き中に任意サイトへ飛ばされる仕組み

脆弱性の型はCWE-472（Assumed-Immutable Parameterの外部制御）です。サーバーが「利用者には書き換えられない」と見なしてHTMLの隠しフィールドやクエリ文字列、Cookieに載せた値を、検証しないまま信じてしまう欠陥を指します。今回は、その値が注文手続き中の遷移先として使われ、書き換えると購入者を外部サイトへ送れる状態でした。

Amazon Payの決済は、店舗とAmazonのページを行き来するリダイレクトの連続です。Amazon Pay API v2のCheckout Sessionでは、注文確認ページへ戻すURL（checkoutReviewReturnUrl）や取引完了後の戻り先（checkoutResultReturnUrl）を店舗側が指定し、本番環境ではドメインをSeller Centralへ登録する決まりがあります。Amazon側の戻り先は守られていても、店舗側のプラグインが自分のページ間の遷移先を外から受け取って検証していなければ、そこが抜け道になります。

どのパラメータが悪用されたかは公表されていません。購入者からは正規の注文フローの途中で画面が切り替わったようにしか見えないため、偽のログイン画面でアカウント情報を入力させる攻撃と相性が良い点が問題です。リダイレクトの種類と挙動の基礎はリダイレクトの仕組みと301・302の違いで整理しています。

JVNのCVSS 5.3と公式の危険度「高」が食い違う理由の読み方

JVNの評価はCVSS v4.0で5.3（AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N）、v3.0で4.7です。購入者の操作が必要で、影響は店舗のシステムではなく遷移先という「後続のシステム」の完全性に限られる、という読み方になります。スコアの各指標の意味はCVSSの計算式とスコアの目安で確認できます。

一方、EC-CUBE公式のお知らせは危険度を「高」とし、その理由を「不正管理者アカウントが登録でき、管理画面にログインできるため」と書いています。CVSSの数字だけを見て後回しにするのは誤りです。悪用が確認済みで、開発元が管理画面の乗っ取りまで想定している以上、緊急案件として扱います。

修正版リリース2026年8月17日から10月14日公表までの時系列

見落としやすいのは、修正版が公表より約2か月早く出ていた点です。

日付（2026年）	出来事	出典
8月17日	V2プラグインv4.3.2・v1.1.13公開	EC-CUBEストア
10月14日	脆弱性を公表・悪用確認を記載	EC-CUBE公式・JVN
10月14日	JVNDB-2026-000150を登録	JVN iPedia

Amazon Pay V2プラグイン（4.2/4.3系）のストアページには、v4.3.2のリリースノートとして「注文手続き中のリダイレクト処理において、想定外の画面へ遷移するケースを修正しました」とだけ書かれています。この文面からは脆弱性の修正だと読み取れず、8月の時点で更新の優先度を上げる材料はありませんでした。8月以降にプラグインを更新していない店舗は、公表日まで露出していた前提で調査範囲を決めてください。

影響を受けるプラグインのバージョンとEC-CUBE本体系列ごとの修正版の対応

AmazonPayプラグインは、EC-CUBE本体の系列とAmazon Payの世代（CV1・CV2）によって製品が分かれています。まず自社がどの製品を入れているかを特定します。

4.2/4.3系はv4.3.2・4.0/4.1系はv1.1.13へ上げる対応表

JVNの「影響を受けるシステム」と、各製品のストアページに載ったリリースノートを突き合わせると、次の対応になります。製品名は短縮し、版番号はプラグイン側の番号です。

製品（EC-CUBE本体の系列）	影響を受ける版	修正を含む版
Amazon Pay V2（4.2/4.3系）	v4.2.0〜v4.3.1（バンドル版含む）	v4.3.2
Amazon Pay V2（4.0/4.1系）	v1.0.0〜v1.1.12	v1.1.13
Amazon Pay CV1版（4.0系）	v1.3.0以前	v1.3.1

4.0/4.1系の修正版v1.1.13も、4.0/4.1系のストアページで2026年8月17日リリース、同じ修正文言であることを確かめられます。修正手順の詳細ページはEC-CUBEのマイページ（会員ログイン）経由で公開されています。版番号は追って変わることがあるため、作業前に公式お知らせとストアページで最新版を確認してください。

EC-CUBE 4.3.1同梱のバンドル版とCV1版v1.2.9以前が抱える落とし穴

EC-CUBEは2025年9月のプレスリリースで、Ver.4.3.1にAmazon Payを標準搭載したと発表しました。4.3.1以上ではプラグインのダウンロードが不要になった反面、「プラグインを入れた覚えがないので関係ない」という誤解が起きやすくなっています。公式お知らせは対象に「バンドル版含む」と明記しています。4.3.1で構築した店舗は、Amazon Payを使っていなくても版を確認してください。

もうひとつの落とし穴がCV1版です。公式お知らせによると、CV1版のv1.2.9以前はv1.3.1へバージョンアップできません。修正版へ上げる経路がないため、CV2版への移行が実質的な対策になります。移行の判断は後半の章で扱います。

dtb_pluginのSQL照会によるAmazon Payの版と有効状態の確認手順

版の確認は管理画面の「オーナーズストア」配下のプラグイン一覧で足ります。複数の店舗や環境をまとめて確かめるなら、データベースを直接照会したほうが速く、記録も残せます。

管理画面とSQLの両方でプラグインのバージョンを確認するコマンド

EC-CUBE 4系はインストール済みプラグインをdtb_pluginテーブルに保持しています。EC-CUBE 4.3ブランチのPluginエンティティが列名の確認先です。プラグインコードは製品ごとに異なるため、名前とコードの両方を部分一致で拾います。

-- Amazon Pay関連プラグインのコード・版・有効状態を確認する（MySQL/PostgreSQL共通）
SELECT id, name, code, version, enabled, update_date
FROM dtb_plugin
WHERE LOWER(code) LIKE '%amazon%'
   OR LOWER(name) LIKE '%amazon%'
ORDER BY update_date DESC;

versionが上の対応表の「影響を受ける版」に入っていれば対象です。enabledが0（false）でも安心はできません。無効化したプラグインのファイルがapp/Plugin配下に残っていれば、有効化した時点で同じ欠陥が戻ります。

更新はオーナーズストアから行うのが標準です。ファイルを差し替えて更新処理だけを流す運用をしている場合は、本体のPluginUpdateCommandが提供する bin/console eccube:plugin:update <プラグインコード> を使います。このコマンドはapp/Plugin配下に置かれたファイルの設定を読んで更新処理を流すため、新しいファイルの配置を先に済ませておきます。

複数店舗・検証環境・停止中プラグインまで確認範囲を広げる理由

確認は本番だけでは足りず、検証環境も対象です。検証環境の管理画面がインターネットから到達でき、本番と同じ管理者のパスワードを使い回していれば、そこで盗まれた情報が本番に効きます。

制作会社が複数の店舗を預かっている場合は、店舗ごとにEC-CUBE本体の版・プラグインの版・Amazon Payの有効状態・最終更新日を1行ずつ記録し、8月17日以降に更新済みかどうかで色分けすると、どこから手を付けるかが決まります。

不正な管理者アカウントとリダイレクト被害を洗い出す侵害調査のSQLとログ確認

プラグインの更新は今後の悪用を止めるだけで、すでに登録された管理者アカウントや盗まれた情報は元に戻りません。更新の前後で、次の順に痕跡を確認します。

dtb_memberの作成日時と二段階認証の有無から不審な管理者を抽出するSQL

管理者アカウントはdtb_memberテーブルにあります。Memberエンティティの定義では、作成日時・更新日時・最終ログイン日時に加え、二段階認証の有効状態と、そのアカウントを作った管理者のID（creator_id）を持っています。

-- 管理者アカウントを作成日時の新しい順に並べ、作成者と二段階認証の状態を確認する
SELECT m.id, m.login_id, m.name, m.authority_id,
       m.creator_id, c.login_id AS created_by,
       m.two_factor_auth_enabled,
       m.create_date, m.update_date, m.login_date
FROM dtb_member m
LEFT JOIN dtb_member c ON c.id = m.creator_id
ORDER BY m.create_date DESC;

見るべき点は3つあります。社内の誰も作った覚えのないアカウント、作成者が本来その操作をしない人になっているアカウント、そして最近ログインしているのに担当者がいないアカウントです。調べる期間は、影響を受ける版を入れていた全期間です。不審な行が見つかっても、削除する前に結果を保存してください。

アクセスログで管理者登録URLへのPOSTと見慣れない送信元を探すコマンド

管理者の新規登録は、MemberControllerの定義どおり /{管理画面のパス}/setting/system/member/new へのPOSTで行われます。管理画面のパスは環境変数ECCUBE_ADMIN_ROUTEで決まり、既定値はadminです。Webサーバーのアクセスログから、このURLへのPOSTと、管理画面へアクセスした送信元IPを集計します。

# 管理者の新規登録URLへのPOSTを抜き出す（ADMIN は ECCUBE_ADMIN_ROUTE の値に置き換える）
ADMIN=admin
zgrep -h "POST /${ADMIN}/setting/system/member/new" /var/log/nginx/access.log*

# 管理画面へのアクセスを送信元IP別に数え、多い順に並べる
zgrep -h " /${ADMIN}/" /var/log/nginx/access.log* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 30

コマンドに記載したログの場所は、Nginxの既定パスです。Apacheなら/var/log/httpd/や/var/log/apache2/に読み替えます。社内や制作会社の固定IP以外から管理画面へ継続的にアクセスがあれば、前のSQLで見つけたアカウントの作成日時と突き合わせます。

痕跡が見つかったときに優先する保全・パスワード変更・購入者への連絡

不審なアカウントやPOSTが見つかったら、ログとデータベースのダンプを先に退避し、その後でアカウントの無効化と全管理者のパスワード変更に進みます。順番を逆にすると、何が起きたかを後から説明できなくなります。

購入者側の被害は、偽のログイン画面で入力したアカウント情報の流出です。注文フローの途中で外部ドメインへ遷移したという問い合わせがないかを確認し、該当期間の購入者へ注意喚起を出すかを決めます。偽画面への誘導がどう成立し、受け手側で何を防げるかはフィッシング詐欺の仕組みと技術的対策で整理しています。同じEC-CUBE 4系では本体側にもMFAバイパスの脆弱性CVE-2026-30777が見つかっており、本体側の修正ファイルが当たっているかも同時に確認しておくと手戻りがありません。

更新を当日中に行う店舗と移行計画で対応する店舗を分ける判断基準

結論から言うと、V2プラグインを使っている店舗は当日中に修正版へ上げます。手間がかかるのはCV1版の店舗だけで、そこは移行計画を立てるまでAmazon Payを止める判断になります。

Amazon Payを有効化したまま即日更新すべき条件と一時停止で凌ぐ場面

V2プラグインの4.2/4.3系・4.0/4.1系で、修正版v4.3.2・v1.1.13がそのまま当てられる店舗は、営業中でも更新を優先します。リリースノートに書かれた変更はリダイレクト処理の修正だけです。検証環境で注文を1件通してから本番へ反映する、という最小限の確認で足ります。

独自にプラグインを改修していて、上書きすると改修が消える店舗は事情が違います。この場合は改修の差分を取り直すまでの間、管理画面でAmazon Payの決済方法を停止し、ほかの決済手段だけで営業する判断が妥当です。改修を守るために脆弱な版で決済を受け続ける選択は取りません。

CV1版利用店舗はCV2移行かEC-CUBE本体更新かを決める判断

CV1版のv1.3.0なら、まずv1.3.1へ上げて当面の穴を塞ぎます。v1.2.9以前は修正版がないため、Amazon Payを停止したうえで、次のどちらかを選びます。

EC-CUBE本体が4.0/4.1系のままで、本体の更新を当面予定していないなら、CV2版の4.0/4.1系向けプラグインv1.1.13へ移行します。本体の4.3系への更新を検討中なら、移行先を4.3.1以上にそろえ、標準搭載のAmazon Payを使う計画にしたほうが、プラグインを二度入れ替えずに済みます。どちらも決済フローとテンプレートの改修を伴い、本番前の注文テストが必須です。社内に担当者がいない場合は、ECシステム開発として決済まわりの改修と本体更新をまとめて外注するのが現実的です。

ECCUBE_ADMIN_ALLOW_HOSTSによる接続元制限と二段階認証の設定

今回の危険度の根拠が管理画面への不正ログインである以上、管理画面の入口を狭める設定は更新とあわせて入れます。EC-CUBE 4.3のeccube.yamlでは、管理画面の接続元をECCUBE_ADMIN_ALLOW_HOSTS（JSON配列）で制限でき、二段階認証はECCUBE_2FA_ENABLEDで既定が有効です。

# .env の設定例（IPアドレスは自社・制作会社の固定IPに置き換える）
ECCUBE_ADMIN_ROUTE=shop_manage_7k2q
ECCUBE_ADMIN_ALLOW_HOSTS=["203.0.113.10","198.51.100.24"]
ECCUBE_2FA_ENABLED=1

設定を変えたら bin/console cache:clear --no-warmup でキャッシュを消します。前のSQLでtwo_factor_auth_enabledが0の管理者は二段階認証を設定していない状態なので、残っていないかを確かめてください。多要素認証の方式ごとの強さは多要素認証（MFA）の実装方式で比べています。

EC-CUBE AmazonPayプラグイン脆弱性の対応でよく受ける質問と回答

CVE-2026-103671の対応を進めるときに出てきやすい疑問に、公開されている一次情報の範囲で答えます。

Amazon Payを申し込んでいなくても対応は必要ですか？

プラグインが入っていれば必要です。EC-CUBE 4.3.1以上ではAmazon Payが標準搭載されており、公式お知らせは対象に「バンドル版含む」と明記しています。Amazonとの契約がなく決済方法として使っていなくても、記事中のSQLでdtb_pluginに該当行があり、版が影響範囲に入っていれば更新してください。使う予定がないなら、更新したうえで無効化しておくと安全です。

クラウド版のec-cube.coを使っている場合はどうなりますか？

イーシーキューブの公式お知らせによると、クラウド版の「ec-cube.co」はすでに修正済みです。利用者側でプラグインを更新する作業はありません。ただし、修正前の期間に不正な管理者アカウントが作られていないかは別の問題です。管理画面のメンバー管理で、身に覚えのないアカウントがないかだけは確認しておくことを勧めます。

8月にプラグインを更新済みなら調査は不要ですか？

v4.3.2またはv1.1.13を8月17日以降すぐに入れていたなら、露出期間は短く、調査の優先度は下がります。ただし、それ以前の版を使っていた期間に悪用されていた可能性はゼロではありません。開発者は悪用を確認していますが、いつから攻撃があったかは公表されていません。管理者アカウントのSQLだけは、更新済みの店舗でも一度流しておくのが確実です。

CVSSが5.3なのに緊急扱いする必要はありますか？

あります。CVSSは脆弱性そのものの技術的な深刻度で、悪用の有無や事業への影響は含みません。今回はJVNが「悪用を確認」と記載し、開発元は管理画面へのログインまで起こりうるとして危険度を「高」にしています。決済の途中で購入者を偽サイトへ誘導されれば、店舗の信用にも直結します。点数ではなく悪用状況で優先度を決めてください。

自社で更新や調査ができない場合はどこに相談すればよいですか？

まずはサイトを構築した制作会社に、プラグインの版と更新可否を確認するのが近道です。構築元と連絡が取れない、独自改修が多く更新で壊れる恐れがある、CV1版からの移行が必要、といった場合は、EC-CUBEの改修経験がある開発会社に依頼します。外部に点検を頼むときの範囲の決め方は脆弱性診断の進め方と外注時の判断基準が参考になります。