PHPの脆弱性「PHP2Shell」｜対象と直し方、8.1以前は切り替えを

ここからは、2026年10月22日10時時点の資料をもとにした全文です。PHP公式の勧告、IPAの注意喚起、国内のレンタルサーバー5社の告知を読み比べました。

番号が先に漏れ、2日で修正版の適用まで進んだ

※上図は、Infosecurity Magazineの記事、IPAの注意喚起、PHP公式の勧告、エックスサーバーの告知（2026年10月22日確認）をもとに当サイトが作成した図です。IPA・The PHP Group・エックスサーバーが提供している図ではありません。

漏れた投稿の「CVSS 10.0」は、PHP公式の評価とは違います。公式の勧告は2件とも9.2です。

2つの脆弱性は、どちらも「前のリクエストの後始末」の穴

2件とも、PHPがリクエストを処理し終えるときの片付けに関わる穴です。勧告の中身を、ざっくり並べるとこうなります。

PHP公式は、最も危険なのはApacheのmod_phpだとしています。アプリのコードが1行も動く前に、ログインなしのリクエストで攻撃が成り立つからです。

CVSSの内訳を見ると、「攻撃の複雑さ」は高いと評価されています。いっぽう、ログインも利用者の操作も要りません。手間はかかっても、条件がそろえば外から誰でも狙える、という評価です。

発見したのは、Wiz Research、OpenAIのCodex Security、Califの研究者です。研究チームの解説サイトによると、ログイン前の乗っ取りを再現できたのは、WordPress・Drupal・Joomlaの最新の公式コンテナ。メモリの中からは、パスワードや認証トークン、APIキーも読み出せると書いています。

確定していること、まだ確かめられないこと

一次資料で確かめられることと、報道や推測の段階のものを分けておきます。

修正版が出ていない8.1以前のサイトも、対象に入ると考えて動くほうが安全です。悪用については、この記事の時点で、一次資料で確かめることはできませんでした。IPAのページも、22日10時時点で「事前準備のお願い」のままです。

レンタルサーバー5社の告知：「PHP」と書いた会社、書いていない会社

国内の主なレンタルサーバーの告知を、2026年10月22日10時ごろに読み比べました。

5社のうち2社は、告知にPHPの名前がありません。同じ時間帯の緊急メンテナンスでも、告知だけでは、自分の契約のPHPが直ったかを判断できません。気になるなら、サポートに聞くのが確実です。

古いバージョンの扱いをはっきり書いているのは、エックスサーバーとKAGOYAだけでした。エックスサーバーは、管理画面の再開後に、利用者にも追加の対策を頼む場合があるとしています。条件は利用状況しだいです。管理画面は22日9時30分から順次戻っているので、お知らせを一度見ておきたいところです。

ちなみにロリポップ！の告知は、確認した時点で、利用者のサイトそのものも「現在利用できません」の欄に入れていました。サイトが表示されなくても、契約先の障害情報を見るのが先です。

8.1以前のサイトは、「待つ」より「切り替える」

PHP公式は、8.1以前について「PHPのプロジェクトからは更新が出ない」とはっきり書いています。そのうえで、例外的に7.4・8.0・8.1向けの最小限の修正を公開しました。ただしこれは、ソースからPHPを組み立てる人向けのもの。共用サーバーの利用者が使える形ではありません。

だから8.1以前のサイトは、サーバー会社が古い版をどこまで直すか次第になります。エックスサーバーのように順次直す会社もあれば、まだ方針が出ていない会社もあります。待つよりも、管理画面で新しい版へ切り替えるほうが確実です。

切り替え先は8.3以上がおすすめです。8.2は修正版こそありますが、セキュリティ修正が12月31日で終わります。2か月後に、また同じ作業をすることになります。

WordPressの公式も、推奨は8.3以上

WordPress公式の動作要件は、PHP 8.3以上を推奨しています。7.4以上でも動くとは書いていますが、同じページで「サポートが終わった版で、サイトをセキュリティの穴にさらすおそれがある」と添えています。今回の修正版の事情とも合う線です。

WordPressのサイトで切り替えるなら、順番はこうです。

1. バックアップを取る。 ファイルとデータベースの両方。サーバー会社の自動バックアップがあっても、手元に1つあると戻しやすい
2. WordPress本体・テーマ・プラグインを先に最新にする。 古いプラグインほど、新しいPHPで動かないことが多いため
3. 管理画面でPHPを8.3以上に切り替える。 レンタルサーバーなら、ドメインごとに選べることが多い
4. 表示と管理画面を一通り確かめる。 トップ・記事・お問い合わせフォーム・ログインの4か所は最低限

もし表示が崩れても、元の版に戻すのは原因を調べる間だけにしたいところです。元の版に戻すと、穴も一緒に戻ります。動かないプラグインが見つかったら、代わりを探すか、開発元の更新を待つことになります。

自分で管理するサーバーは、更新と再起動までがセット

VPSやクラウドで自分がPHPを入れたサーバーは、更新も自分の仕事です。PHP公式は、Linuxの配布元にパッチを前もって渡してあります。だから、まず配布元の更新を確かめるよう案内しています。

配布元のパッケージは、番号の後ろに配布元の印が付きます。たとえばDebianでは、bookworm向けの修正済みが 8.2.35-1~deb12u1、trixie向けが 8.4.27-1~deb13u1 でした。修正済みかどうかは、配布元のCVEのページで確かめるのが確実です。

PHP公式は、ボランティアが運営するリポジトリ（rpms.remirepo.net）について、公開の日には更新が出ないとも書いています。そこから入れているなら、配布元のパッケージかソースからの組み立てへ切り替えるよう勧めています。

更新したら、Apache・PHP-FPM・常駐しているPHPのプロセスをすべて再起動します。古いプロセスが残っていると、古いPHPのまま動き続けるからです。

すぐ更新できないときの設定は、穴を減らすだけ

PHP公式と勧告は、更新までのつなぎの設定を挙げています。どれも「安全にはならない、特定の経路を減らすだけ」と念を押しています。

もう一つ、大事な注記があります。error_reporting や display_errors、@ でエラーを隠しても効きません。PHPは、警告を出すかどうかを決める前に、問題のデータに触れてしまうからです。

共用サーバーで利用者が書けるのが .user.ini だけなら、ここに挙がった設定の多くは自分では効かせられません。その場合にできるのは、会社の更新を待つことと、PHPのバージョンを切り替えることです。

勧告は、アップロードの進み具合を見る機能（session.upload_progress）を使っていないなら、修正版にしたあとも切っておくのが賢明だとしています。今後、攻撃者がこの機能を調べにくると見ているためです。

サイト以外の、機器やソフトの中のPHPも

IPAは、PHPがWebアプリの外でも使われていると注意しています。ソフトウェア製品やネットワーク機器の中です。製品の中のPHPは、利用者からは見えないことが多いもの。管理画面をWebで開く機器を使っているなら、メーカーのセキュリティ情報を確かめておくと安心です。

以下はスポンサーによる広告です。記事の内容とは独立しています。