PHPの脆弱性(CVE-2026-109618/109619)：EC-CUBEサイトの対応手順｜更新できないPHP 7.4・8.1の暫定策

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つです。

1. サイトを動かしているPHPのバージョンを確認する
2. 修正版に更新できるなら、更新して再起動する
3. 更新できないなら、公式の暫定策を設定してバージョンアップを計画する

(2026年10月22日時点のPHP公式の告知にもとづいています。同日、OSのパッケージとレンタルサーバーの状況、mod_phpの暫定策、UbuntuのPPAでPHPを入れている場合を追記しました)

先に結論：対象の範囲と「安全」の基準

この脆弱性はEC-CUBEだけでなく、PHPで動いているすべてのサイト・システムが対象です。WordPressの会社サイト、キャンペーン用のLP、問い合わせフォームだけのページ、テスト用に置いたままのページも含みます(cronやコマンドラインだけで動くPHPは対象外です)。PHPで動いているサイトを洗い出して、1つずつ確認・対処する必要があります。

安全と言える状態

• 修正版のPHPに更新されている(PHP 8.2以上には公式の修正版があります。8.1以下は公式の修正版がないので、OSやPPA、レンタルサーバー会社が修正入りの版を配っていなければ、暫定策か停止になります)
• 全URLがWebサーバーのBasic認証またはIP制限で保護されている(管理画面だけの保護では不十分です)
• 使っていないサイトはPHPを止めるか削除する

一時しのぎ。安全にはならないが、リスクは下がる

• PHP公式の暫定策を設定している(session.upload_progress.enabled = 0、post_max_size を下げる、memory_limit = -1)。php.ini、php-fpmのプール設定、Webサーバーの設定のどれかに書いて、PHPを再起動(reload)して初めて有効になります。.user.ini や ini_set() では有効になりません。
• Cloudflareを経由している。Cloudflareは10月21日にこの脆弱性向けのWAFルールを無料プランを含む全プランに配信しています。ただし、サーバーに直接アクセスできない構成になっていること、DNSがCloudflare経由になっていること、有料プランならManaged Rulesetがブロックモードになっていることが条件です。Cloudflare自身も「WAFは修正ではないのでPHPを更新するように」と書いています。

対策にならないもの

• サイトの閲覧にログインが必要(EC-CUBEのマイページやLaravelの認証のように、PHPの中で行うログイン)。ログイン画面に到達した時点でPHPが動いているので、ログイン判定の前に攻撃が成立します。
• Cloudflare以外のWAFやCDNを経由している(同等のルールが出ているかは各社に確認が必要です)
• 個人情報を扱っていない

誤解されやすいのは最後の点です。個人情報を扱っていないブログなどでも対処は必要です。未対策のサイトが攻撃の入口になり、同じサーバー上の別のサイトが改ざんや情報流出を起こす可能性があるためです。攻撃者はPHPを動かしているOSユーザーの権限でプログラムを実行できるので、そのユーザーが読める場所にある別サイトの設定ファイルやデータベースまで届きます。Apacheのmod_phpで複数サイトを動かしているサーバーは、全サイトが同じプロセスで動くため特に影響が大きくなります。サイト単位ではなく、サーバー単位で見てください。

1. PHPのバージョンを確認する

EC-CUBEの管理画面「設定 > システム設定 > システム情報」にPHPのバージョンが出ます。サーバーに入れるなら php -v でも確認できます。あわせて、PHPをどこから入れたか(OSのパッケージ、Remiリポジトリ、UbuntuのPPA、レンタルサーバーの切替機能)も確認してください。次の判定で必要になります。

2. 修正版に更新できるか判定する(EC-CUBEバージョン別)

OSのパッケージ(Ubuntu、RHEL系など)は、バージョン番号を変えずに修正だけを取り込むのが普通です。php -v の番号が古くても、ディストリビューションのセキュリティ情報に今回のCVEが載っていれば修正済みです。

ただし修正が入るのは、サポート中のOSと、延長サポートを使っている場合だけです。たとえばAmazon Linux 2のamazon-linux-extrasでは、2026年10月22日時点でphp8.2に修正版の8.2.35が出ていますが、php8.1には出ていません。Amazon Linux 2でEC-CUBE 4.2を動かしているなら、4.3にバージョンアップしてphp8.2へ移るのが現実的な対応です。php8.2へ移るときにシステムのlibcurlが古いままだと、PHPのcurl拡張が読み込まれません。curlとlibcurlも更新し、php -mでcurlが表示されることを確かめてください。

Remiリポジトリ(rpms.remirepo.net)でPHPを入れているサーバーは要注意です。公式の告知に「当日中の更新はない」と明記され、CentOS 7向けは2024年6月で更新が止まっているので、CentOS 7のサイトには修正が来ません。レンタルサーバーは会社によって対応が違います。新しい版が追加されてコントロールパネルで切り替える場合のほかに、既存の版がバージョン番号を変えないまま修正入りに入れ替わる場合があります。たとえばエックスサーバーは、10月22日にPHP 7.4・8.0・8.1などを、番号はそのままで修正入りの版に入れ替えました。この場合は番号を見ただけでは対応済みか分からないので、会社の告知と、phpinfoのBuild Dateが10月21日以降になっているかの両方で確かめてください。

UbuntuでPPA(ppa:ondrej/php)からPHPを入れているサーバーには、サポートが終わった版にも修正版が出ています。PHP 5.6では、10月21日に公開された 5.6.40-104 が修正版です。末尾の -104 は修正のたびに上がる番号なので、php -v の表示で確かめられます。ほかの版は、更新したあとに次のコマンドでCVE番号が表示されれば修正済みです(5.6 は使っている版に置き換えます)。

zcat /usr/share/doc/php5.6-common/changelog.Debian.gz | grep "CVE-2026-10961[89]"

このPPAの修正版は、Ubuntuの自動更新(unattended-upgrades)では入りません。標準の設定ではPPAが対象外だからです。また、以前からこのPPAを使っているサーバーでは、apt-get update が次のエラーで止まり、修正版が候補に出てこないことがあります。

E: Repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu jammy InRelease' changed its 'Label' value from 'Use https://packages.sury.org/php/ instead' to 'PPA for PHP'

PPAのラベルが変わったことを知らせるエラーです。次のようにラベルの変更を承認してから、修正版を入れてください。

sudo apt-get update --allow-releaseinfo-change-label

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をApacheのモジュール(mod_php)として動かしているサーバーは、Apacheが読み込むphp.iniに同じ2つを書いて、Apacheを再起動します。php.iniの場所はOSによって違うので、phpinfoの「Loaded Configuration File」で確かめます。

; 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は株式会社イーシーキューブの商標です

ECCUBE制作トップへ

EC-CUBEに関するお問い合わせ

[重要]現在公式にセキュリティサポートが切れていないPHPは8.1以上、MySQLは8.0以上で、対応しているEC-CUBEバージョンは4.2以上です。古いEC-CUBEを使っている方は適切なタイミングでバージョンアップをご検討ください。