2026年10月21日22時40分頃（日本時間）、PHP開発チームが重大な脆弱性2件の修正版を公開しました。通称は「php2shell」。CVE番号はCVE-2026-109618とCVE-2026-109619で、CVSS v4.0のスコアはいずれも9.2です。細工したHTTPリクエストを送られるだけで、Webサーバー上で任意のプログラムを実行される（リモートコード実行、RCE）おそれがあります。

PHPでWebサイトや業務システムを動かしている場合、修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）への更新を今日中に進めてください。攻撃に使えると称するコードがすでにインターネット上に出回り始めています（調査時点: 2026年10月）。

本記事は、PHP公式の告知・セキュリティアドバイザリと、GMO Flatt Securityの解説記事をもとに、自社で何を確認し、どの順で対応すればよいかを整理したものです。情報は随時更新されているため、最新の状況は記事内の一次情報源もあわせて確認してください。

php2shellとはどんな脆弱性か

WordPressを動かす、PHP本体を確認する
WordPress
サイト・アプリ
WordPressなど
PHP
PHP本体
今回の更新対象
WordPress本体やプラグインの更新とは別に、サーバーで動くPHPの修正が必要です。
ロゴ：PHP © Colin Viebrock（CC BY-SA 4.0、形状・配色の変更なし）、WordPress®（WordPress Foundation）。

php2shellは、2026年10月21日に公表された次の2件の脆弱性の通称です。名称は、発見に関わったと見られる研究者の投稿と、開示に関わったWiz社の記事で使われたものです。

CVE番号内容CVSS v4.0
CVE-2026-109618メモリ不足（OOM）時の処理の中断に起因するRCE9.2
CVE-2026-109619リクエスト間に残る内部状態（Stale Global State）に起因するRCE9.2

出典: PHP公式アドバイザリ（GHSA-w8hw-w9fx-j79w）、同（GHSA-6wmf-4rv5-p3rp）（調査時点: 2026年10月）

2件に共通する仕組みは、次の2段階です。

  1. 攻撃者が送った1つ目のリクエストの処理中に、PHPのメモリ上に中途半端なデータが残る
  2. 続けて送った2つ目のリクエストの処理で、その残ったデータが使われ、本来起きないはずの処理が走る

PHPは本来、リクエストごとに状態を片付けてから次の処理に移ります。その片付けが不完全になる経路があり、解放済みのメモリを再び使ってしまう（Use After Free）ことで、最終的に攻撃者が用意した処理を実行させられる、という構造です。公式アドバイザリでは、1つ目を引き起こす処理を「Producer」、2つ目を「Consumer」と呼んでいます。

外部からのリクエストがPHPの脆弱性を経由し、データやWebサイトに影響する様子
Fig. 01 — 細工したリクエストでPHP上の処理が悪用されると、データの持ち出しやサイトの改ざんにつながるおそれがあります。仕組みを簡略化した概念図です。

なぜ深刻なのか

CVSSのスコアが高いことに加えて、今回の脆弱性は次の4点で影響が大きくなっています。

1. 初期設定のままで攻撃に使える機能がある。 攻撃の入り口として確認されているのは、ファイルアップロードの進捗を扱うSession Upload Progress機能です。この機能はPHPの初期設定で有効になっており、使っている自覚がなくても動いています。

2. 影響するバージョンの範囲が広い。 原因となる実装はPHP 5.2〜5.4の頃までさかのぼるとする分析があり、GMO Flatt Securityは「PHP 5系・7系・8系に広く影響すると考えておくべき」としています。8.1以前には公式の修正リリースが出ないため、古いPHPを使い続けているシステムほど対応が重くなります。

3. 一般的な構成で攻撃が再現している。 公式アドバイザリと研究者の投稿によれば、mod_php・PHP-FPMのどちらでも、WordPress・Laravel・Symfonyといった広く使われる構成でも攻撃が成立したとされています。特殊な設定をしているサーバーだけの問題ではありません。

4. 修正版の公開で、攻撃側の準備も進む。 修正版が出ると、修正内容の差分から攻撃手法を割り出せるようになります。攻撃に使えると称するコードはすでに出回り始めており、インターネットに公開されたPHPのサーバーは、自動化された攻撃の対象になると考えておくべきです。

