【PHP脆弱性 php2shell】CVE-2026-109618・109619（CVSS 9.2）とは？影響範囲・修正版・今すぐやるべき対策

2026年10月21日、PHPの開発元（The PHP Group）が、認証なしで遠隔からサーバー上のコードを実行される（RCE）重大な脆弱性2件を修正したセキュリティリリースを公開しました。CVE番号は CVE-2026-109618 と CVE-2026-109619、深刻度はいずれも CVSS v4.0 で 9.2（Critical） です。セキュリティ業界では「php2shell」と呼ばれています。

PHPはWordPress・Laravel・Drupal・EC-CUBEなど、国内の多くのWebサイトや業務システムの土台になっている言語です。公開前から情報が漏れて攻撃コードが出回ったこともあり、高市早苗首相が自身のXで「今夜に対応して頂きたい大至急のお願い」と国民に呼びかける異例の事態になりました。

この記事では、Webサイトや業務システムを運用している企業の担当者に向けて、何が起きたのか、自社が影響を受けるのか、今すぐ何をすべきかを図解で整理します。

結論：PHPを使っているなら、いますぐ修正版へ更新してください。 PHP 8.1以前は公式の修正版が出ません。設定による緩和策は一時しのぎで、完全な対策は更新だけです。

php2shell（CVE-2026-109618・109619）の概要

項目	内容
CVE番号	CVE-2026-109618 / CVE-2026-109619
通称	php2shell
深刻度	CVSS v4.0 基本値 9.2（Critical）※2件とも
脆弱性の種類	認証不要のリモートコード実行（RCE）、解放後使用（Use After Free）など
修正版	PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
修正版の公開	2026年10月21日（日本時間の夜）
公式アドバイザリ	GHSA-w8hw-w9fx-j79w / GHSA-6wmf-4rv5-p3rp

CVSSベクトルは2件とも CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N です。ネットワーク越しに、ログインなしで攻撃でき、成功すると被害が大きいという評価です。なお、セキュリティ企業 watchTowr は、より深刻な CVSS 10.0 と評価しています（GMO Flatt Securityより）。

攻撃の仕組み

• CVE-2026-109618：メモリ不足（OOM）で処理が中断されたとき、準備途中のデータが残ってしまう。Apache の mod_php では既定の設定のまま攻撃が成立すると検証されています（GHSA-w8hw-w9fx-j79w）
• CVE-2026-109619：解放済みのメモリを指す状態がワーカーに残り、次のリクエストが使ってしまう。既定で有効な「セッションのアップロード進捗」機能を使い、mod_php と PHP-FPM の両方で攻撃が確認されています（GHSA-6wmf-4rv5-p3rp）

なぜここまで大きな騒ぎになったのか

今回の件が大きく報じられたのには、4つの理由があります。

1. 修正版の前に情報が漏れた：PHP公式の予告（PHP公式）と同じ頃、伏せられていた情報が外部に漏れた（piyolog）
2. 攻撃コードが出回り始めた：悪用できると主張するコードがネット上に出回り始めた（GMO Flatt Security）
3. 対象が桁違いに多い：影響を受けうる公開サーバーは 2,260万件以上 と推計（Unit 42。侵害の件数ではない）
4. 首相が直接呼びかけた：高市首相がXで、PHPの確認と修正パッチの適用準備を求め、すぐ適用できなければサイトの一時停止も有効とした（高市早苗氏の投稿。2,700万回以上表示）

国内外の主な動き（時系列）

人気ゲーム、ネットショップ作成サービス、保育施設向けのサービス、行政のシステム、大学のサイトなど、業種を問わず停止が広がりました（piyolog。停止の理由にPHPを挙げていない組織も含む）。

影響を受けるPHPのバージョンと環境

対象のバージョン

PHP公式のアドバイザリでは、8.2.35未満・8.3.36未満・8.4.27未満・8.5.12未満が影響を受けるとされています。

注意したいのが PHP 8.1以前 です。公式の修正版は出ません。GMO Flatt Security は PHP 5・7・8系に広く影響すると考えるべきとしています。PHP公式は7.4・8.0・8.1向けの最小限の修正も公開していますが、自分でビルドする必要があります。

また、8.2系は今回の修正版で解消しますが、2026年12月31日でサポートが終わることがPHP公式から改めて案内されています。あわせて 8.3 以降への移行を計画しておきましょう。

対象の環境

PHP公式によると、PHP-FPM、Apache（mod_php）、php-cgi、FrankenPHP、LiteSpeed など、Webのリクエストを処理するあらゆるPHPの実行環境が対象です。中でも最もリスクが高いのは Apache の mod_php で、アプリケーションのコードが動く前の段階で、未認証のリクエストによって攻撃できる実証済みのコードがあるとされています。

WordPress・Laravelなどのアプリ側の対応は？

今回の脆弱性は PHPそのものの問題です。WordPress の公式ブログは、WordPress 本体の更新は不要で予定もないとしたうえで、サイトを動かしているPHPを直ちに更新するよう呼びかけています（WordPress.org）。Laravel・Symfony・Drupal なども同じで、フレームワークやプラグインを最新にしても、この脆弱性は直りません。Cloudflare も、アプリのコードやプラグインの更新だけでは修正されないと注意しています（Cloudflare）。

