更に更に追記 2026/10/23 22:21
本記事でのUpload Progress無効化は、CVE-2026-115560にも有効だという点を添えておきます。
更に追記 2026/10/22 4:02
修正版にアップデートしました。
追記2026/10/21 18:25
2026/10/21 18:25現在、筆者vpsでは念には念を入れてphp-fpmを暫定停止しています。
これは付け焼き刃では対処できないと判断。
sudo systemctl stop php8.3-fpmで止めています。
→ 修正版が出たために再開しています
概要
2026年10月21日、PHPの重大な脆弱性として報じられた「php2shell」（CVE-2026-109618、CVE-2026-109619）への暫定対応として、PHP-FPMのSession Upload Progress機能を無効化します。
本対応では、session.upload_progress.enabled を Off に設定し、PHP-FPMへ反映しますが、これは本当に緩和策でしかないようでしたが……
CVE-2026-115560の暫定措置としては依然として推奨される策のようです。
2026/10/21 20:27 追記
以下、Geminiによる要約
1. 一体どういう攻撃なのか？
「細工したHTTPリクエストをWebサイトに送るだけで、外部からサーバーのOSコマンドを実行されてしまう」攻撃です。
- 攻撃の手口:
攻撃者がWebブラウザやツール経由で特殊なパラメータ（セッション管理やマルチパートフォームの処理に関わるリクエスト）を送信します。 - 発生する問題:
PHPコア（C言語で書かれたエンジン部分）内部でメモリ破壊が発生し、Webサーバーの権限で任意のプログラム（シェルなど）を遠隔実行されます。 - 結果:
サーバーが丸ごと乗っ取られ、ランサムウェアの設置、データ漏洩、他サイトへの踏み台攻撃などに悪用されます。
2. 大騒ぎしている理由
主に以下の4つの理由から、世界中のエンジニアやセキュリティ企業（watchTowr、各国のCERT等）が大騒ぎしています。
- 深刻度スコアが最大級（CVSS 9.2 〜 10.0）
認証（ログイン）不要、事前の権限不要で、外部ネットワークから直接狙えるため、危険度が最高レベルに設定されています。 - 影響範囲が広すぎる
PHP 5系から8系に至るまで非常に幅広いバージョンが影響を受け、WordPress、Laravel、EC-CUBEなど、Web上の膨大なシステムが標的になり得ます。 - アプリ側の改修や設定変更では防ぎきれない
PHPスクリプト（WordPressやPHPコード自体）の書き方で防げる問題ではなく、PHPエンジンそのもののバグです。php.iniでsession.upload_progress.enabledを無効化するなどの緩和策も議論されましたが、完全な遮断には至らず「パッチ適用以外に根本解決がない」と判明したためです。 - PoC（実証コード）がパッチ前に出回り始めた
公式パッチの公開直前（ゼロデイ／準ゼロデイ状態）の段階で、すでに悪用を試みる検証コードや解析情報がネット上に出回り始め、攻撃の自動ボット化が危惧されたためです。
上記理由により、本設定変更は暫定的な緩和策であり、脆弱性そのものの修正を保証するものではありません。正式な修正版PHPが提供されたら、対象バージョンと修正状況を確認したうえで更新します。
また、今回の対応前にApacheのModSecurity CRSが不審なリクエストをHTTP 403で遮断したことを確認しています。WAFによる防御とPHP実行環境の対策を重ね、複数の防御層を維持します。
環境
- OS：Ubuntu 24.04 LTS
- Webサーバー：Apache
- PHP：8.3
- PHP実行方式：PHP-FPM
- PHP-FPM設定ファイル：
/etc/php/8.3/fpm/php.ini - 対象設定：
session.upload_progress.enabled - 対応目的：脆弱性に対する暫定的なリスク低減
14:00の時点で実施した、さっくりとした手順
- PHP-FPMの現在の設定値を確認します。
- PHP-FPMの設定ファイルをバックアップします。
session.upload_progress.enabledをOffに変更します。- PHP-FPMの設定を検査します。
- PHP-FPMを再読み込みします。
- 設定値とサービスの状態を確認します。
- Web経由での設定反映とアップロード機能を確認します。
- 正式な修正版PHPの公開状況を確認し、更新します。
詳細手順
1. 現在の設定値を確認します
PHP-FPMの設定値を確認します。
sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'今回の確認結果は以下のとおりでした。
session.upload_progress.enabled => On => On設定ファイル上では該当行がコメントアウトされていました。
;session.upload_progress.enabled = On先頭の ; はコメントを示すため、この行自体は設定として適用されません。PHPのデフォルト値が On であるため、コメントアウトされていても機能が無効化されているとは限りません。
実際の設定値を確認し、無効化が必要であることを判断します。
2. 設定ファイルをバックアップします
変更前に、PHP-FPMの設定ファイルをバックアップします。
sudo cp -a /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.bak-20261021バックアップファイルが作成されたことを確認します。
ls -l /etc/php/8.3/fpm/php.ini.bak-20261021設定変更により問題が発生した場合は、このバックアップから元の設定へ切り戻します。
3. Session Upload Progressを無効化します
設定ファイルを編集します。
sudoedit /etc/php/8.3/fpm/php.ini以下の設定項目を探します。
;session.upload_progress.enabled = Onコメントアウトを解除するだけではなく、値を Off に変更します。
session.upload_progress.enabled = Off同じ設定項目を重複して追加しないようにします。
変更後、差分を確認します。
sudo diff -u /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini意図した設定項目だけが変更されていることを確認します。
4. PHP-FPMの設定を検査します
設定ファイルの構文を検査します。
sudo php-fpm8.3 -t正常な場合は、設定ファイルのテストに成功した旨が表示されます。
エラーが表示された場合は、PHP-FPMを再読み込みせず、設定ファイルを修正します。
5. PHP-FPMへ設定を反映します
設定検査に成功したら、PHP-FPMを再読み込みします。
sudo systemctl reload php8.3-fpm続いてサービスの状態を確認します。
systemctl status php8.3-fpm --no-pagerサービスが正常に稼働していることを確認します。
6. 設定値を再確認します
PHP-FPMの設定値を再確認します。
sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'期待する結果は以下のとおりです。
session.upload_progress.enabled => Off => Offただし、このコマンドは新しく起動したPHP-FPMプロセスの設定を確認するものであり、稼働中のWebリクエストが使用する設定値を直接保証するものではありません。
必要に応じて、Web経由でPHPの設定値を確認します。確認用スクリプトを公開する場合は、外部からアクセスできないように制限し、確認後は必ず削除します。
7. Webアプリケーションの動作を確認します
設定反映後、対象のWebアプリケーションが正常に動作することを確認します。
- Webサイトの表示
- ログインとセッション維持
- ファイルアップロード
- アップロード後のファイル処理
- ApacheとPHP-FPMのエラーログ
通常のファイルアップロード自体は、この設定変更によって原則として無効になりません。ただし、PHPのSession Upload Progress機能に依存した進捗表示などには影響する可能性があります。
作業上の注意
影響範囲
session.upload_progress.enabled = Off にすると、PHPがセッションにアップロード進捗情報を記録する機能が無効になります。
通常のファイルアップロード、ログイン、セッション管理などは、この設定変更だけで通常は影響を受けません。ただし、進捗情報を利用するアプリケーションについては動作確認が必要です。
切り戻し
変更後にアプリケーションの動作不良などが発生した場合は、バックアップから設定を復元します。
sudo cp -a /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini復元後、設定を検査します。
sudo php-fpm8.3 -t検査に成功したら、PHP-FPMを再読み込みします。
sudo systemctl reload php8.3-fpm最後にサービスの状態とWebアプリケーションの動作を確認します。
なお、切り戻しによって設定値が On に戻る場合、暫定緩和策も解除されます。切り戻しは必要な場合に限り、影響とリスクを確認して実施します。
根本対策
本対応は暫定的な緩和策です。正式な修正版PHPが公開されたら、PHP公式およびUbuntuのセキュリティ情報を確認します。
Ubuntuでは修正がバックポートされる場合があるため、バージョン番号だけで判断せず、使用中のリリースに対する修正状況を確認します。
修正版が提供されたら、実際にWebアプリケーションが使用しているPHP実行環境を更新し、動作確認を実施します。
まとめ
PHPの設定ファイルで該当項目がコメントアウトされていても、機能が無効になっているとは限りません。PHPのデフォルト値が On であれば、コメントアウトされた状態でも機能は有効です。
今回の対応では、設定ファイルの記述だけで判断せず、実際の設定値を確認したうえで Off を明示し、PHP-FPMへの反映と動作確認を行います。
WAFによるリクエスト遮断、PHP実行環境の暫定対策、修正版への更新を組み合わせ、単一の防御機構に依存しない構成を維持します。
コメントを残す