PHP2Shell の対策：PHP をアップデートしてワーカーを再起動する

目標バージョン

• 8.5 系：PHP 8.5.12 以降
• 8.4 系：PHP 8.4.27 以降
• 8.3 系：PHP 8.3.36 以降
• 8.2 系：PHP 8.2.35 以降
• それより古いもの：上記のいずれかへ移行するか、ベンダーのバックポートを確認し、あくまでつなぎとして扱ってください。CISA は、更新できない場合は PHP 8.1 以前を含め未修正の PHP をオフラインにするよう求めています。

ソースの tarball と Windows ビルドは PHP ダウンロードページにあります。php.net によれば、Linux ディストリビューションと LTS ベンダーは一般公開前にパッチを受け取っているため、多くの場合ディストリビューションのパッケージが適切な経路です。同じ告知は、ボランティアの Remi リポジトリ（rpms.remirepo.net）は 10 月 21 日時点で更新がないとし、利用者にディストリビューションのパッケージへの切り替えかソースからのビルドを勧めています。

Debian、Ubuntu などの apt 系

Debian は修正を公開しています。Debian 12 bookworm 向けは DLA-4848-1（Debian LTS）で php8.2 8.2.35-1~deb12u1、Debian 13 trixie 向けは DSA-6574-1 で php8.4 8.4.27-1~deb13u1 です。Debian のセキュリティトラッカーは基本スイートのビルド（bookworm の php8.2 8.2.32-1~deb12u1、trixie の php8.4 8.4.24-1~deb13u1）を脆弱としているため、修正は security スイートを sources に入れている場合にのみ届きます。10 月 22 日時点でトラッカーは testing（forky）の php8.4 8.4.26-1 をまだ脆弱としていました。

メタデータを更新し、アーカイブで実際に公開された PHP パッケージをインストールします。パッケージ名はマイナーブランチに対応します（php8.3-fpm、php8.3-cli、php8.3-common、mod_php を使う場合は Apache モジュールのパッケージ）。候補バージョンがまだ修正版より低い場合は、設定の問題ではなくディストリビューションの対応待ちです。

sudo apt-get update
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
sudo apt-get install --only-upgrade php8.3-cli php8.3-fpm php8.3-common
php8.3 -v
# Web SAPI, not just the CLI:
php-fpm8.3 -v
sudo systemctl restart php8.3-fpm
# If Apache loads mod_php, restart Apache as well:
sudo systemctl restart apache2

RHEL、Alma、Rocky、Fedora：dnf または yum

sudo dnf clean expire-cache
sudo dnf update php php-cli php-fpm php-common
php -v
php-fpm -v
sudo systemctl restart php-fpm
# mod_php under httpd:
sudo systemctl restart httpd

Docker などのイメージ

再ビルドして再デプロイしてください。新しいベースイメージを pull しても、トラフィックを処理するワークロードを入れ替えるまで何も変わりません。公式イメージのタグは通常 PHP のバージョンに従います。固定する前に Docker Hub でタグの存在を確認してください。Cloud Run と GKE に関する Google Cloud の説明も同じで、Google が置き換えるとしているサーバーレスのベースイメージでない限り、デプロイするイメージを再ビルドする必要があります。

FROM php:8.3.36-fpm
# or: php:8.3.36-apache, php:8.4.27-fpm, php:8.2.35-fpm, php:8.5.12-cli

# then, on the host:
# docker pull php:8.3.36-fpm
# docker build -t your-app:php2shell-fix .
# redeploy and confirm the running container's PHP version

cPanel

1. EasyApache で修正済みの PHP ビルドを使えるよう、cPanel 自体を更新します。メニューは変わることがあるので、表記が異なる場合は cPanel のドキュメントに従ってください。
2. WHM で EasyApache 4 を開き、そのブランチの修正版以上の PHP を用意します。MultiPHP Manager でドメインごとに PHP バージョンを指定します。
3. ベンダーがバックポートを含むと明言していない限り、インターネットに公開しているドメインを PHP 8.1 以前のハンドラーから切り替えます。
4. WHM から Apache と PHP-FPM を再起動し、ドメインの PHP バージョンを確認し、一時的な確認用ページは削除します。

Plesk

1. Plesk とシステムパッケージの更新をインストールします。現在の操作手順は Plesk のドキュメントを参照してください。
2. 「ツールと設定」で更新と PHP ハンドラーの一覧を確認します。ドメインの PHP 設定で、各サブスクリプションが実際に使うバージョンがわかります。
3. 修正済みのハンドラー（8.2.35、8.3.36、8.4.27、8.5.12、または検証済みのベンダービルド）を選び、公開サイトから適用します。
4. Plesk が使う PHP サービスを再起動し、パネルのホストだけでなくドメインに対してバージョンを確認します。

宝塔面板（BT Panel）

