AIトレンド・最新動向

PHP2Shell｜プラグイン更新では直らない4点検

PHP2Shell（CVE-2026-109618／109619・CVSS9.2）はPHP本体の欠陥で、WordPressのプラグイン更新では直りません。公表前から攻撃が観測された経緯と、自社サイトを点検する4ステップを整理します。

PHPの土台にひびが入り、その上にWebサイトが積まれている図

2026年10月21日、The PHP Group がPHPのセキュリティリリース（8.5.12・8.4.27・8.3.36・8.2.35）を公開しました。修正されたのは認証不要で任意のコードを実行できる2件の脆弱性「PHP2Shell」で、CVSS v4.0 基本値はいずれも9.2（Critical）です。厄介なのは、これがWordPress本体やプラグインの問題ではなくPHPランタイムそのものの欠陥だという点です。プラグインを全部最新にしても直りません。経営・DX側で決めるべきことは1つ、「自社サイトのPHPを誰が把握し、誰が上げるのか」です。

2026年10月21日に何が公開されたのか

The PHP Group は2026年10月21日、PHP 8.5.12・8.4.27・8.3.36・8.2.35 をセキュリティリリースとして公開しました。修正対象は CVE-2026-109618 と CVE-2026-109619 の2件で、いずれも認証なしのリモートコード実行（RCE）につながります。

項目内容
公開日2026年10月21日
修正版PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
影響を受けるバージョン上記より前のすべて（PHP 8.1以前はEOLで更新提供なし）
CVECVE-2026-109618、CVE-2026-109619（後日 CVE-2026-115560 が追加）
CVSS v4.0 基本値9.2（Critical）
想定される影響PHPの実行プロセス権限で任意のコードを実行される

PHPのニュースアーカイブには、4バージョンすべてに同じ文言で「2件の重大な脆弱性を修正するセキュリティリリースであり、認証不要のリモートコード実行を許す可能性がある」と記載されています。米国CISAは10月21日のアラートで Apache＋mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeed を名指しし、「Webリクエストを処理するすべてのPHP構成が影響を受ける」としています。

国内でもJPCERT/CCが注意喚起 JPCERT-AT-2026-0033（2026年10月22日公開・10月26日最終更新）を出し、当該製品が国内で広く利用されていることを確認したと記述しています（JVNVU#99905564）。原因はPHPが致命的エラー（とくに `memory_limit` 超過によるメモリ不足）を処理する際のメモリ安全性の問題で、CERT-EU 2026-018 はCVE-2026-109618を「メモリ不足処理時のメモリ破壊」、CVE-2026-109619を「リクエスト状態の残留による任意コード実行」と整理しています。

発見にAIを使ったとWiz Researchが公表

PHP2Shell を発見したのはクラウドセキュリティ企業Wizの研究部門Wiz Researchで、発見・エクスプロイト開発・検知・検証の各工程に3つのフロンティアAIモデルを用いたと公表しています。

Wiz Research の技術ブログによれば、発見は2026年8月19日。その2日後の2026年8月21日には、WordPressに対する認証不要のRCEが成立することを確認しています。用いたAIは Wiz Atlas、Gemini 4 Argon、GPT-5.6 Sol の3つ。同ブログはPHPを「世界のWebサイトの70%を支える汎用スクリプト言語」と位置づけ、WordPress、Drupal、MediaWiki、Joomla を例示しています。つまり自社で書いたコードに問題がなくても、PHPで動いている以上は影響範囲に入るということです。

国内のCMSベンダーも影響調査を公表しました。シックス・アパートは2026年10月21日、Movable Type への影響として「ダイナミックパブリッシング、および一部の Movable Type プラグインなどでは PHP が利用されている」ため影響を受けると案内しています。

プラグイン更新では直らない理由

WordPress本体・テーマ・プラグインをすべて最新にしても、PHP2Shell は解消しません。脆弱性があるのはアプリケーションの一段下で動くPHPランタイム（実行エンジン）であり、更新の権限を持つ相手も更新の手段も別だからです。

層例誰が更新するか
アプリケーションWordPress本体、テーマ、プラグインサイト運用担当・制作会社
PHPランタイムPHP 8.3.36 などサーバ管理者・ホスティング事業者・保守会社
OS・ミドルウェアLinux、Apache／nginxサーバ管理者・ホスティング事業者

