WordPressのPHPバージョン確認とバージョンの更新作業は弊社で対応可能です！
ご不安な方は、至急ご連絡下さい。
WPプロサポ

2026年10月、PHPにおいて、認証を必要とせずにサーバー上で任意のコードを実行されるおそれがある、重大なセキュリティ脆弱性が2件公表されました。通称「php2shell」と呼ばれるこの問題は、Webサイトの基盤となるPHPそのものに関係するものであり、WordPressをはじめとする多くのWebアプリケーションに影響する可能性があります。

今回の脆弱性は、CVSS v4.0でいずれも9.2（Critical）と評価されており、PHPの開発チームは修正バージョンへの速やかな更新を強く推奨しています。

特に注意したいのは、WordPress本体やプラグインを最新の状態にしていても、サーバーで稼働しているPHP自体が脆弱なままであれば、十分な安全性を確保できないという点です。

本記事では、2026年10月22日時点の公式発表とセキュリティ専門企業の分析をもとに、php2shellの概要、脆弱性が発生する仕組み、影響を受ける環境、WordPressサイトの運営者が今すぐ実施すべき対策について詳しく解説します。

こんにちは、フロントエンドエンジニアのスズキです。

Webサイトのセキュリティ対策では、WordPress本体やプラグインの更新に注目しがちですが、実際にはPHPやWebサーバー、データベースといった基盤部分の管理も欠かせません。

今回のように、Webアプリケーションよりも下のレイヤーにあるPHP自体に重大な脆弱性が見つかった場合、サイトの管理画面を保護するだけでは十分な対策にならない可能性があります。

すでに修正バージョンが公開されているため、現在のPHPバージョンを確認し、適切なアップデートを進めることが重要です。あわせて、不正アクセスの痕跡がないかを調べ、必要に応じて認証情報の変更や復旧作業も実施しましょう。

2026年10月に公表されたPHPの重大な脆弱性とは

「php2shell」と呼ばれる2件の脆弱性

2026年10月20日、PHPの公式サイトでは、重大なセキュリティリリースを予定していることが事前に告知されました。その後、10月21日に修正版が公開され、2件の重大な脆弱性について詳細が明らかになりました。

この脆弱性群は、セキュリティ研究者や関連企業の情報発信において「php2shell」と呼ばれています。PHPの内部処理におけるメモリ管理や状態管理の問題を悪用し、条件が成立すると、外部から認証なしで任意のコードを実行される可能性があります。

PHP公式のセキュリティアドバイザリで公表された脆弱性は、次の2件です。

• CVE-2026-109618：メモリ不足時の異常処理に関連する脆弱性
• CVE-2026-109619：古い内部状態が残存することに関連する脆弱性

いずれもCVSS v4.0の評価は9.2で、深刻度は「Critical」に分類されています。攻撃者が有効なアカウントやWordPressの管理者権限を持っていなくても、脆弱なPHP環境に対して攻撃を成立させる可能性がある点が重要です。

なお、php2shellは2件の脆弱性をまとめた呼称です。すべての環境で同じ攻撃手順が成立するという意味ではなく、実際の悪用可能性はPHPの実行方式や有効な機能、リクエスト処理の条件などによって異なります。

参考：PHP公式セキュリティアドバイザリ
GMO Flatt Securityによるphp2shellの技術解説

深刻度CVSS 9.2が意味するもの

CVSS（Common Vulnerability Scoring System）は、ソフトウェアの脆弱性が持つ危険性を評価するための共通指標です。CVSS v4.0では、評価値が9.0以上10.0以下の場合、「Critical」に分類されます。

今回のPHP脆弱性は、2件とも9.2という非常に高い評価になっています。これは、単にサイトが表示されなくなるといった不具合だけでなく、攻撃者がサーバー上で任意のコードを実行できる可能性があるためです。

任意コード実行（RCE：Remote Code Execution）が成立すると、サーバー上の権限や設定によっては、ファイルの読み取り・改ざん、不正プログラムの設置、データベースへのアクセス、追加の攻撃への足がかりなどにつながるおそれがあります。

ただし、脆弱性が存在することと、実際に侵入や情報漏えいが発生したことは別です。リスクを過小評価せず、同時に被害の有無についてもログなどの証拠に基づいて判断する必要があります。

