公開2026.03.09更新2026.11.12 脆弱性・インシデント

EC-CUBEのMFAバイパス脆弱性CVE-2026-30777とは｜影響版の確認・修正手順とPHP2Shellへの備え

CVE-2026-30777は、EC-CUBE 4.1.0〜4.3.1の管理画面で、管理者のIDとパスワードを知る攻撃者が二段階認証（2FA）を迂回してログインできてしまう脆弱性です。EC-CUBE公式は2026年2月10日に修正ファイルを公開し、JVNは3月5日にJVN#63765888として公表しました。この記事では、2FAの設定画面を認証の対象から外していた実装の欠陥、CVSSの読み方、自社のサイトに修正が入っているかを確かめるコマンド、修正ファイルの適用手順と暫定策を、公式告知とソースコードに基づいて整理します。2026年10月にはAmazonPayプラグインの脆弱性と、PHP本体のPHP2Shellも続きました。本体の修正だけでは閉じないこの2件と、EC-CUBEの系列ごとに更新すべきものも扱います。記載は2026年11月12日時点の公開情報に基づきます。

まとめ：影響版への修正適用と2FA設定画面のアクセス制御

対象はダウンロード版のEC-CUBE 4.1.0〜4.3.1です。修正前の各系列の最終版（4.1.2-p4・4.2.3-p1・4.3.1）で対象の2ファイルをカスタマイズしていなければ、公式の修正ファイルで上書きしてキャッシュを削除し、動作を確認します。旧版やカスタマイズ済みの環境では差分適用が必要です。修正済みのリリースは4.1.2-p5・4.2.3-p2・4.3.1-p1（GitHub上の公開は2026年3月4日）です。

攻撃には管理者のIDとパスワードが要るため、公式の危険度は「中」です。ただし2FAは、まさにパスワードが漏れたときの防御として入れるものです。2FAを有効にしている店舗ほど、この欠陥で防御が無効になります。公式の詳細告知は「現時点で被害報告はございません」としており、CISAの悪用確認リスト（KEV）の2026年11月10日版にも載っていません。どちらも悪用がないことの証明ではありません。

この修正を当てても、10月に公表された2件は残ります。AmazonPayプラグインのCVE-2026-103671はプラグインの更新で、PHP2Shell（CVE-2026-109618・109619）はPHP本体の更新で直すものです。PHP2Shellは2026年10月26日にKEVへ登録されました。4.2系以前はPHP 8.1以下でしか動かないため、PHPの開発元からは修正版が出ません。

CVE-2026-30777の公表経緯と影響を受けるEC-CUBEの版の範囲

EC-CUBE公式の告知は「EC-CUBE 4.1/4.2/4.3におけるMFAバイパスが可能な脆弱性」として、不具合のある版を4.1.0〜4.3.1と明記しています。告知は2026年2月10日に初版が出て、3月5日にJVNへのリンク、3月6日に謝辞が追記されました。

JVN#63765888とGHSA-7rhv-h82h-vpjhに登録された基本情報

項目	内容
CVE	CVE-2026-30777
JVN	JVN#63765888（3-05公表）
影響版	4.1.0〜4.3.1
修正済み（4.1系）	4.1.2-p5
修正済み（4.2系）	4.2.3-p2
修正済み（4.3系）	4.3.1-p1
弱点の分類	CWE-288
CVSS v3.0	4.9（JPCERT/CC）
CVSS v4.0	6.9（JPCERT/CC）
公式の危険度	中

JVN#63765888のほか、開発元のGitHubにもアドバイザリGHSA-7rhv-h82h-vpjhが登録されています。CWE-288は「代替の経路による認証の迂回」で、正規の認証画面を通らない別の入口が残っていた、という種類の欠陥です。

ダウンロード版とクラウド版の扱いと4.0系が対象外になる理由