WordPressの管理画面に出る「更新があります」という通知は、表の一番上の層しか見ていません。PHP2Shell の対策はその下の層の作業で、管理画面からは実行できません。ここを取り違えると「全部更新したので対応済み」という誤った報告が上がります。

CISAが推奨する初動も、技術的な修正ではなく棚卸しから始まります。「PHP稼働システムを棚卸しする」→「インターネットに面したものを優先してパッチを当てる」→「当てられないなら停止するかWAFで守る」→「不審な挙動を監視する」の順です。

アプリ層・PHP層・OS層の3層図。PHP層だけが未対応で赤く表示されている

自社サイトの点検は何から始めるか（4ステップ）

点検は技術作業の前に「対象を数えること」から始めます。経営・DX側が当日から着手できる4ステップです。

ステップ1：PHPで動いているサイトを数える（判断：経営・DX責任者） 自社サイト、採用サイト、ECサイト、キャンペーンLP、放置中のサブドメイン、社内ツール。漏れるのはたいてい「作った人が退職したサイト」と「代理店が立てたLP」です。

ステップ2：各サイトのPHPバージョンと更新権限者を確認する（判断：情報システム／保守委託先） サーバの管理コンソール、または保守会社への照会で確認します。見るのは「バージョン番号」と「誰が上げる権限を持つか」の2点です。PHP 8.1以前で動くサイトは修正版が提供されないため、PHPそのものを上げるかサイトを畳む判断が必要になります。

ステップ3：更新するか、緩和策を当てるかを決める（判断：情報システム＋事業部門） 修正版の適用が原則です。即時更新できない場合、JPCERT/CCは `session.upload_progress.enabled=0` に設定し全ワーカープロセスを再起動する緩和策を示しています（CVE-2026-109619・CVE-2026-115560向け）。CERT-EUはCVE-2026-109618向けに `memory_limit` と `post_max_size` の設定変更も挙げます。いずれも暫定措置で、Cloudflareも「WAFの保護は有効にしたまま、できるだけ早くベンダー更新を適用する」よう案内しています。

ステップ4：すでに侵害されていないかを確認する（判断：情報システム／保守委託先） JPCERT/CCは侵害調査の着眼点として、異常な PHPSESSID Cookie、不審な multipart/form-data リクエスト、PHPワーカープロセスの異常終了を挙げています。CISAも「PHPワーカープロセスがシェルを起動したりツールをダウンロードしていないか」を監視対象としています。更新前に入られていないかを見る工程が要ります。

優先順の判断軸は「インターネットに面しているか」と「個人情報・決済を扱うか」の2つです。両方に当てはまるBtoC・ECサイトが最優先で、社内向けPHPツールもVPN経由で社外から使えるなら「面している」と見なします。

棚卸し・版の確認・更新・侵害調査の4ステップを上り階段で示した図

経営が見るべきは「何日で上げられるか」

PHP2Shell が示したのは、発見から公表までの期間が防御側の猶予にならなくなったという事実です。経営が整えるべきは個別の対策ではなく、重大な脆弱性の公表から自社サイトを更新し終えるまでの日数を把握し、短くしておくことです。

日付（2026年）出来事
8月19日Wiz Research が脆弱性を発見
8月21日WordPressに対する認証不要のRCEを確認
10月21日PHP修正版公開。Cloudflareは公開の約9時間前（03:02 UTC）からWAFルールを配信し、顧客を狙う攻撃通信を観測
10月22日JPCERT/CCが注意喚起を公開（実証コード多数公開・悪用を試みる通信を観測）
10月26日CISAが2件を Known Exploited Vulnerabilities（KEV）カタログへ追加

注目すべきは10月21日の行です。Cloudflareの公表によれば公式リリース前に情報がリークし、同社は公開前から攻撃通信と、攻撃者がペイロードを変化させて検知回避を試みる動きを観測していました。「公表されたら対応を検討する」という段取りでは、検討に入る前に攻撃が始まっていたことになります。

