2026年10月21日、PHPの開発チームは2件の重大な脆弱性を修正する緊急アップデートを公開した。今回の問題は「PHP2Shell」と呼ばれ、悪用されると、攻撃者がログイン認証を突破せずにサーバー上で不正なプログラムを実行できる恐れがある。
脆弱性の深刻度は、いずれもCVSS v4.0で9.2。最も深刻な「Critical」に分類されている。影響するのはPHPを使用するWebサーバーであり、WordPressなどのCMSに加え、企業の業務システムや独自開発のWebアプリケーションも対象となる。
すでに修正版が公開されており、PHPの開発チームは速やかな更新を求めている。
PHP2Shellとは何か
PHPは、Webサイトの裏側で動くプログラミング言語である。ユーザーのログイン処理、データベースからの情報取得、フォームの送信、ページの生成など、さまざまな処理に使われている。
通常、ブラウザからWebサイトへアクセスすると、サーバーは送られてきたリクエストを解析し、必要に応じてPHPのプログラムを実行する。
今回問題となったのは、この処理を支えるPHP本体のメモリ管理である。
メモリの扱いに問題が見つかった
プログラムは動作中、必要な情報をメモリと呼ばれる一時的な保存領域に置いている。処理が終了すると、その領域は解放され、別の処理で再利用される。
ところが、今回の脆弱性では、処理中のエラーやメモリ不足をきっかけに、正しく準備されていないデータや、すでに解放された領域を参照してしまう場合がある。
こうした問題は、プログラムの異常終了だけでなく、メモリに残っていた情報の漏洩や、意図しないコードの実行につながる可能性がある。
今回確認された脆弱性には、それぞれ「CVE-2026-109618」と「CVE-2026-109619」という識別番号が付けられている。
2件の脆弱性は発生する仕組みが異なる
CVE-2026-109618は、メモリ不足が発生した際の後処理に関係する問題である。PHP内部で処理に必要なデータの準備が終わる前にメモリ不足が発生すると、不完全なデータを正常なものとして扱ってしまう可能性がある。
一方、CVE-2026-109619では、以前のリクエストで使用したメモリへの参照が、処理終了後も残ってしまう場合がある。同じPHPプロセスが次のリクエストを処理した際、すでに無効になった情報へアクセスする恐れがある。
どちらも、PHPの実行環境そのものに存在する問題である。そのため、Webアプリケーション側のコードに明らかな不備がなくても、PHPのバージョンや実行環境によって影響を受ける可能性がある。
なぜ深刻なのか
PHP2Shellで特に問題視されているのは、認証されていない外部の利用者から攻撃が成立する可能性がある点である。
通常、サーバー上でプログラムを実行するには、管理者権限や適切な認証情報が必要になる。しかし今回の脆弱性では、細工されたHTTPリクエストを送信することで、PHPの内部処理を悪用できる可能性がある。
HTTPリクエストとは、ブラウザなどからWebサーバーへ送られる通信である。ページの閲覧やフォームの送信、ファイルのアップロードなどで日常的に使用されている。
不正なコード実行や情報漏洩につながる恐れ
攻撃が成功すると、PHPを実行しているプロセスの権限で、不正なコードを動かされる可能性がある。
これをリモートコード実行（RCE）と呼ぶ。
被害の程度はサーバーの構成や権限設定によって異なるが、Webサイトの改ざん、保存情報への不正アクセス、マルウェアの設置などにつながる恐れがある。
また、今回の脆弱性ではメモリの不適切な参照も問題となっているため、機密情報の漏洩やサービスの停止なども想定される。
ただし、脆弱性が存在することと、実際に攻撃を受けたことは別である。影響を受けるPHPを使用しているだけで、情報流出やサーバーの乗っ取りが発生したと判断することはできない。
特に危険なのはApacheのmod_php環境
PHPは、サーバーの構成によって異なる方法で実行される。
代表的なものには、ApacheにPHPを組み込むmod_phpや、独立したPHPプロセスへ処理を渡すPHP-FPMなどがある。
今回、PHPの開発チームは、PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理する幅広い実行環境が影響を受けると説明している。
その中でも、特に危険性が高いとされているのがmod_phpである。
アプリケーションの処理が始まる前に攻撃が成立する
mod_phpは、WebサーバーのApacheにPHPの実行機能を組み込む方式である。
PHPの開発チームによると、この方式では、Webアプリケーション本体の処理が始まる前に攻撃を成立させられることが実証されている。
つまり、アプリケーションのログイン認証や入力チェックが実行される前の段階で、PHP本体の脆弱性を悪用される可能性がある。
この点が、通常のWebアプリケーションの不具合とは大きく異なる。
PHP2Shellは、特定のCMSやプラグインだけを修正すれば解決する問題ではない。PHPの実行環境自体へ対策を適用する必要がある。
情報漏洩を受けて公開予定が前倒しに
今回の脆弱性は、もともと2026年10月22日に情報公開する予定だった。
PHPの開発チームは、OSの開発元や関係企業などと協力し、修正版を準備してから詳細を公表する手順を進めていた。
しかし、公開前に脆弱性に関する情報が外部へ漏れたため、予定を変更。10月20日に緊急アップデートを予告し、翌21日に修正版と詳細情報を公開した。
修正前から攻撃を試みる通信も確認
Cloudflareは、PHP2Shellを狙った通信を実際に観測していると発表した。
同社によると、攻撃者は防御を回避するため、送信するデータの内容を変えながら攻撃を試みていたという。
脆弱性に関する情報が広まると、まだ更新されていないサーバーを狙う動きが増える可能性がある。
そのため、インターネットからアクセスできるPHPサーバーについては、通常の更新予定を待たずに対応することが求められている。
修正済みPHPバージョンは？
PHPの開発チームは2026年10月21日、以下の修正版を公開した。
| PHPの系統 | 修正済みバージョン |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
例えばPHP 8.4.26を使用している場合、PHP公式の修正版は8.4.27である。
一方、PHP 8.1以前のバージョンについては、PHP公式プロジェクトによる通常のサポートが終了している。
ただし、Linuxディストリビューションや長期サポートを提供する事業者が、古いPHPに対して修正だけを適用する場合もある。
この方法はバックポートと呼ばれる。バックポートされたPHPでは、バージョン番号が古く見えても、今回の修正が適用されていることがある。
そのため、実際の対応状況はPHP本家のバージョン番号だけでなく、利用しているOSやサーバー事業者の案内と照合する必要がある。
PHP公式の緊急セキュリティ情報：
Cloudflareも無料プランを含む防御を実施
今回の脆弱性を受けて、Cloudflareも新しい防御ルールを公開した。
Cloudflareは、Webサイトへの通信を中継し、不正なアクセスを検出・遮断するサービスである。
その機能の一つであるWAF（Web Application Firewall）は、Webサーバーへ送られてくる通信を調べ、攻撃と判断したものを制限する。
Cloudflareは10月21日、無料プランを含むWAF利用者へPHP2Shellへの防御ルールを標準適用したと発表した。
リクエストとレスポンスの両方を分析
今回の対応では、Cloudflareが新たに開発した「Full Transaction Detection」という仕組みも使用されている。
従来のWAFでは、主にサーバーへ送られるリクエストを調べて攻撃を判断していた。
しかしPHP2Shellでは、送信されたデータだけで攻撃かどうかを判断することが難しい場合がある。
そこでCloudflareは、サーバーから返されるレスポンスも分析し、通信全体の特徴から不正な処理を検出する方式を導入した。
ただし、レスポンスを遮断しても、すでにサーバー内部で実行された処理が取り消されるわけではない。
Cloudflare自身も、WAFは追加の防御手段であり、PHP本体の更新が必要だと説明している。
Cloudflare公式発表：
サーバー管理者は何をすべきか
今回の問題への対応では、まずPHPを使用しているシステムを把握することが重要である。
PHPはWebサイトの運営だけでなく、企業の社内システムやAPIサーバーなどにも利用されている。
そのため、外部公開しているWebサイトだけでなく、ネットワーク経由でアクセスできるPHPアプリケーションも確認対象となる。
修正版の適用と実行環境の確認
修正済みパッケージが提供されている場合は、利用しているOSやPHPの配布元が案内する手順で更新する。
Ubuntuを開発するCanonicalは、今回の脆弱性に対応する修正済みパッケージを10月21日に公開している。
なお、UbuntuなどのLinuxでは、PHP本家とは異なるバージョン番号で修正が適用される場合がある。
また、パッケージを更新しただけでは、すでに動作しているPHPプロセスへ修正が反映されないこともある。
更新後はApacheやPHP-FPMなど、使用している実行環境の再起動が必要になる場合があるため、OSの案内に従って対応する必要がある。
Ubuntu公式の対応情報：
更新できない場合はどうする？
PHPの開発チームは、設定変更によって一部の攻撃経路を制限できる場合があると説明している。
例えば、メモリ制限やファイルアップロードの設定変更により、特定の問題が発生する条件を減らせる可能性がある。
しかし、こうした対策だけで脆弱性を完全に解消することはできない。
PHP公式は、更新が唯一の完全な対処方法であると明言している。
更新まで時間が必要な場合は、不要な外部アクセスの制限やWAFの利用などで危険を減らしつつ、修正版への移行を優先する必要がある。
更新後も確認が必要
すでに攻撃を受けていた場合、PHPを更新しても、過去に実行された不正な処理まで取り消せるわけではない。
そのため、攻撃が疑われる環境では、アクセスログやエラーログ、不審なファイルの変更、異常なプロセスの有無などを確認する必要がある。
重要な認証情報が保存されているシステムでは、情報流出の可能性も考慮する必要がある。
また、更新後には実際に稼働しているPHPが修正済みであることを確認し、アプリケーションが正常に動作するかテストすることも重要だ。
PHP2Shellが示した問題
今回のPHP2Shellでは、Webアプリケーションの個別の機能ではなく、その土台となるPHPの実行環境そのものに問題が見つかった。
そのため、特定のアプリケーションの更新だけでは対策できず、サーバー側のPHPへ修正を適用する必要がある。
また、情報公開前の漏洩によって修正版の提供時期が前倒しされ、Cloudflareなどの企業も防御ルールを緊急配布する事態となった。
現在、PHP 8.2から8.5までの修正版が公開されており、Ubuntuなどでも対応が進んでいる。
PHPを利用するシステムの管理者は、使用しているバージョンと修正状況を確認し、可能な限り早く更新する必要がある。
今回の公式発表は、PHPのWebサイトで公開されている。
コメント