相談してみる

PHPのセキュリティ更新（2026年10月21日）｜EC-CUBEのサイトが当てはまるかと、今できること

公開：更新：脆弱性・サポート終了の情報

2026年10月21日、PHP（EC-CUBEを動かしているプログラムの言語）の開発チームが、2件の脆弱性（悪用されるおそれのある弱点）を直した修正版の8.5.12、8.4.27、8.3.36、8.2.35を出しました。悪用されると、ログインしていない外部の人に、サーバで任意のプログラムを動かされるおそれがあります。

この記事では、EC-CUBEのサイトが当てはまるかの確かめ方と、自社サーバ（VPSなど）とレンタルサーバそれぞれで今できることをまとめます。

何が起きたか

PHPの開発チームは、10月20日に修正版を出すことを予告し、21日の日本時間23時に出しました。直したのは次の2件です。

  • CVE-2026-109618 - メモリが足りなくなったときの処理の不具合です。作りかけのデータが、正しいものとして扱われることがあります。
  • CVE-2026-109619 - 片付けたはずの内部の情報が残り、次のリクエストで使われてしまう不具合です。

どちらも、ログインしていない外部の人に、サイトを動かしているサーバのアカウントの権限で、任意のプログラムを動かされるおそれがあります（リモートコード実行）。CVSS v4.0での評価は、どちらも9.2です。CVSSは脆弱性の大きさを0〜10で表す共通の物差しで、9.0以上はいちばん高い区分にあたります。

PHPの動かし方（PHP-FPM、Apacheのモジュール（mod_php）、CGI、LiteSpeedなど）にかかわらず、Webサイトのリクエストを受けているPHPはすべて対象です。開発チームは、Apacheのモジュールで動かしている場合を、攻撃が成り立つことを確かめたため、いちばんリスクが高いとしています。

自社サーバ（VPSなど）の場合

PHPの修正版を入れるのは、サーバを管理している側（自社、またはサーバの管理の委託先）です。修正版が出ても、入れるまでは直りません。開発チームによれば、Linuxのディストリビューション（OSの提供元）には修正が事前に渡されています。

レンタルサーバの場合

PHPを入れ替えるのはサーバ会社で、利用者がPHPそのものを直すことはできません。それでも、どのバージョンのPHPを使うかを選ぶことや、サーバ会社の対応を確かめることはできます。

自分のサイトが当てはまるか

PHPの動かし方にかかわらず、修正版より前のPHPは当てはまります。

  • 8.2、8.3、8.4、8.5 - 8.2.35、8.3.36、8.4.27、8.5.12より前が当てはまります。8.2のサポートは、2026年12月31日で終わります。
  • 7.4、8.0、8.1 - サポートが終わっているため、修正版は出ません。ただし今回は、ソースからPHPを入れている人向けに、開発チームが修正を移したソースを用意しています。
  • 7.3以前（5系を含む） - 当てはまるかは、公表された情報に書かれていません。修正も出ないため、当てはまるものとして扱ってください。

サイトで実際に動いているPHPのバージョンは、EC-CUBEの管理画面で確かめられます。

  • 4系 - 設定 > システム設定 > システム情報
  • 3系 - 設定 > システム情報設定 > システム情報
  • 2系 - システム設定 > システム情報

自社サーバ（VPSなど）の場合

サーバ上で php -v を実行して出るバージョンが、管理画面と違うことがあります。サイト用とコマンド用で、別のPHPが入っていることがあるためです。サイト用のPHPを優先して確かめます。

あわせて、PHPをどこから入れたかを確かめます。修正版の入れ方と、8.1以前でも修正が届くかが変わります。

  • OSの標準のパッケージ - OSの提供元の更新で直ります。8.1以前でも、OSの提供元が修正を移して配ることがあります。この場合、バージョンの番号は変わらないまま直るため、OSの提供元のセキュリティ情報で確かめます。
  • OSの標準以外の配布元 - 配布元によって、修正を出すバージョンと時期が違います。開発チームは、有志で保守されているRemiのリポジトリ（rpms.remirepo.net）には公表の当日に更新が出ないとして、OSの標準のパッケージか、ソースから入れる方法へ切り替えるよう勧めています。
  • ソースから自分で入れた - 修正版のソースから入れ直します。7.4、8.0、8.1は、開発チームが修正を移したソースを使えます。7.3以前には用意されていません。

レンタルサーバの場合

コントロールパネルの、PHPのバージョンの設定でも確かめられます。ドメインやフォルダごとに別のバージョンを選べるサーバもあるため、EC-CUBEを置いている場所の設定を見ます。

8.2以降を使っている場合は、サーバ会社が修正版に入れ替えたかを確かめます。8.1以前を使っている場合、サーバ会社が独自に直すかどうかは会社によって違うため、サーバ会社のお知らせで確かめます。

今できること

まず（共通）

サイトのファイルとデータベースの両方のバックアップを取っておきます。修正版を入れたり、PHPのバージョンや設定を変えたりして動かなくなったときに、戻せるようにするためです。

8.1以前を使っている場合、修正版が出るバージョンへ上げられるかは、EC-CUBEのバージョンで決まります。開発元が示す動作環境のPHPは、次のとおりです。

  • 2.25 - 7.4.33以上。2.25.0で開発元が動作を試しているのは、8.4まで
  • 3系（3.0） - 5.3.9〜7.1
  • 4.0、4.1 - 7.4まで
  • 4.2 - 7.4〜8.1
  • 4.3 - 8.1〜8.3

