php2shellとは？PHPの脆弱性の影響と今すぐやる対策

2026年10月21日、PHP本体に見つかった2件の重大な脆弱性に対して修正版が公開され、通称「php2shell」と呼ばれています。認証なしで外部から任意のコードを実行されるおそれがあり、PHPで動くサイトは基本的に対象です。

WordPressを使っている場合も、WordPress本体やプラグインを更新しても防げません。サーバーのPHPを修正版へ更新する必要があります。

この記事では、php2shellとは何か、自分のサイトが対象かどうかの確認方法、今すぐやるべき対策、侵害の有無の確認方法を、WordPress保守を専門とする立場から解説します。

なお、2026年7月に発表されたWordPress本体の脆弱性である「wp2shell」とは別物となりますので、その点ご注意ください（wp2shellとClick2Shellの違い参照）。

php2shellとは？PHP本体に見つかった2つの重大な脆弱性

php2shellとは、PHP本体に見つかった2件の脆弱性（CVE-2026-109618とCVE-2026-109619）の通称です。どちらもCVSS 4.0の基本値が9.2で、最高レベルの「Critical」とされています。

認証なしの外部からのリクエストで、サーバー上で任意のコードを実行される（RCE）おそれがあります。これらの問題は、何十年も前からPHPに存在していたという報告もあります。

2つの脆弱性の違い

CVE	通称・タイトル	原因の概要
CVE-2026-109618	OOMによるメモリ破壊でのRCE	メモリ不足（OOM）で処理が中断されたとき、初期化途中のデータが正常なものとして後始末される
CVE-2026-109619	古いグローバル状態によるRCE	解放済みのメモリを指す状態が残り、同じワーカーで次のリクエストがそれを使う

攻撃の成功はメモリの配置やサーバー構成にも左右されるため、CVSSでは攻撃の複雑さは「高い」と評価されています。ただし、実証された攻撃手法とエクスプロイトはすでに存在すると報じられています。

公開から現在までの経緯

• 2026年10月17日：Amazonのハニーポットで、公表前にphp2shellの攻撃とみられる通信が観測された
• 10月20日：PHPがセキュリティリリースを予告
• 10月21日：修正版を公開。同日から実際の悪用を観測したとする報告もある
• 10月22日時点：米CISAの悪用確認済み脆弱性カタログ（KEV）には未登録

このように悪用状況については、情報源によって記述が分かれています。公開前に修正版を適用できていないサーバーは、すでに攻撃を受けている前提で確認するのが安全です。

wp2shellとは別物です

名前が似ている「wp2shell」はWordPress本体の脆弱性です。php2shellはPHP本体の脆弱性です。原因も、直す方法も違います。違いはwp2shellとClick2Shellの違いを解説した記事で確認できます。

影響を受けるPHPバージョンと自分のサイトの確認方法

修正版より前のPHPはすべて対象です。PHPをウェブリクエストの処理に使っているサーバーは、PHP-FPM、Apacheのmod_php、php-cgi、LiteSpeed、FrankenPHPなど構成を問わず範囲に入ります。

とくにApacheのmod_php構成は、アプリケーションのコードが動く前に攻撃されるため、最も危険とされています（watchTowr）。

修正版の一覧

PHPの系統	修正版	公式の修正版
8.5	8.5.12	あり
8.4	8.4.27	あり
8.3	8.3.36	あり
8.2	8.2.35	あり
8.1、8.0、7.4	なし（ソースビルド向けの最小限のバックポートのみ）	サポート外
7.3以前（PHP5系を含む）	なし	サポート外。

サポート外のPHPを使っているサイトは、サーバー会社やLTSベンダーの独自パッチを待つか、サポート中のバージョンへ移行することになります。Qualysの調査では、バージョンが判明したインストールの約71%がサポート終了にあたる系統（5.4〜8.1）のようです。

PHPのバージョンの確認方法

WordPressの場合、管理画面から確認できます。

1. WordPress管理画面にログインする
2. 「ツール」→「サイトヘルス」→「情報」→「サーバー」を開く
3. 「PHPバージョン」を確認する

レンタルサーバーの管理画面でも確認できます。ただし、サーバー会社によっては、バージョン番号を変えずに修正を適用している可能性もあります。

