PHPコアのリモートコード実行の脆弱性（PHP2Shell）に関する対応勧告

概要

PHPコア（core）においてリモートコード実行（RCE）が可能となる深刻な脆弱性2件（CVE-2026-109618、CVE-2026-109619）が公開されました。PHPはWebサービスで広く使われている汎用スクリプト言語であり、WordPress、Drupal、Magento（Adobe Commerce）、WooCommerce、ShopwareなどのPHPベースのWebサービスが影響を受けます。PHPを運用する組織は、直ちにPHP資産を特定し、パッチを適用する必要があります。

この2件の脆弱性はPHP2Shellと呼ばれています。PHPセキュリティチームは、2026年10月21日14:00 UTC（韓国時間23:00）に定例外のセキュリティリリースを行うと予告しました。しかし、パッチ公開前の10月20日に、脆弱性情報とエクスプロイトツールのスクリーンショットが外部に流出しました。

図1. セキュリティ研究者J4ck3LSyNがXに投稿した、再現に成功したと主張する投稿。原因をsession.upload\_progressハンドラーのヒープ領域における解放済みメモリ使用（Use-After-Free）としています。PHPが確認した内容ではありません。

セキュリティ企業watchTowrは、CVE-2026-109618の再現に成功したと発表しました。PHPセキュリティチームは、2件の脆弱性をいずれもCVSS v4.0で9.2（Critical）と評価しました。一部のメディアが報じた10.0は公式スコアではありません。

2026年10月21日時点では、実際の侵害事例およびCISA KEVへの掲載は報告されていません。ただし、パッチ公開前に情報が流出したため、攻撃コードが短期間で登場する可能性があります。PHP 5.x、7.x、8.0、8.1など、サポートが終了した（EOL）バージョンには公式パッチは提供されません。

影響を受けるバージョン

流出したエクスプロイトツールのバナーおよび公開報告によると、PHP 5.4.0以降のすべてのバージョンが影響を受けます。PHPは、影響を受けるバージョンと修正済みバージョンを10月21日のセキュリティリリースとともに公開すると発表しました。パッチは、現在サポート中の8.2、8.3、8.4、8.5ブランチにのみ提供される予定です。以下の修正済みバージョンは、セキュリティ研究者が予測した次回のポイントリリース番号です。適用前にphp.netの公式発表と照合してください。

RHEL、Ubuntu、Debian、SUSEなどのLinuxディストリビューションは、独自のパッケージバージョンに修正をバックポートします。ディストリビューションのパッケージを使用している場合は、上記のアップストリームのバージョン番号ではなく、各ディストリビューションのセキュリティアドバイザリ（CVEトラッカー）に基づいてパッチ適用の有無を判断します。Docker公式のphpイメージはphp.netのオリジナルのソースコードからビルドされるため、修正済みバージョンのタグが公開されたら、そのタグで再ビルドします。

脆弱性の分析

PHPは、影響を受けるバージョンと技術的な説明をパッチとともに発表する予定です。以下の分析は、流出資料とセキュリティ研究者による公開分析に基づく推定です。

公開分析では、脆弱性が存在する箇所はPHPセッション拡張（ext/session）のアップロード進捗追跡機能（session.upload_progress）とされています。この機能は、ブラウザーがmultipart/form-data形式でファイルを送信する際に、アップロードの進捗状況をユーザーセッションに記録します。PHPは、アプリケーションコードが実行される前にリクエストボディーを直接解析します。したがって、推定される原因が正しければ、配置されているPHPスクリプトの種類にかかわらず、Webサーバーにリクエストが到達するだけで脆弱なコードが実行されます。

根本原因（推定）

セキュリティ研究者J4ck3LSyNの分析（未確認）によると、ext/session/session.cのphp_session_rfc1867_callback関数は、進捗値（post_bytes_processed、current_file_bytes_processed）を指す生のzvalポインターをセッションのハッシュテーブルにキャッシュします。アップロード処理中にセッションデータが再度デコードされると、既存のツリーがzval_ptr_dtorによって解放されます。キャッシュされたポインターはそのまま残り、すでに解放されたメモリを参照します（ヒープ領域における解放済みメモリ使用、Use-After-Free）。攻撃者は、細工したmultipartリクエストを使って解放済みのメモリ領域を自身のデータで再び埋めた（heap grooming）後、zend_call_function経由で実行フローを乗っ取り、system()などの任意の関数を呼び出すことができます。2件のCVEのうち、一方はアップロード進捗ハンドラーに、もう一方はmultipartパーサーに存在すると推定されています。