公式告知の修正手順は、自社のサーバーにインストールして運用するダウンロード版向けです。クラウド版（ec-cube.co）は、2026年3月4日の公式ニュースで修正済みと案内されています。4.0系は影響範囲に含まれていません。範囲が4.1.0から始まるのは、管理画面の二段階認証が4.1系で入った機能だからです。

制作会社に構築を任せ、保守契約が終わっている店舗では、この種の告知が担当者まで届いていないことがあります。自社の版数と提供形態を、まず確かめてください。

2FA設定ルートを認証の対象から外していた実装の欠陥と攻撃の流れ

EC-CUBE 4の管理画面では、イベントリスナー（TwoFactorAuthListener.php）がページを開くたびに2FAを通過したかを確かめ、未通過なら2FAのコード入力画面へ転送します。ただし入力画面と初回の設定画面だけは、この確認から外さないと誰も2FAを設定できません。

ROUTE_EXCLUDEに設定画面が無条件で入っていた設計ミス

修正前のコードでは、確認の対象外にするルートの一覧 ROUTE_EXCLUDE に、コード入力画面（admin_two_factor_auth）と並んで設定画面（admin_two_factor_auth_set）が無条件で入っていました。設定画面を外す必要があるのは、まだ2FAを設定していない管理者の初回だけです。設定済みの管理者まで一律に外していたため、2FAを通らずに設定画面へ入れる状態でした。

もう1つの要因は、設定画面のコントローラー（TwoFactorAuthController.php）です。すでに2FAのキーを持つ管理者が、2FAを通過していない状態でも新しいキーを作って保存できました。既存の設定を上書きするなら、本来は現在のコードで本人確認をしてから許可すべき操作です。

ID・パスワード入手後にURLの直接入力で2FAを乗っ取る3段階

フィッシングや使い回しで得た管理者のIDとパスワードで、管理画面にログインする
コード入力画面に転送されたところで、管理画面パスの two_factor_auth/set を直接開く
攻撃者の認証アプリで新しいキーを読み取って保存し、以後は自分のコードで2FAを通過する

上書きされた時点で、正規の管理者の認証アプリが出すコードは通らなくなります。攻撃者が管理画面に入れる一方で、本来の管理者は締め出されるという逆転が起きる仕組みです。管理画面からは顧客情報や受注情報を見られ、決済の設定やテンプレートも書き換えられます。

ROUTE_EXCLUDE_WHEN_NOT_CONFIGUREDの未設定時の除外判定

修正では、ROUTE_EXCLUDE から設定画面を外し、新しく ROUTE_EXCLUDE_WHEN_NOT_CONFIGURED という一覧に移しました。ここに入ったルートは、ログイン中の管理者が2FAのキーをまだ持っていない（getTwoFactorAuthKey() が空）ときだけ確認の対象外になります。コントローラー側にも、キーが設定済みなら認証画面へ転送する処理が足されました。公式告知の差分では、2ファイル合わせて追加24行・削除3行です。次の系列として2026年9月25日に出た4.4.0-alpha-1の TwoFactorAuthListener.php にも、同じ一覧が入っています。

CVSS v3.0の4.9とv4.0の6.9の解釈と修正優先度

JPCERT/CCの評価はv3.0が4.9、v4.0が6.9です。数字が違うので「v4.0は被害の大きさを織り込んで上がった」と読みたくなりますが、そうではありません。

v3.0とv4.0で同じ影響評価なのに点数が違う理由とNVDの6.5

v3.0のベクトルは AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N、v4.0は VC:N/VI:H/VA:N で、どちらも影響は完全性（I）だけを高と評価しています。攻撃後に顧客情報を見られる被害は、どちらの点数にも入っていません。差が出たのは、v3.0とv4.0で算出の式が違うためです。旧版の本記事は「v4.0では攻撃チェーン全体が反映されて上昇した」と説明していましたが、これは誤りでした。

なお、NVDは独自にCVSS 3.1で6.5（機密性と完全性がともに高）と評価しています。各指標の意味と点数の目安はCVSSv3のスコアの目安と計算式、2FAを迂回されることの意味は多要素認証（MFA）の3要素と実装方式で確認できます。

