2026年のPHPの脆弱性：影響を受けるWebサービスの確認と修正方法

アラームメッセージを正しく把握する

「PHPのセキュリティ脆弱性が『インターネットの半分』に影響を及ぼす可能性がある」という主張は、注目を集めるための誇張された表現ではあるが、裏付けのある規模を示すものではない。 インターネット上のサービスの半数が脆弱である、あるいはすでに侵害されているという証拠は存在しません。とはいえ、PHPは多くのウェブサイト、オンラインショップ、API、管理画面で実行環境として採用されているため、実際のリスクは依然として甚大です。.

重要なのは、ウェブサイトがPHPを使用しているかどうかではなく、そのウェブリクエストを処理するPHPのバージョンがどれかということです。2026年10月21日のセキュリティアップデートは、サポート対象のブランチのパッチが適用されていないインストール環境のうち、ウェブサービス経由でリクエストを処理しているものすべてに影響を及ぼします。 したがって、開発作業用のローカルPHP環境と、外部からアクセス可能な顧客ポータルとは、別個に評価する必要があります。.

仝 インターネット上での露出 緊急性が決定的な要因となります。 フォームやファイルアップロード機能を備えた、一般に公開されているショップは、閉鎖的な社内サービスよりも多くの接触ポイントを生み出します。しかし、社内サービスであっても自動的に安全であるとは限りません。VPN経由のアクセス、乗っ取られたアカウント、あるいはネットワーク内の他のシステムによって、外部からアクセス可能になってしまう可能性があるからです。したがって、リーチが広いという理由だけで、技術的なリスク評価を省略することはできません。.

同様に重要なのが動作モードと パッチスタンド. PHPは、例えばPHP-FPMを介して、Apacheモジュールとして、php-cgi経由で、あるいは製品に組み込まれた形で動作させることができます。 同じサーバー上の複数のドメインでも、PHPのバージョンや更新方法が異なる場合があります。すべてのPHPウェブサイトに対して一律に「安全」と断言することは、すべてのインストール環境が即座に攻撃を受けると想定することと同様に誤りです。.

PHPの脆弱性が技術的に可能にするもの

A リモートコード実行 (RCE)とは、特定の条件下で攻撃者がリモートシステム上でコードを実行できることを意味します。セキュリティ情報によると、これらのPHPの脆弱性では、事前のログインは不要です。コードはまずWebプロセスの権限で実行され、自動的に無制限の管理者権限で実行されるわけではありません。 したがって、想定される影響は、ファイルの権限、アクセス情報、およびサーバーの分離状況に大きく左右されます。.

CVE-2026-109618 は、以下のバグパスに関連しています。 記憶容量の不足. PHPがメモリ不足の状態によりリクエストを中断した場合、内部データ構造が不完全なまま残る可能性があります。リクエストのクリーンアップ時にそのような状態が再利用されると、メモリ破損が発生する可能性があります。 公式の説明では、特にマルチパートリクエスト、ファイルアップロード、およびネストされた入力の解析時のメモリ消費量が、関連する技術的背景として挙げられています。.

一方、CVE-2026-109619は、リクエストに紐付いた内部状態に影響を及ぼすもので、そのメモリはすでに解放されています。その後、再利用されたワーカーが別のリクエストを処理する場合、PHPは通常の初期化が適用される前に、この古い状態にアクセスしてしまう可能性があります。 このセキュリティアドバイザリでは、セッションのアップロード進捗やエラー処理フローなどが言及されています。これはエラーの分類を説明したものであり、悪用方法の解説ではありません。.

• この問題の影響を受ける可能性があるのは、PHP-FPM、mod_php を使用した Apache、php-cgi、FrankenPHP、および LiteSpeed 経由の Web リクエストです。.
• エラーの原因はPHPのランタイムにあり、WordPress、Joomla、Shopware、テーマ、あるいは個々のプラグインそのものにあるわけではありません。.
• CMSやフレームワークは、ファイルのアップロードなど、実現可能な機能に影響を与えますが、インタプリタの更新に代わるものではありません。.

