PHP2shellとは、2026年10月21日に修正版が公開された、PHPそのものにある2件の脆弱性の呼び名です。WordPressで作ったホームページはPHPで動いています。W3Techsの集計では全サイトの39.6%がWordPressで動いており[6]、その大半が対象に入ります。IPA（情報処理推進機構）は10月22日に注意喚起を出しました[1]。事業責任者や経営層も含めて、更新と維持管理の体制を確保できるか検討するよう求めています[1]。「制作会社がやってくれているはず」と思っていても、PHPは誰も更新していないことがあります。社長が今週やることは、自社のサイトの「PHPを誰が更新するのか」を確かめ、更新されたかを委託先に聞くことです。

PHP2shellとは何か

PHP2shellは認証なしに外から送られた通信で、サーバー上で任意のプログラムを動かされるおそれがある脆弱性です[2]。PHPの開発元はすべての利用者に直ちに更新するよう強く勧めています[2]。

表1 PHP2shellの概要（2026年10月時点）

項目

内容

識別番号（CVE）

CVE-2026-109618（メモリ不足のエラー処理）、CVE-2026-109619（リクエスト処理）

深刻度

2件とも Critical。CVSS v4.0 で 9.2（GitHub のアドバイザリ）

影響を受けるバージョン

8.2.35より前の8.2系、8.3.36より前の8.3系、8.4.27より前の8.4系、8.5.12より前の8.5系

修正版

8.2.35、8.3.36、8.4.27、8.5.12（php.net の告知は2026年10月21日）

さらに古いバージョン

調査に関わったWiz社によれば、PHP 5.4以降のどのバージョンも少なくともどちらか1件の影響を受ける

悪用の報告

米国CISAの「悪用が確認された脆弱性」の一覧（2026年10月21日版）には載っていない

CVEは脆弱性ごとに振られる世界共通の番号で、CVSSは深刻度を0〜10で表す指標です。米国CISA（サイバーセキュリティ・社会基盤安全保障庁）は、実際の攻撃に使われた脆弱性を一覧にして公開しています[14]。出典はIPAの注意喚起[1]、php.netの告知[2]、GitHubのセキュリティアドバイザリ[3][13]です。JPCERT/CCも同じ日に注意喚起を出しています[4]。

AIを使った調査で見つかった

1件目の脆弱性を見つけたのは、クラウドセキュリティ企業Wizの研究チームです。OpenAIとセキュリティ企業のCalifも調査に加わっています[3][5]。Wizは調査の報告で、発見から攻撃手順の検証、修正の確認までに、自社のツールとGoogleのGemini、OpenAIのGPTを使ったと書いています[5]。AIが単独で見つけたわけではありません。研究者がAIを道具として使い、10年以上前のPHP 5.4のころから残っていた欠陥にたどり着いた、という発表です[5]。

Wizは報告の見出しで「AIが、インターネットの70%に影響する重大な脆弱性を見つけた」と書いています[5]。PHPは、サーバー側の言語が分かるサイトの69.3%で使われています（W3Techs、2026年10月22日時点）[8]。

攻撃する側も同じ道具を使えます。AX総合研究所は、古い欠陥がAIを使った調査で見つかる例は今後も続くと見ています。修正版が出たら、その週のうちに上がったかを確かめる体制を持っておくほうが安全です。

WordPressのホームページも対象になるのか

対象になります。WordPressはPHPで書かれたソフトウェアで、PHPがないと動きません。

WizはWordPress公式のコンテナイメージで、ログインせずに外からプログラムを動かせることを実証しました[5]。開発元はPHPをWebサーバーに組み込んで動かす方式（mod_php）でとくに危険が高いとしています[2]。攻撃はWordPressのプログラムの欠陥を使いません。その下で動くPHPの欠陥を使います。そのため、次の作業では直りません。

  • WordPress本体の更新
  • プラグインやテーマの更新
  • ログイン画面のパスワードの変更

直す方法はサーバーで動いているPHPを修正版に上げることだけです。PHPの開発元はすぐに更新できない場合の設定変更も告知しています。ただし、それは一部の攻撃経路を減らすだけで、サイトを安全にするものではないと書いています[2]。応急処置で済ませず、修正版に上げた日を確かめてください。