php2shellで何が起きるのか

CVE-2026-109618：メモリ不足時の異常処理を悪用する問題

1件目のCVE-2026-109618は、メモリ不足（OOM：Out Of Memory）が発生した際のPHP内部の処理に関連する脆弱性です。

プログラムは通常、処理に必要なメモリを確保し、処理が終わった段階で使用したメモリや内部データを適切に解放します。しかし、メモリ確保に失敗した場合など、想定外のエラーが発生すると、通常の処理手順を途中で中断して、異常終了処理へ移行することがあります。

今回の問題では、そのような異常処理の過程で、PHP内部のリクエスト関連データが完全に初期化されていない状態になる可能性があります。その後の後処理が、本来は有効でない内部データを有効なものとして扱ってしまうことが、問題の根本にあります。

攻撃者が外部から特定の条件を引き起こせる場合、メモリ管理の不整合を利用して、最終的に任意コード実行につながるおそれがあります。

この脆弱性はPHPアプリケーションの業務ロジックだけでなく、PHP処理系の内部動作に関係するため、WordPressのテーマやプラグインだけを修正しても根本的な解決にはなりません。PHP本体または利用中の配布元が提供する修正を適用することが必要です。

CVE-2026-109619：古い内部状態が残る問題

2件目のCVE-2026-109619は、リクエストに関連する内部状態が、使用するメモリの解放後も残ってしまう問題です。

PHPの実行環境では、Webサーバーの構成によって、1つのワーカープロセスが複数のHTTPリクエストを順番に処理する場合があります。その際、リクエストごとの内部データは、次のリクエストに影響しないよう適切に初期化・解放されなければなりません。

ところが、内部状態への参照がメモリ解放後も残存すると、後続の処理が古い参照を利用してしまう可能性があります。このような問題は、一般にUse After Free（解放後使用）と呼ばれます。

本来すでに利用できないメモリ領域をプログラムが誤って参照すると、データの破損や予期しない処理が発生し、条件によっては攻撃者が任意コードを実行できる状態につながります。

今回の問題では、リクエスト処理に関連する状態の不適切な管理が重要な要因となっています。PHPの実行方式や有効な機能によって具体的な成立条件は異なるため、特定の設定だけを変更すればすべての環境で安全になると考えるべきではありません。

2件の脆弱性に共通するメモリ管理上の問題

2件に共通しているのは、PHP内部で管理されるデータの状態が想定どおりに維持されず、異常な状態を後続の処理が利用してしまう点です。

ソフトウェアのメモリ管理では、データを生成する処理と、そのデータを利用・解放する処理の間で、データの有効性や寿命を正しく管理する必要があります。この関係が崩れると、通常では発生しない処理の組み合わせが生まれ、セキュリティ上の問題につながります。

今回のような脆弱性は、アプリケーションの入力チェックやログイン制限だけでは防ぎきれない場合があります。攻撃がPHPの内部処理で成立する可能性があるため、根本的な対策は修正済みのPHPへ更新することです。

どのPHPバージョン・実行環境が影響を受けるのか

公式に公開された修正版

PHP開発チームは2026年10月21日、脆弱性を修正したセキュリティリリースを公開しました。2026年10月22日時点で、公式発表に掲載されている主な修正版は以下のとおりです。

• PHP 8.5系：8.5.12
• PHP 8.4系：8.4.27
• PHP 8.3系：8.3.36
• PHP 8.2系：8.2.35

上記は、各メジャー・マイナーバージョン系列に対して公開された修正リリースです。利用中の系列に対応する修正版を適用することが基本となります。

ただし、PHP 8.2は2026年12月31日にセキュリティサポートが終了する予定です。8.2.35への更新は今回の脆弱性への対応になりますが、長期的にはサポート中のPHP系列への移行も計画してください。

また、PHP 8.1以前はPHP公式プロジェクトによる通常のセキュリティ更新対象ではありません。Linuxディストリビューションや長期サポートを提供するベンダーが独自に修正をバックポートしている場合もあるため、古いバージョンを利用している場合は、配布元の公式情報を確認する必要があります。

単に「PHP 8系だから安全」「PHP 7系だから影響がない」と判断せず、具体的なバージョン番号と、利用しているパッケージの修正状況を確認してください。