自社のサイトが影響を受けるか確認する方法

1. PHPを使っているシステムを洗い出す

IPAは事前準備として、自組織で開発・運用しているプログラムのうちPHPを使っているものの棚卸しを推奨しています。製品の中にPHPが組み込まれている場合は、マニュアルや開発元のセキュリティ情報で確認するよう求めています（IPA）。

見落としやすいのは次のようなものです。

• コーポレートサイトとは別に立てた、キャンペーンサイトや採用サイト
• 問い合わせフォームや予約フォームだけをPHPで動かしているサーバー
• 社内の勤怠・ワークフロー・グループウェアなど、PHPで作られた業務システム
• 制作会社に任せたままで、社内に管理者がいないサイト

2. PHPのバージョンを確認する

サーバーにログインできる場合は、次のコマンドでバージョンを確認できます。

php -v

ただし、コマンドラインのPHPと、Webサーバーが使うPHP（PHP-FPMやmod_php）のバージョンが違うことがよくあります。PHP-FPMを使っている場合は、次も確認しましょう。

php-fpm -v                    # 環境によって php-fpm8.3 -v など
apachectl -M | grep -i php    # Apache で mod_php が読み込まれているか

WordPress なら、管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」でもPHPのバージョンが分かります（WordPress.org）。レンタルサーバーの場合は、各社のコントロールパネルで確認できることが多いです。

3. Linuxのパッケージは「修正済みかどうか」で判断する

Ubuntu や Red Hat 系などのLinuxディストリビューションは、**PHPのバージョン番号を上げずに修正だけを取り込む（バックポート）**ことがあります。PHP公式によると、ディストリビューションには事前に修正が提供されていました。番号だけで判断せず、パッケージが修正済みの版になっているかを確認してください。

たとえば Ubuntu は、サポート中のリリースの標準のPHPに修正を取り込んだパッケージを出しています（Ubuntu の案内）。

Ubuntu	パッケージ	修正済みの版
24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
22.04 LTS	php8.1	8.1.2-1ubuntu2.28
20.04 LTS 以前	php7.4 など	Ubuntu Pro（ESM）で提供

このように、OS標準のパッケージなら、PHP 8.1 などでも修正が提供されている場合があります。更新したら、Apache や PHP-FPM の再起動を忘れないでください。自動更新（unattended-upgrades）で修正が入っても、再起動は別途必要です。

# Debian / Ubuntu の例
sudo apt update && apt list --upgradable 2>/dev/null | grep -i php
# RHEL / AlmaLinux / Rocky Linux の例
sudo dnf check-update | grep -i php

なお、PHP公式は、有志が運営する rpms.remirepo.net（Remi リポジトリ）を使っている場合は、ディストリビューションのパッケージかソースからのビルドに切り替えるよう案内しています。公式の発表時点で、同リポジトリには当日の更新がなかったためです。

今すぐやるべき対策

最優先：PHPを修正版に更新する

PHP公式も、完全な緩和策はなく、更新だけが安全な選択肢だとしています（PHP公式）。更新のしかたは、PHPがどこで動いているかで変わります。

再起動を忘れずに。 再起動しないと、古いPHPのワーカーが動き続けます。PHP 8.1以前は、8.3以降への移行が必要です。アプリの改修を伴うことが多いので、移行までは下の緩和策や一時停止で時間を稼ぎます。

すぐに更新できない場合の緩和策（一時しのぎ）

どれも攻撃のすべての経路は防げません。 GMO Flatt Security も、設定の無効化は緩和にとどまるとしています。

CVE-2026-109619 向け（php.ini や FPM のプールの設定で行い、すべてのワーカーを再起動）：

session.upload_progress.enabled = 0
; PHP 8.5 の場合
fatal_error_backtraces = 0

CVE-2026-109618 向け：

; アプリから上書きされないよう、FPM のプールや Apache の設定で強制する
php_admin_value[memory_limit] = -1
; ファイルのアップロードが不要なら 8M、必要なら 32M 程度に絞る
post_max_size = 8M
upload_max_filesize = 8M

あわせて、次の対策も挙げられています。

• Webサーバーやリバースプロキシで、リクエストの大きさ・入力項目の数・マルチパートのパート数・ヘッダーの数を制限する
• ファイルのアップロード（マルチパートのフォーム）を使わないサイトでは、その形式のリクエストを遮断する
• PHP-FPM で pm.max_requests=1 にしてワーカーの使い回しを止める（性能は落ちる）
• RLIMIT_AS や RLIMIT_DATA でメモリを制限しない（かえって脆弱な処理を引き起こすおそれがあるとPHP公式が注意）

ini_set() や .user.ini での設定変更では効かない点にも注意が必要です。

WAF（Webアプリケーションファイアウォール）で時間を稼ぐ

各社のWAFが防御ルールを出しています。Cloudflare は、正式公開の約9時間前から、無料プランを含むWAFの利用者に既定で防御を適用したと発表しました（Cloudflare）。Palo Alto Networks や Akamai もシグネチャを提供しています。