危険度「中」でも決済と個人情報を扱う店舗が最優先にすべき条件

2FAを有効にして運用していて、かつクレジットカード決済や会員の個人情報を扱う店舗は、点数にかかわらず最優先で修正してください。2FAに頼って、管理画面のIP制限をかけていない構成なら、なおさらです。

逆に、2FAを使っておらず、管理画面を社内のIPアドレスに限っている店舗では、この欠陥による追加の危険は限定的です。ただし、公式は可能な限り速やかな対応を求めているため、適用期限を決めて修正してください。決済を扱う事業者のセキュリティ基準はPCI DSSの12要件、漏えい時の報告義務は個人情報保護委員会への報告義務で整理しています。

自社のEC-CUBEに修正が入っているかの確認と修正ファイル適用の実務手順

まず、自社のEC-CUBEに修正が入っているかを確かめます。管理画面の「設定＞システム設定＞システム情報」でも版数は分かりますが、サーバーに入れるならコマンドの方が確実です。

版数・修正の有無・SHA256・アクセスログを確かめるコマンド

# EC-CUBE のインストールディレクトリで実行する

# 1. 版数（EC-CUBE 4 系はこの定数に記録される）
grep -n "VERSION =" src/Eccube/Common/Constant.php

# 2. 公式修正の目印を検索（有無だけでは判定せず、対象2ファイルの差分と動作を確認）
grep -n "ROUTE_EXCLUDE_WHEN_NOT_CONFIGURED" src/Eccube/EventListener/TwoFactorAuthListener.php

# 3. ダウンロードした修正ファイルの SHA256 を公式の値と照合する
sha256sum ダウンロードした修正ファイル.zip

# 4. 2FA 設定画面への直接アクセスを抽出（管理画面のパスを変えている場合は合わせる）
grep -n "two_factor_auth/set" /var/log/nginx/access.log

2つ目のコマンドで ROUTE_EXCLUDE_WHEN_NOT_CONFIGURED が見つかれば、公式修正の一部が存在する目印になります。ただし有無だけでは修正済みかを断定できないため、対象2ファイルを公式差分と照合し、2FA未通過時に設定画面へ入れないことを確認します。3つ目の値は、公式告知に載っているSHA256（4.3.1-p1用は 78aa754893b1f78f560288ad44fa5411a2be8b76c92f6754dc2de10c9734abb7）と完全に一致することを確かめてください。Windowsでは certutil -hashfile ファイル名 SHA256 で同じ確認ができます。

後の章で扱うPHP2Shellに備えて、PHPの版もここで控えておきます。サーバーで打つ php -v はコマンドライン用のPHPの版で、Webサーバーが使うPHPと違うことがあります。管理画面の「システム情報」の「PHP」欄は、EC-CUBEを動かしているPHPの phpversion() をそのまま表示するので、こちらを正とします（4.3.1-p1の SystemController.php で確認）。

バックアップから動作確認までの標準手順と差分適用が要る店舗の構成

本番と同じ構成の開発環境で修正を適用して動作を確認した後、本番のEC-CUBEのファイル全体とデータベースのバックアップを取り、メンテナンスモードに切り替える
利用中の版に合う修正ファイル（4.1.2-p5用・4.2.3-p2用・4.3.1-p1用）をダウンロードし、SHA256を照合する
src/Eccube/EventListener/TwoFactorAuthListener.php と src/Eccube/Controller/Admin/Setting/System/TwoFactorAuthController.php を上書きする
管理画面の「コンテンツ管理＞キャッシュ管理」でキャッシュを削除する
フロントと管理画面の基本操作を確認し、メンテナンスモードを解除する

