PHPの重大脆弱性「php2shell」とは？影響範囲・今やること・次への備え

2026年10月21日23時（日本時間）、Webサイトの開発に広く使われているプログラミング言語「PHP」の重大な脆弱性2件を修正したバージョンが公開されました。通称は「php2shell」です。修正版の公開を待たずに、国内でもECサービスや動画サービス、ゲーム、金融機関、自治体などがサービスの一時停止や緊急メンテナンスに踏み切るという、異例の事態になりました。

この記事の内容は2026年10月22日時点の情報にもとづいています。状況は日単位で変わるため、対応の際は記事中のリンク先にある公式情報もあわせて確認してください。

結論：やることは3つです

• PHPを修正版に更新する：8.5.12／8.4.27／8.3.36／8.2.35、またはOSの提供元が出す修正済みパッケージ
• 誰がどこでPHPを使っているかを棚卸しする：自社サイトだけでなく、委託先・レンタルサーバー・社内システム・検証環境まで
• 公開しなくていいシステムは外から届かなくする：社内の人だけが使う管理画面や業務システムは、インターネットに公開しない

何が起きたのか：時系列で分かるphp2shell

公開までの経緯

php2shellは、修正版の公開前に脆弱性の情報が外部に出回ったことで、関係者が予定を前倒しして対応にあたった点が特徴です。主な出来事を日本時間でまとめます。

出典：PHP公式のリリース告知、The PHP Foundation、piyolog、IPA

通常、重大な脆弱性は「修正版の公開と同時に詳細を公表する」のが原則です。利用者が修正版を入手できる前に攻撃方法だけが広まると、守る手段がないまま攻撃を受けることになるからです。今回は公表前の取り決め（禁止期間）の中で情報が漏れたため、PHPチームは予定を早めて修正版を出しました。

異例の対応を招いた背景

各社が修正版の公開を待たずに先回りでサービスを止めた背景には、2つの事情があります。

1つは、前述のとおり攻撃に使える情報が先に出回ったことです。もう1つは、攻撃コードを作るハードルが下がっていることです。セキュリティ企業のWizは、この欠陥は数十年前から存在していたものの、悪用には非常に複雑な手順が必要だったとしたうえで、最新のAIモデルがその障壁を大きく下げたと指摘しています（Help Net Security）。

なお、PHPの開発を支援するThe PHP Foundationは、2024年の外部監査の作業中に今回の問題の兆候を見つけていたものの、当時は任意のコード実行に至る経路までは確認できておらず、対応が進まなかったと説明しています。

国内でも停止が広がった

報道によれば、BASE、コドモン、pixiv、DMM.com、ニコニコ、グランブルーファンタジーなどのゲーム、銀行、自治体など、業種や地域を問わず多くの組織がサービスの一時停止や緊急メンテナンスを告知しました（Impress Watch）。piyologの集計では、2026年10月22日時点で211組織にのぼります。

ただし、停止の理由にPHPの脆弱性を明記していない組織もあります。Impress Watchは、これらの停止を「修正版公開前の予防的な措置」として報じています。レンタルサーバー各社も、修正版の適用に向けて緊急の対応を行いました。

なぜここまで深刻なのか

「うちはPHPを使っていない」は思い込みのことが多い

PHPは、Webサイトを動かす土台として非常に広く使われています。代表的なものは次のとおりです。

• WordPress：企業サイト・ブログ・オウンドメディアの多くで使われているCMS
• EC-CUBE：国内のECサイトで使われるECパッケージ
• Laravel：自社開発のWebサービスや業務システムで使われるフレームワーク
• 業務システム・管理ツール：勤怠・申請・顧客管理などのWebアプリ、データベースの管理ツール

自社でプログラムを書いていなくても、制作会社に作ってもらったコーポレートサイトや、昔のキャンペーンサイト、社内で使っているWebの業務ツールがPHPで動いていることはよくあります。IPAも、PHPがソフトウェア製品やネットワーク機器に組み込まれていて、利用者からは見えない場合があると注意を促しています。

「認証なし」「アプリより前」で攻撃が成立する

今回の脆弱性が特に深刻なのは、次の2つの性質を持つためです。

1. ログインが不要：攻撃者はIDもパスワードも持たずに、インターネットからリクエストを送るだけで攻撃できる
2. アプリのコードが動く前に成立しうる：WordPressやEC-CUBEなどのアプリが処理を始める前の、PHP本体の段階で攻撃が成立しうる