OSに付属するPHPは、バージョン番号が変わらないまま修正が入ることがあります[2]。委託先にはバージョン番号とあわせて「今回の修正が入ったか」を聞いてください。

誰がPHPを更新するのか

PHPを更新する人はホームページを置いているサーバーの契約の形で決まります。「制作会社がやってくれているはず」と考えて確かめないままだと、誰も更新しない状態に気づけません。

表2 サーバーの契約の形と、PHPを更新する人

契約の形

PHPを更新する人

社長が確かめること

レンタルサーバー（共用）

同じ系列の修正版（例: 8.2.35）への更新はサーバー事業者が行う。8.1以前の古い系列を選んでいる場合は修正が届かず、系列の切り替えは契約者の操作になる

事業者のお知らせで、どの系列に修正が入ったかを見る

VPS（仮想の専用サーバーを借りる契約）・クラウドのサーバー

契約者（自社か、保守を頼んだ会社）

保守契約にPHPの更新が入っているかを契約書で見る

制作会社のサーバーに置いている

制作会社

制作会社に、更新した日とバージョンを書面で聞く

保守契約が切れている

誰も更新しない

下の「古いバージョン」の節へ

PHPの開発元はOSの配布元などには事前にパッチを渡したと書いています[2]。レンタルサーバーでは、事業者が修正を済ませても、8.1以前の系列を選んだままなら修正は届きません。事業者のお知らせで、どの系列に修正が入ったかを確かめてください。

古いバージョンのまま止まっているサイトはどうするか

PHP 8.1以前は、すでに開発元のサポートが終わっています[1]。サポートが終わった日は、7.4が2022年11月28日、8.0が2023年11月26日、8.1が2025年12月31日です[12]。今回、開発元は7.4・8.0・8.1向けに最小限の修正コードを出しました。ただし新しいバージョン番号のリリースではなく、組み込むには技術者の作業が要ります[2]。JPCERT/CCもサポートのあるバージョンへの更新を推奨しています[4]。

古いバージョンは珍しくありません。W3Techsの2026年10月22日時点の集計では、PHPを使うサイトのうち、7.x系が26.9%、5.x系が7.7%です[8]。制作会社が手を引いたあと、作ったときのPHPのまま動き続けているサイトも、この中に含まれていると考えられます。

さらに、サポート中の8.2も、セキュリティ修正の期限は2026年12月31日です[7]。今回8.2.35に上げても、2か月後には移行が要ります。8.3の期限も2027年12月31日なので、移すなら8.4以降（期限は2028年12月31日[7]）を検討してください。

AX総合研究所の考える目安で、選択肢を並べると次のとおりです。

表3 古いバージョンのサイトの選択肢

選択肢

やること

向いている会社

PHPを上げる

サポート中のバージョンに上げ、WordPressとプラグインが動くか確かめる

保守を頼める会社があり、今後も更新を続けられる

サイトを作り直す

新しいWordPressで作り直す

会員機能やネットショップなど、サーバーで動く機能が要る

PHPを使わない作りに移す

ページを先に作っておく静的なサイトにし、公開サーバーでPHPを動かさない

会社案内が中心で、文章の差し替えは年に数回まで

古いバージョンのまま公開を続けるのは、選択肢に入れていません。IPAは、暫定対策が難しい場合は外部からのアクセス遮断やサービスの一時停止も判断するよう求めています[1]。

今週中に確かめること

社長が自分でやるのは、委託先への質問と管理画面の確認です。技術の作業は委託先に任せてかまいません。

委託先には次の4つをそのまま送ってください。

  1. 当社のホームページのPHPは、いま何のバージョンですか
  2. PHP2shell（CVE-2026-109618・CVE-2026-109619）の修正は入りましたか。入った日はいつですか。まだなら、いつ入りますか
  3. PHP 8.2以前を使っている場合、どのバージョンへ、いつ移しますか
  4. この更新は保守契約に含まれていますか。別料金なら金額を教えてください

レンタルサーバーを自社で契約している場合は、管理画面のPHPの設定で、サイトが使っている系列（8.2・8.3など）を見られます。8.1以前だった場合は、切り替える前に制作会社か事業者に動作確認を頼んでください。確かめずに切り替えると、サイトが表示されなくなることがあります。

攻撃を受けていないかも確かめる