数字だけでは「未修正」とは断定できないため、バージョン番号とあわせて、契約中のサーバー会社の告知で自分のプランが対象に入っているかを確かめるようにしてください。

または、ご自身での判断が難しい場合は弊社でお手伝いも可能です。
>>無料相談窓口はこちらをクリック

php2shellへの対策：WordPressを更新しても防げない理由と今すぐやること

完全な対策は、PHPを修正版に更新することだけです。PHPの公式も、設定変更では完全には防げないと説明しています（watchTowr）。

脆弱性はWordPressではなくPHPにあるため、WordPress本体やプラグインを最新にしても、セキュリティプラグインを入れても防げるわけでないことに注意してください。

契約形態別の対応の目安

契約形態	PHPを更新するのは	あなたがやること
レンタルサーバー（共用）	サーバー会社が一括で対応することが多い	契約中のサーバー会社の告知で、自分のプランとPHPの系統が対象か確認する。この系統が8.1以前なら、サポート中のバージョンへ切り替える
VPS・クラウド・自社管理サーバー	自分（または保守委託先）	OSのパッケージでPHPを更新し、すべてのPHPワーカーを再起動する
保守会社に委託中	保守会社	対応状況と完了日を問い合わせる

レンタルサーバー各社の対応状況（10月23日17:30時点）

各社の公式告知をもとにまとめると、10月23日時点で主要なレンタルサーバーはいずれも修正の適用をほぼ完了しています。

多くの事業者はバージョン番号を変えずに修正を適用しているため、サイトヘルスの表示が「8.4.26」のように修正版より前の番号のままでも、告知で対象に入っていれば対策済みです。

状況は更新されるため、必ず各社の最新の告知を確認してください。

事業者	状況（10/23 17:30時点）	PHP 8.1以前の扱い
エックスサーバー	PHP 5.6〜8.5は全対象サーバーへ適用完了（8.2〜8.5は10/22 06:45、7.4〜8.1は同12:00、5.6〜7.3は同14:00）。PHP 5.1〜5.5は過半数のサーバーで適用済みで、残りは対応中	5.6〜8.1はバージョン番号を変えずに対策を適用。XServer VPS・クラウドは対象外のため利用者自身で更新が必要
さくらのレンタルサーバ	必要な対応は完了。10/23 17:30に緊急メンテナンスも終了	サポート終了バージョンにも修正を適用済み。サポート中の最新版への移行を推奨
ロリポップ！	10/22 13:00頃にサイト表示が復旧し、同日中に関連サービスも復旧。8.2〜8.5は公式修正版（8.2.35・8.3.36・8.4.27・8.5.12）を適用	7.4〜8.1はPHP開発元が提供したサポート終了版向けの修正、5.3〜7.3は公式パッチをもとにした独自修正を適用。全バージョンでsession.upload_progressを無効化。8.2以上への切り替えを推奨
KAGOYA	レンタルサーバープラン（7.4・8.1〜8.5）は10/22中に更新完了。マネージド専用・共用・WordPress専用サーバーは恒久対応の方針を調整中（10/23 12:30時点）	レンタルサーバープランの7.4・8.1は修正版へ更新。未対応プランはメンテナンスページ化やアクセス制限を案内
mixhost	10/22 10:18頃に全サーバーへ適用完了（PHP 5.2〜8.5）	CloudLinuxのパッチでサポート終了版にも適用。バージョン番号は変わらない。8.2以上への移行を推奨
ConoHa WING	10/22 20:45に提供中の全PHPバージョンへ適用完了（終報）	5.6.40〜8.5.11の全バージョンに番号を変えずに適用。利用者側の作業は不要

パッチを適用できるまでの暫定策

すぐに更新できない場合、PHPのメンテナーが示すとおり、攻撃経路を減らす設定があります。たとえば、session.upload_progress.enabled=0でセッションのアップロード進捗機能を無効にして、ワーカーを再起動します。

ただし、これはあくまで時間稼ぎにすぎません。GMO Flatt Securityは、この設定だけでは迂回攻撃が可能と見込まれると発表しています（窓の杜）。CDN/WAFのルールも同様に、更新の代わりにはなりません。

古いPHPバージョンへのパッチ適用がないサーバーの場合

上の表のとおり、エックスサーバー・さくら・ロリポップ・mixhost・ConoHa WINGといった主要なレンタルサーバーでは、PHP 8.1以下であっても独自パッチやCloudLinuxのパッチを適用済みです。