公式の修正ファイルは、修正前の各系列の最終版（4.1.2-p4・4.2.3-p1・4.3.1）向けに作られています。それより古い版を使っている場合や、2つのファイルをカスタマイズしている場合は、公式告知の「修正方法2」に載っている差分を見て手で反映します。適用後は、2FAを有効にしたアカウントでログインし、コード入力画面から設定画面のURLを直接開いて、認証画面へ戻されることを確かめてください。これが修正を確かめる最も直接的な方法です。

乗っ取りの痕跡をdtb_memberで確かめるSQLと復旧の考え方

2FAのキーは dtb_member テーブルの two_factor_auth_key 列に、有効かどうかは two_factor_auth_enabled 列に保存されます（4.3.1-p1のMemberエンティティで確認）。次のSQLで、管理者ごとの状態と最終更新日時を一覧できます。見覚えのない login_id が無いかも、同じ一覧で確かめます。

-- 全管理者の2FA有効状態、キーの有無、最終更新日時の一覧
SELECT id, login_id, two_factor_auth_enabled,
       two_factor_auth_key IS NOT NULL AS has_key, update_date
FROM dtb_member
ORDER BY update_date DESC;

update_date は2FA以外の変更でも更新されるため、この列だけで乗っ取りは断定できません。アクセスログで設定画面への直接アクセスがあった日時と突き合わせて判断します。正規の管理者のコードが通らない場合は、キーの上書きも調査対象になりますが、この症状だけでは原因や発生確率を判断できません。復旧は、ログを保全して修正ファイルを当て、パスワードを変更してから行います。two_factor_auth_enabled を0にするだけでは、その管理者の2FAの確認自体が止まり、攻撃者のキーも残ります。two_factor_auth_enabled は1のまま two_factor_auth_key をNULLに戻すと、次回ログイン時に設定画面へ転送されるので、正規の管理者が新しいキーを登録し、自分のコードでログインできることを確かめます（4.3.1-p1の TwoFactorAuthListener.php の分岐で確認）。

本番環境に修正をすぐ当てられない店舗向けの暫定策と防御の限界

本番の変更に承認が要る、カスタマイズの影響調査に時間がかかる、といった事情で今日中に当てられないこともあります。その間の手当てです。

管理画面のIP制限と管理者アカウントの棚卸し

暫定策として効くのは、管理画面への接続元を社内やVPNのIPアドレスに限ることです。許可していないIPアドレスからは管理画面に入れないため、IDとパスワードが漏れていても攻撃が成立しません。まず使うべきはEC-CUBE 4に標準で入っている「設定＞システム設定＞セキュリティ管理」の管理画面IP制限設定で、「IP制限(許可リスト)」に社内やVPNのIPアドレスを登録します。この制限はURLの文字列ではなくEC-CUBEが判定した管理画面のパスで効くので、後述する別経路の抜けが起きません（4.3.1-p1の IpAddrListener.php と Context.php で確認）。

Webサーバーの手前でも絞るなら、ApacheではURLのパスで対象を指定する LocationMatch に Require ip を、nginxでは location に allow と deny all を書きます。EC-CUBEの管理画面は実在のディレクトリではなく index.php が受けるルートなので、/admin だけを塞ぐと /index.php/admin という書き方で同じ画面に届く余地が残ります。下の例は両方を対象にしています。LocationMatch は .htaccess には書けないため、バーチャルホストの設定に追記します。管理画面のパスを既定の /admin から変えている場合は置き換えてください。

# Apache（バーチャルホストの設定に追記し、設定確認のうえ再読み込み）
<LocationMatch "^/(index\.php/)?admin">
    Require ip 203.0.113.10
</LocationMatch>

# nginx（server ブロック内。PHP への受け渡しは既存の location に任せる）
location ^~ /admin {
    allow 203.0.113.10;
    deny all;
    try_files $uri /index.php$is_args$args;
}
# index.php を挟んだ書き方の管理画面URLは、正規の管理者も使わないので閉じる
location ^~ /index.php/admin {
    return 404;
}