PHP-FPMやApacheなど、幅広い実行方式が対象

今回の問題で注意したいのは、WordPressの特定のプラグインだけに限定された脆弱性ではないという点です。PHP公式のアドバイザリでは、Webリクエストを処理するPHP環境として、以下のような構成が挙げられています。

• PHP-FPM
• Apacheのmod_php
• php-cgi
• FrankenPHP
• LiteSpeed環境でのPHP実行

公式発表では、特にApacheのmod_phpについて、アプリケーションコードが実行される前に、認証されていないリクエストから攻撃を引き起こせる実証例が示されており、リスクが高い構成として言及されています。

ただし、mod_php以外であれば安全という意味ではありません。PHP-FPMなどの構成でも、脆弱性の影響を受ける可能性があります。

また、PHPを直接利用していることが表面上分からない製品やサービスでも、内部でPHPを組み込んでいる場合は影響を受ける可能性があります。サーバーだけでなく、コンテナ、業務用アプライアンス、外部ベンダーが管理するサービスなども確認対象に含めましょう。

WordPressサイトへの影響と注意点

WordPress本体を更新するだけでは不十分

WordPressはPHPを使って動作するCMSです。管理画面の表示、投稿データの取得、データベースとの連携、プラグインの実行など、多くの処理がPHPによって行われています。

そのため、サーバー上のPHPに重大な脆弱性が存在する場合、WordPress本体やプラグインを最新にしていても、PHP側の問題が残ってしまいます。

WordPressの更新とPHPの更新は、それぞれ別の対策です。WordPressの管理画面で「すべて最新」と表示されていても、サーバーで稼働するPHPのバージョンや修正状況が最新とは限りません。

サイト運営者は、WordPress本体、テーマ、プラグイン、PHP、Webサーバー、データベースをそれぞれ管理する必要があります。今回のようなPHP本体の脆弱性では、特にPHPの実行環境が修正済みであるかどうかが重要です。

想定される被害

PHPの脆弱性を悪用した任意コード実行が成立した場合、実行されたコードが持つ権限やサーバーの構成によって、さまざまな被害につながる可能性があります。

たとえば、次のようなリスクが考えられます。

• Webサイトの改ざん：トップページや記事に不正なコードを挿入されたり、訪問者を悪意のあるサイトへ誘導されたりする可能性があります。
• バックドアの設置：攻撃者が後から再侵入できるよう、不正なPHPファイルやスクリプトを設置されるおそれがあります。
• 情報の窃取：サーバー上の設定ファイルやデータベースにアクセスされ、保存されている情報を盗まれる可能性があります。
• 認証情報の漏えい：環境によっては、WordPressやデータベース、外部サービスに関連する認証情報が漏えいするリスクがあります。
• 他のシステムへの侵入：サーバーに過剰な権限が付与されている場合、同じ環境にある別のサイトや内部システムへ被害が広がる可能性があります。
• サービス停止：ファイルの破壊やリソースの消費などによって、Webサイトが正常に動作しなくなるおそれがあります。

ただし、これらは脆弱性が悪用された場合に想定される影響です。脆弱性のあるPHPを使用しているという事実だけで、すでに情報漏えいや改ざんが発生したと断定することはできません。

修正を適用するとともに、アクセスログやファイルの更新履歴、管理者ユーザーの追加状況などを確認し、実際の侵害が疑われる場合はインシデント対応を進めることが重要です。

PHPの脆弱性に対して今すぐ実施すべき対策

1. 現在のPHPバージョンを確認する

最初に行うべきことは、自分のサイトがどのPHPバージョンで動作しているかを把握することです。

レンタルサーバーを利用している場合は、サーバー会社の管理画面にある「PHPバージョン設定」「スクリプト設定」などの項目から確認できることがあります。名称や操作手順はサービスによって異なります。

SSH接続が利用できる環境では、コマンドラインからPHPのバージョンを確認できます。

php -v

ただし、このコマンドで確認できるのは、基本的にコマンドラインで使用されるPHPです。Webサイトが実際に使用しているPHPと異なる場合があるため、コマンドの結果だけで判断しないでください。

PHP-FPMや複数のPHPバージョンを利用するサーバーでは、Webサイトに割り当てられたPHPのバージョンも確認する必要があります。共有レンタルサーバーの場合は、サーバーパネルの設定表示やホスティング会社の案内を優先してください。