なぜすべての設備が同じように危険にさらされているわけではないのか

サービスが実際に危険にさらされているかどうかは、複数の要因によって決まります。最優先されるのは、パッチが適用されていないPHP Webランタイムと、外部からアクセス可能なWebサービスです。次に、稼働モード、再利用されるプロセス、アップロード機能や複雑なフォーム、およびWebプロセスアカウントの権限が挙げられます。 Webファイルへの広範な書き込み権限を持つサービスや、他のサービスへのアクセス権を持つサービスは、厳格に隔離されたプロジェクトよりも深刻な影響を及ぼす可能性があります。.

Apacheでは、 mod_php PHPプロジェクトは、このリスクに特に焦点を当てています。文書化されている攻撃の中には、実際のアプリケーションコードが実行される前に引き起こされるものもあるからです。 その場合、適切にメンテナンスされたCMSであっても、実行時の脆弱性から保護することはできません。これは、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedが安全であるという意味ではありません。これらがパッチ未適用の状態にある場合も、同様に優先的に検査する必要があります。.

また、以下の特徴を持つ製品には特に注意が必要です。 埋め込みPHP. これには、コンテナイメージ、アプライアンス、NAS管理ツール、あるいはPHPを内部で利用しているネットワーク製品などが含まれます。こうした環境では、ホスト上でコマンドを実行しても、実際に使用されているランタイムが反映されないことがよくあります。また、オペレーティングシステムの更新を行っても、イメージやベンダー製品に含まれる脆弱なPHPコンポーネントが自動的に修正されるわけではありません。.

ファイアウォール、Webアプリケーションファイアウォール、あるいは厳格なアップロード制限は、個々のリクエストを困難にし、攻撃対象領域を限定することができます。しかし、これらはインタープリタ内の不適切なメモリ管理や状態管理を修正するものではないため、修正プログラムの代わりにはなりません。 たとえバグのないCMSであっても、安全な実行環境に依存しています。したがって、実際にWebリクエストを処理するPHPのパッチ適用状況を確認し、更新することが極めて重要です。.

パッチの適用状況とサポート状況を比較する

これら2つのセキュリティ脆弱性については、まず導入されているPHPブランチ内のパッチ状況が重要となります。PHPプロジェクトでは、サポート対象のシリーズごとに具体的な修正済みリリースを指定しています。 同じシリーズの以前のパッチ状態は影響を受けるとみなされます。指定されたバージョン、またはそのブランチのそれより新しいバージョンへのアップグレードが、推奨される完全な対策となります。.

A パッチの更新 同じ開発シリーズ内での更新であり、例えば8.3.35から8.3.36への更新のようなものです。 これはセキュリティ修正を提供することを目的としており、8.2から8.4への移行に比べて互換性の範囲が狭くなっています。後者は移行作業にあたるため、依存関係、拡張機能、アプリケーションコード、および必要に応じてデプロイメントについても個別に検証する必要があります。.

PHP 8.2は、バージョン8.2.35以上が動作している限り、緊急の修正には引き続き使用可能です。 ただし、このブランチは2026年12月31日にサポート終了となります。そのため、この緊急アップデートで運用を留めておくべきではありません。適切な環境でアプリケーションの互換性を確認した後、サポート期間がより長いブランチへの移行を計画してください。.

PHP 8.1 以前のバージョンについては、特に注意が必要です。PHP プロジェクトはこれらに対して定期的な最新リリースを提供しておらず、最小限のソースコードのバックポートは、一般に利用可能でメンテナンスされているパッケージと同等とは見なされません。 OSベンダーによって文書化されたセキュリティバックポートは適切である可能性がありますが、セキュリティアドバイザリまたはパッケージの変更履歴における裏付けが必要です。それが欠けている場合は、単なるバージョンの表面的な変更ではなく、移行が必要となります。.

実際のWeb実行時間を確認する

