EC-CUBEのXSS対応を「本体更新だけ」で終わらせない｜独自テンプレート・プラグイン・管理画面の入力経路を棚卸しするパッチ適用台帳

EC-CUBEでXSS（クロスサイトスクリプティング）の脆弱性情報が出たとき、「本体を更新したので完了」と判断すると、独自改修部分の確認が抜けることがあります。

特に、商品説明やカテゴリ名、アップロードしたファイルの名称、受注・配送情報のように管理画面で入力される値は、テーマ、独自Twigテンプレート、プラグインのイベント処理、帳票やメールなど、複数の表示先へ渡る場合があります。本体の修正が適用されても、独自コード側で安全な出力処理が行われているかは別に確認が必要です。

本記事で扱う脆弱性情報の確認基準日は2026年2月です。ただし、EC-CUBEの対象バージョン、修正版、パッチの提供状況は固定情報として扱いません。脆弱性対応を開始する当日に、必ず公式の脆弱性リストと利用中のリリース情報を照合し、結果を台帳へ記録してください。

「パッチを当てた」と「対応を完了できる」は別の判断

XSS対応の完了条件は、少なくとも次の6項目に分けると判断しやすくなります。

1. 入力元：どの画面・CSV・外部連携・APIから値が入るか
2. 表示先：ストアフロント、管理画面、メール、帳票、外部連携先のどこに表示されるか
3. 権限：誰がその値を登録・編集できるか
4. 修正方法：本体更新、公式パッチ、プラグイン更新、独自コード修正のどれが必要か
5. 回帰テスト：修正後に管理業務と購入導線が維持されるか
6. 証跡：判断根拠、実施日時、担当者、テスト結果を残せているか

EC-CUBE 4のセキュリティガイドラインでは、カスタマイズ時にも入力値の扱いとXSS対策を意識することが案内されています。つまり、本体の脆弱性情報を起点にしても、確認対象は本体コードだけに限定しません。

まず公式情報で「自社が判断すべき対象」を確定する

公開されたIssue、SNS投稿、ベンダーからの連絡は、調査開始の契機にはなります。しかし、適用対象や正式な対処方法の確定には、EC-CUBE公式の脆弱性リストを使います。

確認時には、次の項目をそのまま台帳に転記します。

• 確認日時と確認者
• 脆弱性情報のURLまたは識別子
• 公式情報に記載された対象バージョン
• 修正版のバージョン、または公式パッチの有無
• 危険度と前提条件
• 利用中のEC-CUBEバージョン
• 本番・ステージング・検証環境ごとの適用状況
• 独自テーマ、プラグイン、外部連携への確認要否

ここで重要なのは、「利用中バージョンが対象か」と「独自改修に同種の処理がないか」を分けることです。前者は公式情報との照合で判断できます。後者は、自社のソースコード、導入済みプラグイン、運用設定を対象にした棚卸しが必要です。

2026年2月に公開されたEC-CUBE 4.xに関するGitHub Issueでは、複数のテンプレートおよびコントローラーでの不十分なエスケープ処理が指摘され、カテゴリ名やファイル名を経路とする可能性が論点として示されました。このような情報を見た場合も、Issueの記載だけで影響範囲やパッチ有無を確定せず、公式リスト・公式リリース情報で確認してから作業方針を決めます。

パッチ適用台帳は「画面」ではなくデータの流れで作る

台帳の行は、単に「商品管理画面」「カテゴリ管理画面」と画面単位で並べるより、入力値がどこから入り、どこで表示されるかで作成します。1つの入力項目が複数画面に表示される場合は、表示先ごとに行を分けます。

台帳の推奨列

棚卸しの起点にする入力経路

最初から全コードを読むのではなく、次の順で確認すると対象を絞りやすくなります。