2. 修正版へ速やかにアップデートする

利用中のPHPが影響を受ける環境であれば、修正済みバージョンへの更新を最優先で進めてください。

PHP公式は今回の脆弱性について、完全な緩和策はなく、更新が唯一の安全な選択肢であると案内しています。設定変更やファイアウォールだけで根本的な解決ができると考えるべきではありません。

具体的な対応は、利用しているサーバーの管理方法によって異なります。

• レンタルサーバー：管理画面で修正済みのPHPバージョンを選択できるか確認し、必要に応じてサポート窓口に問い合わせます。
• VPS・専用サーバー：OSやPHPの配布元が提供するセキュリティ更新を確認し、適切なパッケージを適用します。
• コンテナ環境：修正済みのPHPを含むイメージへ更新し、稼働中のコンテナや関連プロセスが実際に切り替わっていることを確認します。
• 独自ビルド環境：PHP公式の修正内容を反映したビルドへ更新し、稼働中の実行環境に適用されていることを確認します。

更新前には、正常なバックアップを確保し、WordPress本体・テーマ・プラグインとの互換性を確認してください。ただし、重大な脆弱性への対応を不必要に先延ばしにすることは避けましょう。

更新直後には、トップページ、管理画面、問い合わせフォーム、ログイン、投稿・更新処理など、サイトの主要な機能が正常に動作するかを確認します。

3. すぐに更新できない場合は公開環境を隔離する

サーバーの仕様やシステムの制約により、直ちにPHPを更新できない場合は、脆弱な状態のまま公開を続けるリスクを評価する必要があります。

英国の国家サイバーセキュリティセンター（NCSC）や欧州の関係機関は、公開されているPHPシステムを優先して特定し、速やかに更新するよう呼びかけています。直ちに修正できない場合には、修正が完了するまでシステムをオフラインにする、または外部ネットワークから隔離することも検討するよう勧告しています。

運用上どうしても停止できない場合は、ホスティング会社やセキュリティ担当者と相談し、外部からのアクセスを制限するなど、可能な限りの緊急措置を検討してください。

ただし、WAFやファイアウォールで一部の通信を制限しても、すべての攻撃経路を確実に遮断できるとは限りません。アクセス制限はあくまで一時的なリスク低減策として扱い、修正の適用を最優先にしてください。

WordPressのPHPバージョン確認とバージョンの更新作業は弊社で対応可能です！
ご不安な方は、至急ご連絡下さい。
WPプロサポ

4. 不正アクセスの痕跡を調査する

PHPを更新した後も、更新前に攻撃が行われていないかを確認することが重要です。修正版を適用することは、今後の攻撃リスクを低減するための対策ですが、すでにサーバーへ侵入されている場合、その被害まで自動的に解消するわけではありません。

特に、脆弱性の公表前後に不審なアクセスが増加していないか、サーバー上に未知のファイルが作成されていないかを確認してください。

調査では、以下の項目を重点的に確認します。

• WebサーバーやPHPのアクセスログに、不審なリクエストやエラーが記録されていないか。
• WordPressに見覚えのない管理者ユーザーが追加されていないか。
• WordPressのコアファイル、テーマ、プラグインに不審な変更がないか。
• アップロード用ディレクトリなどに、見覚えのないPHPファイルが置かれていないか。
• サーバーの認証ログや管理画面の操作履歴に、不審なログインがないか。
• 不明な外部通信、プロセス、定期実行タスクなどが発生していないか。

ログや不審なファイルは、調査に必要な証拠となる可能性があります。削除や初期化を急ぐ前に、可能な範囲でログやファイルの状態を保存し、発生時刻や変更内容を記録してください。

侵害が疑われる場合は、専門家やホスティング会社に相談し、被害範囲の特定、バックドアの排除、正常なバックアップからの復旧などを進めることが望まれます。

5. 認証情報を見直し、再侵入を防止する

不正アクセスの痕跡が見つかった場合や、認証情報が漏えいした可能性がある場合は、PHPの更新だけでなく、関連する認証情報も見直してください。

ただし、侵入経路やバックドアが残っている状態でパスワードだけを変更しても、再び認証情報を盗まれる可能性があります。まずは侵害の封じ込めと侵入経路の調査を行い、そのうえで安全な端末から認証情報を変更することが重要です。

