2026年10月、EC-CUBEで作ったネットショップに関わる脆弱性が相次いで公表されました。14日にはEC-CUBE 4系の公式「AmazonPayプラグイン」の脆弱性が公表され、すでに悪用が確認されています。21日から22日にかけては、EC-CUBEが動く土台であるプログラム言語「PHP」にも、遠隔からサーバーを操られるおそれのある脆弱性が見つかりました。

EC-CUBEは実績のある国産のECアプリケーションで、最新の版に更新し続けていれば安全に使えます。国内の商慣習にもフィットしてます。問題は、その更新を続けられるかどうかです。EC-CUBEのネットショップを持つ会社が、いま確かめておきたいことを整理します。

2026年10月にEC-CUBEで起きたこと

公式AmazonPayプラグインの脆弱性（10月14日）

EC-CUBE 4系向けの公式「AmazonPayプラグイン」に、注文の途中でお客さまを別のサイトへ誘導されるおそれのある脆弱性が見つかりました。お客さまのアカウント情報を盗まれる可能性があり、開発元は実際の攻撃を確認しているとしています（JVN#43511918）。AmazonPayプラグインを使っている場合は、すぐに最新のバージョンへ更新してください。

PHPの脆弱性「PHP2shell」（10月21〜22日）

EC-CUBEは、PHPというプログラム言語の上で動いています。そのPHPに、悪用されると外部の第三者がサーバー上で任意のプログラムを実行できるおそれのある脆弱性が見つかり、IPA（情報処理推進機構）が注意喚起を出しました。詳しくはPHPの脆弱性「PHP2shell」の記事にまとめています。

EC-CUBE本体だけでなく、プラグインや、土台のPHP、サーバーまで含めて守る必要がある。今回の2件は、そのことをよく表しています。

EC-CUBEの脆弱性は、これまでも繰り返し見つかっている

EC-CUBEには、ここ数年だけでも繰り返し脆弱性が報告され、そのたびに修正版や修正ファイルが公開されています。IPAとJPCERT/CCが運営する脆弱性情報サイト「JVN」で公表されたものの一部です。

脆弱性が見つかること自体は、EC-CUBEに限らずどのアプリケーションやサービスでも起きます。開発元が修正を出しているのは、むしろ健全な証拠です。ただ、EC-CUBEのように自社のサーバーで動かすソフトでは、その修正を自社のサイトに当てるのは、ショップを運営する側の仕事です。

EC-CUBEのバージョンと、対応するPHP

PHPの件で問題になるのは、EC-CUBEのバージョンによって使えるPHPが決まっていることです。公式のシステム要件は次のとおりです（EC-CUBE システム要件、2026年10月確認）。

PHP 8.4と8.5への対応は、2026年10月時点の公式の文書には書かれていません。また、PHP 8.2のサポートは2026年12月31日に終わるため、4.3を使っている場合も、PHP 8.3への移行を考えておく必要があります。2系や3系は、4系とは作りが大きく異なる古い系統です。4系へ移る場合は、データを移して作り直す形になります。

EC-CUBEのバージョンアップは、どれくらい大変か

私たちもEC-CUBEのサイトを運用していましたが、本体のバージョンを上げるだけでも、かなり大変な作業でした。いまは手順が整い、楽になった部分もあります。ただ、どこからどこへ上げるかで、手間は大きく変わります。

• 4.3系の中の更新（4.3.0から4.3.1など）：公式に手順がまとまっています。バックアップ、メンテナンスモード、ソースファイルの差し替え、composer（部品の管理ツール）の更新、データベースの更新、テンプレートの更新です（4.3 本体バージョンアップ）。それでも、サーバーでコマンドを打つ作業で、公式も本番の前にテスト環境で必ず確かめるよう書いています
• 4.2から4.3へ：土台の仕組み（Symfony 6）が変わったため、独自に手を入れた部分やプラグインのコードを直す必要があります。公式は「4.2と4.3はプラグインの互換性を担保している」としていますが、それはプラグインが公式の手順どおりに直されている場合です（4.2から4.3へのマイグレーション）
• 2系・3系から：商品、顧客、購入履歴を移し、デザインと独自の機能を作り直す形になります。費用は、今のサイトの作りによって大きく変わります

