PHPの重大な脆弱性2件とサポートが終わったPHP。修正版が届くまでの確かめ方と対応の進め方

2026年10月21日(日本時間23時)、PHPの開発チームが重大な脆弱性2件を修正した版を公開しました。その約1時間前には、高市早苗首相が自身のXで、修正版を速やかに適用できるよう準備することを求めています。ITmedia NEWSの報道によると、首相は、適用が難しい場合にはWebサイトなどを一時的に止めることもリスクを下げる有効策の一つだと述べています。

ただ、修正版が公開されても、自社のサーバーで修正版が動いているとは限りません。正式な修正版はサポート中の8.2〜8.5にしか出ておらず、W3Techsの集計では、PHPを使うWebサイトの約35%がまだ7系以前のままです。サポート中の版でも、PHPをDockerのイメージで入れたか、OSのパッケージで入れたかによって、修正が届く時期と当て方が変わります。自社のPHPに修正がいつどの経路で届くかを確かめる手順と、届かない場合の対応を整理します。

公表された内容

PHPの公式サイトのセキュリティアドバイザリーによると、修正された脆弱性はCVE-2026-109618とCVE-2026-109619の2件です。深刻度はどちらも共通の評価基準であるCVSS v4.0で9.2(10点満点)とされ、悪用されると、ログインなどの認証を経ずに外部からサーバー上で任意のプログラムを実行されるおそれがあります。対象はPHP-FPM、Apacheのモジュール(mod_php)、php-cgiなど、Webサーバーからの要求を処理しているPHP全般で、公式はmod_phpで動かしている場合の危険がもっとも高いとしています。

国内では10月22日に、IPA(情報処理推進機構)が対策の呼びかけを、JPCERT/CCが注意喚起を出しました。IPAは、調査に関わったWiz社の見方として、PHP 5.4以降の版は少なくとも一方の脆弱性の影響を受けると紹介しています。

修正が提供される範囲

PHPのサポート方針では、各版は最初のリリースから2年間すべての不具合を修正し、その後の2年間は重大なセキュリティ問題だけを修正します。今回の修正の提供状況は次のとおりです。

7.4・8.0・8.1向けの最小限の修正は、PHPのセキュリティチームが深刻さを踏まえて例外として公開したもので、ソースコードからPHPを自分でビルドする人を対象にしています。そのまま入れられる正式な版ではなく、次回以降も出すかどうかは示されていません。8.2も、2027年以降に同様の脆弱性が見つかった場合は修正版が出ません。

修正が届く経路と時期

最初に確かめるのは、本番環境で動いているPHPの版と、そのPHPをどこから入れたかです。php -v で版は分かりますが、コマンドで動くPHPとWebサーバーから呼ばれるPHPが別の版になっていることがあるため、Webサーバーの設定でどのPHPを使っているかも確認してください。保守を外部に委託している場合は、委託先にPHPの版と入れ方、動かし方(Apacheのモジュールか、PHP-FPMか)、フレームワークとその版を確認していただくのが確実です。

Dockerの公式イメージを使っている場合：
php:8.2-fpm などの公式イメージは、修正の公開から8〜10時間ほどで8.2.35などに入れ替わりました。注意が必要なのは、php:8.2-fpm のようなタグの中身が後から差し替わる点です。作り直す端末に古いイメージが残っていると、docker compose build --no-cache を実行しても古いイメージのまま作り直されます。ビルド時に --pull を付けるか、FROM php:8.2.35-fpm のように版の番号まで固定してください。コンテナを作り直したあとは、コンテナの中で php -v を実行して修正版になったことを確かめます。

OSのパッケージを使っている場合：
修正版のパッケージは、OSの提供元が作って配布します。Red Hatのように、修正を当てても版の番号を変えないバックポートの方式をとる提供元もあるため、版の番号ではなく提供元のセキュリティ情報で修正の有無を確かめます。OSがサポート中でも、付属のPHPが修正されるとは限りません。Amazon Linux 2023では、php8.2〜php8.5 向けに10月22日付で修正版が出た一方で、php8.1 は「修正予定なし」とされています(Amazon Linuxのセキュリティ情報)。パッケージを更新したあとは、PHP-FPMやApacheを再起動するまで古いプログラムが動き続けます。