バージョン確認は現状把握から始まりますが、シェルだけで終わらせてはいけません。 自己管理サーバー上では、以下のコマンドを実行することで、そのサーバーで呼び出されたPHPコマンドのバージョンと、その呼び出しによって検出された設定ファイルを確認できます。これらはパッケージや設定を変更しないため、リスクの低い最初の確認手順として適しています。.

php -v
php --ini

この出力には、このシェルコマンドで呼び出されたもののみが記述されています CLIの実行時間. 。一方、Webサイトは、PHP-FPM、mod_php を使用した Apache、php-cgi、あるいはコンテナを通じて動作させることができます。このWebランタイムは、コマンドとは異なるPHPバージョンや設定ファイルを使用することがあります。 php -v ホスト上で。セキュリティ評価においては、実際のHTTPリクエストを処理するプロセスが重要となる。.

そのため、マネージドホスティングでは、顧客パネルでプロジェクトまたはドメインごとに選択されたPHPバージョンを確認し、必要に応じて提供されているサービスのパッチ適用状況を確認してください。 複数のドメインがある場合は、各割り当てを個別に確認する必要があります。メインドメインではすでにパッチが適用されたブランチが使用されている一方で、オンラインショップ、ステージング環境、またはサブドメインでは、まだ古いインタープリタが使用されている可能性があるからです。.

PHP-FPM を実行しているサーバーでは、サービス設定、パッケージ構成、およびデプロイメント関連のドキュメントは一体のものとして扱う必要があります。 コンテナ環境では、ローカルのビルドマニフェストだけでなく、実際にデプロイされたイメージも確認する必要があります。重要なのは、実行中のポッドまたはコンテナがどのリビジョンでWebリクエストを受け付けているかという点です。ベースイメージを更新しても、すでに実行中の古いインスタンスは保護されません。.

運転モードに応じた更新経路の計画

適切な更新方法は、インタープリタを提供する主体と、それがどこで稼働しているかによって異なります。この責任範囲が明確になって初めて、パネルの交換、パッケージの更新、新しいイメージ、あるいはメーカーによる更新のいずれが必要かを確実に判断することができます。 以下の分類では、リスクの観点から運用モードを同一視することなく、これらのケースを区別しています。.

共有ホスティングの場合、プロバイダーは選択されたPHPシリーズの安全なパッチ状態を提供すべきであり、その後、運用担当者がアプリケーションを確認します。PHP-FPMやmod_phpの場合、通常、管理者がパッケージを更新し、その後、実際に担当するサービスを制御された状態で再起動します。 修正プログラムを適用せずに単に再起動するだけでは、更新の代わりにはなりません。.

Linuxディストリビューションは、セキュリティ修正をしばしば バックポート. その場合、修正が含まれているにもかかわらず、表示されるパッケージのバージョン番号がphp.netのリリース情報と異なることがあります。したがって、「8.4.26」のような文字列を単純に比較するだけでなく、ディストリビューターのセキュリティ情報と変更履歴を確認してください。 PHPプロジェクトは、ディストリビューションやLTSプロバイダーがパッチを受け取ることができると指摘しています。.

コンテナには独自の処理手順が必要です。修正済みのイメージをビルドするか、プロバイダーから入手し、それを展開して古いインスタンスを置き換える必要があります。一方、NASのインターフェース、ネットワーク機器、または完成済みのWebアプリケーションの場合、修正はメーカー側の製品に委ねられます。 ホストOSのパッチが、必ずしも組み込みのインタプリタに適用されるとは限らないため、資産管理とメーカーからの通知は依然として不可欠である。.

誤った安心感を与えない緊急対策

パッチ適用日には、まず堅牢なインベントリを作成します。対象となるのは、ドメイン、API、管理インターフェース、コンテナ、およびPHPが組み込まれている可能性のある製品です。各サービスについて、Webの運用モード、担当する更新経路、実際に使用されているPHPランタイムを記録してください。 その後、バージョン番号が最も目立つサーバーだけでなく、一般に公開されているサービスやビジネスに不可欠なサービスすべてを優先的に処理します。.

