PHPの緊急脆弱性「php2shell」（CVE-2026-109618/109619）修正版公開｜影響・対象・今すぐやるべき対策を徹底解説

最新情報（随時更新）

公開情報をもとに、新しい順に追記しています。時刻は日本時間です。海外のセキュリティ企業などの情報は、PHP 公式が確認したものではない点にご注意ください。

1. 10/21 23:12 確認
   Ubuntu が修正パッケージを公開（USN-8948-1）。番号は 8.5.12 などにならない点に注意
   Ubuntu は CVE-2026-109618・CVE-2026-109619 を修正した PHP パッケージを公開しました。修正版のパッケージ番号は、26.04 LTS が 8.5.4-0ubuntu1.5、24.04 LTS が 8.3.6-0ubuntu0.24.04.13、22.04 LTS が 8.1.2-1ubuntu2.28 などです。修正だけを取り込む形のため、PHP 公式の 8.5.12 などとは番号が一致しません。Ubuntu のサーバーは、パッケージを更新したうえで PHP-FPM や Apache を再起動してください。
   出典：Ubuntu Security Notice USN-8948-1
2. 10/21 22:49 確認
   PHP 公式が修正版 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 を公開。すぐに更新を
   PHP 公式は、認証なしでリモートからコードを実行されるおそれがある脆弱性2件（CVE-2026-109618・CVE-2026-109619）を修正した PHP 8.5.12、8.4.27、8.3.36、8.2.35 を公開し、すべての利用者にすぐ更新するよう呼びかけました。対象は Web のリクエストを処理するすべての PHP（PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed）で、mod_php が最もリスクが高いとしています。8.1 以前は更新対象外ですが、7.4・8.0・8.1 向けに最小限のソース修正も出ています。予定の 23:00 より前の公開でした（編集部は 22:49 に確認）。
   出典：php.net
3. 10/21 21:15（日本時間）
   エックスサーバーが告知を更新。利用者のサーバーに緩和策を順次適用、修正版の公開後は各PHPバージョンに適用予定
   エックスサーバーは告知のよくある質問で、利用者のサーバーにも修正版公開前の緩和策を含む安全対策を順次適用していると説明しました。修正版の公開後は、提供している各PHPバージョンに公式の修正版や同社独自の修正を順次適用する予定で、利用状況によっては管理画面の再開後に利用者へ追加の対策を依頼する場合があるとしています。
   出典：エックスサーバー
4. 10/21付（時刻の記載なし）
   IPA が「事前準備のお願い」を公開。ConoHa WING も緊急メンテナンス
   IPA は、PHP を使っているシステムの棚卸しと、修正版をすぐ適用できる準備を呼びかけています。サポートが終わった古い PHP を使い続けているサイトがあることにも触れ、公表後できるだけ早い適用を求めています（掲載時刻の記載なし）。ConoHa WING は 19:00〜翌10:00 に一部サーバーで緊急メンテナンスを実施します。
   出典：IPA
5. 10/21 18:20（日本時間）
   KAGOYA・ロリポップが PHP を名指しして対応を告知
   KAGOYA はレンタルサーバー（PHP 8.2〜8.5系）を修正版の確認後に順次アップデートし、その他のプランは対応方針を調整中としています（18:20 更新）。ロリポップは予防措置として管理ページなどを順次停止し、必要と判断した場合は利用者のサイトを予告なく制限することがあると告知しました。
   出典：KAGOYA
6. 10/21 16:34（日本時間）
   海外で「悪用の報告あり」との情報。一方で IPA などは悪用を確認していない
   海外の WordPress セキュリティ企業 Patchstack は、複数のホスティング会社から悪用の報告を受けたとしています。Cloudflare も緊急の WAF ルールを追加しました。一方、IPA や一部の調査会社は実際の悪用を確認していないとしており、情報が分かれています。
   出典：Patchstack（英語）
7. 10/21 16:00（日本時間）
   エックスサーバーが管理画面などを予防的に停止。サイト表示・メールは通常どおり
   エックスサーバーは 16:00 から、公式サイト・サーバーパネル・WEBメールなどを予防的に停止しました。利用者のサイト表示とメールの送受信には影響がなく、再開は 21日深夜〜22日未明の見込みです。告知に PHP の名前はありませんが、「本日公表される予定」の脆弱性への対策としています。
   出典：エックスサーバー
8. 10/21 14:00（日本時間）
   「php.ini の設定変更だけでは防げない」。暫定策の効果は限定的と追記
   GMO Flatt Security は、当初示した暫定策（php.ini で session.upload_progress.enabled=0 にする）について「ややの緩和策に留まり、根本的にはパッチが必要」と追記しました。窓の杜も 15:20 に同じ趣旨を追記しています。パッチ公開までは攻撃とみられる通信の監視を続け、公開後すぐに適用することが勧められています。
   出典：GMO Flatt Security ブログ
