PHP本体に認証なしでコード実行の脆弱性「PHP2Shell」。8.5.12等への更新が必要

📖 この記事で分かること

• PHP2Shell(CVE 2件)で何が起きるか
• 修正版の版番号と、公式の修正が出ない古い系統
• すぐ更新できない場合に公式が挙げる緩和策
• 発見から攻撃コードの実証までをAIが支えたこと

💡 知っておきたい用語

• 遠隔コード実行(RCE【アールシーイー】):外から送りつけたデータで、サーバーに好きな命令を実行させてしまう攻撃。家の外から勝手に家電を操作されるようなものです。
• mod_php:Web サーバーの Apache の中に PHP を直接組み込んで動かす方式。古くからある構成で、今回は公式が最も危険と評価しています。

最終更新日: 2026年10月22日

▶ 公式ページ

• PHP 公式: セキュリティアドバイザリ(2026年10月21日)(php.net)
• PHP 公式: 修正版のダウンロード(php.net)
• Wiz Research: PHP2Shell の発表(Wiz)

PHP2Shell で何が起きたか

この記事のポイント

• PHP は 2026 年 10 月 21 日、本体の脆弱性 2 件(CVSS v4.0 で 9.2)を修正した PHP 8.5.12 などを公開しました(2026年10月時点)。
• 認証なしのリクエストでコードを実行される恐れがあり、公式は mod_php を最も危険としています。
• 8.2〜8.5 系は修正版への更新が必要です。8.1 以前に公式の修正リリースはありません。
• 発見した Wiz は、Gemini 4 Argon と GPT-5.6 Sol を調査に使ったとしています(2026年10月時点)。

PHP で動く Web サイトやサービスを運用している人は、いま動いている PHP の版をすぐに確かめる必要があります。WordPress や Drupal を自前のサーバーやコンテナで動かしている場合も対象です。

PHP は 10 月 21 日、「Security advisory: Critical remote code execution vulnerabilities, update now」と題した告知で、PHP 本体(インタープリタ)の脆弱性 CVE【シーブイイー】-2026-109618 と CVE-2026-109619 を修正した版を公開しました。2 件とも深刻度の指標 CVSS【シーブイエスエス】v4.0 で 9.2 と評価されています。発見した Wiz はこの 2 件をまとめて「PHP2Shell」と呼んでいます。

公式の告知によると、対象は Web リクエストを処理するすべての PHP で、PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が含まれます。公式は mod_php の危険度を最も高く見ており、認証のないリクエストが、アプリケーションのコードが動く前に攻撃を起こせることを実証済みとしています。

PHP は前日の 20 日、「Upcoming Critical PHP Security Release」として修正版の公開予定を予告していました。その予告の中で、脆弱性の詳細が公になったり、実際の悪用が確認されたりした場合は予定より早く公開する可能性があるとも書いていました。公表前日には CVE 番号がネット上に流出したとされています。実際の攻撃が出始めたとの報告もある一方、Huntress は 21 日夕方(米東部時間)の時点で、自社の監視先では悪用を確認していないとしています。

2 件の脆弱性と対象の版

2 件はどちらも、PHP が処理を途中で打ち切るときや、リクエストをまたぐときのメモリの扱いに原因があります。修正版が出ているのは 8.2〜8.5 の 4 系統だけです。

• CVE-2026-109618(RCE via OOM corruption): メモリ不足(OOM)の処理が、リクエストの内部データが途中までしか初期化されていない時点で PHP を中断させます。その後の後片付けの処理が、壊れたデータを正しいものとして扱ってしまいます。
• CVE-2026-109619(RCE via stale global state): リクエストが持つ内部の状態が、メモリを解放した後も残ります。同じワーカー(リクエストを処理するプロセス)が次に処理するリクエストが、通常の初期化より前にその古い状態を使ってしまいます。

Wiz は、過去 10 年に出たすべての PHP の版が少なくともどちらか 1 件の影響を受けるとしています。

運用者がいま確かめること

確かめるのは、動いている PHP の版と、PHP をどの方式で動かしているかの 2 点です。たとえば、自社サイトを WordPress で作り、VPS 上の Apache(mod_php)で動かしている担当者は、公式が最も危険とする構成にそのまま当てはまります。

• 版: 8.2〜8.5 系なら、上の表の修正版へ上げます。Linux ディストリビューションの PHP パッケージを使っている場合は、配布元のセキュリティ情報に CVE-2026-109618 と CVE-2026-109619 の修正が載っているかで確かめるのが確実です。
• コンテナ: PHP 入りのイメージを使っている場合は、修正版のイメージで作り直して再デプロイします。Google Cloud も、GKE の利用者や、ベースイメージの自動更新を切っている Cloud Run の利用者に、この対応を求めています。
• 8.1 以前: 公式の修正リリースはありません。7.4 / 8.0 / 8.1 向けの修正はソースコードとして公開されているもので、使うには自分でビルドする形になります。Google Cloud は、PHP 8.2 以降への更新と再デプロイを利用者に求めています。

すぐに更新できない場合について、公式の告知は設定での緩和策を挙げています。

• CVE-2026-109618 向け: memory_limit=-1(FPM のプール設定や Apache 設定の php_admin_value で指定)と、post_max_size を小さく保つこと(ファイルのアップロードが無ければ 8M、必要なら 32M)。
• CVE-2026-109619 向け: session.upload_progress.enabled=0。PHP 8.5 では fatal_error_backtraces=0 も加え、どちらも全ワーカーの再起動が必要です。

