PHPの脆弱性情報まとめ

PHP本体、Windows版の同梱ライブラリ、よく使われるアプリ・パッケージのうち、米CISAのKEV（悪用が確認された脆弱性の一覧）に載ったもの、または深刻度が緊急のものです。11月1日に確かめた状態で書いています。

PHP2Shellは、更新できないときの設定による緩和策をPHP公式が示していますが、どれも安全にするものではなく、更新だけが完全な対応だとしています。[1]JPCERT/CCは、悪用できると主張するPoC（検証用のコード）が多数公開され、悪用を試みる通信の観測も相次いでいるとして、更新に加えて侵害の有無の調査を呼びかけています。[3]

10月23日には、セッションのアップロード進捗に関わる別の問題（CVE-2026-115560）も公表されました。設定でsession.serialize_handlerをphp_binaryかphp_serializeにし、実行時にini_set()でphpへ切り替えるアプリが対象です。修正は次の通常リリースで行う方針で、それまではsession.upload_progress.enabled=0を勧めています。PHP2Shellの緩和策としてこの設定をすでに入れていれば、追加の対応は要りません。[1]

PHP公式がサポートしているのは8.2〜8.5の4系列です。8.2のセキュリティ修正は2026年12月31日に終わります。[7]

8.1以前には、PHP2Shellの修正版は出ていません。PHP公式は7.4・8.0・8.1向けに最小限のソースの修正を用意していますが、リリースではありません。8.6.0は開発中の版（RC4）で、本番での利用は控えるよう告知されています。[1][8]

OSの配布元（Linuxのディストリビューション）や長期サポートの事業者は、事前に修正を受け取っていたとPHP公式は説明しています。これらのPHPは配布元のパッケージで更新します。[1]

PHPのパッケージの脆弱性は、Composerのcomposer auditで確かめます。Packagist.orgのセキュリティアドバイザリと照らし合わせ、見つかれば終了コード1を返します。composer updateやcomposer requireも、実行のたびに同じ確認をします。[9]

composer audit
composer audit --locked --no-dev
composer audit --format=json

--lockedはvendorフォルダーではなくcomposer.lockを見て確かめます。--no-devは開発用の依存（require-dev）を外します。[9]ある脆弱なパッケージを、どのパッケージが引き込んでいるかはcomposer whyで確かめます。

composer why livewire/livewire --tree
composer show laravel/framework

composer auditは、PHP本体、Windows版の同梱ライブラリ、Composer以外で入れたWordPressの本体やプラグインを確かめません。PHP本体の版と、cURLが使うBrotliの版は、次のように確かめます。

php -v
php -r "var_dump(curl_version()['brotli_version'] ?? null);"

1. 実際にリクエストを処理しているPHPを見る：ターミナルのphpと、PHP-FPMやApacheのmod_phpが同じとは限りません。php-fpm -v（環境によってはphp-fpm8.3 -vなど）や、管理者だけが開ける場所に置いたphpinfo()で、Webで動いている版と設定を確かめます。更新した後は、PHP-FPMやApacheを再起動するまで古い版が動き続けます。
2. コンテナは本番のイメージで確かめる：docker run --rm <イメージ> php -vのように、本番で動かしているイメージそのものを確かめます。手元で作り直したイメージは、基のイメージの更新で版が変わっていることがあります。
3. OSの配布元のPHPは番号だけで決めない：配布元は修正を古い番号のパッケージに取り込むことがあります。配布元のセキュリティ告知やパッケージの更新履歴で、CVE番号を探します。JPCERT/CCも、PHPを組み込んだ製品やディストリビューションのPHPが影響を受けうるとしています。[3]
4. Windows版は「-1」を確かめる：php -vの表示は8.5.12のままなので、Brotliの版（1.2.1か）で見分けます。
5. 緩和策の設定は効く場所に書く：PHP公式は、PHP2Shellの緩和策をphp.iniやFPMのプール、サーバーの設定に書き、すべてのワーカーを再起動するよう案内しています。ini_set()やFPMの.user.iniには頼らないとしています。[1]
6. lockファイルと間接依存：composer.lockをリポジトリに入れ、本番ではcomposer installでその内容どおりに入れます。Livewireのように、直接書いていないパッケージが引き込んでいることもあるので、composer auditは間接依存まで見る既定のまま使います。[9]

PHP2Shellで侵害を受けていないかは、JPCERT/CCが挙げる痕跡（不自然に長いPHPSESSIDのCookie、不審なmultipart/form-dataのリクエストと前後のメモリ上限のエラーやHTTP 500、ワーカーの異常終了）でログを確かめます。痕跡が見つからなくても、攻撃を受けていないとは言い切れないとしています。[3]国内の各サービスの停止・緊急メンテナンスの告知は、PHP2Shell サービス停止まとめに原資料へのリンクとともにまとめています。停止の記録だけでは、被害の有無は分かりません。