EC-CUBEを動かすPHPの脆弱性「PHP2Shell」にどう対応したか｜検討した選択肢と判断の理由
Satoshi NakanoPHPの脆弱性「PHP2Shell」にどう対応したか｜修正の確認から対応方法の選択まで
PHPの脆弱性「PHP2Shell」への対応では、稼働中のシステムにどう修正を適用するかが課題になりました。提供元の修正パッケージを使えるのか。古いPHPを残して対処できるのか。PHPを更新するなら、既存のEC-CUBEや独自処理にどこまで手を入れる必要があるのか。環境によって、採れる方法が異なります。
当社でも、PHPの修正状況に加え、アプリケーションへの影響と、対応後の構成を保守していけるかを調べながら方法を検討しました。古いPHPを自前で維持する案は見送り、別の環境ではPHPの更新に合わせてライブラリや拡張を調整しています。この記事では、その判断の理由と、実際の対応で確認したことを紹介します。
まず、利用中の環境に修正が届いているかを調べる
PHP2Shellの対象はCVE-2026-109618およびCVE-2026-109619です。PHP公式は10月21日、PHP 8.2.35、8.3.36、8.4.27、8.5.12で修正したと発表しました。EC-CUBE固有の問題ではなく、EC-CUBEを動かしているPHP側の対処が必要です。［1］
ここで確認するのは、PHPのバージョン番号に加え、そのPHPをどこが提供し、どの修正を取り込んでいるかです。OSベンダーが従来のバージョンを維持したまま必要な修正を取り込む「バックポート」を提供することもあるため、PHP本体のリリース情報と、利用中のOSやサーバー提供元の案内を照らし合わせます。
例えばRed Hatは、RHEL 9向けにPHP 8.0.30のまま今回の2件を修正したパッケージ、php-8.0.30-8.el9_8.1を公開しています。PHP本体の修正版として案内された8.2.35以降へ上げなくても、提供元による修正が入っている例です。Rocky Linuxにも、対応する更新の案内があります。［8］［9］
ただし、同じPHP 8.0.30でも、修正前のパッケージはあり得ます。確認するのはPHPの番号だけでなく、RPMのリリース部分を含むパッケージの版と、利用中のOS・ストリームに対応したセキュリティ勧告です。この例は当初の2件への対応を示すもので、後述する10月23日の追加案内への対応まで示すものではありません。
なお、RHEL互換のOSでも、すべての修正が同じタイミング・経路で届くわけではありません。AlmaLinuxは今回の告知で、PHP 7.4はRed Hatの更新を再ビルドし、それ以外のPHPストリームは自ら先行してバックポートしたと説明しています。AlmaLinux 9のPHP 8.2では、8.2.33をベースに修正したパッケージが案内されました。Red Hat側の対応だけで判断せず、実際に使っている提供元の案内を見る必要があります。［4］
提供元の修正を適用できれば、PHPの系列変更に伴う改修を避けられる場合があります。ただし、修正版が配布されたことと、自分のサーバーに導入されたことは別です。案内にあるパッケージと実際の導入状況を照合して、対処できている範囲を確認します。
有料の保守契約を使う選択肢もある
修正を継続して受け取る方法として、Red Hat Enterprise Linux（RHEL）のサブスクリプションや、CanonicalのUbuntu Proを利用することも考えられます。必要な修正を自社で調べ、古いPHPへ適用し続ける負担を考えると、対象パッケージのセキュリティ更新をベンダーから受け取れる契約には意味があります。契約内容によっては、技術的な問い合わせの窓口も確保できます。［10］［12］
ただし、契約する前に、今使っているPHPが対象になるかを確認します。RHELではPHPなどのApplication StreamにOS本体とは異なる保守期限があり、同じPHPの系列でも、RHELの版やストリームによって扱いが変わります。Ubuntu Proの拡張セキュリティ保守（ESM）も、対象となるUbuntu公式パッケージへの提供です。外部リポジトリのPHPや、自分でビルドしたPHPまで自動的に保守されるわけではありません。更新の提供範囲と期間、問い合わせ対応の有無は、それぞれ契約前に確認する必要があります。［11］［12］
もちろん、契約によってEC-CUBEや独自プラグインの動作まで保証されるわけではなく、更新の適用と動作確認は残ります。それでも、既存システムを維持する必要があるなら、改修や移行だけでなく、保守契約を利用した場合の費用と対応範囲も比較する価値があります。古い構成の修正をすべて自前で抱える以外にも、選べる方法があるということです。
古いPHPを残す方法も検討した
提供元の修正で対応できるかを調べる一方、古いPHPを使うシステムでは、アプリケーションをすぐに変更せずに済む方法も検討しました。その一つが、PHP5系を新しいLinux OS上でコンパイルし、PHPに修正を適用して使う案です。これは後述するEC-CUBE4.2の環境とは別の検討で、最終的には採用していません。
この方法で問題になるのは、PHPだけを用意すれば構成が整うわけではないことでした。古いPHPと新しいOSのライブラリが、そのまま組み合わさるとは限りません。PHP5.5では、さらに古いライブラリを用意するか、ソース側の対応を考える必要があり、OpenSSL 1.1.1を持ってくればそのまま使えるわけではありません。一方、PHP7.4を維持する検討も含め、OS標準のOpenSSLとは別に1.1.1を用意する案もありました。［7］
OpenSSL 1.1.1の一般向けサポートは、2023年9月11日に終了しています。また、公式が公表したCVE-2024-0727には、細工されたPKCS#12データの処理によってクラッシュし、サービス拒否につながる問題があります。影響する処理を使うことが条件で、深刻度はLowです。公表時の1.1.1系の修正版1.1.1xは、有償サポート向けでした。［5］［6］
ベンダーのバックポートや有償保守で修正が提供される場合もあるため、1.1.1系というだけで未修正とは判断できません。ただ、一般公開されている古いソースを自分で組み込む案では、その後の修正をどこから受け取り、誰が適用していくかまで考える必要があります。PHPの今回の問題を直しても、一緒に使うOpenSSLなどに既知の問題を残すことになれば、その部分への対処は残ります。
古いアプリケーションへの変更を抑えられるとしても、PHP、拡張、周辺ライブラリを自前で維持する負担が大きい。今回はそう判断し、この案を見送りました。PHPに今回のパッチが当たっていても、周辺ライブラリに既知の問題を残す構成では、安心して運用を続けられません。今回の脆弱性への対処と、その後も修正を受けられる構成にすることを、合わせて考えました。
EC-CUBEは自由に作り込めるが、長く使うための負担が大きい
ここで少し、EC-CUBEを使い続ける側の事情にも触れておきたいと思います。EC-CUBEのよさは、EC事業者のやりたいことに合わせて作り込める点です。販売画面だけでなく、管理画面や受注処理まで、自社の業務に合わせて変更できます。既製の管理画面に業務を合わせるのではなく、日々の仕事に合わせてシステムを作れる。この自由度は、EC-CUBEを選ぶ大きな理由です。［13］
一方で、対応するミドルウェアの保守期限を考えると、開発費をかけて作ったシステムを、その構成のまま長く使える期間は短くなりがちです。カスタマイズの自由度は高いのに、それを維持するための更新・再検証の負担が早い段階で生じる。私はここを、EC-CUBEの弱さだと感じています。
例えば、EC-CUBE4.2の正式版は2022年9月28日に公開され、対応するPHPは7.4〜8.1でした。新バージョンが出ても、すぐに本番案件へ採用するとは限りません。プラグインの対応や不具合の状況を見て、半年ほど経ってから(リリースから半年ぐらい経過したら安定しいるだろうという経験則で公式でアナウンスされているわけではありません)開発を始め、実開発に3〜4か月かけるとします。この進め方なら、サイト公開は2023年6〜7月になります。［2］［14］
PHP8.1のセキュリティサポートが実際に終了したのは、2025年12月31日です。EC-CUBE4.2のリリース時点では約3年3か月あった期間が、この想定でサイトを公開した時点では約2年5〜6か月になります。導入までの9〜10か月は、事業者がシステムを使って売上をつくる前に過ぎてしまいます。［15］
しかも、PHP8.1の当初のサポート計画は2024年11月までで、2024年の方針変更によって延長されています。当初の予定で考えれば、2023年6〜7月に公開したサイトには約1年4〜5か月しか残っていませんでした。実際には延長されたものの、導入を決めた時点で、その延長を見込めたわけではありません。［16］
日本の税制では、自社で使うソフトウェアを資産計上する場合、原則として5年で減価償却します。これは技術的な寿命を定めたものではありませんが、経営者としては、初期開発に投じた費用に見合う成果を得るためにも、必要な保守をしながら、せめて5年は使い続けたいと考えます。まだ投資を回収している途中で、次の更新費用を捻出しなければならない。その負担を「古いから更新しましょう」だけで片付けるのは、実情に合わないと思います。［17］
もちろん、PHP本体の保守終了日にEC-CUBEが使えなくなるわけではありません。前述したOSベンダーのバックポートや有料保守で対応を続けられる場合もあります。ただ、その提供範囲を調べ、契約や構成を見直す作業は必要です。EC-CUBEの自由度を評価するからこそ、作り込んだシステムを長く使うための道筋と、その費用も導入時から考えておきたいところです。
こうした問題意識から、当社ではEC-CUBEをベースに、フロントエンドとバックエンドを分離した「SPREAD Commerce」を作りました。EC-CUBEのカスタマイズ性を生かしながら、少しでも安全にシステムの稼働期間を延ばせるようにしたい、という考えが開発の背景にあります。
もちろん、フロントエンドとバックエンドを分けても、PHPやEC-CUBEの脆弱性がなくなるわけではなく、それぞれの更新と保守は必要です。それでも、作り込んだシステムを長く使うために、構成から見直す余地はあると考えています。今回の脆弱性対応も、目の前の修正をどう適用するかと、今後どう運用を続けるかの両方を考える機会になりました。
PHPを更新した環境では、既存構成をどこまで維持できたか
本来はEC-CUBE本体も新しいバージョンへ追随していくのが望ましいものの、予算や業務上の都合から、当面は4.2を使い続ける必要がある場合もあります。その間の脆弱性を放置せず、既存機能を維持しながら次の更新につなぐ方法として、今回の個別環境ではPHP8.1から8.2へ移行しました。これは対応の一例であり、ほかの環境にも同じ組み合わせを推奨するものではありません。
EC-CUBE4.2の公式システム要件はPHP7.4〜8.1で、PHP8.2はその範囲外です。今回の事例も、すべてのEC-CUBE4.2環境で動作することや、全機能の動作を保証するものではありません。［2］
それでもこの環境でPHP8.2を検討できた理由の一つが、EC-CUBEの土台となるSymfony5.4側の互換性でした。Symfony公式リポジトリには、5.4系を含むPHP8.2対応の追跡情報があります。既存の構成をなるべく維持したまま、必要な箇所を調整できる余地があると考えました。［3］
もちろん、Symfony5.4系を使っているだけでサイト全体が動くとは判断できません。導入されている各コンポーネントの版、ほかのライブラリ、プラグイン、独自処理によって影響は変わります。そこで、実際の環境で依存関係と実行時の問題を確認していきました。
Composerの条件と、固定されているライブラリの版を合わせる
Composerでは、composer.jsonにPHPやライブラリの要件を記載し、composer.lockで実際に使うライブラリの版を固定しています。サーバーのPHPを8.2に切り替えても、記録された条件や固定された版が対応していなければ、依存関係の解決や実行時のチェックで止まることがあります。
今回の対応では、laminas/laminas-codeを4.7.1から4.8.0へ更新しました。フレームワーク全体を一度に更新するのではなく、PHP8.2への移行に伴って必要となる依存関係を調整しています。
対象の一環境では、Composerが依存関係を解決するときに参照するPHPの想定値、config.platform.phpに7.4が残っていました。これを8.2.35へ合わせています。この設定は実際のPHPを切り替えるものではないので、Composerの設定値と、サーバーで動いているPHPはそれぞれ確認しました。
開発用の依存パッケージsoftcreatr/jsonpath 0.7.6では、PHPの上限制約にも当たりました。作業中は上限制約だけを一時的に無視して進める場面がありましたが、その操作でパッケージの互換性が確認できたわけではありません。
最終的には、実際のPHP8.2環境で、開発用依存を除いた実行要件のチェックが通ることを確認しました。開発用パッケージまで含めて、すべて対応済みになったわけではありません。本番で必要な構成の確認を進める一方、開発環境まで含めた依存関係の整理は、別の課題として残っています。
拡張の再ビルドと、実行時に使われるライブラリの確認
Composerの調整に加え、APCuやImagickなどのPHP拡張も作業対象になりました。これらには利用するPHPに合わせたバイナリが必要で、PHP8.1向けの拡張ファイルをそのまま8.2へコピーする方法は採っていません。
今回の環境では、APCu 5.1.23とImagick 3.7.0をPHP8.2向けにビルドし直しました。ZIPとSodiumは、従来手動で用意していたものから、PHP8.2向けの公式RPMパッケージを使う構成へ整理しています。パッケージで管理できる部分を増やし、その後の更新時に個別に手を入れる箇所を減らす意図もありました。
Imagickでは、ビルド時に参照したImageMagickと、実行時に読み込まれるImageMagickが一致しないという警告も出ました。記録上はバージョンコード1692と1693の不一致です。Imagickを再ビルドし、ビルド時と実行時のImageMagickがともに6.9.13-54で一致していることを確認しました。
PHP本体、PHP拡張、さらにその拡張が利用する外部ライブラリまで、組み合わせを確認する作業になりました。ここで確認できたのは当該警告の解消であり、サイト上のあらゆる不具合の原因を特定した、ということではありません。
緊急対応で確認する範囲を決め、残る作業を把握する
修正済みのPHPで動かし、発生した問題を直す進め方は、緊急時の選択肢になります。その場合も、改修によって本来の処理が変わっていないかを確かめる必要があります。購入、問い合わせ、管理画面、外部連携、定期実行処理などから、そのサイトの運営に必要な機能を選び、運営者と確認範囲を合わせます。
確認をどこまで行うかは、変更内容やサービスへの影響によって異なります。すべての機能を網羅できない場合には、確認した箇所と未確認の箇所を残します。今回の個別事例についても、全機能の網羅試験や、すべての脆弱性の解消を示すものではありません。互換性のための改修が広範囲に及ぶようなら、限定的な調整を続けるより、EC-CUBE本体の更新やカスタマイズの作り直しを検討することになります。
不具合が出た場合の切り戻しも、脆弱な旧環境に戻してそのまま公開を続ける前提にはできません。停止やアクセス制限を含め、どう運用するかを事前に決めておきます。WAFやリクエストサイズ制限は対策を重ねる手段ですが、修正版の適用を置き換えるものではありません。
また、今回PHP8.2へ移行した環境では、次の更新までに使える期間にも限りがあります。PHP8.2のPHP本体によるセキュリティサポートは2026年12月31日までです。この対応は、次のEC-CUBE・PHP更新につなげる暫定対応として位置づけています。［1］
対応中にも、追加の案内が出ている
10月23日には、PHP公式からセッションのアップロード進捗機能に関する追加案内が出ました。特定の設定と実行時のセッション処理の変更が組み合わさる場合の問題で、CVE-2026-115560として次回リリース時に詳細を公開する予定としています。当面の案内として、この機能の無効化が提案されています。［1］
当初の2件への修正と、この追加案内の条件は分けて確認する必要があります。すでに修正版を適用した環境でも、追加で示された条件に当てはまるかを確認する作業が残ります。
環境ごとに、適用できる修正と保守の続け方を考える
同じ脆弱性への対応でも、利用できる修正パッケージや既存機能への影響、その後の保守によって選ぶ方法は変わります。現在の構成を確認すれば、すぐに適用できる対処と、まとまった改修が必要な部分を分けて考えられます。
関連ページと参考情報
IT業界歴27年、デザイナーとしてキャリアを始め、デザイン・プログラミング・コンサルを統合したアプローチを提供。幼少期からのプログラミング経験で複数言語・独自フレームワークに精通。年商億超えECサイト運営会社2社の経営を通じ、戦略立案や運営ノウハウを培いました。EC-CUBE公式インテグレートパートナーとして、EC構築・カスタマイズ・運営を一貫サポートし、ビジネス成長に貢献します。
