PHP2Shellとは？影響を受けるサイトと今やる対策をやさしく解説

PHP2Shellとは、2026年10月21日にPHP公式が公表した、PHP本体の重大な脆弱性2件（CVE-2026-109618・CVE-2026-109619）の呼び名です。レンタルサーバーは各社が対応を終えていて、VPSや自前のサーバーは自分で修正版へ更新します。

悩見有造

ニュースで「PHP2Shell」という言葉を見ました。うちのホームページもPHPで動いているらしいのですが、何が危ないのか、何をすればいいのかが分かりません。

編集長

PHP2Shellは、PHPという言語そのものの不具合で、レンタルサーバーならサーバー会社が直していて、VPSなら自分で更新します。まずは自分のサイトがどちらかを確かめるところから、順番に説明しますね。

PHP2Shellとは？10月21日に公表されたPHP本体の脆弱性

編集長

まずは「何が起きたのか」を、PHP公式とIPA（情報処理推進機構）の発表で整理します。

PHP本体の重大な脆弱性2件の組み合わせ

PHP2Shellは、PHP公式が2026年10月21日に公表した2件の脆弱性の組み合わせを指す呼び名です。PHP公式は、この2件を認証なしで遠隔からコードを実行されるおそれがある重大な脆弱性と説明しています。

IPAも10月22日に注意喚起を出し、悪用されると遠隔の第三者に任意のコードを実行されるおそれがあると書いています。ログイン画面を突破されなくても、外からの通信だけで攻撃が成立しうる点が深刻とされた理由です。

米国CISAの「悪用が確認された脆弱性」の一覧に載った

IPAによると、2件は10月26日（現地時間）に米国CISAのKEVカタログ（悪用が確認された脆弱性の一覧）に掲載されました。JPCERT/CC（10月29日更新）によると、悪用を主張する実証コードが多数公開され、悪用を試みる通信の報告も相次いでいるとされています。

一方で、IPAは10月27日の更新で、国内での攻撃被害の事例は把握していないとしています。慌てる必要はありませんが、修正版への更新は後回しにできない段階です。

PHPを組み込んだ機器やソフトも確認の対象

IPAは11月2日の更新で、PHPはVPN機器やセキュリティアプライアンス製品のウェブ管理画面などでも使われていると追記しました。自社で使っている製品は、開発元から出る脆弱性対策情報を確認するよう呼びかけています。

JPCERT/CCも、PHPを組み込んだ製品やLinuxディストリビューションが提供するPHPが影響を受けることがあるとしています。ホームページだけでなく、社内のネットワーク機器の管理画面も確認の対象に入ります。

影響を受けるのはどんなサイト？

編集長

「WordPressじゃないから関係ない」とは言えないのが今回のポイントです。PHPで動いているかどうかで決まります。

Webリクエストを処理するすべてのPHPが対象

PHP公式は、影響を受けるのはWebリクエストを処理するすべてのPHPと書いています。PHP-FPM・Apacheのmod_php・php-cgi・FrankenPHP・LiteSpeedが名前を挙げられています。

中でもPHP公式は、mod_phpの危険度が最も高いとしています。認証のないリクエストで、アプリケーションのコードが動く前に攻撃できることが実証されているためです。

影響を受けるバージョン

IPAの注意喚起では、修正版より前の8.2系・8.3系・8.4系・8.5系が影響を受けるバージョンとして挙げられています。IPAが紹介している調査会社Wiz社の情報では、PHP 5.4以降は少なくとも1つの脆弱性の影響を受けるとされています。

8.1以前は、PHP公式のサポートが終わったバージョンです。古いPHPのまま動いているサイトほど、対応の手間が大きくなります。

WordPressの更新では直らない

不具合があるのはPHP本体なので、WordPress本体やプラグインを更新しても、この脆弱性は直りません。WordPressで作ったサイトも、自作のサイトも、PHPで動いていれば同じように対象です。

直すには、サーバーで動いているPHPそのものを修正版に入れ替えます。レンタルサーバーならサーバー会社、VPSや自前のサーバーなら契約者自身が入れ替える担当です。

修正版はどれ？8.2.35・8.3.36・8.4.27・8.5.12

編集長

修正版の番号は4つです。サポート期限とあわせて表にしました。

各系列の修正版

PHP公式は10月21日に、PHP 8.5.12・8.4.27・8.3.36・8.2.35の4つの修正版を公開しました。Linuxディストリビューションなどには修正が事前に渡されていて、PHP公式は各提供元の更新パッケージを確認するよう案内しています。

出典：PHP公式「Security advisory」「Supported Versions」（2026年11月7日確認）。自分のPHPが表の修正版以上になっていれば、今回の2件は修正済みです。

8.1以前は公式の修正版が出ない

PHP 8.1以前は、PHP公式からの更新がもう出ません。一部のディストリビューションやLTSベンダーが修正を移植して提供しているので、提供元に確認するか、サポート中のバージョンへ上げるよう案内しています。

PHPのセキュリティチームは、ソースから自分でビルドする人向けに、7.4・8.0・8.1用の最小限の修正コードも公開しました。IPAは、8.1以前の利用者にサポート中のバージョンへの移行を検討するよう求めています。