自社でバージョンアップしなくて済む道として、クラウド版（ec-cube.co）もあります。本体の更新やサーバーの管理を開発元に任せられるのが利点です。ただし、いくつか確認しておきたい点があります。

• 月額は約5万〜8.5万円（税別）で、ShopifyなどのECサービスと比べて高めです
• 古いEC-CUBEからクラウド版へデータを移すには、開発元の移行サービスの購入が必須とされています。ところが、そのサービスは2026年10月時点で新規受付を停止しています（ec-cube.co データ移行マニュアル）
• ダウンロード版の最新の4.3でも、公式に対応しているPHPは8.3までです。2024年11月に出たPHP 8.4以降への対応は、まだ公式の文書に書かれていません

使い続ける場合も、移る場合も、こうした点を確かめたうえで判断することをおすすめします。

更新を難しくするのは、プラグインと独自の改修

EC-CUBEは、プラグインで機能を足せるのが強みです。しかし、本体やPHPを新しくしようとしたとき、使っているプラグインが対応していなければ更新できません。プラグインの開発が止まっていれば、その機能ごと作り直すことになります。独自に手を入れた部分があれば、手を入れた人にしか分からないこともあります。

私たちが管理しているサイトの中にも、プラグインが新しいPHPに対応しておらず、すぐにはPHPを上げられないものがあります。更新のしやすさは、最初にサイトを作ったときのプラグインの選び方で、ほぼ決まってしまいます。何年も前に作ったサイトほど、お金を出せばすぐ直せる状態ではなくなっています。（ある意味ではお金で解決できますが費用対効果の課題あり）

保守のためにエンジニアを抱えるべきか

中小企業のネットショップの売上規模では、多くの場合、割に合いません。

• 社内にエンジニアを雇う。脆弱性はいつ見つかるか分からず、対応できる人が常に必要です。保守のためだけに人を雇うのは重い負担です
• 制作会社に外注し続ける。月々の保守費に加え、大きな更新のたびに追加の改修費がかかります。作った会社や担当者がいなくなるリスクもあります
• AIに直してもらう。AIはコードを書いてくれますが、そのコードが正しいか、安全かを判断するには基礎知識が要ります。知識のないまま本番のサイトに当てるのは、かえって危険です

IPAもPHPの件の注意喚起で、更新・移行とその後の維持管理に必要な人員・予算・保守体制を、経営層も含めて検討するよう求めています（IPA）。保守は、担当者だけで決める話ではなく、経営の判断です。

放置したらどうなるか

更新されていないネットショップは、カード情報を狙う攻撃者にとって格好の標的です。日本クレジット協会の集計では、2024年のクレジットカードの不正利用被害は555億円にのぼり、その9割以上がカード番号を盗まれたことによる被害でした（ECのミカタ）。

盗まれたカード番号は、ネットショップでの買い物に使われます。私たちがEC-CUBEでショップを運営していた頃も、不正注文が多くありました。他人のクレジットカードで買い物をされ、商品はそのまま受け取られてしまいます。あとでカードの持ち主が不正利用だと申し出ると、その売上はショップが返すことになり（チャージバック）、手数料も払わなければなりません。商品も代金も失ううえに、手数料まで負担する形です。

EC-CUBEでも、決済会社によっては、月に数千円ほど払うことでチャージバックの損失を補う保証や保険に入れます。EC-CUBEの公式決済「EC-CUBE Payment Plus」を提供しているGMOイプシロンにも、月額3,900円のチャージバック保証サービスがあります（EC-CUBE Payment Plus 料金、2026年10月確認）。なお、以前の公式決済「EC-CUBE Payment」はGMOペイメントゲートウェイとの協業で、2023年12月に今のPayment Plusへまとめられました（ペイメントナビ）。古いサイトでは、契約している決済会社が今の公式決済と違うこともあるので、まずは自社の契約先を確かめてみてください。ただし、補償には上限があり、対象にならないケースもあるので、条件を確かめておく必要があります。Shopifyの決済（Shopifyペイメント）でも不正注文は起こりえますが、怪しい注文には管理画面でアラートが出るので、発送する前に気づくことができます（Shopify ヘルプセンター：不正注文分析）。

