PHP2Shell脆弱性（CVE-2026-109618）とは？PHPのRCEの影響範囲・修正版・今すぐやる対策

PHP2Shellは、PHP本体（php-src）で見つかった重大な脆弱性2件（CVE-2026-109618とCVE-2026-109619）の通称で、悪用されるとログインしていない攻撃者がWebサーバー上で任意のコードを実行できます（RCE）。対策は、PHPを修正版（8.5.12／8.4.27／8.3.36／8.2.35、またはディストリビューションの修正済みパッケージ）に更新し、Apache・PHP-FPMを再起動することです。PHP公式も「完全な対策は更新だけ」としています。

問題はPHPのランタイムそのものにあるため、WordPressやLaravelなど、上で動くアプリやCMSの書き方とは関係なく影響を受けます。WordPress本体やプラグインを更新しても直りません。

この記事でわかること

• PHP2Shell（CVE-2026-109618／CVE-2026-109619）の中身と危険度
• 影響するPHPのバージョンと修正版、Ubuntuの修正パッケージ
• Webで実際に動いているPHPのバージョンを確かめる方法
• 更新・再起動・侵害の確認までの手順
• すぐ更新できない場合の暫定策と、それぞれの副作用
• 2026年10月22日時点の悪用状況と、国内外の機関の発表

この記事が役に立つ人

PHPで動くWebサイトやシステムを運営している人（WordPressサイト、ECサイト、社内システム、レンタルサーバー、VPS、クラウド）、開発や保守を外部に委託している企業の担当者、停止しているサービスの利用者として「自分は何かすべきか」を知りたい人。

情報は2026年10月22日時点のものです。悪用状況や各機関の発表は短い間に変わるため、最新はPHP公式サイトとGitHubのセキュリティアドバイザリで確かめてください。

立場ごとに今すぐやること

PHPで動くサーバーを自分で管理しているなら、更新と再起動を最優先にしてください。サービスを使っているだけの人が、自分で何かを直す必要は基本的にありません。

どの立場でも、次のことは誤解されやすいので注意してください。

1. 更新したら再起動する。 パッケージを入れ替えても、動いているPHPのプロセスは古いままです。
2. 暫定策はどれも不完全。 WAFや設定変更は、更新までのつなぎにしかなりません。
3. サービスの予防的な停止は「侵害された」という意味ではない。 国内でも多くのサービスが念のため止めています。

PHP2Shell（CVE-2026-109618／CVE-2026-109619）とは

出典：PHP2Shell（php2shell.com）

PHP2Shellは、PHPのメモリの扱いに関する脆弱性2件をまとめた呼び名です。2件を組み合わせて認証なしのRCEを実証したエクスプロイトの名前でもあり、発見者の一社であるWizがphp2shell.comで公表しています。PHP公式のアドバイザリでは「PHP2Shell」という名前は使っておらず、「Critical remote code execution vulnerabilities, update now」という見出しで告知しています。

アプリが「Hello World」を表示するだけの内容でも対象になる、とWizは説明しています。PHPはアプリのコードが動く前にリクエストの本文を解析するので、アプリ側の作りでは防げません。

なお、セキュリティ企業Sansecの解説では2つのCVE番号と不具合の対応が公式と逆になっています。この記事はPHP公式のGitHubアドバイザリの対応に従っています。

PHP2Shellで攻撃者にできること

出典：GitHub php/php-src セキュリティアドバイザリ GHSA-w8hw-w9fx-j79w

一番の問題は、ログイン不要で、外からリクエストを送るだけでサーバー上のコードを動かせる点です。実行される権限はWebサーバー（PHPワーカー）のアカウントのものですが、Webアプリが読めるデータベースの接続情報や設定ファイルには通常アクセスできます。