• 商品名、商品説明、規格名、カテゴリ名、タグなどの商品情報
• 画像・添付ファイル・ダウンロードコンテンツのファイル名や説明
• お知らせ、LP、FAQ、レビュー、問い合わせなどのコンテンツ入力
• 受注メモ、配送先情報、帳票用の補足欄
• CSVインポート・エクスポートで扱う任意項目
• 外部PIM、MA、配送、基幹システムなどから取り込む文字列
• プラグインが追加した管理画面項目、独自のマスタ項目

入力者が社内管理者だけであっても、権限を持つアカウントの侵害、連携元データの混入、誤った運用によって値が登録される可能性は切り分けて考えます。一方で、実際のリスク評価は「外部利用者が入力できるか」「どの権限で表示されるか」「表示先が管理画面か公開画面か」といった条件で変わります。すべてを同じ優先度にせず、条件を台帳に残してください。

独自Twigテンプレート・プラグインで確認するポイント

EC-CUBE本体の更新後、独自テーマとプラグインを「稼働しているから問題なし」と扱うのは適切ではありません。更新対象の本体ファイルに依存している場合だけでなく、同じ入力値を独自に出力している場合があるためです。

Twigテンプレートは出力箇所から逆引きする

独自テンプレートでは、台帳で挙げたデータ項目を検索し、表示箇所を特定します。そのうえで、次を開発担当または保守会社に確認します。

• テンプレートで出力している値は、HTML本文・属性値・JavaScript・URLなど、どの文脈で使われているか
• エスケープを解除する記述や、生HTMLを許容する独自処理が含まれていないか
• 本体テンプレートをコピーして改修した箇所があり、公式修正との差分が残っていないか
• JavaScriptへ文字列を埋め込む処理、URLを組み立てる処理を独自に追加していないか
• 商品説明など、意図的にHTMLを許可する要件がある場合、その許可範囲とサニタイズ方針が定義されているか

「自動エスケープがあるから確認不要」とはせず、値の出力文脈と、エスケープを意図的に外している箇所を確認します。HTMLを登録できる商品説明などは、表示上の要件と安全性のトレードオフが発生します。要件が不明なまま一律にHTMLを無効化すると、既存ページのレイアウトや導線を壊すおそれがあるため、公開コンテンツの移行・修正コストも含めて判断します。

プラグインは「バージョン」だけで閉じない

プラグインごとに、以下を台帳へ記録します。

• プラグイン名、提供元、導入バージョン
• EC-CUBE本体の更新後に対応バージョンがあるか
• 商品・会員・受注・ファイルなど、追加または参照するデータ
• 管理画面とストアフロントのどちらに表示を追加するか
• イベント購読、テンプレート差し込み、独自コントローラーの有無
• 提供元への問い合わせ日時、回答、更新可否

提供元の更新が未確認の場合、自己判断でプラグインを削除・更新すると受注処理や外部連携が止まることがあります。緊急度が高いと判断した場合は、公開停止、該当機能の一時停止、管理画面権限の絞り込みといった暫定策を検討します。ただし、WAFやアクセス制限は安全な出力処理や公式パッチの代替ではありません。あくまで複数ある防御層の一つとして位置付けます。

運用担当を含めて入力権限と変更手順を見直す

XSS対応は開発だけの作業ではありません。商品登録、画像差し替え、カテゴリ編集、受注処理を担当する運用部門には、変更期間中の入力ルールと問い合わせ先を共有します。

確認する事項は次のとおりです。

• 管理者アカウントを共用していないか、不要なアカウントが残っていないか
• 商品編集、コンテンツ編集、ファイル管理、設定変更の権限を業務単位で分けられているか
• CSVや外部連携から任意のHTML相当データを取り込む運用があるか
• 緊急パッチ期間に、テーマ・プラグイン・商品説明の変更をどこまで凍結するか
• エラーや表示崩れを見つけたとき、誰へ、どの情報を添えて連絡するか

更新中に運用担当が商品説明やデザインを変更すると、差分の競合により検証結果が再現できなくなることがあります。更新ウィンドウでは、変更凍結の対象と例外承認者を明文化します。

一方、出荷や受注対応を止められない場合は、受注処理に必要な変更だけを例外として認め、変更日時・変更者・対象データを記録します。この記録は、更新後に不具合が出た際の切り分けにも使えます。