どちらも設定例で、IPアドレスは説明用の値です。検証環境で、許可外のIPアドレスから /admin と /index.php/admin の両方が拒否されることを確かめてから本番へ入れてください。在宅勤務などで管理者のIPアドレスが変わる運用では、VPN経由に寄せないと管理者自身が締め出されます。

あわせて、管理画面の「設定＞システム設定＞メンバー管理」で、退職者や契約の終わった外部開発者のアカウントが残っていないかを確かめ、使い回しのパスワードを変えます。攻撃の前提は「管理者のIDとパスワードが漏れていること」なので、この前提を崩すことが危険を大きく下げる対策です。二段階認証そのものの考え方は二段階認証と多要素認証の違いで解説しています。

WAFルールで2FA設定画面を塞ぐ場合の正規管理者の誤遮断と見直し漏れ

WAFで two_factor_auth/set への要求を止める方法もあります。ただし、2FAをこれから設定する正規の管理者まで止めてしまう点と、管理画面のパスを変えている場合にルールのパスも合わせる必要がある点に注意が要ります。IP制限もWAFも、修正ファイルの代わりにはなりません。暫定策を入れた日と、外す条件を記録に残してください。

2026年10月のAmazonPayプラグインとPHP2Shell：本体の修正では閉じない2つの穴

CVE-2026-30777はEC-CUBE本体の2ファイルを直せば閉じます。一方で10月に公表された2件は、直す場所がプラグインとPHP本体です。本体の修正ファイルを当てた店舗でも、この2件は別に確かめる必要があります。

AmazonPayプラグインのCVE-2026-103671と管理者アカウントの点検

2026年10月14日、EC-CUBE 4系用の公式AmazonPayプラグインに、注文手続き中の購入者を任意のサイトへ転送させられる脆弱性がJVN#43511918として公表されました。JVNの深刻度は「緊急」で、開発元は悪用を確認しています。EC-CUBE公式のお知らせは危険度を「高」とし、不正な管理者アカウントを登録されて管理画面にログインされるおそれを挙げています。

直し方はプラグインの更新で、本体の修正ファイルとは無関係です。管理者アカウントが攻撃の行き先になる点は本件と共通するため、前の章の dtb_member の一覧で、見覚えのないアカウントが無いかも確かめてください。対象のプラグイン版と修正版、侵害調査のSQLはEC-CUBE AmazonPayプラグインの脆弱性とは？修正版の確認SQLと侵害調査の手順で整理しています。

PHP2Shell対策と系列別の対応PHP・公式リリースの有無

PHPの開発元は2026年10月21日、認証なしで任意のコードを実行されうる2件（CVE-2026-109618・109619、通称PHP2Shell）を修正したPHP 8.5.12・8.4.27・8.3.36・8.2.35を公開しました。同じ告知は、PHP 8.1以前には開発元から更新を出さないと明記しています。7.4・8.0・8.1向けには最小限のソースの差分だけが用意され、ディストリビューションなどの提供元による修正版を確かめるよう案内しています。CISAは10月26日に2件をKEVへ登録しました。

EC-CUBEは系列ごとに動くPHPの範囲が決まっているため、PHP2Shellへの対応の難しさは系列で変わります。EC-CUBE 4の開発者向けドキュメントのシステム要件と、GitHubのリリースを並べると次のとおりです。

系列	対応PHP	開発元の修正版PHP	本件の修正版
4.0系	7.1〜7.4（版で異なる）	なし	対象外
4.1系	7.3〜7.4	なし	4.1.2-p5
4.2系	7.4〜8.1	なし	4.2.3-p2
4.3系	8.1〜8.3	8.2.35・8.3.36	4.3.1-p1
4.4.0-alpha-1	8.2〜8.5	8.2.35以降	修正入り（試用版）