2つ目はとても重要なので、言い換えます。ログイン画面の強化や、WordPressのセキュリティプラグイン、WordPress本体やプラグインの更新では、今回の脆弱性は解消しません。 守るべき場所はアプリではなく、その下で動いているPHP本体です。

脆弱性の深刻度を示すCVSS v4.0のスコアは2件とも9.2で、「緊急（Critical）」に分類されます。成功すると、攻撃者がサーバー上で任意のプログラムを実行できる「リモートコード実行」につながるおそれがあります。

2つの脆弱性の概要

影響を受けるのは、Webリクエストを処理するPHPです。公式のアドバイザリでは、PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeedが挙げられており、中でもmod_phpの構成が最も危険だとされています。技術的な仕組みの詳細は、PHP公式のアドバイザリやRapid7の解説を参照してください。

自社は大丈夫なのか：影響を判断するフロー

まず「サーバーを誰が管理しているか」で分ける

自社が何をすべきかは、そのサイトやシステムのサーバーを誰が管理しているかで変わります。

見落としがちな場所

ふだん意識していない場所ほど、更新が漏れます。次のようなシステムがないか確認してください。

• 公開を終えたまま残っている、古いキャンペーンサイトや特設サイト
• 開発・検証用の環境（ステージング環境）
• 社内で使っている勤怠・申請・在庫管理などのWebシステム
• データベースをブラウザから操作する管理ツール
• ネットワーク機器やソフトウェア製品に組み込まれたPHP（製品のメーカーの情報を確認する）

PHP 8.1以前を使っている場合

修正版が出ているのは、PHP 8.2以降のサポート中のバージョンです。PHP 8.1以前は公式のサポートが終わっており、修正版のリリースはありません（7.4・8.0・8.1向けには、修正部分のソースコードだけが提供されています）。8.1以前を使っている場合は、サポート中のバージョンへの移行が必要です。なお、PHP 8.2も2026年12月31日でサポートが終了する予定です。

チェックリスト

• 自社に関わるサイト・システムの一覧を作った（委託先・レンタルサーバー・SaaSも含む）
• それぞれ、サーバーを誰が管理しているかを確認した
• 自社管理のサーバーで、PHPのバージョンを確認した
• レンタルサーバー・SaaSの提供元のお知らせを確認した
• 委託先に対応状況を問い合わせた
• 古いキャンペーンサイト・検証環境・社内システムも確認した
• PHP 8.1以前で動いているものがないか確認した

今すぐやること

1. PHPを更新する

根本的な対策は、PHPを修正版に更新することだけです。

LinuxのOSに付属するパッケージでPHPを入れている場合は、OSの提供元が出す修正済みパッケージに更新します。このとき、バージョン番号が上の表と一致しないことがあります。提供元が修正だけを古いバージョンに取り込む（バックポート）ことがあるためです。

対応状況はOSによって異なります。10月22日早朝の時点で、UbuntuやDebianは修正済みのパッケージを公開していた一方、RHEL系の一部やAmazon Linuxでは未対応のものがありました（Zennのまとめ）。状況は時間単位で変わるため、自分の環境の提供元の情報を確認してください。

2. すぐに更新できない場合

PHP公式は、更新までの一時的な緩和策として、session.upload_progress.enabled を無効にする設定などを示しています。ただし公式自身が、これらはリスクを下げるだけで安全にするものではないと明記しています。設定の場所や反映方法によっては効果がないものもあるため、実施する場合は必ず公式のアドバイザリを確認してください。

更新も緩和策も難しい場合は、システムを一時的に止めることも有効な選択肢です。国家サイバー統括室は、ウェブサイトの一時停止もリスクを下げる有効な策の1つだと呼びかけています。英国のNCSC（国家サイバーセキュリティセンター）も、緩和策をすぐに適用できない場合はシステムをオフラインにすることを検討するよう求めています（NCSC）。

3. WAFは補助として使う

WAF（Webアプリケーションファイアウォール）は、Webサイトへの攻撃的な通信を検知して遮断する仕組みです。Cloudflare、Akamai、Palo Alto Networksなどが、今回の脆弱性を狙う通信を検知するルールを提供しています。WAFを導入している場合は、ルールが有効になっているか確認しましょう。

ただし、WAFは攻撃者が通信の形を変えるとすり抜けられることがあり、PHP本体の更新の代わりにはなりません。米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）も、WAFはパッチを適用するまでの部分的な保護だと位置づけています。

4. 侵害の痕跡を確認する