任意のコードを実行されると、サーバー内のデータベース接続情報や顧客データの持ち出し、サイトの改ざん、そのサーバーを踏み台にした社内ネットワークやクラウド環境への侵入につながります。

自社が影響を受けるかを確認する

NERSCのデータセンターに並ぶサーバーラックの実写
サーバー設備の参考写真。NERSC、2011年撮影。 写真：Derrick Coetzee / Wikimedia Commons（CC0）。

まず、PHPがどこで動いているかを洗い出します。自社サイトだけでなく、問い合わせフォーム、予約システム、社内の業務システム、WordPressで作ったキャンペーンサイトなど、外部の制作会社に任せているものも含めて一覧にしてください。

次に、それぞれでWebサーバー経由で実際に動いているPHPのバージョンを確認します。サーバーにログインして php -v を実行して出るのはコマンドライン用のPHPで、Webサイトを動かしているPHP-FPMやApacheのモジュールとはバージョンが異なることがあります。phpinfo() の出力や、管理画面（WordPressなら「ツール」→「サイトヘルス」→「情報」→「サーバー」）で確認するのが確実です。phpinfo() を表示するファイルを置いた場合は、確認後すぐに削除してください。

WordPressなら、ここで確認
ツールサイトヘルス情報サーバー
確認する行：PHP version（PHPバージョン）
WordPress公式資料のサーバー情報。Server architecture、Web serverの下にPHP versionが表示される画像を拡大 ↗
表示されたバージョンを控え、利用中のサーバー事業者の告知と照合してください。
画面引用：WordPress.org「Site Health screen」のサーバー情報欄を抜粋。 公式資料の過去の表示例で、画面内の7.3.5は修正版ではありません。

確認したバージョンを、次の修正版と比べます。

使っている系列修正版対応
8.5.x8.5.128.5.12以上に更新
8.4.x8.4.278.4.27以上に更新
8.3.x8.3.368.3.36以上に更新
8.2.x8.2.358.2.35以上に更新
8.1以前（7系・5系を含む）公式の修正リリースなし（7.4/8.0/8.1向けのソースパッチのみ）OSパッケージの修正版を当てるか、サポート対象の系列へ移行

出典: PHP公式告知、GMO Flatt Securityの解説記事（調査時点: 2026年10月）

今すぐやるべき対応

対応は「更新」「更新までの緩和」「侵害の調査」の3本立てです。更新がすぐにできない場合でも、緩和と調査は並行して進められます。

修正版への更新、一時的な緩和、侵害の調査を並列に示した3つのイラスト
Fig. 02 — 更新・緩和・調査は並行して進められます。緩和は更新までの一時的な対応です。

修正版へ更新する

根本対策はPHPを修正版に更新することです。更新後は、PHP-FPMやApacheを再起動しないと古いPHPが動き続けるため、再起動したうえで、Webサーバー経由のバージョンが修正版になっていることをもう一度確認してください。

Dockerで動かしている場合は、ベースイメージを修正版に上げてイメージを作り直し、再デプロイするまで対応は終わりません。古いイメージのコンテナが残っていないかも確認します。

PHP 8.1以前を使っている場合、公式の修正リリースは出ません。PHP公式は7.4・8.0・8.1向けに最小限のソースパッチを公開していますが、ソースから自前でビルドしている環境向けのものです。UbuntuやRed Hat系、AlmaLinuxなどのOSパッケージを使っているなら、まずOSの修正版が出ていないかを確認してください。いずれにしてもサポート切れのPHPは今後の脆弱性も直らないため、8.2以降への移行が必要で、フレームワークやプラグインの対応状況によっては改修を伴います。移行に時間がかかる場合は、次の緩和策を入れたうえで、移行の計画をすぐに立ててください。

更新後は、ログと主要機能の動作も確認します。修正の中身や報告されている不具合、確認手順はパッチの修正内容と更新後の確認ポイントにまとめています。

更新までの緩和策を入れる