ただし、Cloudflare は同時に、攻撃者がWAFをすり抜けようと攻撃の中身を変えてきていることも観測しています。WAFは更新までの時間を稼ぐものであり、PHPの更新の代わりにはなりません。

それでも対応できないなら、サイトを一時停止する

首相の投稿や WordPress.org の案内でも触れられているとおり、すぐに修正できないサーバーは、一時的に止めることがリスクを下げる有効な手段です。問い合わせフォームが止まるなどの影響はありますが、サーバーを乗っ取られて顧客情報が漏れたり、他社への攻撃の踏み台にされたりする損害と比べれば小さく済みます。

更新したあとにやるべきこと：侵害されていないかの確認

修正版を当てても、更新前にすでに侵入されていたら、その被害は消えません。Unit 42 や Cloudflare は実際の攻撃の通信を観測したと公表しています（セキュリティ対策Lab のまとめ。watchTowr や Huntress は悪用を観測していないとしており、情報は割れています）。

エラーログでは Allowed memory size exhausted や signal 11（segfault）が目印になります。

よくある質問

php2shellとは何ですか？

2026年10月に公表されたPHPの重大な脆弱性2件（CVE-2026-109618 と CVE-2026-109619）の通称です。どちらも、ログインなしで外部からサーバー上のコードを実行される（RCE）おそれがあり、CVSS v4.0 で 9.2（Critical）と評価されています。

WordPressを最新版にすれば大丈夫ですか？

いいえ。今回の脆弱性はPHPそのものの問題なので、WordPress 本体やプラグインを更新しても直りません。WordPress を動かしているPHPを、修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）以降に更新する必要があります。

レンタルサーバーを使っている場合、自分で何かする必要はありますか？

多くの事業者がPHPの更新やWAFの適用を進めていますが、どのバージョンのPHPを使うかを利用者が管理画面で選ぶサービスでは、古いバージョンを選んだままだと修正されないことがあります。事業者の告知を確認し、サポート対象のバージョン（8.3以降を推奨）を選んでください。

PHP 7.4 や 8.0 を使っています。どうすればいいですか？

PHP公式の修正版は提供されません。ただし、Ubuntu 22.04 の php8.1 のように、OS標準のパッケージで修正が提供されている場合があるので、まず OS の更新を確認してください。自分でビルドしたPHPや、修正が提供されない環境では、サポート対象のバージョンへの移行が根本的な対策です。移行が終わるまでは、この記事の緩和策とWAFで時間を稼ぎつつ、リスクが高い場合はサイトの一時停止も検討してください。

設定を変えれば、更新しなくても安全ですか？

安全ではありません。session.upload_progress.enabled=0 や memory_limit=-1 などの設定は、攻撃の一部の経路を塞ぐ一時しのぎです。PHP公式も、完全な緩和策はなく、更新だけが安全な選択肢だとしています。

CVSS 9.2とはどのくらい危険ですか？

CVSSは脆弱性の深刻度を0.0〜10.0で表す国際的な指標で、9.0以上は最も深刻な「Critical（緊急）」に当たります。今回は、ネットワーク越しにログインなしで攻撃でき、成功するとサーバーを乗っ取られるおそれがあるため、この評価になっています。

まとめ

• PHPに、認証なしでサーバーを乗っ取られるおそれのある脆弱性2件（php2shell、CVE-2026-109618・109619、CVSS 9.2）が見つかった
• 修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。PHP 8.1以前は公式の修正がなく、移行が必要
• WordPress・Laravel などアプリ側の更新では直らない。PHPそのものの更新と、PHP-FPM・Apache の再起動が必要
• すぐ更新できないなら、緩和策・WAF・サイトの一時停止で時間を稼ぐ
• 更新したあとも、10月20日以降のログを確認し、侵害の痕跡がないかを調べる

PHPで動くサイトは、作ったあと何年も更新されないまま動き続けていることが少なくありません。今回をきっかけに、どのサーバーで、どのバージョンのPHPが動いているかを一覧にし、定期的に更新する体制を整えておくことをおすすめします。

参考資料

• PHP公式ニュース（セキュリティアドバイザリ・各修正版のリリース告知）
• GHSA-w8hw-w9fx-j79w（CVE-2026-109618）- PHP公式アドバイザリ
• GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）- PHP公式アドバイザリ
• 【事前準備のお願い】PHPのセキュリティリリース公開予定について - IPA
• 高市早苗氏のXへの投稿（2026年10月21日）
• PHPの重大な脆弱性「php2shell」の概要と対応指針 - GMO Flatt Security Blog
• 修正予告されたPHPの2件の深刻な脆弱性についてまとめてみた - piyolog
• CVE-2026-109618・CVE-2026-109619 の脅威情報 - Palo Alto Networks Unit 42
• PHPの脆弱性に対するWAFの防御 - Cloudflare Blog
• Critical PHP Security Release - WordPress.org
• php2shell の修正版の提供について - Ubuntu
• PHPの重大な脆弱性 php2shell 修正版公開、悪用試行と各社の防御策 - セキュリティ対策Lab