確認・変更の対象には、次のようなものがあります。

• WordPress管理者および関連ユーザーのパスワード
• データベースの接続認証情報
• FTP・SFTP・SSHの認証情報
• レンタルサーバーやクラウドの管理アカウント
• 外部サービスのAPIキーやアクセストークン
• 必要に応じたWordPressの認証用ユニークキー（Salt）

認証用ユニークキー（Salt）を更新すると、既存のログインセッションを無効化する効果が期待できます。ただし、すべての認証情報や侵入経路を一度に解決するものではありません。バックドアの排除、権限の見直し、多要素認証の導入などを組み合わせてください。

php2shellに関する情報を確認する際の注意点

設定変更だけで安全になったと判断しない

今回の脆弱性については、PHPの設定を変更することで、一部の攻撃条件を緩和できる可能性が技術記事などで紹介されています。たとえば、Session Upload Progress機能の無効化やリクエストサイズの制限などです。

しかし、これらの設定は環境や攻撃経路によって効果が異なり、すべての悪用シナリオを防止できるとは限りません。設定によってはファイルアップロードなどのサイト機能に影響する可能性もあります。

そのため、技術情報に記載された設定値をそのまま適用し、修正済みのPHPに更新しなくても問題ないと判断することは危険です。公式の修正版を適用するまでの一時的な緩和策として扱い、サーバー管理者や専門家の確認を受けながら実施してください。

サーバー会社の案内も必ず確認する

レンタルサーバーやマネージドサービスを利用している場合、PHP本体の更新作業を利用者自身で行えないことがあります。また、OSやサーバー会社が独自に修正を取り込んだパッケージを提供している場合、バージョン番号だけでは修正の適用状況を正確に判断できないケースもあります。

そのため、サーバー会社の公式告知を確認し、今回の脆弱性への対応状況、適用された修正、利用者側で必要な作業について確認してください。

サポートに問い合わせる際は、利用中のPHPバージョン、対象サイト、更新の可否、適用予定時期を具体的に伝えると、必要な対応を確認しやすくなります。

よくある質問

まとめ：PHPの脆弱性対策は迅速な更新と継続的な管理が重要

いかがでしたでしょうか。

2026年10月に公表されたphp2shellは、PHPの内部処理に関する2件の重大な脆弱性であり、条件が成立すると認証なしの任意コード実行につながる可能性があります。いずれもCVSS v4.0で9.2と評価され、PHP開発チームは修正済みバージョンへの速やかな更新を強く推奨しています。

2026年10月22日時点で、PHP 8.5.12、8.4.27、8.3.36、8.2.35が修正版として公開されています。古いPHPを使用している場合は、配布元による修正状況を確認し、必要に応じてサポート中のバージョンへの移行を進めましょう。

また、WordPress本体やプラグインの更新だけでは、PHPそのものに存在する脆弱性への対策にはなりません。PHPの更新、アクセスログの確認、バックドアの調査、認証情報の見直しなどを組み合わせて、サイト全体の安全性を高めることが大切です。

まずは、ご自身のサイトが使用しているPHPのバージョンを確認し、修正が適用されているかを確かめてください。すぐに更新できない場合は、サーバー会社や専門家に相談し、公開環境の隔離も含めて適切な対応を検討しましょう。

セキュリティ対策は一度実施すれば終わりではありません。日頃からPHPやWordPress関連ソフトウェアの更新情報を確認し、バックアップと監視の仕組みを整えておくことが、被害を未然に防ぐための重要な取り組みです。

WordPressのPHPバージョン確認とバージョンの更新作業は弊社で対応可能です！
ご不安な方は、至急ご連絡下さい。
WPプロサポ

参考情報

• PHP公式：重大なリモートコード実行の脆弱性に関するセキュリティアドバイザリ
• GMO Flatt Security：PHPの重大な脆弱性「php2shell」の概要と対応指針
• ENISAなど欧州関係機関による共同声明
• 英国NCSC：PHPの重大なセキュリティ問題に関する注意喚起

WordPressのハッキング修復はWPプロサポに

WP.復旧センターは「ハッキングされた」「表示がおかしい」「ログインできない」などのWordPressのトラブルをスピーディに修復します。