外部のリポジトリから入れている場合：
Red Hat系のOSで新しいPHPを入れるためによく利用されるremiリポジトリ(rpms.remirepo.net)について、公式は当日の更新はないとし、OSの提供元のパッケージへの切り替えか、ソースコードからのビルドを検討するよう求めています。

レンタルサーバーや製品に組み込まれている場合：
レンタルサーバーは管理画面で版を確かめ、提供元の告知で対応状況を確認します。PHPを組み込んだソフトウェア製品やネットワーク機器も影響を受けうるため、開発元の告知を確認してください。

修正版を当てるまでの対処

修正が届くまでの間や、8.1以前で修正が届かない場合は、公式が示した設定の変更で、確認されている攻撃の経路を塞げます。ただし公式は、根本的な解決は更新だけであり、これらの設定では安全な状態にならないと明記しています。

• CVE-2026-109619には、session.upload_progress.enabled=0 を設定し、PHPのワーカーをすべて再起動します。リクエストを読み込む前に効かせる必要があるため、設定は php.ini、PHP-FPMのプール、Webサーバーの設定のいずれかに書きます。プログラムの中の ini_set() や .user.ini では効きません。.user.ini しか変更できないレンタルサーバーでは、提供元の対応を確かめることになります
• CVE-2026-109618には、memory_limit=-1 と、受け付けるリクエストの大きさの制限が示されています。メモリの上限をなくすと大きな要求でサーバーのメモリを使い切るおそれがあるため、リクエストの大きさはWebサーバーやその手前のプロキシでも制限し、保守の担当者と相談のうえで決めてください

あわせて、社内向けの管理画面や古い試験用の環境が外部から開ける状態になっていないかを見直します。IPAは、必要に応じて外部からのアクセスの遮断やサービスの一時停止も判断するよう求めています。

侵入されていないかの確認も必要です。修正版の公開当日には、悪用を試みる通信を観測したと発表した調査会社もあります。JPCERT/CCは侵入の痕跡として、異常に長い、または不正な形式の PHPSESSID のCookie、不審な multipart/form-data のリクエストの前後に出たメモリ上限のエラーやHTTP 500、PHPのワーカーの予期しない終了や頻繁な再起動を確かめるよう勧めています。痕跡が残らない攻撃もあるため、見つからなくても被害がないとは言い切れないとしています。

対応の優先順位

複数のシステムを抱えている場合は、修正の届き方に加えて、次の2点で並べると手を付ける順番を決めやすくなります。

誰でも開けるか：
WAFや接続元の制限がなく、誰でも開ける画面を持つシステムが先です。一般の人が使う申込フォームのように、接続元を絞れない画面はとくに優先します。

乗っ取られたら何に届くか：
同じ脆弱性でも、乗っ取られたサーバーから届く範囲によって被害の大きさが変わります。次の点を確かめておくと、更新の順番だけでなく、当面の対処で何を絞るべきかも分かります。

• サーバーに付けたクラウドの権限が、ファイルの保存先全体を読み書き・削除できるなど、必要以上に広くないか
• 同じネットワークにあるデータベースや別のシステムに、そのサーバーから接続できないか
• 環境変数や .env などの設定ファイルに、別のシステムのAPIキーやパスワードが入っていないか
• アプリケーションのログに、氏名や電話番号などの個人情報がそのまま書かれていないか
• ファイルの保存先やデータベースへのアクセスの記録が残り、何を読まれたかを後から確かめられるか

カード決済の画面には別の注意が必要です。カード番号をブラウザで決済代行会社のトークンに変え、サーバーに通さない構成でも安心はできません。攻撃者がサーバーを乗っ取れば入力画面のプログラムを書き換えられるため、トークンに変わる前の番号を抜き取られるおそれがあります。

保守を請け負う会社では、こうした項目をシステムごとに一覧にし、修正を当てれば済むもの、当面の対処をしながらPHPの更新を計画するもの、フレームワークの移行まで必要なものに分けておくと、お客様に予算のご判断をお願いするときの材料になります。

