【ITニュース解説】No Patch Is Coming: PHP 7.4, 8.0 and 8.1 After PHP2Shell

インターネット上で広く利用されているプログラミング言語であるPHPに、極めて深刻なセキュリティ上の欠陥が見つかった。これはWebサイトやWebサービスを動かすサーバー上で、悪意のある第三者が許可なくプログラムを実行できてしまうという重大な問題だ。この種の脆弱性は「リモートコード実行」と呼ばれ、システムを乗っ取られたり、機密情報が盗まれたりする危険性があるため、セキュリティの専門機関から緊急の警告が発せられている。具体的には、CVE-2026-109618とCVE-2026-109619という二つの脆弱性が報告され、その危険度を示すCVSSスコアは9.2とされており、これは最高レベルに近い非常に高い評価だ。

この深刻な脆弱性に対処するため、PHPの新しいバージョンである8.2.35、8.3.36、8.4.27、8.5.12に対しては、緊急の修正プログラム（パッチ）が提供された。これらのバージョンを使っているユーザーは、比較的簡単な作業でサーバー上のPHPを最新の状態にアップデートすることで、この問題を解決できる。しかし、PHPの古いバージョンである7.4、8.0、8.1を使っているシステムには、この修正プログラムが一切提供されない。今後も提供される予定はない。これは、これらの古いPHPバージョンを使い続けているWebサイトやサービスが、この深刻なセキュリティの脅威に常に晒され続けることを意味する。

今回発見された脆弱性はPHPの核心部分に存在し、WebサーバーでPHPを動かす一般的な方法、例えばmod_phpやPHP-FPM、php-cgiなど、ほとんど全ての環境に影響する。さらに、この二つの脆弱性の公表からわずか二日後には、別の三つ目の脆弱性（CVE-2026-115560）も明らかになった。これにはまだ公式な修正プログラムは出ていないが、一時的な対策として、PHPの設定ファイル（php.ini）に「session.upload_progress.enabled = 0」という一行を追加することで、ある程度の緩和が期待できる。

この状況において、PHPを使い続けるシステム管理者が直ちに行うべきことはいくつかある。まず第一に、現在利用しているPHPのバージョンを確認し、もし8.2以降のパッチが提供されたバージョンであれば、速やかに最新の修正済みバージョンへとアップデートすることだ。次に、三つ目の脆弱性への対策として、先述のsession.upload_progress.enabled = 0という設定を、Webサイトが実際に利用しているPHPの設定ファイルに適用し、それが正しく機能しているかを必ず確認することだ。PHPには複数の設定ファイルが存在することがあり、間違ったファイルに設定しても意味がないため、注意が必要だ。

また、レンタルサーバーやクラウドサービスを利用している場合は、サービス提供元が「PHPをアップデートしました」とアナウンスしていても、それを鵜呑みにせず、実際に自分のWebサイトが動いているPHPのバージョンが最新のものになっているか、そして設定が正しく適用されているかを自分で確認する必要がある。そして、Webサーバーだけでなく、裏で定期的にプログラムを実行している「cronジョブ」や、バックグラウンドで処理を行う「キューワーカー」、あるいは「Dockerコンテナ」といった環境でPHPが使われている場合も、それら全てのPHPのバージョンを確認し、アップデートの対象に含めることが重要だ。これらの見落とされがちな環境も、攻撃の足がかりとなる可能性があるからだ。

しかし、PHP 7.4、8.0、8.1というサポートが終了したバージョンを利用しているシステムにとっては、これらの緊急対応では根本的な解決にはならない。なぜなら、今回の脆弱性に対するパッチがそもそも提供されないため、アップデートによる修正ができないからだ。これは単なる「セキュリティ上の問題」というよりも、「技術的負債」と呼ばれる、より根深い問題を示唆している。つまり、開発元からの公式なサポート期間が終了したソフトウェアを使い続けると、今回のように新たな脆弱性が発見されても、公式な修正プログラムが提供されなくなり、常にリスクに晒されることになるのだ。その場しのぎの対策で対応できる場合もあるが、それも万能ではない。