AIの影響は二重に効きます。防御側は従来見つけにくかったメモリ安全性の欠陥を発見できるようになり（当社でも「AIが脆弱性2.9万件を検出｜修正体制の4点検」で、AIによる検出が「検出」より「修正体制」の問題に変わることを扱いました）、攻撃側も実証コードを素早く仕上げます。発見が速くなれば、公表から悪用までの時間も縮むという対称的な変化です。

経営・DX担当者が点検すべき論点は3つです。

  • 保守契約の範囲：PHPのマイナーバージョン更新は契約に含まれているか。含まれないなら誰がやるのか。
  • 連絡経路とSLA：脆弱性の公表時、保守会社から連絡が来るのか、自社から照会するのか。何時間以内か。
  • 資産台帳：PHPで動くサイトの一覧が、人の記憶ではなく台帳として存在するか。

AI開発ツールの共通欠陥を扱った「Plugin4Shell｜4つのAI開発ツール共通の欠陥」でも、問題はツール単体の品質ではなく「自社が何を使っているかを把握しているか」でした。PHP2Shell も技術ではなく台帳の問題として現れています。

よくある質問

レンタルサーバでWordPressを動かしているだけですが、自社でも対応は必要ですか。

必要です。PHP2Shell はPHP本体の脆弱性のため、WordPressの更新では直りません。契約中のサーバの管理コンソールでPHPバージョンを確認し、PHP 8.5.12・8.4.27・8.3.36・8.2.35 より前なら、事業者の案内に従って更新してください。

WordPressを使っていなければ安全ですか。

安全とは言えません。CISAは「Webリクエストを処理するすべてのPHP構成が影響を受ける」としており、Wiz Research は Drupal、MediaWiki、Joomla も例示しています。PHPで動くサイトや社内ツールがあるかどうかで判断してください。

すぐにPHPを更新できない場合は何をすべきですか。

JPCERT/CCは `session.upload_progress.enabled=0` に設定し全ワーカープロセスを再起動する緩和策を示しています。あわせてインターネットからの到達経路を絞り、WAFを適用します。いずれも暫定措置なので、更新の日程を同時に決めてください。

まとめ

  • 2026年10月21日、PHPが修正版 8.5.12・8.4.27・8.3.36・8.2.35 を公開。CVE-2026-109618／109619（CVSS 9.2）は認証不要のRCEにつながる。
  • WordPress本体・テーマ・プラグインの更新では直らない。更新権限を持つのはサーバ管理者・ホスティング事業者・保守会社。
  • 公表前にリークがあり、Cloudflareは公開前から攻撃通信を観測。CISAは10月26日に2件をKEVへ追加した。
  • 着手は「PHPで動くサイトを数える」から。版と更新権限者を特定し、更新または緩和策を決め、侵害の有無を確認する。

Auto-IDフロンティアの視点として、今回いちばん効くのは技術対応そのものではなく、自社サイトのPHPバージョンを即答できる状態を作っておくことだと考えます。AIが脆弱性を見つける速度は今後も上がり、公表から悪用までの時間はさらに縮みます。そのとき効くのは、慌てて動ける体制ではなく、対象が数えられている台帳です。

次に取るべきアクションは、自社名義で公開しているWebサイトの一覧を作り、各サイトの「PHPバージョン」「更新権限を持つ相手」「連絡先」の3列を埋めることです。

自社のWeb資産やAI活用環境の棚卸しから整理したいという方は、AI導入相談フォームからお気軽にご相談ください。

出典・参考資料

← ブログ一覧へ

CONTACT

記事を読んで、自社ではどうか気になったら

一般論ではなく、御社の業務に当てはめて一緒に考えます。
まずは無料相談からどうぞ。

無料で相談する 1分でAI活用度診断 →
CASES ｜ 関連事例

実際に業務が変わった事例

マーケティング｜SEO対策

後回しになりがちなSEO対策を、AIエージェントで一括修正

作業時間調べながら数日→半日で一巡 事例を読む → マーケティング｜LP制作

外注前提だったLP制作が、AIとの対話だけで内製に

制作期間2週間〜1か月（外注）→1週間程度 事例を読む → ドキュメント作成｜議事録

1〜2時間かけていた議事録づくりを、文字起こしを渡すだけで10分に

議事録作成1〜2時間→約10分 事例を読む →
無料相談する 1分でAI診断