4.3系をPHP 8.3で動かしている店舗は、PHP2Shell対策として8.3.36以降の修正版を適用し、プラグインとカスタマイズを含む購入・決済・管理画面の動作を確認します。4.3系でも8.1のまま動かしているなら、8.3へ切り替えてください。PHPのサポート期限の一覧では、8.2のセキュリティ修正は2026年12月31日で終わります。今から8.2を選ぶと、すぐに同じ判断をやり直すことになります。

4.2系以前の店舗は、OSやレンタルサーバーの提供元が修正を取り込んだPHPを出しているかを確かめるしかありません。提供元の修正版が無いなら、4.3系への移行を前提に計画を立てます。4.4.0-alpha-1は試用版なので、本番の移行先にはしないでください。PHP2Shellの攻撃条件と、すぐ更新できないときの php.ini の暫定設定はPHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版で詳しく扱っています。

EC-CUBEの脆弱性情報の追い方と保守体制

EC-CUBEの公式の脆弱性リストには、2021年5月の4.0系のクロスサイトスクリプティング（JVN#97554111、危険度「高」）から今回の件まで、系列ごとの公表が並んでいます。2026年11月12日時点で、本体の公表は3月の本件が最後です。AmazonPayプラグインの件はこのリストには載らず、公式ニュースとJVNで公表されました。本体のリストだけを見ていると、プラグインとPHPの公表を取りこぼします。

公式の脆弱性リストとニュース、JVN、使っているプラグインの配布元、PHPの告知の5つを、店舗の担当者と制作会社の両方が受け取れるようにしておくことが出発点です。カスタマイズの多い店舗では、修正ファイルをそのまま当てられず差分の反映が要るため、影響調査と動作確認に必要な期間を見積もり、適用期限と担当者を決めます。外部から攻撃されうる箇所を定期的に洗い出すなら脆弱性診断の進め方と外注時の判断基準、要件や改修の範囲を整理し直すならECサイトの要件定義と法令由来の必須要件が参考になります。保守の手が足りず、カスタマイズ済みのEC-CUBEへの差分適用や系列の移行を任せたい場合は、一創のECシステム開発で、既存サイトの改修と保守を引き受けています。

よくある質問

CVE-2026-30777について寄せられやすい質問に答えます。

2FAを使っていなければ、この脆弱性の影響はありませんか？

2FAを使っていない店舗では、この欠陥で新たに増える危険はほとんどありません。もともとIDとパスワードだけで管理画面に入れる状態だからです。ただし、それ自体が危険な状態でもあります。修正ファイルを当てたうえで、2FAの有効化か管理画面のIP制限を検討してください。

PHPを修正版に上げれば、この脆弱性も直りますか？

直りません。CVE-2026-30777はEC-CUBE本体のコードの欠陥なので、PHPの版とは関係なく、本体の修正ファイルか修正済みの版（4.1.2-p5・4.2.3-p2・4.3.1-p1）が要ります。逆に本体の修正ファイルを当てても、PHP2Shellは直りません。両方を別々に確かめてください。

修正ファイルは古い版のEC-CUBEにもそのまま使えますか？

使えません。公式の修正ファイルは、修正前の各系列の最終版（4.1.2-p4・4.2.3-p1・4.3.1）向けに作られています。それより古い版や、該当の2ファイルをカスタマイズしている場合は、公式告知の「修正方法2」の差分を見て手で反映します。古い版のままだと、ほかの既知の脆弱性も残っている可能性があるため、系列の最新版への更新もあわせて検討してください。

すでに乗っ取られていたら、どう復旧すればよいですか？

正規の管理者の認証アプリのコードが通らなくなっていたら、キーが上書きされた可能性のある状態です。修正ファイルを当ててパスワードを変えたうえで、dtb_member の該当者の two_factor_auth_key をNULLに戻します（two_factor_auth_enabled は1のまま）。次のログインで設定画面へ転送されるので、正規の管理者が新しいキーを登録し直します。有効フラグを0にするだけでは2FAが止まるだけで、攻撃者のキーが残ります。顧客情報を見られた可能性があれば、個人情報保護委員会への報告が必要かどうかも判断します。