• 任意のコード実行: Webワーカーの権限でコマンドやプログラムを動かせる。Webシェルの設置、改ざん、データの持ち出しの入口になる
• メモリの漏えい（CVE-2026-109619）: ワーカーのメモリには、他の利用者のリクエストやパスワード、APIキー、トークン、証明書が含まれることがある（php2shell.comのFAQ）
• 主要なCMS・フレームワークでの実証: Sansecは、WordPress、Drupal、Joomla、Magento、MediaWiki、phpMyAdmin、Nextcloud、Roundcube、Laravel、Symfony、WHMCSで認証なしのRCEを実証したとしている

「アップロード機能がないから安全」は誤り

ファイルのアップロード画面がないサイトでも影響を受けます。PHPは、アプリのコードが動く前にmultipart/form-data形式のリクエストを解析します。攻撃に使われる処理はこの段階で起きるため、PHPで処理されるURLであれば、どこでも攻撃の入口になりえます。

実行形態（SAPI）で危険度が違う

PHP公式は、Webリクエストを処理するすべての形態（PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed）を対象としています。そのうえで、危険度には差があると説明しています。

FPMなら安全という意味ではありません。どの形態でも更新は必要です。

攻撃の難しさ

CVSSの評価では、攻撃の複雑さは「高」、攻撃の前提条件は「あり」とされています。たとえばCVE-2026-109619は、状態を残すリクエストと、それを読み出すリクエストが同じワーカーで処理される必要があります。ただし、脆弱性の詳細は修正版の公開前から流出しており、Unit 42（Palo Alto Networks）も概念実証コードを確認しています。条件の厳しさを理由に更新を後回しにするのは危険です。

影響を受けるバージョンと修正版

出典：PHP公式サイト

修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です（2026年10月21日公開）。それより前のバージョンはすべて対象と考えてください。

影響が及ぶ最も古いバージョンについて、PHP公式は範囲を明示していません。Wiz、Calif、Cloudflare、Sansecは「PHP 5.4以降」と説明しており、Sansecは脆弱なコードが2012年からあったとしています。

ディストリのパッケージは番号だけで判断しない

Ubuntu、Debian、RHEL系などのパッケージは、上流のバージョン番号を上げずに修正だけを取り込む（バックポートする）ことがあります。たとえばUbuntu 24.04の修正版は「8.3.6-0ubuntu0.24.04.13」で、PHPの番号は8.3.6のままです。番号が8.3.36未満だから危ない、とは限りません。ディストリのセキュリティ情報で、修正済みのパッケージ版数を確かめてください。

Ubuntuは公式ブログで次の修正パッケージを公表しています。

出典はUbuntuの公式ブログです。ESMはUbuntu Pro（個人利用は5台まで無料）で受け取れます。Pleskも同梱PHPの対応表をサポート記事で公開しています。RHEL系・Debianなど、その他のディストリは各社のセキュリティ情報を確認してください。

Webで動いているPHPのバージョンを確かめる方法

確かめるべきなのは、Webのリクエストを処理しているPHPのバージョンです。サーバーにログインしてphp -vを打っても、表示されるのはコマンドライン用のPHPで、Webで動いているものとは別のことがあります。

phpinfo()のページを公開したままにすると、それ自体が攻撃者に情報を与えます。確認が終わったら必ず消してください。

対応の手順：更新→再起動→侵害の確認

対応の順番は、更新、再起動、侵害の確認です。GMO Flatt Securityの解説や、日本の国家サイバー統括室が示した手順も、おおむねこの流れになっています。

1. インターネットに公開しているサーバーから優先して更新する。 ソースからビルドする場合はPHP公式のダウンロードページ、WindowsはWindows版のページから入手します。Ubuntuならsudo apt update && sudo apt upgradeです。
2. Apache・PHP-FPM・常駐ワーカーを再起動する。 自動更新（unattended-upgradesなど）でパッケージが入れ替わっていても、再起動しなければ古いPHPが動き続けます。
3. Webで動いているバージョンを確認し直す。 サイトヘルスやphpinfo()で、修正版になっているかを確かめます。
4. ログで侵害の兆候を探す。 不審なmultipartリクエスト、HTTP 500の連続、ワーカーの不自然な再起動がないかを見ます。
5. 侵害が疑われる場合は、サーバーが持つ権限を洗い出す。 データベース、保存データ、クラウドのIAMロール、APIキーなど、Webワーカーから届く範囲を確認し、必要に応じて認証情報を入れ替えます。
6. ログの保存状況を見直す。 あとから調べられるだけの期間とログの種類を残せているかを確かめます。