しかしながら、独自のパッチ適用がなく今後も提供予定がないレンタルサーバーも散見されるため、その場合はバージョンアップを強行するか、または、独自CMSなどですぐのバージョンアップが難しい場合はエックスサーバーへ一旦サーバー移転して回避するなどの方法も考えられます。

「自分たちはどのような手段を取ればいいのか分からず困っている」
そのような場合は弊社サイト引越し屋さんへお問い合わせください。

>>無料相談窓口はこちらをクリック

不正アクセスを受けたか確認する方法

攻撃は10月17日に公表前から観測されています。そのため、PHPを更新しただけで終わらせず、インターネットに公開されていたサイトは侵害のあとがないかを確認してください。跡が見つからなくても、攻撃を受けていないとは言い切れません。

WordPressサイトで確認する項目

• wp-content/uploadsや一時ディレクトリに、見覚えのない.phpファイルがないか
• 見覚えのない管理者アカウントが作られていないか
• 見覚えのない定期実行（cron）が登録されていないか
• サイトが急に表示されなくなったり、スパムページが生成されていないか

サーバーログで確認する項目

JPCERT/CCが挙げる確認点は次のとおりです（Webセキュリティ診断センター）。

• 不自然なPHPSESSIDのCookieが送られている
• 不審なmultipart/form-dataリクエストと、メモリ上限エラーやHTTP 500が増えている
• PHPワーカーの異常終了や、頻繁な再起動が起きている

自分での対応が難しい場合は、専門業者への依頼を検討しましょう。

PHPの更新は、バージョンを上げるとテーマやプラグインが動かなくなることがあります。特に8.1以前からの切り替えは、互換性の確認とバックアップ、動作テストを含めて計画的に進める必要があります。次のような場合は、専門家への依頼をお勧めします。

• 自分のサイトがPHP 8.1以前で動いている、またはバージョンが分からない
• サーバーの管理画面やログイン情報を把握していない
• 更新後に表示崩れやエラーが出た、または出る不安がある
• 侵害の跡があるかもしれない

弊社「サイト引越し屋さん」では、WordPress保守管理サービスとしてPHPバージョンアップの対応を承っています。こちらのお問い合わせフォームからお気軽にご相談ください。

サイト引越し屋さんが実際に対応した事例

10月21日の発表後、弊社ではWordPress保守契約中のサイトを順次修正版へ更新するとともに、メールマガジンを見てご相談いただいた方の対応にあたりました。

ここでは、10月22日〜23日の2日間で実際に起きたことを、サーバー会社名は実名、お客様は業種のみ記載する形で紹介します。「自分で上げても大丈夫か」を判断する材料にしてください。

事例1：自分でPHPを上げたら「重大なエラー」、しかも元に戻せない（音楽教室サイト）

メールマガジンをご覧になったお客様が、サーバー管理画面からご自身でPHPのバージョンを変更したところ、サイトが「このサイトで重大なエラーが発生しました。」の表示になり閲覧できなくなりました。

慌てて元のバージョンに戻そうとしたものの、他の設定と干渉しアラートが出て戻せない状態に。弊社でサーバー管理画面にログインし、設定を調整したうえでPHPを元のバージョンに戻して表示を復旧させました。

その後、影響の少ない夜間にWordPress本体・プラグイン・PHPをまとめて更新し、翌日には安全なバージョンで安定稼働しています。

事例2：PHP 5.6の独自CMSを8.2に切り替えたら大部分が表示されず、即ロールバック（エックスサーバー・情報サイト）

WordPressではなく独自CMSで運用されている情報サイトで、PHP 5.6.40のまま稼働していました。お客様の了承のもと、試験的にサーバーパネルからPHP 8.2へ切り替えたところ、サイトの大部分が表示されない状態になったため、その場で5.6.40へ戻しています。

このサイトはエックスサーバーの独自対策（5.6〜8.1はバージョン番号を変えずに修正を適用）の対象に入っていたため、php2shellそのものへの当面のリスクは下がっています。

ただし、PHP 5.6はそれ以外の既知の脆弱性も抱えたままなので、検証環境を用意したうえで計画的にバージョンアップする方向でご提案しました。

