---
title: "EC-CUBEのMFAバイパス脆弱性CVE-2026-30777とは｜影響版の確認・修正手順とPHP2Shellへの備え"
url: "https://www.issoh.co.jp/tech/details/11295/"
published: 2026-03-09
updated: 2026-11-12
categories: ["脆弱性・インシデント"]
publisher: "株式会社一創"
---

# 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公式の告知](https://www.ec-cube.net/info/weakness/20260209/index.php)は「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](https://jvn.jp/jp/JVN63765888/)のほか、開発元のGitHubにも[アドバイザリGHSA-7rhv-h82h-vpjh](https://github.com/EC-CUBE/ec-cube/security/advisories/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段階

1. フィッシングや使い回しで得た管理者のIDとパスワードで、管理画面にログインする
2. コード入力画面に転送されたところで、管理画面パスの `two_factor_auth/set` を直接開く
3. 攻撃者の認証アプリで新しいキーを読み取って保存し、以後は自分のコードで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](https://nvd.nist.gov/vuln/detail/CVE-2026-30777)は独自にCVSS 3.1で6.5（機密性と完全性がともに高）と評価しています。各指標の意味と点数の目安は[CVSSv3のスコアの目安と計算式](/tech/details/5094/)、2FAを迂回されることの意味は[多要素認証（MFA）の3要素と実装方式](/tech/details/13314/)で確認できます。

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

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

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

## 自社の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` で確認）。

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

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

公式の修正ファイルは、修正前の各系列の最終版（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とパスワードが漏れていること」なので、この前提を崩すことが危険を大きく下げる対策です。二段階認証そのものの考え方は[二段階認証と多要素認証の違い](/column/details/13268/)で解説しています。

### 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](https://jvn.jp/jp/JVN43511918/index.html)として公表されました。JVNの深刻度は「緊急」で、開発元は悪用を確認しています。[EC-CUBE公式のお知らせ](https://www.ec-cube.net/news/detail.php?news%5Fid=490)は危険度を「高」とし、不正な管理者アカウントを登録されて管理画面にログインされるおそれを挙げています。

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

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

[PHPの開発元は2026年10月21日](https://www.php.net/archive/2026.php)、認証なしで任意のコードを実行されうる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の開発者向けドキュメントのシステム要件](https://doc4.ec-cube.net/quickstart/requirement)と、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のサポート期限の一覧](https://www.php.net/supported-versions.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の影響範囲と修正版](/tech/details/18738/)で詳しく扱っています。

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

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

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

### クラウド版のec-cube.coを使っている場合も作業が必要ですか？

修正ファイルの適用は不要です。クラウド版（ec-cube.co）は、2026年3月4日の公式ニュースで修正済みと案内されています。ただし、管理者アカウントの棚卸しとパスワードの見直しは、どちらの形態でも利用者側で行う対策です。

## 関連記事

- [EC-CUBE AmazonPayプラグインの脆弱性とは？修正版の確認SQLと侵害調査の手順](/tech/details/18380/)
- [PHP2Shellとは：CVE-2026-109618・109619の影響範囲と修正版、悪用の実態と更新できない場合の設定【2026年10月】](/tech/details/18738/)
- [多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説](/tech/details/13314/)
- [CVSSv3とは？v3.1のスコアの目安・計算式と計算機の使い方を解説](/tech/details/5094/)
- [Magentoの脆弱性CVE-2026-48356とは：PolyShellの対象版・確認コマンド・パッチ適用手順](/tech/details/19023/)

---

出典: [EC-CUBEのMFAバイパス脆弱性CVE-2026-30777とは｜影響版の確認・修正手順とPHP2Shellへの備え](<https://www.issoh.co.jp/tech/details/11295/>)（株式会社一創）