クマひよ工房同じ脆弱性でも、PHPのバージョンで対応はこれだけ違う｜8.3・7.4・5.6のサーバで対応した記録
2026年10月21日に公表されたPHPの2件の脆弱性（CVE-2026-109618、CVE-2026-109619）に、クマひよ工房では、PHPのバージョンが違う3台のサーバで対応しました。
この記事では、修正版が出るかどうかで、作業の中身と時間がどれだけ変わったかと、対応してわかったことをまとめます。自分のサイトが当てはまるかの確かめ方は、PHPのセキュリティ更新（2026年10月21日）にまとめています。
何が起きたか
PHPの開発チームが、ログインしていない外部の人に、サーバで任意のプログラムを動かされるおそれのある2件の脆弱性を直しました。修正版が出たのは、サポート中の8.2、8.3、8.4、8.5だけです。サポートが終わった7.4、8.0、8.1には、ソースからPHPを入れる人向けに、開発チームが修正を移したソースが用意されました。7.3以前には、どちらもありません。
工房が対応したのは、次の3台です。
- PHP 8.3 - 修正版が出るバージョン
- PHP 7.4 - 2022年11月28日にサポートが終わり、修正を移したソースだけがあるバージョン
- PHP 5.6 - 2018年12月31日にサポートが終わり、修正が何も出ないバージョン
3台のサーバで行ったこと
PHP 8.3：更新するだけで、およそ15分
PHPは、OSの標準のパッケージで入れていました。OSの提供元が修正版の8.3.36を配っていたため、パッケージを更新し、PHPを動かしているプログラムを再起動して、バージョンとサイトの動きを確かめました。作業はおよそ15分です。
PHP 7.4：ソースから組み立て直して、4〜5時間
7.4には修正版が出ないため、開発チームが修正を移したソースから、PHPを組み立てました（ソースからのビルド）。PHPのプログラムを、元になる設計図から自分で作る作業です。
- テスト用のサーバに、組み立てに要る道具と部品を入れ、サイトに要る機能を選んでPHPを組み立てました。
- 前のPHPにあった機能のうち、いくつかが入りませんでした。サイトで使っていないことを確かめてから進めました。
- 前のPHPの設定（速さにかかわる設定や、同時に受けられる処理の数など）を、新しいPHPへ移しました。
- 組み立てたPHPを本番のサーバへ運び、本番の設定を移してから切り替えました。
- 前のPHPは消さずに止めるだけにして、動かなかったときに戻せるようにしました。
作業はおよそ4〜5時間です。
PHP 5.6：つなぎの対策と有志のパッチで、3時間ほど
5.6には、修正版も、修正を移したソースもありません。サーバのOSもサポートが終わった古いもので、OSの提供元からの修正も届きません。
- まず、開発チームが挙げたつなぎの設定（
session.upload_progress.enabled=0、memory_limit=-1）を、サイト側から上書きできない場所に入れました。 - このサイトではファイルのアップロードを使っていなかったため、ファイルを送るリクエスト（multipart）を、PHPに届く手前のWebサーバで止めました。管理画面で商品画像やCSVをアップロードするEC-CUBEでは、そのままでは取れない手段です。
- 有志が公開している5.6向けのパッチ（修正のための差分）を、5.6の最後の版の5.6.40に当てて、PHPを組み立てました。PHPの開発チームの検証は受けていないパッチです。
- PHPの動かし方を、開発チームがいちばんリスクが高いとしたApacheのモジュール（mod_php）から、PHP-FPMへ切り替えました。Webサーバも古いため、PHP-FPMとつなぐ部品や、サーバの起動時にPHPを動かす仕組みも用意しました。
- 古いPHPが、サイト用にもコマンド用にも残っていないことを確かめました。
作業は3時間ほどです。7.4の作業のあとで、重なる手順に慣れていたため、7.4より短く済みました。
対応してわかったこと
修正版が出るかどうかで、作業の重さがまるで違う
同じ脆弱性への対応で、8.3はおよそ15分、7.4は4〜5時間、5.6は3時間ほどかかりました。違うのは時間だけではありません。8.3は修正版に替えて終わりですが、5.6は検証を受けていないパッチに頼り、つなぎの対策を続けることになります。
修正版が出るバージョンのPHPを、OSの標準のパッケージから入れていれば、次に脆弱性が見つかったときも、更新するだけで済む見込みが高くなります。EC-CUBEのバージョンごとに、上げられるPHPのバージョンはPHPのセキュリティ更新（2026年10月21日）にまとめています。
コマンド用のPHPだけが、古いまま残っていた
5.6のサーバでは、サイト用のPHPを切り替えたあとも、サーバ上で php -v を実行すると古いバージョンが出ました。コマンド用のPHPが、別に残っていたためです。
コマンド用のPHPは、サイトへのリクエストを受けないため、今回の脆弱性を突かれる経路にはなりません。ただ、cron（決まった時刻に動く処理）で動かしている処理は、古いPHPで動き続けます。修正を入れたら、サイト用とコマンド用の両方のバージョンを確かめ、cronで古いPHPを直に指定していないかも見ておきます。
PHPを入れ替えると、EC-CUBEがエラーを出すことがある
あるサーバでは、新しいPHPに替えたあと、EC-CUBEで次のエラーが出ました。どちらも、新しく組み立てたPHPに、前のPHPと同じ設定が入っていなかったことが原因です。
- タイムゾーンの設定がない - PHPが出した警告を、EC-CUBEがエラーとして扱いました。
date.timezoneを設定して直りました。 - データベースにつながらない - 新しいPHPが、データベースの接続先を、前とは違う場所に探しに行っていました。接続先を設定して直りました。
PHPを入れ替えるときは、前のPHPの設定を新しいPHPへ引き継ぎます。入れ替えたあとは、トップと商品ページの表示、カートへの追加、注文の完了、注文メールの受け取り、管理画面へのログインまで試します。
修正が出ないバージョンでは、つなぎの対策を外せない
有志のパッチは、PHPの開発チームの検証を受けていません。パッチを当てたあとも、つなぎの設定とリクエストの遮断は外せません。つなぎの設定には、PHPのメモリの上限を外すといった引き換えもあります。
また、サポートが終わったPHPでは、今回のほかに見つかった脆弱性も直されません。根本の対策は、OSとPHPをサポート中のバージョンへ上げることです。EC-CUBEのバージョンによっては、EC-CUBEの改修や移行が先に要ります。
相談先
サポートが終わったPHPのサーバでの脆弱性への対応や、修正を入れたあとの確認はセキュリティの対応で、EC-CUBEとPHPをサポート中のバージョンへ上げる改修や移行はサポート終了への対応で、ご相談を承っています。