ステージングで行う回帰テストと、完了証跡の残し方

本番へ適用する前に、可能な限り本番に近い構成のステージング環境でテストします。決済・配送・メールなど外部サービスは、本番課金や実配送を発生させない検証方法を各サービスの仕様に従って準備してください。

最低限のテスト観点

管理画面

• 管理者がログインできる
• 商品、カテゴリ、画像・ファイル、コンテンツを登録・編集・削除できる
• CSV登録・更新を利用している場合は、対象データを処理できる
• 受注検索、受注詳細、配送情報編集、出荷に必要な画面を操作できる
• 権限の異なるアカウントで、想定外の編集権限が付与されていない

ストアフロント

• トップ、カテゴリ、商品詳細、検索結果など、独自テンプレートを含む主要画面が表示される
• カート投入、数量変更、ログイン、会員登録またはゲスト購入の対象導線が動く
• 利用中の決済方法で注文確定まで進める
• 注文確認メールなど、購入後の通知が期待どおり生成される
• 商品説明、カテゴリ名、ファイル名など、確認対象データが意図せず崩れず表示される

XSS確認のために本番環境で検証用文字列を入力する必要はありません。テスト用アカウントとステージング環境を使い、実行内容・画面・確認者を記録します。具体的なテストデータは、社内のセキュリティ手順または保守会社の手順に従って管理してください。

完了報告には、少なくとも以下を添付します。

• 適用前後のEC-CUBEバージョン、プラグインバージョン
• 適用した公式パッチまたはリリースへのリンク
• ソースコード変更のPR、コミット、レビュー記録
• 台帳の未確認・保留項目と、その理由・期限・担当者
• テストケース、実施日時、結果、障害時の判断記録
• ロールバック手順と、実際に戻す必要があった場合の記録

緊急パッチ時は「保留項目」を隠さず、期限付きで管理する

緊急度が高い場合、すべての独自改修を同日に確認できないことがあります。その場合でも、未確認項目を空欄のまま完了扱いにしないことが重要です。

保留にする項目には、次の情報を設定します。

• 保留理由：提供元回答待ち、検証環境不足、改修影響が大きいなど
• 暫定措置：該当機能の停止、公開範囲の限定、権限の削減、監視強化など
• 恒久対応：プラグイン更新、コード修正、テーマ統合、運用変更
• 完了期限と責任者
• 再確認日と経営・運用責任者への報告先

2021年のJPCERT/CCのインシデント報告対応レポートには、EC-CUBEを利用したサイトでXSS脆弱性を悪用したインシデントへの対応が記録されています。また、JCDSCのレポートでは、過去に公表されたEC-CUBE 3系・4系の管理画面XSS脆弱性が悪用された攻撃が推定される事案に触れられています。これらは、個別の脆弱性情報を受け取ったときに、本体・独自改修・管理画面運用を分けずに確認する必要性を検討する材料になります。

ただし、過去の記録だけから自社環境の被害や影響を断定することはできません。利用中のバージョン、公開範囲、独自実装、権限設計、ログの状況を基に、公式情報と照合して判断してください。

パッチ適用台帳は、一度作れば次回のEC-CUBE更新、テーマ改修、プラグイン追加時にも使えます。「何を更新したか」だけでなく、「どのデータが、どこへ表示され、誰が確認したか」を残すことで、脆弱性対応の完了基準を説明可能にできます。

参考情報

• 脆弱性リスト｜公式EC-CUBE
• EC-CUBE 4 セキュリティガイドライン
• [セキュリティ] XSS脆弱性: 複数のテンプレートおよびコントローラーで不十分なエスケープ処理 · Issue #6634 · EC-CUBE/ec-cube · GitHub
• JPCERT/CC インシデント報告対応レポート［2021年4月1日 ～ 2021年6月30日］
• キャッシュレスセキュリティレポート2024｜日本カード情報セキュリティ協議会（JCDSC）