その後、ホスティング事業者、Linuxディストリビューター、イメージまたは製品メーカーがリリースしたセキュリティアップデートを適用してください。サポート対象のPHPブランチについては、修正済みのパッチ状態への更新が完全な対策となります。WAF、アップロードルール、またはWebサーバーの再起動では、これを代替することはできません。 この作業は、パッケージ、イメージ、またはベンダーによる更新内容が明確に文書化され、問題が発生した際に追跡できるよう計画してください。.

更新後は、以下の操作を行う必要があります。 すべての旧ワーカー 終了させ、パッチが適用されたランタイムを確実に読み込んだことが確認されたプロセスに置き換えてください。リロードは、具体的なサービス管理がこの完全な置換を保証する場合にのみ使用してください。そうでない場合は、制御された再起動が必要です。 その後、単に置換が行われたと仮定するのではなく、プロセスの起動時刻、サービスのステータス、または内部で検出されたWebランタイムを確認してください。コンテナの場合は、修正済みのイメージを展開し、古いインスタンスをすべて削除してください。.

その後、ログイン、フォーム、ファイルのアップロード、チェックアウト、API などの主要なアプリケーションの経路を確認してください。 これらのテストにより、アプリケーションおよび拡張機能が最新のパッチ適用状態で正常に動作するかどうかが確認できますが、それだけでは、ワーカーの完全な入れ替えや、過去の侵害の有無を証明するものではありません。これらの点は、運用およびセキュリティ監査を通じて個別に評価する必要があります。.

パッチの適用が直ちに行えない場合、個別の設定によって既知の攻撃経路を制限することは可能ですが、完全なセキュリティを確保することはできません。アップロードの進行状況表示を無効にする設定は、リクエストの解析が行われる前に有効になっている必要があります。 事前に、アプリケーションやインターフェースがこの進行状況表示を必要としているかどうかを確認し、その後、関連するすべてのPHPワーカーを再起動してください。その後、以前の設定のまま動作し続けている古いプロセスがないことを確認してください。.

session.upload_progress.enabled = 0

POSTデータの厳格な制限や、セキュリティ通知に記載されているその他のオプションも、攻撃対象領域を部分的にしか縮小できません。遅れて読み込まれる .user.ini-ファイル、または ini_set() アプリケーション内での対策だけでは、この設定には不十分です。こうした措置は一時的なリスク低減策として扱い、セキュリティアップデートの実施を目標として堅持してください。.

これとは区別されるのが、保存されたセッションの通常の管理である。本稿では、 PHPセッションのガベージコレクション 通常の運用において、クリーンアップ、ファイルアクセス、およびワーカーがどのように連携するかを説明します。ただし、この運用上の最適化は、ここで取り上げた脆弱性を解消するものではなく、修正済みのPHPパッチの適用や、その後実行中のプロセスを置き換える作業に代わるものでもありません。.

パッチ適用後、稼働状況と異常の有無を確認する

パッケージの更新が正常に完了したとしても、それはあくまでファイルやパッケージがインストールされたことを示すに過ぎません。ウェブプロセスが新しいランタイムを読み込んだこと、あるいはアプリケーションがそれを使って正常に動作していることを保証するものではありません。 したがって、再起動後は、当該サービスに関連するWebランタイムを確認し、日時、バージョン、再起動されたサービス、および機能チェックの結果を記録してください。.

機能テストでは、実際の主要な業務プロセスを網羅する必要があります。具体的には、重要な公開ページ、ログイン・ログアウト、フォーム送信、ファイルアップロード、チェックアウトや予約、さらにはAPIエンドポイントやバックグラウンドタスクなどが挙げられます。 権限のある操作のみをテストし、本番環境のショップでは可能な限り、その目的のために用意されたテストデータを使用してください。並行して、Webサーバー、PHP、およびアプリケーションのログを確認し、新たなエラー、繰り返されるクラッシュ、または予期しないステータスコードがないかチェックしてください。.