9. 10/21 13:00
   Movable Type（シックス・アパート）が影響ありと告知。さくらのレンタルサーバも緊急メンテナンス
   シックス・アパートは、ダイナミックパブリッシングなどで PHP を使うため影響を受けると告知し、ソフトウェア版の利用者には修正版公開後の PHP 更新を強く勧めています。さくらインターネットはレンタルサーバなどで 13:00〜翌8:00ごろの緊急メンテナンスを実施中です（告知に PHP の記載はありません）。
   出典：シックス・アパート
10. 10/21 11:12（日本時間）
    GMO Flatt Security が分析を公開。「Session Upload Progress 機能に関係」と推定
    国内のセキュリティ企業 GMO Flatt Security が、この脆弱性（通称 php2shell）はメモリ破壊系で、初期設定で有効な Session Upload Progress 機能に関係すると推定する分析を公開しました。研究者の投稿では mod_php・PHP-FPM、WordPress・Laravel・Symfony などの構成で再現したとされています。
    出典：GMO Flatt Security ブログ
11. 10/20付（協定世界時・時刻の記載なし）
    PHP公式が「重大なセキュリティリリース」を予告。日本時間 21日23:00 公開予定
    PHPのセキュリティチームが php.net で、Critical（致命的）な脆弱性2件を修正するリリースを 10月21日 14:00（協定世界時）＝日本時間 23:00 に出すと告知しました。CVSS 4.0 の基本値はどちらも 9.2。影響を受けるバージョンと修正版はリリースと同時に公開され、悪用の証拠が出た場合などは前倒しもあり得るとしています。※告知は10月20日付（時刻の記載なし）。
    出典：php.net（英語）
12. 10/21 00:20（日本時間）
    海外の掲示板に「PHPのRCE（遠隔からのコード実行）2件が近く公開される」との投稿
    協定世界時 10月20日15:20（日本時間 21日0:20）、Hacker News に PHP の深刻な脆弱性2件が近く公開されるとする投稿があり、攻撃ツール「PHP2Shell」の画面とされる画像も出回りました。本来の公開日は 10月22日だったとされ、情報が漏れた形です（いずれも海外のセキュリティ企業の分析による未確認情報）。
    出典：Sansec（英語）

php2shell とは？何が起きているのか

「php2shell」は、Web サイトを作るためのプログラミング言語 PHP 本体に見つかった、2件の深刻な脆弱性の通称です。研究者の投稿で使われた呼び名で、PHP 公式の名前ではありません。

なぜここまで騒がれているのか

理由は3つあります。1つ目は、PHP を使っているサイトが非常に多いこと。サーバー側の言語が分かるサイトの約7割が PHP だという調査もあります［ITmedia が W3Techs を引用］。WordPress で作られたサイトの多くもここに含まれます。

2つ目は、アプリより手前で攻撃が成立するとみられること。海外の分析では、PHP がリクエストを受け取って解析する段階の問題とされており、WordPress やプラグインをどれだけ最新にしていても、PHP 本体が古ければ防げません［Sansec］。

3つ目は、修正前に情報が漏れたことです。本来の公開日は 10月22日だったとされますが、情報が出回ったため PHP が日程を前倒ししました［SOCRadar・abgeo.dev］。海外の調査会社は「リリースから15分以内に大規模な攻撃が始まる」と予想しています［Sansec］。

原因は？（PHP 公式の発表）

PHP 公式の発表では、2件の中身は次のとおりです［php.net］。

• CVE-2026-109618（メモリ不足時の処理の不具合）：メモリ不足の処理で PHP が途中で止まると、リクエストの内部データが中途半端なまま後片付けされ、それを正しいデータとして扱ってしまう。
• CVE-2026-109619（解放済みの状態が残る不具合）：リクエストごとの内部の状態が、メモリを解放したあとも残り、同じワーカーが処理する次のリクエストで使われてしまうことがある。

mod_php では、認証なしの1回のリクエストで、アプリのコードが動く前に攻撃が成立することが実証されているとしています。

すぐに更新できない場合の緩和策（PHP 公式）

PHP 公式は「完全な対策は更新だけ」としたうえで、攻撃の経路を減らす設定を挙げています［php.net］。どれも安全にするものではありません。

• CVE-2026-109618 向け：memory_limit=-1（アプリから上書きできない形で）、post_max_size を小さくする（アップロード不要なら 8M、必要なら 32M）、Webサーバー側でリクエストの大きさや項目数を制限する
• CVE-2026-109619 向け：session.upload_progress.enabled=0 にしてワーカーをすべて再起動（php.ini などで。ini_set() や .user.ini では効かない）。PHP 8.5 では fatal_error_backtraces=0 も

設定の変更でサイトの動きが変わることがあります。レンタルサーバーでは変えられない項目もあるので、まずは修正版への更新を優先してください。

どんなサイトが対象になるのか

PHP 公式は、Web のリクエストを処理するすべての PHP が対象としています。なかでも、次のようなサイトは特に注意が必要です。

自社サイトが対象か確かめる方法

1. PHP で動いているかを確かめる

WordPress で作られたサイト（URL に /wp-content/ や /wp-admin/ が含まれる）は PHP で動いています。分からない場合は、サイトを作った制作会社や、サーバーの契約内容を確認します。