情報が漏れれば、調査の費用やお客さまへの対応に加えて、サイトの停止と、ブランドへの信頼の低下につながります。「何も起きていないから大丈夫」は、確かめられていないだけかもしれません。

使い続けるか、移るか

EC-CUBEは、社内の稟議が通りやすい仕組みです。国産で、本体は無料、決済も円建てで請求書払いができます。ただ、稟議書に載るのは月額と決済手数料だけで、バージョンアップや脆弱性への対応、不正注文への備えにかかる費用は載りません。

決済の費用だけを比べると、EC-CUBEの公式決済とShopifyに大きな差はありません。違いが出るのは、表の最後の行です。

※2026年10月時点の各社の料金ページより（EC-CUBE Payment Plus、Shopify）。

EC-CUBEの決済の月額だけで、Shopifyのいちばん安いプランとほぼ同じです。EC-CUBEでは、ここにサーバー代と保守の費用が加わります。

選択肢は大きく2つです。

• 守る体制にお金をかけて、EC-CUBEを使い続ける。最新版への更新と、更新を前提にした保守契約を結びます。プラグインを整理し、独自の改修を減らすのが前提です。独自の機能が事業の強みになっている会社には、こちらが合います
• 守る仕組みごと任せられるサービスに移る。Shopifyのようなサービス型では、基盤の更新や脆弱性への対応は、サービスの提供元が行います。Shopifyはカード業界の国際的なセキュリティ基準「PCI DSS」のレベル1に準拠しています（Shopify）。外部のセキュリティ研究者に最大20万ドルの報奨金を払う制度も公開しています（Shopify）。ショップの側は、売ることに集中できます

better standardは、自社ブランドをShopifyで運用しながら、EC-CUBEなどからの移行を支援しています。移行で引き継げるもの、工夫が必要なものも含めて、ECサイト制作のページにまとめています。

よくある質問

自社のEC-CUBEのバージョンは、どこで確認できますか？

EC-CUBE 4系なら、管理画面の「設定」→「システム設定」→「システム情報」で確認できます。分からない場合は、サイトを作った制作会社に問い合わせてください。

EC-CUBE 2系や3系を使っています。すぐに危ないですか？

バージョンと、修正が当たっているかによります。ただ、古い系統ほど、プラグインやPHPの対応は難しくなります。今回のPHPの件では、古いPHPを使い続けているサイトほど対応が難しくなっています。まずは制作会社やサーバー会社に、いまの状態を確認してください。

EC-CUBE 4.2を使っています。PHPだけ上げられますか？

EC-CUBE 4.2が対応するPHPは8.1までです。PHP 8.1には今回の脆弱性の新しい版が出ないため、PHPを8.2以降に上げるには、先にEC-CUBE本体を4.3へ上げる必要があります。

EC-CUBEからShopifyに移ると、何が変わりますか？

サーバーやソフトの更新作業がなくなります。一方で、決済の画面は標準の仕組みになり、独自の機能はアプリで実現することになります。移る前に、今の機能をすべて洗い出して確かめることが大切です。

出典

• JVN#43511918 EC-CUBE4系用プラグイン「AmazonPayプラグイン」の脆弱性（2026年10月14日）
• IPA「PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）」（2026年10月22日）
• EC-CUBE 4 システム要件、4.3 本体バージョンアップ、4.2から4.3へのマイグレーション
• クラウドECならec-cube.co（料金）、ec-cube.co データ移行マニュアル（2026年10月確認）
• ScanNetSecurityのJVN関連報道（表内の各リンク）
• ECのミカタ「2024年のクレジットカード不正利用被害額は前年比2.6%増の555億円に」
• Shopify：PCI DSS準拠、Shopify：Bug Bounty Program