セキュリティ

PHPの重大な脆弱性「php2shell」。影響範囲と、企業が取るべき対応

2026年10月21日、PHPに認証なしでコードを実行される脆弱性2件の修正版が公開されました。国内でも多くのサービスが予防的に停止し、公開前から攻撃が観測されています。この記事では、何が起きたのか、自社に影響があるのか、何をすべきかを、2026年10月22日時点の情報で整理します。

何が起きたのか

2026年10月21日、PHP公式が重大な脆弱性2件を修正したセキュリティリリースを公開しました。通称「php2shell」と呼ばれています。

• CVE-2026-109618／リクエストの初期化中にメモリ確保が失敗すると、不完全な状態が残る。後続のリクエスト終了処理がそのデータを使うことでコード実行につながる
• CVE-2026-109619／致命的エラーの発生時に内部データが消えずに残る。解放済みメモリへの参照が残り、後続のリクエストがそれを使うことでコード実行につながる

どちらも深刻度はCVSS v4.0で9.2（Critical）。認証を一切必要とせず、外部から任意のコードを実行できる点が重大です。攻撃が成立すれば、Webサーバーの権限でそのまま乗っ取られます。

特に危険とされているのがApacheのmod_php構成です。アプリケーション側のコードが動き出す前に攻撃が成立するため、アプリ側でどれだけ入力値を検証していても防げません。

影響を受ける環境

PHP公式は、Webリクエストを処理しているPHP環境はすべて対象になりうるとしています。具体的には次の構成です。

• mod_php（Apache）／最も危険。アプリのコードが動く前に成立することが実証されている
• PHP-FPM／コード実行が実証済み。ただし成立条件はアプリケーションの作りに依存する
• php-cgi／対象
• FrankenPHP／対象
• LiteSpeed／対象

修正版はPHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35です。サポートが終了している7.4・8.0・8.1についても、PHP公式が最小限の修正をソースコードで提供しています。8.1以前は通常のリリースがないため、自動更新では直りません。

なお、PHPを使っていない構成（静的HTMLの配信、Node.jsやGoで書かれたアプリケーションなど）は対象外です。まず「自社のどこでPHPが動いているか」を確定させることが出発点になります。

公開までの経緯が異例だった

この脆弱性は、技術的な内容よりも公開までの流れが注目されました。

1. 2026年8月、AIを使った調査で発見される。Calif社のRyan Austin氏、OpenAI、Wizがそれぞれ独立してPHPへ報告した
2. 10月20日、修正版の公開を予告。同日、CVE番号がSNSや掲示板に流出する
3. PHPは公開を1日前倒しし、10月21日リリースに変更。理由は攻撃の観測ではなく、番号が予定より早く出回ったこと
4. さらに発見者側が攻撃の実演動画を誤って公開。削除後も拡散した
5. 10月21日、修正版を公開

発見者のAustin氏は、2004年に報告されたメモリ上限まわりの問題に「取りこぼしが残っているのではないか」という仮説を立て、AIへの問いを重ねて数日で経路にたどり着いたと説明しています。特別な仕組みや非公開のモデルは使っていないとしています。

既存のコードに潜む問題を、AIを使って短期間で掘り起こせることを示した事例でもあります。攻撃側も同じ手段を取れるため、「古いが動いているから触らない」コードの扱いを見直す必要が出てきます。

悪用の状況

修正版の公開前から攻撃が始まっていました。

• Hadrian／10月21日20時35分（日本時間）に大規模な悪用を観測。多くはsession upload progressの経路を悪用していた
• Patchstack／複数のホスティング事業者から悪用事例の報告を受けたと公表
• watchTowr／パッチ公開前後から自社センサーで試行を観測。成功した侵害はまだ見ていないとした
• Vega／10月22日未明、公開された実証コードを使った試行を観測

一方で、侵害に成功した事例の確認報告は、2026年10月22日時点では出ていません。米CISAの悪用確認リスト（KEV）にも未登録です。ただし攻撃は継続しているため、状況は変わりえます。

取るべき対応

優先順位は明確です。更新が本筋で、それ以外はすべて時間稼ぎです。

1. PHPのバージョンを確認する。サーバー上で php -v を実行し、8.5.12／8.4.27／8.3.36／8.2.35以上かを見る
2. 修正版に更新する。レンタルサーバーの場合は事業者の対応状況を確認する
3. 8.1以前を使っている場合は、公式の最小限パッチを適用する。通常の更新では提供されない
4. 更新後、ワーカープロセスを再起動する。再起動しないと古いプロセスが残る
5. 更新前に侵害されていないかを確認する。確認点は後述

すぐに更新できない場合の暫定回避策も公表されていますが、いずれも完全ではありません。

• CVE-2026-109618向け／memory_limit=-1 に設定し、アプリ側で上書きされないようにしてワーカーを全再起動する。RLIMIT_AS・RLIMIT_DATA は脆弱な経路を踏むため使わない
• CVE-2026-109619向け／php.ini で session.upload_progress.enabled=0 を設定する。ini_set() や .user.ini ではなく php.ini に書く必要がある
• WAF／Cloudflareなどが10月21日から防御を開始。ただし有効化されているか、DNSをWAF経由にしているかの確認が要る。いずれにせよ更新の代わりにはならない

更新前に攻撃を受けていないかは、次の3点を見ます。

• アクセスログ／不自然なリクエストが集中していないか。特にsession upload progressに関わる経路
• ファイル／身に覚えのない .php ファイルが置かれていないか。更新日時が不自然なものも含む
• アカウント／作った覚えのない管理者アカウントが増えていないか

※ エラーを画面に出していない、ログに何も出ていない、という状態は「安全である」ことの証明にはなりません。

国内の動き

情報処理推進機構（IPA）と国家サイバー統括室が10月21日に注意喚起を出し、PHPを使っているプログラムの棚卸しと、速やかにパッチを当てられる体制の整備を呼びかけました。

国内では54組織以上が、修正版の公開前にサービス停止や緊急メンテナンスを告知しています。ECサイト、ゲーム、保育施設向けサービス、官公庁のシステム、大学まで業種を問いません。

これは「攻撃を受けたから止めた」のではなく、パッチが出た瞬間から攻撃が本格化することを見越して、先に止めた判断です。修正の内容が公開されれば、そこから攻撃手法を組み立てられるためです。

この件から読み取れること

個別の脆弱性への対応とは別に、押さえておきたい点が3つあります。

• 棚卸しができていないと動けない／どのサーバーでどのバージョンのPHPが動いているかを即答できる状態になっていないと、影響判断に半日を使うことになる。一覧は平時に作っておくもの
• サポート終了バージョンの扱いを決めておく／今回は公式が例外的にEOL版へパッチを出したが、次も出るとは限らない。「動いているから触らない」はコストを先送りしているだけ
• 公開前に止める判断を、誰が下すかを決めておく／今回、国内の多くの組織が予防的に止めた。この判断は現場だけでは下せない。事前に権限と基準を決めておかないと、当日の数時間を調整に使う

脆弱性そのものは防げませんが、公表されてから動き出すまでの時間は、平時の準備で短縮できます。