更新の前に、CMSやアプリが新しいPHPで正しく動くかも確かめておきます。同じ系列内（8.3.x→8.3.36など）の更新なら互換性の問題は起きにくい一方、8.1以前から8.2以降へ系列をまたぐ場合は、プラグインやライブラリが動かなくなることがあります。

侵害の兆候の例

php2shell.comは、次のような兆候を挙げています。ただし、兆候があっても侵害の証明にはならず、なくても安全の証明にはなりません。

• 異常に大きい、または壊れたPHPSESSIDのレスポンスクッキー
• 不審なmultipartリクエストの直後に、メモリ上限のエラーやHTTP 500が続く
• 説明のつかないPHPワーカーのクラッシュや再起動

Sansecによると、確認されている攻撃の引き金はすべてmultipart/form-data形式のリクエストです。この形式のリクエストが急に増えていないかも見ておきましょう。

すぐに更新できない場合の暫定策

更新までの間は、WAFでの遮断とPHPの設定変更で、攻撃を受けにくくできます。ただし、どれも完全ではなく、PHP公式も「更新だけが完全な対策」と明記しています。副作用もあるため、試してから本番に入れてください。

設定まわりで間違えやすい点もあります。

• メモリの上限をRLIMIT_ASやRLIMIT_DATAでかけるのは避けてください。脆弱なエラー処理を通ってしまいます。上限はコンテナやcgroup v2のmemory.maxで設定します。
• アプリの「メンテナンスモード」では防げません。 PHP自体は動いたままなので、リクエストの解析の段階で攻撃が届きます。止めるならPHPのプロセスごと止めます。
• error_reportingやdisplay_errors、@演算子で警告を隠しても効果はありません。
• 更新が済んだら、memory_limitなどの暫定の設定は元に戻してください。

WAF・セキュリティ製品の対応状況

主なベンダーは、すでに防御ルールを出しています。

Cloudflare自身も、WAFは「パッチの代わりではない」と書いています。Cloudflareを通らない経路（サーバーのIPアドレスへの直接アクセスなど）は守れません。

悪用状況と各機関の発表（2026年10月22日時点）

出典：JPCERT/CC

2026年10月22日時点では、実際の攻撃を観測したという報告と、まだ確認していないという発表が混在しています。CISAの「悪用が確認された脆弱性カタログ（KEV）」には、確認した範囲ではまだ載っていません。それでも、脆弱性の詳細は修正版の公開前に流出し、概念実証コードも確認されているため、悪用されている前提で動くのが安全です。

日本の国家サイバー統括室は、次の手順を示しています（JAPAN Security Summitの記事より）。

1. 使っているPHPのバージョンを確認する
2. 公式情報を確認し、速やかに修正を適用する
3. 外部委託先に、バージョンと適用状況を確認する
4. 更新の前に、CMSやアプリへの影響を確認する
5. インターネットに公開しているシステムを優先する

海外では、欧州のCERT-EUや英国のNCSCが「修正を待つ間はサイトを止める」よう助言し、米NSAも即時に更新できないならオフラインにすることを勧めたと報じられています。

公開までの経緯

国内の影響と、不安をあおる情報の見分け方

国内でも、多くのサービスが10月21日に緊急メンテナンスや一時停止に入りました。ただし、止めたことは「被害を受けた」ことを意味しません。多くは修正を当てるまでの予防的な停止です。

ITmedia NEWSの報道では、コドモン、Shadowverse: Worlds Beyond、BASE、さくらのレンタルサーバ、XServer、GMOペパボ、ニコニコ、pixiv、静岡銀行、阪急電鉄などが停止やメンテナンスを行いました。そのうち、PHPの問題が原因だと発表や取材で確認されたのは、Shadowverse: Worlds Beyond、キンブル、pictSQUARE、BASEです。高市首相も公式Xで「大至急のお願い」として、対応を呼びかけました。