8.2は修正済みでも12月31日で期限切れ

PHP 8.2は8.2.35で今回の2件が直りましたが、セキュリティ修正の期限は2026年12月31日です。年明け以降に新しい脆弱性が見つかっても、8.2には修正版が出ません。

8.2を使っている場合は、今のうちに8.3以上へ切り替えておくと二度手間を防げます。8.2のサポート終了と切り替えの手順は、PHP 8.2は2026年12月31日でサポート終了｜WordPressで今やる3つのことにまとめています。

利用者別にやること（レンタルサーバー・VPS・制作会社任せ）

編集長

やることは、サイトの置き場所で変わります。レンタルサーバー、VPS・自前サーバー、制作会社任せの3つに分けました。

レンタルサーバーの人：各社の対応完了を確認する

エックスサーバー・ConoHa WING・ロリポップ・さくらのレンタルサーバ・mixhostの5社は、今回の脆弱性への対応完了を公式に発表しています。エックスサーバーは10月26日6時20分までにPHP 5.1～8.5のすべての対象サーバーで対応を終え、利用者の作業は原則不要としています（2026年11月7日時点）。

ただし、サイトヘルスなどに表示されるPHPのバージョン番号は、修正後も変わらないことがあります。番号が変わらない理由はサイトヘルスのPHPバージョンが変わらない…本当に修正済み？サーバー別に確認で、自分で新しいバージョンへ切り替える手順は【サーバー別】PHPバージョンの確認・変更方法｜エックスサーバー・ConoHa WING・ロリポップ・さくら・mixhostで説明しています。

VPS・自前サーバーの人：自分で修正版に更新する

VPSは、OSやPHPを契約者自身が管理するサービスです。エックスサーバーも、XServer VPSなどのVPS系サービスには会社側で修正パッチを当てておらず、利用者がPHPを確認して修正版へ更新する必要があると明記しています。

IPAは、すぐに更新できない場合も脆弱な状態のまま放置せず、暫定対策やアクセス制限を考えるよう求めています。有効な暫定対策が難しいときは、外部からのアクセス遮断やサービスの一時停止が必要かを判断するよう書かれています。

VPS各社の案内と更新の考え方は、VPSのPHPは自分で更新が必要｜PHP2Shell後にやること（OS別の手順）で詳しく扱います。

更新したあとに見ておきたい侵害の痕跡

JPCERT/CCは、修正版へ更新したあとも、攻撃を受けていないかをログで確認するよう勧めています。痕跡が見つからなくても攻撃を受けていないとは言い切れないため、不審なプロセスや外部への通信、見覚えのないファイルも見るよう書いています。

出典：JPCERT/CC 注意喚起（2026年10月29日更新）。侵害が疑われるときは、ログなどの証拠を残したうえで影響範囲を調べ、必要ならシステムを切り離すよう案内されています。

制作会社・保守会社に任せている人：3つを聞く

ホームページを制作会社や保守会社に任せている場合は、サーバーの種類・PHPのバージョン・修正版の適用日の3つを確認します。サーバーの種類で担当が変わるので、最初に置き場所を聞くと話が早く進みます。

保守契約にPHPの更新が入っているかどうかで、追加の費用が出るかどうかも変わります。保守契約で確かめる項目は、ホームページ保守で制作会社に確認すること｜PHP・WordPressの更新は誰がやる？にまとめています。

10月23日の追加告知とWAFの位置づけ

編集長

10月23日にはPHP公式から追加のお知らせも出ています。あわせて、WAFでどこまで守れるのかも整理しておきます。

CVE-2026-115560は条件がそろったときだけの経路

PHP公式は10月23日に、起こりにくいコード実行の経路としてCVE-2026-115560を「情報提供」として公表しました。アプリケーションが設定でsession.serialize_handlerをphp_binaryかphp_serializeにし、実行中にini_set()でphpへ切り替えてからsession_start()を呼び、さらにセッションのアップロード進捗機能が有効なときに限られます。

PHP公式は通常のリリースで修正し、次のリリースで詳しい告知を出すとしています。それまではsession.upload_progress.enabled=0にしておくよう勧めていて、10月21日の緩和策でphp.iniやFPMの設定にすでに入れた人は追加の作業は不要です（ini_set()や.user.iniでは不十分）。

WAFや設定変更は「時間かせぎ」で、更新の代わりにならない

PHP公式は、更新できない人向けに設定の変更などの緩和策を示しましたが、これらは特定の攻撃経路を減らすだけで、安全にするものではないと書いています。完全な対策は更新だけとしています。

Cloudflareは、10月21日3時02分（UTC）から無料・有料のWAFの利用者を既定で保護したと公表しました。それでもCloudflare自身がWAFがあってもPHPは更新するべきと書いていて、session.upload_progress.nameを変えている場合はWAFのルールの対象外としています。

WAFの仕組みと、無料で使えるものの選び方はWAFとは？無料で使えるものと有料の選び方｜レンタルサーバー・Cloudflareで説明しています。