2026年10月21日、PHP本体にログインなしで外部からサーバー上で好きなプログラムを実行できる脆弱性2件(CVE-2026-109618、CVE-2026-109619)が公表され、修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 が同時に公開されました。Webで動いているPHPはすべて対象で、EC-CUBEのバージョンや設定に関係なく影響を受けます。PHP公式は「暫定策は不完全で、更新だけが完全な対策」としています。やることは次の3つです。
- サイトを動かしているPHPのバージョンを確認する
- 修正版に更新できるなら、更新して再起動する
- 更新できないなら、公式の暫定策を設定してバージョンアップを計画する
(2026年10月22日時点のPHP公式の告知にもとづいています)
1. PHPのバージョンを確認する
EC-CUBEの管理画面「設定 > システム設定 > システム情報」にPHPのバージョンが出ます。サーバーに入れるなら php -v でも確認できます。あわせて、PHPをどこから入れたか(OSのパッケージ、Remiリポジトリ、レンタルサーバーの切替機能)も確認してください。次の判定で必要になります。
2. 修正版に更新できるか判定する(EC-CUBEバージョン別)
| EC-CUBE | 対応PHP | 判定 |
|---|---|---|
| 4.3 / 4.4 | 8.1〜8.3 / 8.2〜8.5 | 8.2以上なら更新できる。8.2.35、8.3.36、8.4.27、8.5.12 に更新する。8.1 はOSのパッケージに修正が入るのを待つ |
| 4.2 | 7.4〜8.1 | PHP公式からの修正版はない。OSのパッケージには修正が入る(PHP公式がOS各社に事前に修正を渡している)。Remiやレンタルサーバーは、それぞれの告知を待つ |
| 4.0 / 4.1 | 7.1〜7.4 | 4.2と同じ。PHP公式は7.4 / 8.0 / 8.1向けに修正パッチだけ出している(自分でPHPをビルドしている人向け) |
OSのパッケージ(Ubuntu、RHEL系、Amazon Linuxなど)は、バージョン番号を変えずに修正だけを取り込むのが普通です。php -v の番号が古くても、ディストリビューションのセキュリティ情報に今回のCVEが載っていれば修正済みです。
Remiリポジトリ(rpms.remirepo.net)でPHPを入れているサーバーは要注意です。公式の告知に「当日中の更新はない」と明記され、CentOS 7向けは2024年6月で更新が止まっているので、CentOS 7のサイトには修正が来ません。レンタルサーバーは、会社の告知で修正版が追加されたらコントロールパネルで切り替えます。
3-A. 更新できる場合：更新してPHPを再起動する
パッケージを更新しただけでは、動いているPHPは古いままです。php-fpmなら systemctl restart php-fpm、mod_phpならApacheを再起動してください。更新後に管理画面のシステム情報でバージョンを確認し、トップ、商品一覧、カート、管理画面ログインまで表示を確認して終わりです。
3-B. 更新できない場合：公式の暫定策を設定する
php-fpmのプール設定(/etc/php-fpm.d/www.conf など)に次の3行を追加します。php_admin_ の付いた書き方にすると、EC-CUBEや .user.ini から上書きされません。レンタルサーバーならコントロールパネルのphp.ini編集で、session.upload_progress.enabled = 0 と post_max_size = 32M の2つを書きます。
; php-fpm プール設定に追加(php.ini でも可。.user.ini と ini_set() では効かない)
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M書いたら systemctl reload php-fpm で反映します。サイトを止めずに反映できます。反映はphpinfoで確認します。EC-CUBE 4.3系は .env に ECCUBE_PHPINFO_ENABLED=true を書くと管理画面のシステム情報からphpinfoを表示できます(確認後に戻す)。
3行の意味と注意は次のとおりです。
- session.upload_progress.enabled = 0:2件目の脆弱性で確認されている攻撃の入口を塞ぎます。EC-CUBE本体はこの機能を使っていないので動作は変わりません。PHP 8.5なら
fatal_error_backtraces = 0も追加します。 - memory_limit = -1:1件目の脆弱性は、攻撃者がわざとメモリ上限超過を起こすことで成立します。上限をなくせばそれができなくなります。普段は勧めない設定ですがPHP公式の推奨です。代わりにOS側で上限をかけてください。systemdなら
systemctl set-property php-fpm MemoryMax=2G(CentOS 7系はMemoryLimit=)です。ulimitのメモリ制限(RLIMIT_AS / RLIMIT_DATA)で代用してはいけません。脆弱性の条件をかえって作ってしまいます。OS側の上限をかけられない共用サーバーでは、この行は入れません。 - post_max_size = 32M:1件目の脆弱性は、ファイルアップロードに使う形式(multipart)のデータを送りつけて起こします。受け付けるデータ量を絞って、それをやりにくくします。EC-CUBEは商品画像とCSV取り込みがあるので32Mが目安で、
upload_max_filesizeはそれ未満にします。レンタルサーバーで1Gになっていることがあるので要確認です。
暫定策は「特定の攻撃方法を塞ぐだけで、安全にはならない」とPHP公式が明記しています。4.0〜4.2のサイトは4.3へのバージョンアップ(PHP 8.2〜8.3)を、CentOS 6 / 7 のようにOS自体がサポート終了のサーバーは移設を計画してください。PHP 8.2 も2026年12月末でサポートが終わります。
脆弱性の中身(CVE-2026-109618 / CVE-2026-109619)
CVE-2026-109618は、メモリ上限超過で処理が強制的に止まったとき、処理途中のデータを正常なものとして扱ってしまう不具合です。ファイルアップロードに使う形式(multipart)のデータを送ると、わざと起こせます。CVE-2026-109619は、エラーや時間切れで終わった処理のデータの残りが消えず、同じプロセスが次に受け付けた処理がそれを使ってしまう不具合です。どちらもEC-CUBEのプログラムが動く前の段階で起きるので、問い合わせフォームや商品登録のようにファイルアップロード形式のデータを受け付ける公開サイトは、EC-CUBE側がこの機能を使っていなくても対象になります。公式はApacheのmod_phpを最もリスクが高い構成としています。
参考リンク
- PHP公式: Security advisory: Critical remote code execution vulnerabilities, update now
- GHSA-w8hw-w9fx-j79w(CVE-2026-109618)
- GHSA-6wmf-4rv5-p3rp(CVE-2026-109619)
- 公式の PHP 8.1 向けソースパッチ(7.4 / 8.0 のブランチも同じ場所)
- EC-CUBE 4 システム要件
EC-CUBEゴールドパートナー
EC-CUBEに関するお問い合わせ
[重要]現在公式にセキュリティサポートが切れていないPHPは8.1以上、MySQLは8.0以上で、対応しているEC-CUBEバージョンは4.2以上です。古いEC-CUBEを使っている方は適切なタイミングでバージョンアップをご検討ください。