すぐに更新できない場合、公式アドバイザリで言及されている次の設定が攻撃の一部を防ぐ緩和策になります。

  • session.upload_progress.enabled=0（Session Upload Progress機能を無効化する。php.iniかPHP-FPMのプール設定で行い、すべてのワーカーを再起動する。ini_set() や .user.ini では効かない）
  • memory_limit=-1、fatal_error_backtraces=0
  • post_max_size を適切に設定し、巨大なリクエストを拒否する
  • multipart形式のリクエストが不要な画面では遮断する
  • 性能の低下を許容できるなら、PHP-FPMの pm.max_requests=1 で1リクエストごとにプロセスを入れ替える
  • max_input_nesting_level を下げ、リクエストの複雑さを制限する

攻撃を受けていないか調査する

修正版の公開前から攻撃が試みられていた可能性があります。更新が終わったサーバーでも、次の点を確認してください。

担当者がパソコンでログ、ファイル、権限の3つを調査している様子
Fig. 03 — ログだけでなく、プロセス・ファイルの変化と、サーバーが持つ権限も確認します。
確認するもの見るポイント
アクセスログアップロード処理やmultipart形式のリクエストが、短時間に同じ送信元から集中していないか
PHPのエラーログメモリ不足や実行時間超過の致命的エラーが急に増えていないか
プロセス・ファイルWebサーバーの実行ユーザー（www-dataなど）で、見覚えのないプロセスやファイルが作られていないか
サーバーの権限クラウドのIAMロールやサービスアカウント、DBの認証情報など、そのサーバーから使える権限が何か
ログの保全ログが記録され、改ざんされにくい場所に保存されているか

侵害の痕跡が見つかった場合は、サーバー内のデータが持ち出されていないかを精査し、そのサーバーが持つ権限で他のシステムに侵入されていないか（横展開）まで調べる必要があります。認証情報は、侵害の有無がはっきりするまで切り替えておくと安全です。

エラーログの急増は、毎日人が見ていなければ気づけません。当社では自社サイトの数値を過去の平均と比べて異常があったときだけSlackに通知する仕組みで見ており、サーバーのエラー件数も同じ考え方で見張れます。

外部に公開するサーバーに強い権限を持たせない設計は、今回のような脆弱性が出たときの被害を小さくします。AIエージェントに業務を任せる場合も考え方は同じで、当社では実行権限を「自動可・要レビュー・手動のみ」に分けて、被害が広がる操作には必ず人の承認を挟んでいます。

侵害や情報持ち出しが疑われる場合は、情報漏洩時の初動と原因の切り分けで、封じ込め・証拠保全・報告の進め方を確認してください。更新後に権限や運用も見直す場合は、Webサービス事業者のセキュリティ対策に確認項目をまとめています。

環境別の対応の進め方

誰がサーバーを管理しているかで、やることが変わります。

環境やること
自社で管理するサーバー・VPS・クラウド自社でPHPを更新し、再起動とバージョン確認、ログ調査まで行う
Dockerで動かしているシステムベースイメージを更新し、作り直して再デプロイする
レンタルサーバー・マネージドホスティング事業者の障害・メンテナンス情報で対応状況を確認する。PHPのバージョンを利用者が選ぶ方式なら、修正版の系列に切り替える
制作会社・開発会社に保守を任せているサイト委託先に対応予定と完了日を確認する。保守契約がない場合は、誰が更新するかから決める

注意が必要なのは、制作を外注したまま保守契約を結んでいないWordPressサイトやキャンペーンサイトです。誰も更新しないまま公開され続けているサーバーは、今回のような脆弱性で最初に狙われます。公開を続ける必要がないサイトは、この機会に閉じることも検討してください。

社内の役割分担や委託先への確認事項はphp2shellへの職種別の対応で整理しています。経営者・情シス・開発者・制作会社・サイト担当ごとに、今日やることを確認できます。

WordPressから別のCMSへ移すか迷っている方には、乗り換えのメリット・デメリットと判断基準を整理しています。今回の対応はPHPの修正を優先し、移行は編集業務や保守体制への影響も確かめて決めます。

当社でお手伝いできること

当社は受託開発のほか、技術顧問・SRE顧問として、インフラの構成管理やデプロイの自動化、障害対応の手順づくりを担当しています。「PHPがどこで動いているか分からない」「更新したいが、フレームワークやプラグインが新しいPHPで動くか不安」「8.1以前からの移行計画を立てたい」といった段階から相談を受けています。

今回の対応や、今後同じことが起きたときに慌てないための保守体制づくりについては、SRE顧問へのお問い合わせからご連絡ください。