利用者として気になるのは「パスワードを変えるべきか」でしょう。現時点では、個人情報の流出などを公表したサービスは確認できていません。変更が必要かどうかは、各サービスの発表を待って判断するのが確実です。

「15分で乗っ取り」は予想が広まったもの

SNSでは「修正版の公開から15分で乗っ取られる」という話が広まりました。Sansecが「修正版の公開から15分以内に大規模な攻撃が始まるだろう」と予想したものが、事実のように伝わった面があります（ITmediaオルタナティブ・ブログの検証）。とはいえ、攻撃が早く来る可能性は高く、急いで更新すべきことに変わりはありません。

「wp2shell」とは別の脆弱性

名前の似た「wp2shell」は、WordPress本体の脆弱性として報じられている別の問題です。PHP2ShellはPHP本体の問題なので、WordPressの更新では直りません。両方の対応が必要になるサイトもあるため、検索結果で両者を混同しないよう注意してください。

AIが見つけた脆弱性という背景

PHP2Shellは、AIを使った脆弱性探しから見つかった点でも注目されています。

• Calif: OpenAIのプロジェクト「Patch the Planet」の一環として、一般に提供されているモデルを使ってPHPのソースコードを調べ、見つけたと説明しています。一方で「単純なプロンプトで全部のバグが見つかるわけではない」とも述べています。
• Wiz: 発見、エクスプロイトの開発、パッチの検証に、自社のWiz Atlas、Gemini 4 Argon、GPT-5.6-Solを使ったとphp2shell.comで明かしています。
• 調整: OpenAIのCodex Securityチーム、PHPのセキュリティチーム、GoogleのGeminiチームが関わったと報じられています。

AIで脆弱性を見つける速さが上がると、守る側の更新もそれに合わせて速くする必要があります。発見に使われたモデルや仕組みについては、GPT-5.6とは、Gemini 4とは、Codex Securityとはで詳しく解説しています。AIが攻撃に使われた事例はAIが作った初のゼロデイ脆弱性悪用とは、AIでパッチ適用を回す取り組みはSoftBank × OpenAI「Patching as a Service」を参考にしてください。

古いPHPのシステムを抱える企業が見直すこと

今回、修正版がすぐに出たのはPHP 8.2以降だけでした。8.1以前を使っているシステムは、ディストリやLTSベンダーのパッケージに頼るしかなく、自前でビルドしたPHPならソースパッチを当てる手間がかかります。PHP 8.2も2026年12月31日でサポートが終わります。

この機会に次の点を確認しておくと、同じような脆弱性がまた出たときに速く動けます。

• 社内のどのシステムが、どのPHPのバージョンと実行形態で動いているか（台帳があるか）
• サポート終了済み、または年内に終わる系列をいつ移行するか
• 更新と再起動を、誰がどの手順で行うか（夜間・休日も含めて）
• 委託先と、脆弱性が出たときの連絡と対応の期限を決めているか
• 本番を止めずに試せる検証環境があるか

外部に開発や保守を委託している場合は、委託先に次の内容を問い合わせると状況をつかみやすくなります。

古い業務システムの保守を見直す流れで、既存のシステムにAIの機能を足すことを検討する企業もあるはずです。その場合は、セキュリティ更新を回せる体制を先に整えてから組み込む範囲を決めると、後で手戻りが出にくくなります。進め方は既存システムにAIを組み込む方法で整理しています。

急いで対応すべき人・慌てなくてよい人

PHPのサーバーを自分や自社で管理しているかどうかで、急ぐべきかが分かれます。

すぐに対応すべき人

• Apache mod_phpでPHPを動かしている人（公式が最も危険としている形態）
• インターネットに公開したWordPress、EC、会員サイト、社内システムをVPSや自社サーバー、クラウドで運用している人
• PHP 8.1以前など、修正版がすぐに出ない系列を使っている人
• 決済、個人情報、APIキーなど、漏れると影響の大きい情報をPHPのサーバーで扱っている人
• 外部委託先のPHPの状況を把握していない企業