持続可能なプロセスを確立するためには、新たなスタートが必要であり、 労働者 更新されたコードを読み込むことはできますが、それ自体では修正は行われません。アップデートを適用しない限り、脆弱性は残ったままとなります。負荷が高い場合は、リクエストが順序よく処理され、ワーカーの再起動による影響を監視できるよう、メンテナンスウィンドウを適切に設定する必要があります。.

制御された再起動がスループットに与える影響の大きさは、PHPプロセスの数と負荷状況によって異なります。計画を立てる際には、プロセスを無計画に終了させるのではなく、キュー、実行中のジョブ、および重要なトランザクションを考慮に入れることが役立ちます。ガイド PHPのワーカーについて理解する 並列動的クエリにおけるこれらのプロセスの役割について説明します。.

パッチ適用後に異常が発生した場合は、アプリケーションの互換性エラーとロールアウトの不完全さを区別してください。設定、有効化されている拡張機能、およびWebランタイムを、メンテナンス前の状態と比較してください。 ロールバックを行った結果、一般に公開されているサービスが脆弱な状態のまま長期にわたり放置されることがあってはなりません。その場合は、互換性があり、パッチが適用された更新パスを速やかに確立してください。.

古く、隠れたPHPのインストール環境を優先する

PHPが意図的にインストールされたランタイムとして認識されないシステムには、特に注意が必要です。これには、Dockerイメージ、仮想アプライアンス、NASやネットワークインターフェース、および既製のソフトウェア製品などが含まれます。 ホストのアップデートを行っても、コンテナイメージや、ベンダー製品に内部的に組み込まれているランタイムは自動的に更新されません。そのため、ベンダーに対して、その製品に関する評価や、具体的な製品向けのセキュリティアップデートについて、個別に問い合わせる必要があります。.

古いブランチについては、3つのケースを明確に区別する必要があります。正規にサポートされているPHPリリースには、PHPプロジェクトが公開したセキュリティアップデートが提供されます。 ディストリビューションやベンダーによるバックポートは、表示上のバージョン番号が異なっていても修正が含まれている場合がありますが、そのベンダーのセキュリティ情報または変更履歴によって裏付けられている必要があります。 一方、自身でメンテナンスを行うソースコードについては、ビルド、テスト、運用に関する責任を自ら負う必要があり、正規のアップデートチャネルと同等の代替手段とはなりません。.

PHP 8.1 およびそれ以前のブランチには、今後、アップストリームからの定期的なリリースは行われません。 PHP 8.2 については修正済みのパッチが提供されていますが、このブランチのサポートは 2026 年末に終了します。差し迫った問題に対しては利用可能な修正プログラムを活用しつつ、古いバージョンやサポート終了間近のバージョンについては、さらにテスト済みの 移住 長期サポートが提供されるブランチへ。.

1. 特にファイルのアップロードや管理機能にアクセス可能な場合は、パッチが適用されていないPHPランタイムを使用している一般に公開されているサービスを、まず優先して更新してください。.
2. mod_php を搭載した Apache を使用し、その直後にビジネスに不可欠なオンラインショップ、API、または顧客ポータルを処理する場合、公式のセキュリティ通知では、mod_php に関して特に重大なリスクが指摘されています。.
3. イメージ、インベントリ、およびメーカーステータスに基づいて、コンテナ、アプライアンス、およびサードパーティ製品を把握する。目に見えるPHPパッケージが欠落しているからといって、安全だと判断してはならない。.
4. サポート対象外、あるいは速やかにパッチを適用できないサービスを隔離し、アクセスを制限すると同時に、代替策、アップグレード、または移行を確実に計画する。.

管理インターフェースに即座にパッチを適用できない場合、ネットワークのセグメンテーション、VPNの義務化、あるいは厳格なアクセスルールは、時間を稼ぐ手段となり得ます。しかし、これらはあくまで 移行措置, 、というのも、内部のユーザーアカウント、侵害されたデバイス、設定ミスのある共有設定などが、依然として攻撃の経路となり得るからです。製品に対して修正プログラムが提供されていない場合や、PHPのブランチが恒久的にサポート対象外となっている場合は、代替品への切り替えや移行が確実な選択となります。.