修正版が出る8.2以降での動作が開発元から示されているのは、2.25と4.3です。2.25は、2.13をPHPの7と8に対応させたもので、2.25より前の2系を使っている場合は、2.25への更新が上げ先の1つになります。ただし、入れているプラグインやカスタマイズによっては、あわせて改修が要ります。

3系と、4.2以前の4系は、そのままでは8.2以降で動かせません。EC-CUBEの改修や、新しいバージョンへの移行が必要になります。その進め方は、サポート終了への対応でまとめています。

自社サーバ（VPSなど）の場合

修正版を入れる

  1. PHPを入れた方法に合わせて、修正版（8.5.12、8.4.27、8.3.36、8.2.35）か、OSの提供元が修正を移したパッケージを入れます。
  2. PHPを動かしているプログラム（PHP-FPMやApacheなど）を再起動します。修正版を入れただけでは、動いているPHPは古いままのことがあります。
  3. 管理画面のシステム情報でバージョンを確かめます。
  4. トップと商品ページの表示、カートへの追加、注文の完了、注文メールの受け取り、管理画面へのログインを試します。

テスト用の環境があれば、先にそちらで試します。

すぐに入れられないとき

開発チームは、修正版を入れることだけが確かな対策だとしたうえで、攻撃の経路の一部を減らす設定を挙げています。どれも、入れるまでのつなぎです。

  • session.upload_progress.enabled=0 にして、PHPを動かしているプログラムをすべて再起動します。
  • 8.5では、fatal_error_backtraces=0 にもします。
  • memory_limit=-1 にして、PHPのメモリの上限を外します。サーバ全体のメモリを使い切らないよう、コンテナやcgroupで上限を設けることも、あわせて挙げられています。
  • post_max_size を小さくします。ファイルのアップロードを使うときは32M、使わないときは8Mが目安で、upload_max_filesize はそれより小さくします。EC-CUBEの管理画面では、商品画像やCSVをアップロードします。

これらの設定は、php.ini、PHP-FPMのプール、Apacheの設定に書き、サイト側から上書きできないようにします。.user.ini や ini_set() では効きません。設定を変えたら、上の4.に加えて、管理画面での商品画像のアップロードやCSVの取り込みも試します。

8.1以前で、OSの提供元からも修正が届かないとき

PHPを、修正版が出るバージョンへ上げることを考えます。上に挙げたとおり、EC-CUBEのバージョンによっては、EC-CUBEの改修や移行が先に要ります。それまでの間は、上の設定でつなぎます。

レンタルサーバの場合

サーバ会社の対応を確かめる

サーバ会社のお知らせ（メンテナンス情報や障害情報）で、修正版に入れ替えたかと、その日時を確かめます。お知らせが見つからないときは、サーバ会社に次のことを問い合わせます。

  • 使っているPHPのバージョンに、今回の修正（CVE-2026-109618、CVE-2026-109619）が入ったか
  • まだなら、いつ入るか
  • 8.1以前を使っている場合、どう扱われるか

8.1以前を使っていて、修正が入らないとき

コントロールパネルで、修正が入ったバージョンへ切り替えることを考えます。ただし、EC-CUBEが動かなくなることがあります。

  1. 切り替える前に、バックアップを取ります。
  2. 切り替えたら、注文の完了や管理画面へのログインなどを試します。
  3. 動かなければ、元のバージョンに戻します。

EC-CUBEの動作環境より新しいバージョンへは、改修をせずに切り替えないでください。

PHPの設定を変える

コントロールパネルでphp.iniの設定を変えられるサーバでは、自社サーバの場合に挙げた設定のうち、session.upload_progress.enabled や post_max_size を変えられることがあります。ただし、開発チームは .user.ini や ini_set() では効かないとしています。コントロールパネルの設定がどの仕組みで反映されるかはサーバによって違うため、効くかどうかはサーバ会社に確かめてください。

WAFを有効にする

多くのレンタルサーバでは、コントロールパネルから、WAF（サイトへの攻撃を見分けて止める仕組み）を有効にできます。今回の脆弱性を突く攻撃を止められるかは、WAFの仕組みとサーバ会社の対応によります。PHPの修正の代わりにはならないため、修正が入るまでの備えの1つと考えてください。

WAFを有効にすると、管理画面での保存などが攻撃と見分けられ、止められることがあります。有効にしたら、管理画面の操作も試します。

見覚えのないファイルに気づいたら（共通）

見覚えのないファイルや管理者アカウントに気づいたときは、削除する前にご相談ください。調査の手がかりが消えてしまうことがあります。

相談先

PHPに修正が入るかは、自社サーバならOSの提供元のセキュリティ情報やサーバの管理の委託先、レンタルサーバならサーバ会社のサポートで確かめられます。EC-CUBEが新しいPHPで動くか、修正版を入れたあとの確認、PHPを上げるための改修は、セキュリティの対応とサポート終了への対応でご相談を承っています。

参考にした情報

同じカテゴリーの記事

脆弱性・サポート終了の情報の記事

あなたのEC-CUBEを、ひとりにしない。

おかしい、あぶない、そろそろ。EC-CUBEのことは、クマひよ工房にひと声。

相談してみる

受付時間：土日祝と年末年始を除く、9時〜17時