新しい版への更新にかかる手間

根本的な対処は、サポートが続いている版へPHPを上げることです。これから上げるのであれば、2026年末でサポートが終わる8.2ではなく、8.3以降を目標にするとその後の期間を確保できます。

ただし、PHPの版を上げると、それまで動いていたコードが動かなくなることがあります。とくに8.0で仕様が大きく変わったため、今の版が古いほど手間は大きくなります。

フレームワークの対応

使っているフレームワークが新しいPHPに対応していなければ、PHPだけを上げることはできません。見落としやすいのは、PHPを修正版にできても、フレームワーク自体のセキュリティ修正が終わっている場合です。広く使われているLaravelでも、10と11はすでにセキュリティ修正の期間を過ぎています。

Laravelの期限は公式のサポート方針によります。たとえばPHP 8.2とLaravel 10で動くシステムは、今回はPHPの修正版を当てられますが、フレームワークにはすでにセキュリティ修正が出ず、PHPのサポートも2026年末で終わります。Laravelは公式が版の間の変更を小さく抑える方針を示しているため、10や11から12以降へ上げる場合も、周辺のパッケージの更新は必要ですが、別のフレームワークへ移すほどの規模にはならないことが多いでしょう。一方、FuelPHPやCakePHP 2で動くシステムは、PHPを8.3以降に上げるにはフレームワークごと別のものへ移す必要があります。それぞれの事情と移行先の選び方は、FuelPHPのサポート終了とLaravelへの移行とCakePHP 2の移行先の選び方で解説しています。

当社のPHPの移行事例

フレームワークごとの移行は、PHPの版を上げるだけの作業より規模が大きくなります。当社は、サポートが終わったFuelPHPで動いていた基幹システムを、AIを使ってPHP 8系とLaravel 12へ移行した実績があります。株式会社ウイズ・ワン様と共同で行った案件です。

コードの解析と変換、新旧の動作を比べる自動テストをAIが担い、その成果物のレビュー、業務知識に基づく受入テスト、本番移行の判定を人が担当しました。AIによる変換は繰り返し実行できるため、移行の作業中に既存システムへ入った改修にも追従できます。案件の詳細はFuelPHPからLaravelへの移行事例で、作業を分けて並行して進める手順はAIマイグレーションの進め方で紹介しています。

CakePHPなど、FuelPHP以外のフレームワークからの移行は、まだ公開できる事例がありません。その場合は、実際のコードの一部を先にサンプル変換し、AIによる変換が適用できるかを確かめてから、次の工程へ進むかをご判断いただく進め方にしています。

まとめ

まず、本番環境のPHPの版と、そのPHPをどこから入れたかを確認してください。Dockerのイメージなら作り直したあとにコンテナの中で版を見て、OSのパッケージなら提供元のセキュリティ情報で修正の有無を確かめたうえでPHP-FPMなどを再起動します。8.1以前や、修正が届かないパッケージであれば、session.upload_progress.enabled=0 などの当面の対処と公開範囲の見直しをしながら、新しい版への更新を計画します。

そのうえで、8.3以降のPHPとフレームワークの組み合わせまで見て、更新で済むのか、フレームワークの移行が必要なのかを判断します。複数のシステムを抱えている場合は、誰でも開ける画面を持つシステムと、乗っ取られたときに個人情報や決済に届くシステムから順に進めてください。

DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえソースコードをお預かりし、無料精密診断を行っています。古いPHPで動くシステムであれば、コードの修正の範囲と、フレームワークの移行まで必要になるかの見立て、概算費用をまとめてご提示します。保守を請け負っている会社からのご相談もお受けしています。

AIマイグレーションサービスの内容と進め方

よくある質問

Q. 社内だけで使っているシステムでも対応は必要ですか？

公式は、Webサーバーからの要求を処理しているPHPを広く対象に挙げています。外部に公開していないシステムは攻撃を受ける経路が限られるため、外部に公開しているシステムを先に対応し、社内のシステムをその後に回すという順番を付けることは可能です。ただし、社内のネットワークに入られた場合の経路は残りますので、対応しなくてよいとは言えません。