慌てなくてよい人

• Webサービスを利用しているだけの人。止まっているサービスは再開を待ち、各サービスの発表に従えば十分です
• PHPを使っていないサイト（静的サイトのみ、Node.jsやPythonだけで動くシステムなど）の運営者
• 社外に公開していない開発用PCでだけPHPを使っている人。ただし、そのPCも時間のあるときに更新しておきましょう

レンタルサーバーの利用者は、その中間です。PHPそのものは事業者が更新しますが、自分でPHPのバージョンを選べるサービスでは、古い系列を選んだままにしていないかを確かめてください。

よくある質問

Q. PHP2ShellとCVE-2026-109618は同じものですか？

PHP2ShellはCVE-2026-109618とCVE-2026-109619の2件をまとめた通称です。「CVE-2026-109618だけ直せばよい」というものではなく、修正版のPHPに更新すれば両方が直ります。

Q. CLIでphp -vを打ったら修正版でした。もう安全ですか？

まだわかりません。コマンドラインのPHPと、Webで動いているPHPが別のことがあります。また、更新後に再起動していなければ、Webでは古いPHPが動き続けています。サイトヘルスやphpinfo()で、Web側のバージョンを確かめてください。

Q. Cloudflareを使っていれば更新しなくてよいですか？

更新は必要です。Cloudflareは無料プランを含めて自動でルールを入れていますが、Cloudflare自身が「パッチの代わりではない」としています。Cloudflareを通らない直接のアクセスは守れず、ルールをすり抜けるよう攻撃の中身を変える動きも観測されています。

Q. PHP 7.4を使っています。どうすればよいですか？

PHP公式は7.4向けの修正版を出していません。Ubuntu 20.04ならESM（Ubuntu Pro）の修正パッケージ、他のディストリならそのセキュリティ情報を確認してください。自前でビルドしている場合は、PHPのセキュリティチームが公開した最小限のソースパッチを当てる方法があります。どの方法でも一時しのぎなので、サポートされている8.3以降への移行を計画しておくのが現実的です。

Q. 更新したあと、何か戻す設定はありますか？

暫定策でmemory_limit=-1にした場合などは、元の値に戻してください。multipartの遮断やGET・HEADだけの制限を入れていた場合も、更新と再起動を確認してから外します。

Q. 侵害されていたか、どうすれば確かめられますか？

完全に確かめる方法はありません。異常に大きいPHPSESSIDクッキー、不審なmultipartリクエスト後のHTTP 500の連続、説明のつかないワーカーの再起動などが手がかりになります。疑わしい場合は、Webサーバーから届くデータベースや認証情報、クラウドの権限まで調べ、必要ならセキュリティ会社に調査を依頼してください。

まとめ

PHP2Shell（CVE-2026-109618／CVE-2026-109619）は、PHP本体で見つかった認証不要のRCE脆弱性です。CVSSは9.2で、WordPressなどの上で動くアプリに関係なく影響を受けます。

• 対策の本命は、PHP 8.5.12／8.4.27／8.3.36／8.2.35、またはディストリの修正済みパッケージへの更新と、その後の再起動
• 確かめるのはWebで動いているPHPのバージョン。CLIのphp -vだけで判断しない
• WAFや設定変更、アプリのメンテナンスモードでは完全には防げない
• 2026年10月22日時点で、実際の悪用を観測したという報告がある。KEVには未登録でも、悪用される前提で動く
• サービスの予防的な停止は侵害を意味しない。利用者は各サービスの発表を待てばよい

AIを使った脆弱性探しが広がり、重大な脆弱性が見つかってから攻撃が始まるまでの時間は短くなっています。生成AIまわりのセキュリティの全体像は生成AIのセキュリティリスク、同じRCE脆弱性の事例はFlowise RCE（CVE-2025-59528）の脆弱性まとめもあわせて確認しておくと、次の脆弱性にも速く対応できます。