2. PHP のバージョンを確かめる

• レンタルサーバー：管理画面（サーバーパネル・コントロールパネル）の「PHP バージョン設定」などで確認できます。
• WordPress：管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」に PHP のバージョンが表示されます。
• VPS・専用サーバー：コマンドの php -v に加えて、Web サイト側で動いている PHP（PHP-FPM など）のバージョンも確認します。両者が別のことがあります。

3. サーバー会社・制作会社の告知を確かめる

レンタルサーバーを使っている場合、サーバー会社が PHP 本体を更新するのが一般的です。各社の告知ページで、対象プランと更新の予定を確認してください（各社の状況）。

今すぐやるべきこと

IPA は「棚卸し」「PHP Group や開発元の情報を見張る」「すぐ適用できる準備」の3つを求めています。中小企業の場合は、次の順で進めるのが現実的です。

1. PHP を使っているものを洗い出す：コーポレートサイト、採用サイト、EC、予約システム、問い合わせフォーム、社内ツールなど。制作会社に任せているサイトも含めます。
2. 誰が更新するのかを決める：レンタルサーバーならサーバー会社、VPS・クラウドなら自社か保守業者。連絡先と、いつ誰が更新するかをすぐに決めます。
3. バックアップを取る：ファイルとデータベースを丸ごと保存し、更新で不具合が出ても戻せるようにします。
4. 管理画面で PHP のバージョンを確認する：8.1 以前なら、サポート中のバージョンへの切り替えを準備します（後述）。
5. サーバー上の情報と権限を減らす：不要なデータを置かない、クラウドの権限を最小にする、ログが残る設定か確かめる［GMO Flatt Security］。
6. すぐに更新できない重要なサイトは、一時停止も選択肢：決済や個人情報を扱うサイトで更新の見込みが立たない場合、公開を止めることも検討します［CERT-EU］。

修正版に更新したあとにやること

1. 公式の発表で、影響バージョンと修正版を確認する：php.net のリリースノートと、自社の PHP のバージョンを照らし合わせます。
2. 修正版に更新し、Web サーバー・PHP-FPM を再起動する：古いプロセスが残っていると修正が効かないことがあります。
3. 実際に動いている PHP のバージョンを確かめる：Web サイト側で確認します。Linux ディストリビューションの PHP は、番号が上がらずに修正だけ取り込まれることがあるため、更新履歴で CVE 番号を確認します。
4. サイトの表示と動作を確かめる：トップページ、フォームの送信、ログイン、決済など。
5. 乗っ取られていないかを確かめる：見覚えのないファイルや管理者アカウント、新しく登録された定期実行（cron）、Web サーバーから不審なコマンドが実行された跡がないかを確認します。リーク（10月20日）から更新までの期間を重点的に見ます。
6. 怪しい点があれば：サーバーを切り離し、ログを保全したうえで、データベースのパスワードや API キーなどを変更します。

レンタルサーバー各社の対応状況

各社の公式告知で確認できた内容です（10/21 23:12 時点）。最新の情報は各社のページをご確認ください。

古い PHP のままのサイトはどうする？

PHP には、バージョンごとにサポート期間があります。サポートが終わったバージョンには、セキュリティの修正も出ません［php.net］。

PHP 8.1 以前のサイトは、今回の修正が公式には出ない見込みのため、サポート中のバージョンに切り替える必要があります。8.2 もまもなくサポートが終わるので、切り替えるなら 8.4 か 8.5 がおすすめです。

ただし、PHP のバージョンを上げると、古いテーマやプラグイン、独自のプログラムが動かなくなることがあります。いきなり本番で切り替えず、検証用の環境で表示と動作を確かめてから切り替えるのが安全です。古いサーバーでは新しい PHP を選べない場合もあり、その場合は新しいサーバーへの引っ越しが必要になります。

よくある質問

WordPress を最新にしていれば大丈夫ですか？

いいえ。今回は PHP 本体の問題なので、WordPress やプラグインの更新では防げません。サーバーの PHP を修正版にする必要があります。

レンタルサーバーなら何もしなくていいですか？

PHP 本体の更新はサーバー会社が行うことが多いですが、管理画面でサポートの終わった古い PHP を選んでいる場合は、ご自身で切り替える必要があります。サーバー会社の告知もあわせて確認してください。

php.ini の設定を変えれば防げますか？

防げません。PHP 公式も「完全な対策は更新だけ」としています。公式が挙げた緩和策（session.upload_progress.enabled=0 や memory_limit=-1 など）は、確認された攻撃の経路を減らすだけです。修正版（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35）への更新を優先してください。

すでに攻撃されているか分かりますか？

見覚えのないファイルや管理者アカウント、不審な定期実行の登録、アクセスログなどから確認できます。ご不安な場合はご相談ください。

参考にした情報

• php.net（PHP 公式の告知） / サポート中のバージョン
• IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」
• CERT-EU Security Advisory 2026-018
• GMO Flatt Security ブログ
• 窓の杜（Yahoo!ニュース）
• Sansec / Patchstack / abgeo.dev / SOCRadar
• ITmedia NEWS