推定される原因が正しければ、脆弱性を引き起こすために必要な設定はすべてPHPのデフォルト値です。

推定される原因が正しければ、設定を変更していないPHP Webサーバーはすべて攻撃対象です。攻撃者は認証なしで、ファイルアップロードフォームがないパスに対しても、PHP_SESSION_UPLOAD_PROGRESSフィールドを含むmultipart POSTリクエストを送信することで、脆弱なコードを実行できます。

攻撃が成功した場合の影響

• 任意のコマンド実行：PHP-FPMまたはWebサーバー（www-data、apache、nginxなど）の権限でシステムコマンドを実行
• Webシェルの設置：WebルートにPHP Webシェルを書き込み、継続的なアクセス経路を確保
• 情報漏えい：DB接続情報を含む設定ファイル（wp-config.php、.env、env.phpなど）、セッションデータ、顧客情報を窃取
• 決済情報の窃取：ECサイトの決済ページにカード情報スキマー（Magecart）を挿入
• 内部ネットワークへの攻撃：Webサーバーを足掛かりに、DBサーバーなどの内部システムへラテラルムーブメント（Lateral Movement）を実行
• 権限昇格：カーネルの脆弱性またはローカルの脆弱性と組み合わせてroot権限を取得

検知方法

1. 脆弱な資産の特定

稼働中のすべてのWebサーバーで、PHPのバージョンとアップロード進捗機能が有効かどうかを確認します。

# PHPのバージョンを確認
php -v

# アップロード進捗機能が有効かどうかを確認（1またはOnの場合、脆弱性があると推定される経路が有効）
php -i | grep -i "session.upload_progress"

# ディストリビューションのパッケージバージョンを確認
dpkg -l | grep php          # Debian/Ubuntu
rpm -qa | grep php          # RHEL/Rocky/Alma

2. Webアクセスログの点検

公開分析によると、この脆弱性はPHP_SESSION_UPLOAD_PROGRESSフィールドを含むmultipart POSTリクエストによって引き起こされます。ファイルアップロード機能がないURLや静的リソースのパスに対するmultipart POSTリクエスト、特に同じ送信元IPから短時間に繰り返し送られたリクエストがないか確認します。アクセスログにはリクエストボディーが記録されないため、WAFやリバースプロキシによるボディーのログ記録、またはパケットキャプチャを併用します。

# 確認対象：/var/log/nginx/access.log、/var/log/apache2/access.logなど
# アップロード機能のないパスに対するmultipart POSTリクエストを特定
# （以下は形式を示す例であり、実際に確認された攻撃ログではありません）
"POST /index.php HTTP/1.1" 500 ... "python-requests/2.x"
"POST /wp-login.php HTTP/1.1" 502 ... "curl/8.x"

3. PHP-FPM / Webサーバーのエラーログの点検

ヒープUAFのエクスプロイトでは、メモリ配置の操作に失敗するとワーカープロセスが異常終了します。通常とは異なる頻度で発生するセグメンテーションフォールトやワーカー再起動のログは、攻撃試行の指標となる可能性があります。

# 確認対象：/var/log/php-fpm/error.log、/var/log/php8.x-fpm.log
# （以下は形式を示す例です）
WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV - core dumped) after 3.214 seconds from start
WARNING: [pool www] child 12346 exited on signal 6 (SIGABRT) after 0.812 seconds from start

# 確認対象：/var/log/nginx/error.log
upstream prematurely closed connection while reading response header from upstream

4. 異常なプロセスの点検

PHPワーカーがシェルやシステムコマンドを子プロセスとして実行した形跡がないか確認します。正常な運用環境では、php-fpmワーカーはシェルを実行しません。

# php-fpmまたはapacheワーカーの子プロセスを確認
ps -ef --forest | grep -A3 -E "php-fpm|apache2|httpd"

# 不審なパターン：php-fpm配下のsh、bash、curl、wget、nc、python、perlプロセス

5. Webシェルおよびファイル改ざんの点検

Webルート、およびアップロード、キャッシュ、一時ディレクトリに、最近作成または変更されたPHPファイルがないか確認します。

