EOLのPHP 7.4、8.0、8.1にも異例のパッチ JPCERT/CCが警告する「php2shell」の侵害痕跡3つと緊急対策：8.2系からの移行期限は2026年12月31日まで（2/2 ページ）

[＠IT]

直ちにアップデートできない場合の緩和策

　直ちにアップデートできない場合の緩和策としてThe PHP Groupが挙げているのは、次の通り。

　CVE-2026-109618には、FPMプールやApacheの設定で「php_admin_value」などを使って「memory_limit=-1」を設定する。「post_max_size」も低くする（ファイルアップロード不要なら「8M」、必要なら「32M」）。Webサーバまたはプロキシレベルでデコードされたリクエストサイズ、入力フィールド数、マルチパートパート数、ヘッダ数、ネスト深度を制限する。可用性の境界にはコンテナや「cgroup」を使い、「RLIMIT_AS」や「RLIMIT_DATA」は代用しない。

　CVE-2026-109619には、「php.ini」や FPM プール、サーバ設定で「session.upload_progress.enabled=0」を設定し、全ワーカーを再起動する（「ini_set()」「FPM .user.ini」には依存しない）。PHP 8.5では「fatal_error_backtraces=0」を設定して再起動する。初期化前に診断情報を出力する、リクエストごとに適用された無効または非推奨の設定の削除や、致命的エラーおよび実行タイムアウトの修正も推奨されている。

　詳細は、セキュリティアドバイザリを参照。

　JPCERT/CCは、緩和策について「特定の攻撃経路への対処にとどまる」と表現し、「アップデートのみが本脆弱性に対する対策」として推奨している。PHPを組み込んだ製品やLinuxディストリビューションのパッケージも各提供元の情報を確認する必要があるという。

侵害調査で確認した方がよい、3つの痕跡

　JPCERT/CCは、発見者らの情報（特設サイト「PHP2Shell」やWizのブログ）から、悪用有無の調査では、次の3点の確認を推奨している。

• 過去のHTTPレスポンスで、不自然に長い、または異常な形式の値を含む「PHPSESSID Cookie」が設定されていないかどうか
• 不審な「multipart/form-data」形式のHTTPリクエストの送信や、その前後にPHPのメモリ上限エラー、HTTP/500エラーが発生していないかどうか
• PHPのワーカープロセスが異常終了や頻繁な再起動をした痕跡がないかどうか

　ただし、「複数の悪用経路が存在し、手口やログ状況によっては痕跡が残らない場合もあるので、上記が確認されなくても未被害とは断定できない」とし、修正済みバージョンへのアップデートとともに、不審なプロセス実行や外部通信、ファイル作成などの侵害痕跡も確認し、継続的に監視するよう求めている。侵害が疑われる場合は証拠を保全した上で、影響範囲の調査やシステムの隔離を実施する必要があるという。

修正アップデート後も、PHP 8.2系ユーザーは2026年12月31日までに移行が必要

　The PHP Groupは、PHP 8.5.12、8.4.27、8.3.36、8.2.35へのアップデート後も、サポート対象バージョンに移行、および計画することも推奨している。

　セキュリティサポートまでの期間は、8.2が2026年12月31日まで、8.3が2027年12月31日まで、8.4が2028年12月31日まで、8.5が2029年12月31日までとなっている。特に、PHP 8.2系ユーザーはあと2カ月で今回のようなセキュリティ修正が提供されなくなるので、早急に8.3以上に移行する必要がある。

PHPサポートのカレンダー図（提供：The PHP Group）

　移行ガイドは次の通り。

• 8.2
• 8.3
• 8.4
• 8.5