ただし、GitHub 上のアドバイザリは CVE-2026-109619 について、設定だけで完全に防ぐ汎用の方法は無いとしています。緩和策は更新までのつなぎです。

クラウドやネットワーク側の防御も動いています。Google は、Cloud Armor のマネージドルールを有効にしている利用者は自動で保護されるとし、App Engine スタンダード環境(PHP 8.2 以降)には修正を自動で適用済みとしています。WAF【ワフ】で入口を絞っても、PHP 本体の欠陥はサーバーに残ることに変わりはありません。

発見から実証までを支えた AI

今回の脆弱性は、AI を使った調査で見つかり、攻撃コードの実証まで AI が支えています。

Wiz の公開した経緯によると、8 月 19 日に Wiz Atlas、Gemini 4 Argon、GPT-5.6 Sol を使って最初の脆弱性を発見し、20 日に Drupal、21 日に WordPress で認証なしのコード実行を確認しました。24 日に PHP のセキュリティチームへ報告し、PHP は 9 月 21 日に報告を受理して修正に着手しています。

Wiz は、2 件を組み合わせた攻撃スクリプトで、WordPress・Drupal・Joomla の公式最新コンテナイメージに対して、認証なしのコード実行ができたとしています。そのうえで「最先端の AI モデルと適切な道具があれば、1 人の研究者が 1 週間で、これまでなら世界トップのチームが数か月かけた仕事をこなせた」と書いています。Google も、Gemini 4 Argon が脆弱性の発見、攻撃コードの開発、攻撃の検知、修正の検証に大きく貢献したとしています。

Wiz は同時に、AI が複雑な攻撃コードを作る手間を減らすことで、これまで悪用が現実的でなかった脆弱性も狙われるようになると指摘しています。同じ力は、長年見逃されてきた欠陥を防御側が見つけて直す機会にもなる、というのが Wiz の見立てです。

編集部の見方

編集部は、今回は WAF やクラウド側の防御を待たず、PHP 本体を修正版へ上げることを最優先で進めるのが妥当だと見ています。

• 設定での回避に限界がある: GitHub のアドバイザリは、CVE-2026-109619 を設定だけで完全に防ぐ汎用の方法は無いとしています。CVE-2026-109618 の緩和策も、リクエストごとのメモリ上限を外すという、運用への影響を見極めてから入れたい内容です。
• 再現の条件が身近: Wiz は、特別な設定ではなく、WordPress・Drupal・Joomla の公式最新イメージで攻撃を実証しています。手を入れていない標準的な構成でも当てはまる話です。
• 猶予が短い: CVE 番号は公表前日に流出したとされ、公式も 20 日の予告で前倒し公開の可能性に触れていました。修正の公開から攻撃までの時間を、長く見積もる材料がありません。

生成AIを追ってきた立場から見ると、今回は「AI が脆弱性を見つけた」話にとどまりません。発見から攻撃コードの作成、修正の検証までを AI が支えた事例が、PHP のような基盤ソフトで公になった点に重みがあります。Wiz 自身が書くとおり、同じ道具は攻撃する側も使えます。修正版が出てから適用するまでの社内の段取りを、これまでより短い前提で組み直す時期に来ていると編集部は考えます。

この見方が変わる条件は、使っているクラウドやホスティング事業者が「修正済み」と明言している場合です。そのときは、自分で動く範囲は「版の確認」まで下がります。

よくある質問

Q: WordPress やプラグインを更新すれば直りますか?

A: 直りません。脆弱性は PHP 本体にあり、PHP そのものを修正版(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35)にする必要があります。

Q: mod_php ではなく PHP-FPM で動かしていれば安全ですか?

A: 安全ではありません。公式は PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed を含む、Web リクエストを処理するすべての PHP を対象としています。mod_php は、その中で最も危険度が高いという位置づけです。

Q: PHP 8.1 以前を使い続けている場合はどうなりますか?

A: 公式の修正リリースはありません。7.4 / 8.0 / 8.1 向けにはソースコードの修正が公開されていますが、使うには自分でビルドする必要があります。8.2 以降の修正版への移行が、公式の修正を受けられる道です。

まとめ

PHP は 10 月 21 日、本体の脆弱性 2 件「PHP2Shell」を 8.5.12・8.4.27・8.3.36・8.2.35 で修正しました。Web リクエストを処理するすべての PHP が対象で、公式は mod_php を最も危険としています。設定での緩和は完全ではなく、Wiz も完全な対策は PHP の更新だけだとしています。発見と攻撃の実証を AI が支えたことは、修正の適用を急ぐ理由にもなっています。

【用語解説】

• CVSS v4.0: 脆弱性の深刻度を 0〜10 の点数で表す共通の物差しの最新版。9.0 以上は最も重い「Critical」に当たります。
• ワーカー: Web サーバーの裏で、届いたリクエストを順番に処理するプロセス。1 つのワーカーが複数のリクエストを続けて処理するため、前のリクエストの状態が残ると次に影響します。
• バックポート: 新しい版で入れた修正を、古い版のコードにも移し替えること。

引用元:

• [1] Security advisory: Critical remote code execution vulnerabilities, update now(php.net)
• [2] RCE via stale global state(GHSA-6wmf-4rv5-p3rp)(GitHub / php-src)
• [3] PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet(Wiz)
• [4] Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619(Google Cloud)
• [5] Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities(Huntress)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。