更新したあとは、すでに攻撃を受けていないかを確認します。悪用の状況について、IPAとCISAは10月21日時点で悪用を確認していないとしていました。一方、CloudflareやwatchTowr、Amazonなどは、攻撃の試みを観測したと発表しています。侵害に成功した事例は、10月22日時点では報告されていません。

注意したいのは、Rapid7が指摘するとおり、関連するログが見当たらないことは、安全である証拠にはならないという点です。サーバー上に見覚えのないファイルやプログラムがないか、不審な外部通信がないかを確認し、判断が難しい場合はセキュリティの専門業者に相談してください。

今回の教訓：「公開しなくていいもの」を公開していないか

インターネットから届かなければ、攻撃されない

今回のように、ログインが不要でアプリより前に成立する脆弱性は、「インターネットからリクエストが届く」だけで狙われます。裏を返せば、攻撃者のリクエストが届かないシステムは、この種の攻撃を受けません。

もちろん、会社のWebサイトやECサイトは、誰でもアクセスできることが前提です。一方で、社内の人しか使わない管理画面や業務システムまで、インターネットに公開したままになっていないでしょうか。PHPで動くシステムを、次の2つに仕分けてみてください。

社内向けのシステムを外から届かなくする方法として、ここでは2つのやり方を紹介します。

方法1：接続元を「会社の固定IP」だけに絞る

サーバーやクラウドのアクセス制限（ファイアウォールやセキュリティグループ、Webサーバーの設定）で、接続を許可する送信元を会社の固定IPアドレスだけにする方法です。許可していないIPアドレスからのリクエストは、PHPに届く前に遮断されます。

このやり方の課題は、在宅勤務や外出先からはつながらなくなることです。「ロリポップ！固定IPアクセス」を使うと、自宅や外出先のパソコンからも、会社として契約した同じ固定IPアドレスで通信できます。サーバー側では1つの固定IPアドレスだけを許可すればよいので、アクセスを絞っても、社外からの業務を止めずに済みます。機器は不要で、最短5分で使い始められます。

Webサーバーでの具体的な設定方法は「nginxのIP制限設定｜allow/denyの書き方」で解説しています。

方法2：許可した端末からだけつなぐ

もう1つは、サーバーをインターネットに公開せず、許可した端末からだけ接続できるようにする方法です。「ロリポップ！ゼロトラストリンク」は、アプリを入れてログインした端末同士だけを暗号化した通信で直接つなぐサービスです。サーバー側にも同じアプリを入れれば、インターネットにポートを開けなくても、メンバーの端末から社内システムや開発環境を使えます。VPN機器も必要ありません。

「止める」代わりの選択肢にもなる

今回、多くの組織が「更新が終わるまでサービスを止める」判断をしました。社内向けのシステムについては、止める代わりに「社内の人からだけ使える状態」にして業務を続けるという選択肢もありえます。普段から外に公開していなければ、そもそも緊急時の判断に迫られることも減ります。

ただし、外から届かなくしても、PHPの更新は必ず行ってください。社内の端末がマルウェアに感染した場合など、内側から攻撃されるおそれは残ります。

必ず押さえておきたい注意点

誤解のないよう、2つの点をはっきりさせておきます。

1. 一般に公開しているWebサイトは、固定IPやゼロトラスト接続で守ることはできません。 誰でもアクセスできる状態で公開するサイトは、接続元を絞れないためです。公開サイトの根本対策は、PHPの更新だけです。
2. WordPressの管理画面（wp-admin）だけをIP制限しても、今回の脆弱性は防げません。 今回の攻撃はログインが不要で、アプリが処理を始める前の段階で成立しうるため、管理画面以外の公開ページへのリクエストも攻撃の経路になりえます。管理画面のIP制限は不正ログイン対策としては有効ですが、今回の対策にはなりません。

WordPressの管理画面のIP制限が何に効くのかは「WordPressのIPアドレス制限を徹底解説」で解説しています。

次に備える：脆弱性に強い会社の普段の運用

今回のような緊急事態は、今後も起きると考えておくべきです。慌てずに対応できるよう、普段から次の4つを整えておきましょう。