# 過去7日以内に作成・変更されたPHPファイル
find /var/www -type f -name "*.php" -mtime -7 -ls

# 書き込み可能なディレクトリに作成されたPHPファイル（アップロード・キャッシュ・tmp）
find /var/www /tmp /var/tmp -type f -name "*.php" -newermt "2026-10-20"

# Webシェルのシグネチャを検索
grep -rlE "eval\(base64_decode|system\(\$_(GET|POST|REQUEST)|passthru\(|shell_exec\(" /var/www

6. 異常な外部通信の確認

Webサーバーから外部への接続、特にphp-fpmやapacheプロセスによるリバースシェルやC2通信がないか確認します。

# php-fpm / Webサーバープロセスの外部接続を確認
ss -tnp | grep -E "php-fpm|apache|httpd" | grep -v ":80 \|:443 "

# ファイアウォール・プロキシのログで、Webサーバーからのアウトバウンド接続のうち、異常なポート（4444、1337など）および未登録の宛先を確認

7. ECサイトの追加点検

Magento、WooCommerce、Shopwareを運用する組織は、決済ページにスキミングスクリプトが挿入されていないか、管理者アカウントの不審な作成がないかを追加で点検します。過去にPHPやプラットフォームの脆弱性が悪用された際には、Magecart系の攻撃者が数日以内に大規模な悪用に乗り出した事例があります。

対応方法

1. セキュリティリリースの即時適用

運用中のPHPのバージョンをすべて確認し、PHP公式のセキュリティリリースが公開され次第、直ちにサポート対象ブランチ（8.2以降）の修正済みバージョンに更新します。ディストリビューションのパッケージを使用している場合は、各ディストリビューションのバックポートパッケージを適用し、Dockerイメージは修正済みバージョンのタグで再ビルドします。更新後は、php -vですべてのホストのバージョンが実際に変更されたこと、およびPHP-FPMとWebサーバーが再起動されたことを確認します。

2. パッチ適用前の一時的な緩和策

パッチを適用するまで、アップロード進捗機能を無効にします。ファイルアップロードは引き続き動作し、進捗表示のみが停止します。ただし、この措置は、推定される2つの経路のうち、アップロード進捗ハンドラー側の1つだけを防ぐものと報告されています。パッチの代わりにはなりません。

# php.ini（サーバー全体に適用後、PHP-FPMまたはApacheを再起動）
session.upload_progress.enabled = 0

# .user.ini（PHP-FPM/CGI、user_ini.cache_ttlのデフォルト値である300秒後に反映）
session.upload_progress.enabled = 0

# .htaccess（mod_php、AllowOverride Optionsが必要）
php_flag session.upload_progress.enabled off

3. WAF・リバースプロキシによる遮断

WAFやリバースプロキシで、PHP_SESSION_UPLOAD_PROGRESSというフィールド名を含むmultipartリクエストを遮断するか、アップロード機能がないパスへのmultipart POSTリクエストを遮断します。適用前に、正常なサービスが進捗追跡機能を使用しているかを確認します。

4. サポートが終了したバージョン

PHP 8.1以前など、サポートが終了したバージョンには公式パッチは提供されません。一時的な緩和策を直ちに適用し、サポート対象ブランチへのアップグレード日程を策定します。アップグレードが難しい場合は、ホスティング事業者やディストリビューションベンダーに、バックポートパッチを提供しているか確認します。

5. 侵害の有無の点検

パッチ公開前に脆弱性情報が流出したため、攻撃コードが短期間で登場する可能性があります。パッチ適用とは別に、上記の検知方法に従って、PHP-FPMの異常終了ログ、Webシェルの有無、異常な外部通信を必ず点検してください。

参考資料

• PHPセキュリティチームの告知： Upcoming Critical PHP Security Release
• watchTowr, PHP Remote Code Execution FAQ (CVE-2026-109618 & CVE-2026-109619)
• Huntress, Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
• Sansec, Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
• SecurityWeek, PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws
• Phoenix Security, PHP Core RCE (CVE-2026-109618, CVE-2026-109619)
• Mallory, PHP's Critical RCE Fixes Skip 884,000 Internet-Facing Hosts
• lilting.ch, Disabling session.upload\_progress Before the php2shell Patch Lands
• J4ck3LSyN, php-up-2026