PHP 8.5 の PHP2Shell 対策｜修正版 8.5.12 と確認方法

PHP 8.5 のサイトが PHP2Shell でどれだけ危ないか、修正版の有無、今やることをまとめた。数値はすべて php.net の公式情報にもとづく。

PHP 8.5 の状況

• PHP 8.5 には修正版（8.5.12）が出ている。
• PHP 8.5 の公式の保守は 2029年12月31日 まで続く。

PHP2Shell で起きること

• ログインなしで、外部からサーバー上のプログラムを実行される
• いちばん危ないのは mod_php（Apache に PHP を組み込む方式）。アプリのプログラムが動く前に攻撃が届く実例がある
• 危険度は CVSS 4.0 で 9.2（10 点満点）
• CVE-2026-109618：メモリ不足の処理の途中で、作りかけのデータを正しいものとして扱ってしまう
• CVE-2026-109619：解放したはずのデータを、同じワーカーの次のリクエストが使ってしまう

今やること

1. サーバー会社の告知で、修正が適用済みか確認する。

修正の入れ方

移行で動かなくなる主な原因

PHP 8.5 から 8.4 へ移るときに、古いプラグインや古い書き方のプログラムで問題になりやすいもの（php.net の移行ガイドより）。

8.3 から 8.4 への変更

• E_STRICT の定数が非推奨
• DBA・ODBC・SOAP の一部で is_resource() の判定が効かない
• round() に無効な mode を渡すと ValueError
• OPcache の JIT の既定値が変わった（opcache.jit を明示する）
• str_getcsv() の区切り文字などの長さの確認が厳しくなった

すぐ更新できないときの応急処置

php.net 公式の一時しのぎ。完全に防げるのは更新だけ。

CVE-2026-109619

• session.upload_progress.enabled=0 にして、すべてのワーカーを再起動
• 設定は php.ini・FPM のプール・サーバーの設定で行う（ini_set() や .user.ini では効かない）
• PHP 8.5 は fatal_error_backtraces=0 も設定して再起動
• エラーを隠す（display_errors や @）だけでは効かない

CVE-2026-109618

• memory_limit=-1（FPM のプールか Apache の設定で。ほかの設定で上書きされないようにする）
• アップロード不要なら post_max_size = 8M、必要なら 32M（upload_max_filesize はそれより小さく）
• Web サーバーやプロキシで、リクエストの大きさ・項目数・ヘッダー数・入れ子の深さを制限
• メモリの上限はコンテナや cgroup でかける（RLIMIT_AS や RLIMIT_DATA は使わない）

レンタルサーバーでは、これらを利用者が変えられないことが多い。

移行の手順

1. サイトのファイルとデータベースを、まるごとバックアップする
2. WordPress なら、本体・プラグイン・テーマを先に新しくする
3. テスト用の環境で、新しい PHP で動くか試す
4. 本番の PHP を切り替え、トップ・フォーム・管理画面を確かめる
5. おかしければ、すぐ元の版に戻す

よくある質問

PHP 8.5 は PHP2Shell の影響を受ける？

受ける。修正版は 8.5.12 以降。

PHP 8.5 のまま使い続けても大丈夫？

修正版（8.5.12 以降）にしておけば、2029年12月31日までは公式の修正を受けられる。

PHP 8.5 から上げると WordPress は動く？

WordPress 本体は新しい版ほど新しい PHP に対応している。問題になるのは古いプラグインやテーマが多い。テスト環境で確かめてから切り替える。

移行を頼むと費用はどれくらい？

サイトの作りやプラグインの数で変わる。PHP診断では、サイトを確認してから無料で見積もる。

無料ツールPHP2Shell 脆弱性チェッカーPHP のバージョンとサーバー会社を選ぶだけで、危険度と今やることが分かります。

参考にした情報

• php.net（2026年10月21日のセキュリティ告知）
• php.net：Supported Versions
• php.net：Unsupported Branches
• php.net：付録（移行ガイド）