• ソフトウェアの台帳を作る：どのサーバーで、何のソフトウェアの、どのバージョンが動いているかを一覧にしておく。今回のように「どこでPHPを使っているか」を即答できるかどうかで、初動の速さが変わる
• 提供元・委託先の連絡網を作る：レンタルサーバー、SaaS、制作会社、保守ベンダーの窓口と、お知らせを確認する場所をまとめておく
• 止めていいシステムの基準を決めておく：緊急時に「このシステムは止めてよいか」を誰が判断するか、止めた場合の業務への影響を事前に整理しておく
• サポート切れを計画的に更新する：PHP 8.2のように、サポート終了の予定日は事前に分かる。期限の前に移行の計画を立てておく

脆弱性を突いた侵入は、情報漏えいの主な起点の1つでもあります。MM総研の調査では、2026年1〜9月に脆弱性を突いた侵入による情報漏えいが48件ありました。

個人として気をつけること

PHPの脆弱性は企業のサーバーの問題ですが、個人として気をつけたいこともあります。

• 利用しているサービスのお知らせを確認する：停止していたサービスが再開したときは、公式サイトや公式アプリのお知らせで、利用者に求められる対応がないか確認する
• 便乗したフィッシングに注意する：「脆弱性対応のためパスワードの再設定をお願いします」といったメールやSMSが届いても、リンクは開かず、公式サイトや公式アプリから確認する
• 個人でサイトを運営している人はPHPのバージョンを確認する：個人ブログや副業のネットショップを運営している場合も、利用しているサーバーのお知らせを確認し、PHPのバージョンが修正版になっているかを確かめる

「社内だけで使う」を実現する2つの方法

社内向けのシステムをインターネットから届かなくする2つの方法を比べます。

固定IPアクセスは、個人から1,000人規模の法人まで、公的機関や学校法人でも利用されています。料金は月額490円（税込539円）〜（ライトプラン）です。

php2shellに関するよくある質問

レンタルサーバーを使っている場合は何をすればよいですか？

まず、契約しているレンタルサーバーの公式サイトや管理画面のお知らせを確認してください。PHPの更新はサーバーの提供元が行うのが一般的ですが、管理画面でPHPのバージョンを自分で選ぶ方式の場合は、サポートが終わった古いバージョンを選んでいないかも確認しましょう。PHP 8.1以前を選んでいる場合は、サポート中のバージョンへの切り替えが必要です。

WordPressを最新版に更新すれば大丈夫ですか？

WordPress本体やプラグインの更新だけでは解消しません。今回の脆弱性はWordPressではなく、その下で動いているPHP本体の問題で、WordPressが処理を始める前の段階で攻撃が成立しうるためです。WordPressの更新とは別に、サーバーのPHPが修正版になっているかを確認してください。

PHPのバージョンはどうやって確認しますか？

自社でサーバーを管理している場合は、サーバー上で php -v を実行すると表示されます。ただし、コマンドラインで動くPHPとWebサーバーで動くPHPが別のバージョンのことがあるため、Webサーバー側の設定やパッケージのバージョンもあわせて確認してください。レンタルサーバーの場合は、管理画面のPHP設定の画面で確認できるのが一般的です。WordPressなら、管理画面の「ツール」→「サイトヘルス」→「情報」でも確認できます。

WAFがあればPHPを更新しなくてもよいですか？

更新は必要です。WAFは攻撃的な通信を検知して遮断する仕組みですが、攻撃者が通信の形を変えるとすり抜けられることがあります。米国のCISAも、WAFはパッチを適用するまでの部分的な保護だと位置づけています。WAFは更新までの時間を稼ぐ補助として使い、PHP本体の更新を必ず行ってください。

IPアドレス制限をすれば安全ですか？

一般に公開しているWebサイトは、IPアドレス制限では守れません。誰でもアクセスできる状態で公開するため、接続元を絞れないからです。一方、社内の人だけが使う管理画面や業務システム、開発環境は、接続元を会社の固定IPアドレスに絞ることで、許可していない場所からのリクエストを届かなくできます。ただし、その場合もPHPの更新は必要です。

まとめ：PHPの更新と、「公開しない」の見直しを

php2shellは、ログインが不要で、アプリが処理を始める前に成立しうる重大な脆弱性です。根本的な対策はPHPを修正版に更新することだけで、WordPressの更新やWAFはその代わりになりません。まずは自社に関わるサイトとシステムを棚卸しし、サーバーを誰が管理しているかに応じて、更新や問い合わせを進めてください。

そのうえで、今回の教訓として、社内の人だけが使うシステムをインターネットに公開していないかを見直しましょう。外から届かないシステムは、この種の攻撃を受けません。普段から公開する範囲を絞っておくことが、次の緊急時に慌てないための備えになります。