修正版に上げる前に攻撃されていた場合、更新しただけでは被害は消えません。JPCERT/CCは、発見者が公開している情報をもとに、攻撃を受けた可能性があるかを調べる点を挙げています[4]。PHPの処理が異常終了や再起動を繰り返していないか、不審な形式のリクエストの前後にエラーが続いていないか、といった痕跡です[4]。JPCERT/CCは、痕跡が見つからなくても攻撃を受けていないとは断定できないとも書いています[4]。侵害が疑われるときは、ログなどの証拠を保全したうえで対応するよう求めています[4]。

委託先には更新の日付とあわせて「攻撃の痕跡を調べたか」も聞いてください。調べていないなら、調べるかどうかと費用を確かめます。

IPAの2024年度の調査では、不正アクセスを受けた中小企業419社のうち48.0%が「脆弱性（セキュリティパッチの未適用等）を突かれた」と答えています[9]。同じ調査では、過去3期にサイバー被害を受けた企業全体で、被害額の平均は73万円、復旧までの平均は5.8日でした（2025年2月公表）[9]。

7月のwp2shellに続く3か月で2件目

2026年7月22日には、IPAがWordPress本体の脆弱性（wp2shell）について注意喚起を出しています。こちらは攻撃の実証コードが公開され、米国CISAの「悪用が確認された脆弱性」の一覧にも載りました[10]。3か月のあいだに、WordPressとPHPの両方で、外から任意のプログラムを動かされるおそれのある脆弱性が見つかったことになります。

プラグインの脆弱性はさらに多く見つかります。Patchstackの集計では、2025年にWordPressの周りで新しく見つかった件数は11,334件で、91%がプラグインでした[11]。PHPとWordPressを公開サーバーで動かす限り、今回と同じ「確かめて、更新して、また確かめる」作業は続きます。保守費の多くがこの作業の費用であることは「ホームページ保守費用の相場と内訳」で示しました。

AX総合研究所は、会社案内が中心のホームページなら、公開サーバーでPHPを動かさない作りに移すことを提案しています。ページを先に作って置いておく静的なサイトにすれば、公開側にPHPもログイン画面も残りません。仕組みと向かないサイトは「WordPress静的化とは？仕組みと向き不向き」に書きました。

まとめ

PHP2shellはWordPressではなくPHPを直す必要がある脆弱性です。今週は上の質問を委託先に送り、修正が入った日とバージョンを書面で受け取ってください。古いバージョンのまま止まっていたサイトは、PHPを上げるか、作り直すか、PHPを使わない作りに移すかを決める時期に来ています。PHP 8.2のサポートが終わる2026年12月31日[7]が、1つの区切りです。自社のサイトがどのバージョンで動いているか分からない場合は、無料相談からホームページのアドレスをお送りください。移行できるかどうかと、お見積りをお返事します。

参考文献・出典

  1. PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell) — 情報処理推進機構（参照 2026-10-23）
  2. Security advisory: Critical remote code execution vulnerabilities, update now — The PHP Group（参照 2026-10-23）
  3. RCE via OOM corruption (GHSA-w8hw-w9fx-j79w) — php/php-src（参照 2026-10-23）
  4. PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起 — JPCERT/CC（参照 2026-10-23）
  5. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet — Wiz Research（参照 2026-10-23）
  6. Usage statistics and market share of WordPress — W3Techs（参照 2026-10-23）
  7. Supported Versions — The PHP Group（参照 2026-10-23）
  8. Usage statistics of PHP for websites — W3Techs（参照 2026-10-23）
  9. 2024年度中小企業等実態調査 速報 — 情報処理推進機構（参照 2026-10-23）
  10. WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030：wp2shell) — 情報処理推進機構（参照 2026-10-23）
  11. State of WordPress Security In 2026 — Patchstack（参照 2026-10-23）
  12. Unsupported Branches — The PHP Group（参照 2026-10-23）
  13. RCE via stale global state (GHSA-6wmf-4rv5-p3rp) — php/php-src（参照 2026-10-23）
  14. Known Exploited Vulnerabilities Catalog — CISA（参照 2026-10-23）

※数値・制度は2026年10月23日時点の情報です。PHPのバージョンとサポート期限、悪用の状況は変わることがあるため、最新の情報は各出典でご確認ください。