ポイント：PHP 5系・7系から8系への切り替えは、本番で直接試すと高確率で表示崩れが起きます。独自CMSや古いテーマを使っているサイトは、検証環境での動作確認を前提に進めてください。

事例3：PHP更新は成功したが、特定のプラグインが非対応で画像アップロードが不可に（wpX・個人サイト）

wpXをご利用のお客様がPHPを8.3.36へ更新したところ、サイト表示は問題なかったものの、管理画面から画像のアップロードと削除ができなくなりました。調べると、利用中のプラグインがPHP 8以降に対応しておらず、これがエラーの原因でした。

ポイント：PHPを上げた後は、トップページが表示されるかだけでなく、画像のアップロード、お問い合わせフォームの送信、記事の投稿・編集といった管理画面側の操作まで一通り確認してください。長く更新されていないプラグインは、PHP 8系で動かなくなることがあります。

事例4：保守契約中サイトの一斉更新で起きたこと（さくら・エックスサーバー・wpX）

弊社の保守契約サイトについては、発表翌日から順次、PHPを8.3.36などの修正版へ切り替えました。

さくらのレンタルサーバで7.4.33のまま稼働していた研究団体のサイトは8.3へ更新し、更新直後にエラーで一時的に表示できなくなったものの、同日中にエラー箇所を修正して復旧しています。別のサイトでは確認したところすでに8.3.35で稼働しており、追加対応は不要でした。

なお、10月22日の日中はエックスサーバーやさくらの管理画面にアクセスが集中し、ログインや設定変更自体ができない時間帯がありました。このため一部の作業は翌日にずれ込んでいます。

ポイント：発表直後は各社の管理画面が混み合います。無理に何度も操作せず、時間を置いて再試行してください。また、更新前にバックアップを取得しておけば、エラーが出ても落ち着いて復旧できます。

ご相談から見えた傾向

今回ご相談いただいたサイトの多くは、PHP 7.4.33や7.3.33のまま数年間更新されておらず、中には古いWordPressのため「サイトヘルス」の画面自体が表示されないものもありました。

php2shellを機に、PHPだけでなくWordPress本体・プラグイン・テーマも含めて、サポート中の組み合わせへ引き上げることをおすすめします。

よくある質問

ここでは、php2shellに関して弊社クライアントからいただいたご質問を列挙しておきます。

php2shellはWordPressの脆弱性ですか？

いいえ。PHP本体の脆弱性です。WordPress.orgは、WordPress本体の更新は不要で、サーバーのPHPを更新する必要があるとしています。

PHPのバージョンが8.4.26のように修正版より前でも、未修正とは限らないですか？

はい。サーバー会社やディストリビューションは、バージョン番号を変えずに修正を適用することがあります。契約中の事業者からの案内や公式サイトなどで直接確認してください。

PHP 8.1以前のサイトはどうすればよいですか？

公式の修正版はありません。サーバー会社やLTSベンダーの独自パッチを確認するか、サポート中のPHPへの切り替えを計画してください。

それが難しい場合には、エックスサーバーなど古いPHPバージョンに対して独自のパッチを適用しているサービスへのサーバー移転を検討しましょう。

サーバー会社が古いPHPにも独自パッチを当てたなら、そのままで安全ですか？

php2shellに関しては、当面のリスクは下がります。ただし、PHP 8.1以前はPHP開発元のサポートが終了しており、今後見つかる脆弱性には公式の修正が出ません。サーバー会社も「今回の修正は暫定的なもの」と案内しています。今回のパッチで時間を確保しつつ、サポート中のPHP 8.2以上へ計画的に切り替えることをおすすめします。

WAFを入れていれば大丈夫ですか？

多少の時間稼ぎにはなりますが、今回の脆弱性を解消できるほどの対策にはなりえません。

まとめ

php2shellは、PHP本体の脆弱性（CVE-2026-109618・109619）です。対策の要点として、本脆弱性はWordPressの更新では直らないため、PHPを修正版（8.5.12・8.4.27・8.3.36・8.2.35）へ引き上げる必要があり、設定変更やWAFはあくまで暫定策にとどまります。

まずは契約中のサーバー会社の告知から自身のプランとPHPの系統が対象かを確認し、PHP 8.1以前を利用している場合は切り替えを計画してください。ご自身での対応が難しい場合には、お気軽にご相談ください。