このような状況に直面したとき、システム管理者が問われるのは、「システム全体をどうするか」という大きな問いだ。選択肢としては、大きく二つある。一つは「バージョンジャンプ」と呼ばれ、PHPのサポートされている最新バージョンへとシステム全体をアップグレードすることだ。もう一つは「スタックジャンプ」と呼ばれ、PHPから別のプログラミング言語や技術基盤（スタック）へと、システム自体を完全に移行してしまうことだ。

どちらの選択肢を選ぶべきかは、そのシステムがどのような状況にあるかによって変わってくる。判断のポイントはいくつかある。まず、「システムの規模」。Webサイトにどれくらいの機能があり、どれくらいの数のページや外部サービスとの連携があるかだ。機能が多いほど移行は複雑になる。次に「コードの内容」が重要だ。Webサイトのコードの大部分が、汎用的なフレームワーク（開発を助ける土台）を使った「糊（のり）」のような部分か、それともそのWebサイト独自の複雑な「ビジネスルール」（特定の業務処理に関するプログラム）が大量に書かれているかだ。ビジネスルールが多いほど、それを別のシステムに移植するのは難しく、コストもかかる。

また、「テストの有無」も大きな要素だ。もし、システムが正しく動作するかどうかを自動で確認できる「テストスイート」が十分に整備されていれば、新しいバージョンや新しい技術基盤への移行は比較的スムーズに進められる。しかし、テストが全くない場合、古いシステムが唯一の「仕様書」となるため、移行後に問題が発生しないかを一つ一つ手作業で確認する必要があり、非常に労力がかかる。最後に、「システムを知る人の有無」も重要だ。もし、そのシステムを開発した人がすでに退職しており、詳細なドキュメントもない場合、システムの内部を理解するのに時間がかかり、移行作業はさらに困難になるだろう。

もし、現状のシステムを全面的に書き換える「リライト」が必要だと判断された場合、その進め方には現実的なアプローチがある。まずは、時間をかけて現在のシステムを詳しく分析し、新しいシステムへの移行にかかるコストと期間を正確に見積もることが重要だ。そして、一度に全てを新しいシステムに切り替える「ビッグバン」方式はリスクが高いため、避けるべきだ。推奨されるのは「ストランギュラーパターン」という手法で、古いシステムを稼働させながら、新しい機能やシステムの一部を徐々に開発し、古いシステムと置き換えていく方法だ。これにより、リスクを最小限に抑えながら移行を進めることができる。

移行の際には、データ構造、支払い処理、ユーザー認証といった、最も重要でシステムの中核をなす部分から優先的に着手すると良い。これらはシステム全体の土台となり、もし問題が発生すれば金銭的な損失やセキュリティ上の重大な影響が生じる可能性があるからだ。そして、もしテストが不十分な場合は、古いシステムを「仕様書」として稼働させ続け、新しいシステムが古いシステムと同じ結果を出すかを確認しながら開発を進めるべきだ。これにより、文書化されていない「隠れたビジネスルール」を発見し、新しいシステムに正確に反映させることができる。

このような大規模な移行作業は、短期間で終わるものではない。小さなシステムであれば数日で移行できることもあるが、大規模なシステムであれば、計画的に数週間から数ヶ月を要するプロジェクトとなるだろう。しかし、重要なのは、このような作業を緊急事態としてではなく、計画的なシステム運用の一部として捉えることだ。サポート期間の終了は事前に公表されているため、それに合わせて計画的にシステムのバージョンアップや移行を進めることができれば、今回のような緊急対応に追われることなく、常に安全で安定したシステムを維持できるはずだ。古いシステムを放置すればするほど、将来の移行コストは膨れ上がり、そのリスクも増大する。