本記事では、2026年10月21日にThe PHP Groupが公表した重大な脆弱性「PHP2shell」の概要と、WordPressでWebサイトを構築している際の影響や具体的な確認・対応手順について解説します。
「自社サイトにWordPressを使っている中で、PHPの脆弱性の対象か分からず不安」「何をどこから確認・対応すべきか分からない」とお悩みのWebサイトの担当者や管理者の方は、PHPの脆弱性の影響があるバージョンの判別基準や対応手順、侵入痕跡の確認方法などを本記事で確認しておきましょう。
この記事を読めば、自社サイトが直面しているリスクを正確に把握し、PHPのバージョンの更新や制作会社への依頼など、被害を防ぐために今すぐに取り組むべき具体的なアクションが判断できるようになります。
目次
PHPは、WebサイトやWebアプリケーションを開発する際にWebサーバー側でプログラムを設計するためのプログラミング言語です。Webサイトの開発ではHTMLやJavaScriptという言語も耳にしますが、これらの言語とPHPは稼働させる場所や役割が異なります。3つの言語の違いは、次のとおりです。
| 言語 | 動く場所 | 主な役割 |
|---|---|---|
| HTML | ブラウザ(表示) | 画面の骨組みを作る |
| JavaScript | ブラウザ | ボタン操作など、画面上の動きを担う |
| PHP | サーバー | データベースを参照し、閲覧者ごとにページを組み立てる |
PHPは、例えば次のような処理を実行しています。
なぜ世間で話題になったのかというと、このPHP本体に外部から攻撃され得る重大な欠陥が2件見つかったためです。次の章から、その詳細を紹介していきます。
WordPressは、PHPの仕組みを用いたコンテンツ管理システム(CMS)です。そのため、PHP全体に問題がある場合は、このシステムで構築したWebサイトにも影響が及びます。
W3Techsの2026年7月の調査(※1)によると、PHPの利用シェアはサーバー側の言語が判明しているWebサイト全体の69.1%になると言われています。利用者が大勢いるということはそれだけ攻撃者にとって攻撃する価値が高いということであり、Web担当者は「WordPressだから安心」ではなく「WordPressだからこそ確認が必要」と考えることが大切です。
【参考】
※1 W3Techs|Usage statistics of server-side programming languages for websites
2026年10月21日、PHPプロジェクトは重大な脆弱性2件の修正版を公開しました。こちらでは、2件の脆弱性の概要、なぜ「乗っ取られる」と言われるのか、そして公表前から攻撃が始まっていた経緯を解説します。
PHP2shellは、PHPから見つかった2件の脆弱性(識別番号:CVE-2026-109618、CVE-2026-109619)の通称です。この発見に関与したとされる研究者の投稿で用いられた呼び名のため、本記事ではこの2件をまとめて通称として使用します。
PHP2shellは、どちらも深刻度を示すCVSS v4.0のスコア(0〜10で評価)が9.2で、最上位の区分「Critical(緊急)」に分類されています(※2、※3)。
【参考】
※2 GMO Flatt Security|PHPの「緊急」レベルの脆弱性、開発元が修正バージョン公開 「直ちにアップデートを」
※3 ITmedia NEWS|PHPの重大な脆弱性「php2shell」(CVE-2026-109618、CVE-2026-109619)の概要と対応指針
条件がそろうと、認証IDやパスワードを持たない第三者が、外部からWebサーバーに命令を実行させる恐れがあります。専門的には「認証なしのリモートコード実行(RCE)」と呼ばれ、悪用されると次のような被害につながります。
ただし、実際に悪用できるかは環境や設定によって異なるため、「必ず乗っ取られる」とは限りません。仕組みは、次の3段階で捉えると分かりやすくなります(※2、※3)。
この「片付け漏れ」が残る点が、今回の脆弱性の核心です。
時系列で整理すると、攻撃の試みは公表前から始まっており、その後も状況が進んでいます。主な動きは次のとおりです。
ここで重要なのは、2026年10月21日にPHPの修正版に更新したWebサイトでも、それ以前に侵入されている可能性が残る点です。更新は「これからの攻撃」を防ぐための対策で、「すでに起きた侵入」への対応においては別途の確認が必要です。
【参考】
※4 Acronis|PHPの重大な脆弱性「php2shell」:知っておくべきことと対策
※5 gihyo.jp|PHP、重大な脆弱性2件を修正
※6 Pivo-te|【緊急】PHPの脆弱性をわかりやすく図解解説|確認すべき5つのこと
※7 独立行政法人情報処理推進機構|PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619:PHP2shell)
自社サイトがPHPの脆弱性に直面しているか、PHPのバージョンから判断できます。修正済みのPHP最新バージョン一覧と、WordPress上でのPHPのバージョンの調べ方、WordPress本体の更新の必要性について確認しておきましょう。
2026年10月21日時点での修正済みの最新バージョンは、次の表のとおりです(※8、※9)。7.4、8.0、8.1はサポートが終了していますが、深刻度を考慮して最小限の修正がソースコードで提供されました。ただし、こちらは通常の修正版ではないため、サポート中のバージョンへの移行が必要です。LinuxディストリビューションのPHPは、各社の更新パッケージの案内も確認しましょう。
【参考】
※8 ITmedia NEWS|PHPの「緊急」レベルの脆弱性、開発元が修正バージョン公開 「直ちにアップデートを」
※9 gihyo.jp|PHP、重大な脆弱性2件を修正
| 使用中のPHP | 判定 | 対応 |
| 8.5系 | 8.5.12以上なら修正済み | 8.5.11以下は更新が必要 |
| 8.4系 | 8.4.27以上なら修正済み | 8.4.26以下は更新が必要 |
| 8.3系 | 8.3.36以上なら修正済み | 8.3.35以下は更新が必要 |
| 8.2系 | 8.2.35以上なら修正済み | 2026年12月31日でサポートが終了するため、8.3以上への移行検討も必要 |
| 7.4、8.0、8.1 | 通常の修正版なし(最小限のソース修正のみ) | サーバー会社やOS提供元の対応を確認し、8.3以上へ移行 |
| 7.3以前 | PHPプロジェクトからの修正なし | 影響を受ける懸念があり、早急に移行 |
「修正済み」と判定されていても、更新前の侵入有無については別途確認が必要です。その確認方法については、後述の対応手順で把握できます。
PHPのバージョンは、WordPressの管理画面から確認できます。ただし、WordPressのバージョンによって管理画面の表記が異なる場合がある点にはご注意ください。
レンタルサーバーを用いている場合、Webサーバーの管理画面にあるPHP設定でも確認は可能です。PHPのバージョンを更新した際、再起動を行うまで古いバージョンが動き続けるケースがあるため、更新後にサイトヘルスで番号の変動を確認することで、その問題に気づきやすくなります(※6)。自身で確認できない場合、サーバー会社やWebサイトの運営・管理会社へ「当Webサイト(URLも記載)で動いているPHPのバージョンと、2026年10月21日に公開された修正版への更新状況を教えてください」と問い合わせると良いでしょう。
WordPress公式サイトは10月21日の告知で、Webサイト運営者に向けてPHPを直ちに更新するよう呼びかけました。加えて、2件の脆弱性がWordPress本体の問題ではないため、その更新が不要であると説明しています(※9)。
Webサイト運営者に求められるのは、Webサーバー側のPHP更新と再起動です。ただし、PHPのバージョンを更新する場合、現在利用中のプラグインとテーマが新しいPHPのバージョンで稼働するかを事前に確認する必要があります。
一般的に、例えば8.3.35から8.3.36などの同じ系統内の更新では影響が小さい一方、8.1から8.3のように系統をまたぐ移行では古いプラグインが原因で画面が正しく表示されなくなる恐れがあるため、注意しましょう。
PHPに脆弱性があるサイトと分かったら、その対応が必要です。こちらでは、対象確認から再起動までの5ステップ、更新が難しいときの判断基準、更新後の侵入確認について解説します。
次の5ステップでPHPの脆弱性を確認、対処できます(※6)。
レンタルサーバーでは、管理画面上にあるPHP設定でバージョンを切り替えられる場合が多い一方、サーバー会社に更新してもらう際には、利用者の作業範囲が限られることを理解しておくことが大切です。
VPSやクラウドなど自社で管理するサーバーの場合、開発会社や社内のインフラ担当者への依頼が必要で、更新後も古いPHPのバージョンが動き続けないようPHP-FPMやWebサーバーを再起動しましょう(※6)。その依頼の際、「PHPのバージョンを更新後、再起動まで含めてお願いします」と伝えると確実です。
なお、ENISA(EUサイバーセキュリティ機関)は、PHPを用いる社内製品が見落とされやすい点に触れつつ、インターネットに公開しているシステムを優先して対応するよう推奨しています(※10)。
【参考】
※10 Lovguiden|Critical PHP vulnerabilities: ENISA urges organisations to patch
PHPのバージョンを更新できない事情がある際の判断は、Webサイトの性質によって変わります。次の表を目安にしてください(※6、※10)。
| 状況 | 判断の目安 |
| すぐ更新できる | 停止せず、更新を最優先にします |
| 更新できない事情があり、会員情報や決済を扱っている | 更新まで一時停止する判断も合理的です。ENISAも、修正が適用されるまで公開システムを公共のネットワークから切り離すよう推奨しています |
| 情報発信が中心で、サーバー会社の対応が進んでいる | 停止よりも、更新を急ぎましょう |
「更新できない事情」としては、次のような例があります。
停止する場合、HTTPステータス503(一時的に利用不可)に設定します。200でメンテナンス画面に返すとその画面がインデックスされる恐れがあり、404ではページが消えたと扱われるためです(※6)。
設定変更による緩和策もありますが、session.upload_progress.enabledの無効化だけでは不十分である(※3)といった言及も見られるため、あくまで応急処置としてとどめておき、安全な選択肢として更新しましょう(※2)。
PHPのバージョンの更新が完了していても安心はできません。10月17日ごろから攻撃の試みがあったことを受け、それ以前に侵入された可能性も考える必要があるからです。その不安を解消するために、Webサイトのサーバー会社や制作会社に、10月17日以降のログ確認を依頼することが肝心です。同時に、自身でも次の点を確認できます(※6)。
上記のいずれかに当てはまる場合、すぐにWebサイトのサーバー会社や制作会社へ連絡し、対処してもらう必要があります。
今回、修正済みのバージョンに更新しても、Web担当者の対応は終わりではありません。こちらでは、PHPの各バージョンのセキュリティサポートの終了時期と、新たな脆弱性が発見された場合に備えた運用体制を整理できます。
PHPの各バージョンともに、公開から2年間が通常サポート、その後の2年間が重大なセキュリティ修正のみのサポートを受けられます(※11)。その中で、PHP 8.2はセキュリティサポートが2026年12月31日に終了します。つまり、今回8.2.35のバージョンにしても、2027年1月1日以降に次のバージョンが出ません。
そのため、PHP8.2を利用している場合はセキュリティサポートが2027年末まで続く8.3以上へのバージョン移行が望ましいでしょう。各バージョンのセキュリティサポートの終了時期は、次の表から確かめられます。
【参考】
※11 PHP|Supported Versions
| バージョン | セキュリティサポートの終了 |
| 8.2 | 2026年12月31日 |
| 8.3 | 2027年12月31日 |
| 8.4 | 2028年12月31日 |
| 8.5 | 2029年12月31日 |
PHPのバージョンを移行するなら、事前にプラグインとテーマの対応状況の確認、さらにはテスト環境での表示確認を行うことが必要です。
さらに10月23日、3件目(CVE-2026-115560)の脆弱性も告知されました。特定の設定とアプリケーションの処理が重なった場合にのみ起こる問題で、本記事公開時点では修正版がありません。しかし、PHPはその対策として、「session.upload_progress.enabledを0にする」という設定を推奨しています(※5)。このような続報に備えて、次の4点を整えておくと安心です。
これらを平時から整えておけば、続報が出たときも慌てずに判断と依頼を進められます。
こちらでは、PHPについて多くの方からお問い合わせがある内容とそれに対する回答を把握できます。
社内の責任者、もしくはサーバー会社や制作会社に自社サイトにPHPを使用しているかを確認しましょう。PHPを使用している場合、重大な脆弱性という問題に直面している恐れがあるため対処が必要です。なお、WordPressを用いて自社サイトを運営、管理しているなら、PHPを用いています。
詳しくは、記事内の「PHPの脆弱性に対応する手順と判断基準」をご確認ください。
いいえ、PHPの脆弱性を解消するためには、Webサーバー側のPHPのバージョンを更新する必要があります。その後、従来のPHPのバージョンが稼働する状況を防ぐために、再起動まで行うことも大切です。
詳しくは、記事内の「自社サイトがPHPの脆弱性の対象バージョンかの確認」をご覧ください。
PHPのバージョンを更新しても、古いバージョンが稼働したままになる可能性があるため、必ず再起動しましょう。また、PHPの脆弱性が発表される前から、攻撃が始まっていた事実があります。そのため、Webサーバーに外部からの命令がないか確かめることも必要です。
詳しくは、記事内の「PHPの脆弱性に対応する手順と判断基準」で確かめられます。
PHPは、多くの企業Webサイトに用いられているプログラミング言語です。そのため、Web担当者はPHPの重大な脆弱性に直面している可能性を想定し、自社サイトで使用するプログラミング言語を確認しましょう。
PHPを用いている自社サイトの場合、修正版のバージョンに更新する必要があります。すぐにその対応ができないならHTTPステータス503を設定し、一時停止をするのも手段のひとつです。
PHPの重大な脆弱性を放置して自社サイトが攻撃を受けると、Webサイトの改ざんや保存データの窃取につながったり、自社の信頼が損なわれたりするリスクがあります。自社サイトにPHPを用いている場合は、迅速にその脆弱性への対処を行いましょう。
執筆者
コンテンツディレクター/ライター
Tomoyuki Chiba
2024年ファングリーに入社。人材紹介会社と広告代理店で営業を経験。その後ジョブチェンジを行い、クリエイティブエージェンシーでディレクターや編集者、ライターとして社内報やパンフレットといった紙媒体を中心した制作業務に従事。趣味はサッカー観戦とドライブ。