2026 年 10 月 22 日更新の宝塔の告知によると、Linux 版と Windows 版のパネルは 8.2.35、8.3.36、8.4.27、8.5.12 を同期済みです。Linux 版のみの 7.4.34、8.0.31、8.1.35 は宝塔のビルドで、PHP プロジェクトのリリースではありません。操作手順と Windows 向けの不完全な設定は 宝塔面板のページにあります。

mod_php と PHP-FPM の違い

どちらも PHP プロジェクトのリスク一覧に含まれます。mod_php は、実証済みの認証不要の経路がアプリケーションコードより前に発動するため最もリスクが高いとされています。mod_php を読み込み直すのは Apache の再起動です。PHP-FPM は別プロセスなので、すべてのプールを再起動してください（systemctl restart php8.3-fpm など）。プールが独自のバイナリを固定していることもあり、シェルの PATH 上の php はプールとは別のビルドの場合があります。FrankenPHP、php-cgi、LiteSpeed も Web リクエストを処理するものとして対象に挙げられています。apt の php-fpm パッケージで足りると思い込まず、各ベンダーの手順に従ってください。

暫定策（PHP は不完全としています）

以下は php.net の勧告から写した、つなぎとしてのみ使う設定です。特定の経路を減らすだけで、ホストを安全にはしません。php.ini か、管理者レベルのプールまたは Apache の設定（php_admin_value）に記述してください。PHP によると、ini_set() やディレクトリ単位の .user.ini ではセッションアップロードの経路に対して遅すぎます。

CVE-2026-109618

• memory_limit=-1 にし、アプリケーションが有限の制限を再設定できないよう固定します。PHP は、これで制御可能なメモリ制限の失敗はなくなるが、根本的なメモリ確保の失敗はなおバグに到達し得るとしています。
• post_max_size を小さくします。アップロードが不要なら 8M、必要なら 32M とし、upload_max_filesize は post_max_size より小さくします。
• Web サーバーやプロキシでのリクエストサイズ制限（有効な Content-Length のないリクエストを含む）。PHP はデコード後のリクエストサイズ、入力フィールド数、multipart のパート数、ヘッダー数、ネストの深さを挙げています。
• 影響を受けたワーカーを停止させる可用性の境界として、コンテナや cgroup の制限を使います。RLIMIT_AS や RLIMIT_DATA は脆弱なメモリ確保の失敗を引き起こし得るため代わりにしないよう、PHP は述べています。

CVE-2026-109619

• session.upload_progress.enabled=0 にし、すべてのワーカーを再起動します。確認済みのセッション経路は塞げますが、他の変種は塞げません。
• PHP 8.5 のみ：fatal_error_backtraces=0 にして再起動します。確認済みの致命的エラーのバックトレース経路だけを塞ぎます。
• 初期化前に診断を出力する、無効または非推奨のリクエスト単位の設定を削除します。error_reporting、display_errors、@ でエラーを消してもバグは塞がりません。
• 攻撃者が到達できる致命的エラーと実行タイムアウト（コールバックやアップロード・インポートの後処理での失敗を含む）を修正します。これはプロジェクトの表現で、堅牢化のヒントであり、バグのないアプリなら FPM が安全という主張ではありません。

Web アプリケーションファイアウォール（WAF）

CISA は、システムを更新するまでの間、WAF がある程度の防御になる可能性があるとしています。Cloudflare は、この問題に対応するマネージドルールを 2026 年 10 月 21 日 03:02 UTC から無料・有料の WAF プランの顧客に展開したとし、禁輸期間中に PHP Foundation などと開発したと説明したうえで、それでもパッチを当てるよう求めています。ルールは回避され得ます。Cloudflare 自身、攻撃者がルールを回避しようとペイロードを変えるのを観測しています。WAF は維持しつつ、修正の代わりにはしないでください。

アップグレード後

• HTTP リクエストに応答する SAPI でバージョンを確認し、再起動します。Expel とトロント大学の勧告はいずれも再起動を強調しています。
• インターネットに公開しているシステムを最優先にし、次に信頼できないアップロードやインポートを処理するもの、その次にアプライアンスを対応します。英国 NCSC とカナダ サイバーセンターは、PHP を同梱するサードパーティ製品には各ベンダーの更新が必要だとしています。
• すぐにパッチを当てられず公開状態が続いたホストについて、CISA は PHP ワーカーがシェルを起動したりツールをダウンロードしたりしていないか調べるよう勧めています。英国 NCSC は、公開されていたホストをアップグレード後に信頼する前にバックドアを調べるよう求めています。本サイトには、この助言に加えられる検証済みの侵害指標（IoC）の一覧はありません。
• 英国の勧告からリンクされている NCSC-NL の一覧は製品の棚卸しの出発点であり、掲載されていない製品が安全だという証明ではありません。