PHPの脆弱性PHP2Shell（CVE-2026-109618）｜コード実行の対象バージョンと確認方法・修正版

PHP公式によると、2件はどちらも認証なしで遠隔からコードを実行されるおそれがあります。CVE-2026-109618は、メモリ不足（OOM）で処理を抜けたとき、初期化の途中のデータを終了処理が正しいものとして扱う問題です。CVE-2026-109619は、終わったリクエストのメモリを指す内部状態が残り、同じワーカーの次のリクエストがそれを使う問題です。[1][2][3]

深刻度は緊急です（PHP公式の評価：CVSS 4.0で2件とも9.2）。NVDはCVSS 3.1で、CVE-2026-109618を9.8（緊急）、CVE-2026-109619を8.1（高）としています。攻撃の複雑さは高く、成功するかはPHPの版・実行環境・メモリの配置などで変わるとJPCERT/CCは説明しています。[2][3][5][6][8]

PHP公式は対象を「Webのリクエストを処理するすべてのPHP」とし、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを挙げています。最も危険なのはmod_phpで、アプリのコードが動く前に攻撃が始まることを実証済みとしています。コマンドライン（CLI）だけで動かすPHPの記載はありません。[1]

足がかりは、multipartのリクエストでmemory_limitを使い切らせること、初期設定で有効なセッションのアップロード進捗、致命的エラーや実行時間切れ、8.5のfatal_error_backtracesなどです。[2][3]

米CISAは10月26日（米国時間）に2件をKEVへ追加し、連邦政府機関の対応期限を10月29日としました。今後30日に悪用される見込みの推定（EPSS）は、2件とも99.9%を超えています（11月1日時点）。[4][18]

JPCERT/CCは、悪用できると主張するPoCが多数公開され、悪用を試みる通信の観測も相次いでいるとし、10月29日には、あるファイアウォール製品で侵害の成功を示唆する痕跡が報告されたと追記しました。IPAの注意喚起（11月2日更新）は、国内での攻撃被害の事例は把握していないとしています。国内で緊急メンテナンスを行ったサービスはPHP2Shellのサービス停止まとめにあります。[7][8][12]

更新に加えて、それまでに攻撃を受けていないかを確かめます。JPCERT/CCが挙げる確認点は次の3つです。[8]

1. 過去のレスポンスで、不自然に長い、または形式のおかしいPHPSESSIDのCookieを設定していないか。
2. 不審なmultipart/form-dataのリクエストと、その前後のメモリ上限のエラーやHTTP 500がないか。
3. PHPのワーカーの予期しない異常終了や、頻繁な再起動がないか。

米CISAの検知ルール（Sigma）は、index.phpへのPOSTでPHPSESSIDとPHP_SESSION_UPLOAD_PROGRESSを含むmultipartのリクエスト、エラーログの「PHP Fatal error:」「Allowed memory」「in Unknown」がそろう行、PHP-FPMやApacheから/bin/sh・curl・wgetを起動した記録、公開された攻撃コードやスキャナーの印（php2shell-scan、区切り文字列B7kQpoc618・BNDRY12345）を探します。[10]

grep -E "PHP Fatal error: +Allowed memory.* in Unknown" /var/log/php*-fpm.log /var/log/apache2/error.log
grep -E "php2shell|B7kQpoc61|BNDRY12345" /var/log/nginx/access.log /var/log/apache2/access.log

本文の文字列はアクセスログに残らないことが多いので、WAFやプロキシの記録でも探します。JPCERT/CCは、痕跡が無くても侵害されていないとは言い切れないとし、不審なプロセス・外部への通信・ファイルの作成も確かめ、疑わしければログを保全してシステムを隔離するよう求めています。[8]

対象と修正版は、PHP公式の告知と2件のアドバイザリから出しました。11月2日時点で、これより新しい版は出ていません。[1][2][3]

NVDの判定では、CVE-2026-109619は5.4.0以降、CVE-2026-109618は7.3.0以降が対象です（11月2日確認）。Windows版は、10月26日の8.5.12-1などを入れると、同梱のBrotliの脆弱性もあわせて直ります。[5][6][19][16]

1. Webのリクエストを処理しているPHPの版を確かめます。ターミナルのphpとPHP-FPM・mod_phpは別の版のことがあります。FPMの実行ファイル名は環境で違います。

   ターミナル

   php -v
   ls /usr/sbin/php-fpm*
   php-fpm8.3 -v
   apachectl -M | grep -i php

2. OSのパッケージは、番号ではなく配布元の修正版と比べます。Debian 12のphp8.2は8.2.35-1~deb12u1、Ubuntu 24.04のphp8.3は8.3.6-0ubuntu0.24.04.13、Ubuntu 22.04のphp8.1は8.1.2-1ubuntu2.28で直っています。RHEL系は更新履歴でCVE番号を探します。[13][14]

   ターミナル

   dpkg -l 'php*' | grep '^ii'
   rpm -q --changelog php-fpm | grep -m1 CVE-2026-10961

3. コンテナは本番のイメージそのもので確かめます。公式のphpイメージは、8.4-fpmのような系列のタグも10月31日に作り直されています。手元のイメージは基のイメージを取り直して作り直します。[15]

   ターミナル

   docker run --rm <本番のイメージ> php -v
   docker build --pull --no-cache -t <イメージ名> .

4. composer auditが見るのはインストールしたパッケージです。PHP本体の版はcomposer show --platformで見られますが、Composerを動かしたPHPの版なので、手順1と照らし合わせます。[17]

   ターミナル

   composer show --platform | grep '^php '

5. 更新したらPHP-FPMやApacheを再起動し、手順1と同じ方法で修正版になったことを確かめます。再起動までは古い版が動き続けます。

   ターミナル（Debian系の例）

   sudo apt update && sudo apt upgrade
   sudo systemctl restart php8.3-fpm
   sudo systemctl restart apache2
   php-fpm8.3 -v

PHP公式は、更新だけが完全な対策で、次の設定は特定の経路を減らすだけだとしています。php.iniやFPMのプールに書いてすべてのワーカーを再起動し、ini_set()や.user.iniには頼りません。[1]

• memory_limit=-1をアプリが上書きできない形で設定し、メモリの上限はコンテナやcgroupで設ける（RLIMIT_AS・RLIMIT_DATAは使わない）。
• post_max_sizeをアップロードが無ければ8M、あれば32Mにし、upload_max_filesizeをそれより小さくする。
• session.upload_progress.enabled=0にする（10月23日に告知された別の問題CVE-2026-115560の対策も兼ねる）。8.5ではfatal_error_backtraces=0も。[11]

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

米CISAは、すぐ更新できないPHPはオフラインにするよう勧めています。[9]

PHP公式は8.1以前を更新の対象外とし、配布元や長期サポートの事業者の修正を確かめるか、サポート中の版へ上げるよう求めています。7.4・8.0・8.1向けの最小限のソースの修正はGitHubのブランチにありますが、リリースではありません。[1][20]

Ubuntu 22.04のphp8.1のように配布元が直したものもあります。一方、公式のphpイメージの8.1のタグは2026年1月2日から更新されていないので（11月2日確認）、8.2以上のイメージへ移ります。[14][15]