1. ホーム
  2. ブログ
  3. バージョン別の対策

PHP 8.3 / 8.4 / 8.5 の PHP2Shell 対策|修正版 8.5.12・8.4.27・8.3.36 と確認方法

公開
著者
編集部

PHP 8.3 / 8.4 / 8.5 は PHP2Shell(CVE-2026-109618 / 109619)の影響を受ける。修正版は 8.5.12・8.4.27・8.3.36 以降。公式の保守は8.5 は 2029年12月31日、8.4 は 2028年12月31日、8.3 は 2027年12月31日まで。今やることと、移行で動かなくなる原因をまとめた。

この記事の流れ約40秒
この記事で分かること

PHP 8.3 / 8.4 / 8.5 の PHP2Shell 対策|修正版 8.5.12・8.4.27・8.3.36 と確認方法

  • PHP2Shell の影響:受ける
  • 公式の修正版:8.5.12・8.4.27・8.3.36 以降
  • 公式の保守:8.5 は 2029年12月31日、8.4 は 2028年12月31日、8.3 は 2027年12月31日まで
  • 判定:要確認
1 / 7

PHP 8.3 / 8.4 / 8.5 の状況

  • PHP2Shell の影響:影響あり
  • 公式の修正版:8.5.12
  • 公開日:2025年11月20日
ここを読む
2 / 7

PHP2Shell で起きること

  • ログインなしで、外部からサーバー上のプログラムを実行される
  • いちばん危ないのは mod_php(Apache に PHP を組み込む方式)。アプリのプログラムが動く前に攻撃が届く実例がある
  • 危険度は CVSS 4.0 で 9.2(10 点満点)
ここを読む
3 / 7

今やること

  • サーバー会社の告知で、修正が適用済みか確認する。
ここを読む
4 / 7

修正の入れ方

  • レンタルサーバー:サーバー会社の告知で、PHP 8.3 / 8.4 / 8.5 に修正が入ったか確認する
  • 自分で管理するサーバー:PHP を 8.5.12・8.4.27・8.3.36 以降に更新し、Web サーバーと PHP を再起動する
  • Linux の配布元のパッケージ:版の番号が変わらないことがある。パッケージの更新履歴で確認する
ここを読む
5 / 7

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

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

ここを読む
6 / 7

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

php.net 公式の一時しのぎ

ここを読む
7 / 7

移行の手順

  • サイトのファイルとデータベースを、まるごとバックアップする
  • WordPress なら、本体・プラグイン・テーマを先に新しくする
  • テスト用の環境で、新しい PHP で動くか試す
ここを読む
PHP の移行の5つの手順

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

この記事の要点
  • PHP2Shell の影響:受ける
  • 公式の修正版:8.5.12・8.4.27・8.3.36 以降
  • 公式の保守:8.5 は 2029年12月31日、8.4 は 2028年12月31日、8.3 は 2027年12月31日まで
  • 判定:要確認

PHP 8.3 / 8.4 / 8.5 の状況

項目PHP 8.5PHP 8.4PHP 8.3
PHP2Shell の影響影響あり影響あり影響あり
公式の修正版8.5.128.4.278.3.36
公開日2025年11月20日2024年11月21日2023年11月23日
公式の保守2029年12月31日まで2028年12月31日まで2027年12月31日まで
判定要確認要確認要確認
  • PHP 8.3 には修正版(8.3.36)が出ている。
  • PHP 8.3 の公式の保守は 2027年12月31日 まで続く。

PHP2Shell で起きること

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

今やること

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

修正の入れ方

使い方やること
レンタルサーバーサーバー会社の告知で、PHP 8.3 / 8.4 / 8.5 に修正が入ったか確認する
自分で管理するサーバーPHP を 8.5.12・8.4.27・8.3.36 以降に更新し、Web サーバーと PHP を再起動する
Linux の配布元のパッケージ版の番号が変わらないことがある。パッケージの更新履歴で確認する

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

PHP 8.3 / 8.4 / 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 は使わない)

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

移行の手順

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

よくある質問

PHP 8.3 / 8.4 / 8.5 は PHP2Shell の影響を受けますか?

受けます。
修正版は 8.5.12・8.4.27・8.3.36 以降です。

PHP 8.3 / 8.4 / 8.5 のまま使い続けても大丈夫ですか?

修正版(8.5.12・8.4.27・8.3.36 以降)にしておけば、8.5 は 2029年12月31日、8.4 は 2028年12月31日、8.3 は 2027年12月31日までは公式の修正を受けられます。

PHP 8.3 / 8.4 / 8.5 から上げると、WordPress は動きますか?

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

移行を頼むと、費用はどれくらいですか?

サイトの作りやプラグインの数で変わります。
PHPチェッカーでは、サイトを確認してから無料で見積もります。

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

参考にした情報

この記事の情報

2026年10月22日時点の公開情報にもとづく。最新は php.net と、利用中のサーバー会社の告知を確認すること。

PHP のバージョンとサーバー会社を選ぶだけで、危険度と今やることが分かる。移行の相談もできる。

無料で診断する

この記事の著者

編集部