php2shell エックスサーバーの緊急対応と利用者の点検

2026年10月22日 21時時点の情報に更新しました(初版は9時時点)

10月21日の夜、世を騒がせたPHPの脆弱性をまとめます

エックスサーバーの管理画面に入れませんでした
PHP本体に見つかった脆弱性「php2shell」の公表に備えて、エックスサーバーが公式サイトや管理画面を止めていたためです
javeo.jpのほうは、普通に表示されたまま

結論から言うと、エックスサーバーは22日6時45分のお知らせで、PHP 8.2〜8.5の修正パッチを対象のすべてのサーバーに当て終えたと発表しています
古いバージョンも14時までに5.6〜8.1の適用が終わり、残るのは5.5以下だけです
私が借りているサーバーでも、入っているPHPのうち8.2〜8.5は朝の6時16分に、8.1以前は10時に入れ替わっていました

管理画面は22日の9時半から順に再開し、公式サイトも20時10分から戻っています

PHP本体を直すのはサーバー会社です
利用者がやることは大きく2つ
使っているPHPのバージョンの確認と、サイトの点検

php2shellとは PHP本体に見つかった2件の脆弱性

php2shellは、PHP本体に見つかった2件の脆弱性(CVE-2026-109618とCVE-2026-109619)の通称です
研究者や報道が使う呼び名で、PHP公式の告知には出てきません

PHPは、多くのWebサイトを動かしているプログラミング言語
WordPressもPHPで動いているので、php2shellはWordPressのサイトにもそのまま関わります
PHP公式の評価は、深刻度を表すCVSS v4.0で9.2(Critical=緊急)です

• CVE-2026-109618は、メモリが足りなくなったときの後片付けで、作りかけのデータを正しいデータとして扱ってしまう不具合
• CVE-2026-109619は、前のアクセスで使った情報がメモリの解放後も残り、次のアクセスの処理がそれを使ってしまう不具合(メモリの中身が漏れることもある)

どちらも、ログインも利用者の操作もいらない状態で、攻撃者にサーバー上のプログラムを動かされるおそれがあります
PHP公式は、PHPの動かし方(PHP-FPM・mod_php・CGIなど)を問わず、Webのアクセスを処理しているPHPをすべて対象としています
実際に攻撃が確かめられたのはmod_phpとPHP-FPMで、リスクがいちばん高いのはmod_php

修正版は8.2〜8.5の4つ 8.1以前は新しい版が出ない

PHP公式が出した修正版は、サポート中の4系列ぶん

PHPの系列	修正版
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35(サポートは2026年12月31日まで)
8.1以前	新しい版は出ない

※7.4・8.0・8.1には、ソースから自分で組み立てる人向けの最小限の修正だけが公開されています

PHP公式のリリース告知には「There are no complete mitigations, updating is the only safe choice.」とあります
完全な回避策はなし
安全なのは更新だけです

公式が影響を受けるバージョンとして挙げているのは、この8.2〜8.5
ただ、7.4〜8.1にも修正を出している以上、8.1以前なら影響が無い、とは読めません
GMO Flatt Securityや発見者のWizは、5.x系を含む古いバージョンにも及ぶ可能性を指摘しています

予定の23時より早く公開された

当初の予定は日本時間の21日23時でしたが、遅くとも22時34分には、GitHubでPHP公式の勧告が公開されていました
報道やエックスサーバーの案内では「23時ごろ」とされていて、1時間ほどずれています

公開前に情報の一部が出回っていました
PHP側も、詳細が公になったり悪用が出たりしたら前倒しすることがある、と予告していました

見つけたのはセキュリティ企業のCalifとWizで、AIを使って発見し、OpenAIの取り組みの枠組みで対応した、とGIGAZINEは伝えています
CVEの記録では、OpenAIも発見者に名前があります

php2shellで最悪どうなる？ サーバーの乗っ取りと情報漏えい

攻撃が成功すると、サーバー上でPHPを動かしているアカウントの権限で、攻撃者が好きなプログラムを動かせます
サイトのファイルの書き換えや、データの持ち出しにつながります

日本ハッカー協会の杉浦隆幸代表理事は、TBS NEWS DIGの取材に「攻撃が成功しますと、サーバーを乗っ取ることができるほか、データを盗んでさらに暗号化することも可能ですし、破壊することも可能となる」と話しています

CVE-2026-109619には、メモリの中身が漏れるおそれもあります
メモリに載っているのは、PHPがそのとき扱っている情報
たとえばWordPressなら、データベースのパスワードもPHPが読み込んで使っています

厄介なのはその先です
もし入られていたら、裏口(外からサーバーを操作するための不正なファイル)を置かれているかもしれません
PHPを修正版に入れ替えても、先に置かれたファイルは消えません

ただし、PHP公式の評価では攻撃の複雑さは「高」で、攻撃が通るための条件もあるとされています
どのサイトでも簡単に乗っ取れる、とまでは言えない評価です
ただしmod_phpでは、既定の設定のまま攻撃が実証されています

修正版の公開前から、ホスティング事業者から悪用の事案が報告されたとの情報(詳細は非公開)もあります
一方で、侵入の成功を具体的に示した公表は、22日の時点で見つかっていません
IPA(情報処理推進機構)も、修正版の公開前に出した注意喚起の中で、悪用した攻撃を確認しているわけではないとしています

メンテナンスのために止まったサービスの例

21日の午後から深夜にかけて、ネットショップ・イラスト投稿・ゲームなどのサービスが、PHPの修正版の公開に合わせて相次いで止まりました

piyologは22日午前の更新で、告知を確認できた211の組織を業種別にまとめています
ゲームやホスティングの会社のほか、国の機関・金融機関・自治体の名前も

21時55分には、高市総理がXで「皆様に、今夜に対応して頂きたい大至急のお願いです」と投稿しました
投稿は、Webサイトの一時停止もリスクを下げる有効策の一つとしています
ITmedia NEWSは、首相が個別の脆弱性でXから直接呼びかけるのは異例と伝えています

目立ったのは前倒し
ウマ娘とグランブルーファンタジーは、23時の予定を22時に早めています

サービス	開始	終了	内容
BASE	21日 15:50	22日 8:00(完了の告知)	緊急メンテナンス
pixiv・pixivFANBOXなど	21日 19:00	21日 23:30	対象サービス全体※1
ウマ娘 プリティーダービー	21日 22:00ごろ	22日 2:30	ゲーム全体
グランブルーファンタジー	21日 22:00	22日 7:00※2	全機能
セガの製品情報サイト	21日 22:55	未定(22日の告知時点)	サイト全体
ロリポップ!	21日 21:43(告知)	未確認	ユーザー専用ページなど※3

※1 pixivの告知にPHPの記載は無く、理由は「サービスの安全性確保のため」(報道ではPHPへの対応として扱われています)
※2 DMM版・GREE版を除く
※3 22日3時5分に、一部のサーバーでサイトも一時的に止めると告知

同じ時間帯には、さくらのレンタルサーバ・ConoHa WING・mixhostもメンテナンスや一部の停止をしていました
ただ、3社とも告知にPHPの名前は無く、今回の件のためだったかははっきりしません

エックスサーバーの対応と、借りているサーバーで確かめた結果

エックスサーバーは、利用者のサイトとメールを動かしたまま、公式サイトや管理画面を止めて、PHPの修正を進めました
停止から8.2〜8.5の適用完了の発表までは、およそ15時間でした

管理画面は止まり、サイトとメールは動いていた

停止は21日(水)の16時から
お知らせの題は「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」です

管理画面に入れないと、サイトまで止まったのかと心配になります
公式のお知らせの、利用中のサーバーについての記述がこちら

お客様のご利用サーバーは稼働を継続しており、Webサイトの表示やメールソフトでの送受信に影響はございません。— エックスサーバー「予防的な安全対策に伴う公式サイト・管理画面等の一時停止のお知らせ」

私のサイトも、普通に表示されていました

止まっていたのは次のとおり

• 公式サイト(各種サービスサイト・コーポレートサイト)
• アカウント管理画面・サーバーパネル
• WEBメール・ファイルマネージャ
• 各種API・MCP
• 新規申し込み・契約更新・支払いなどの手続き

サポートも一部だけでした
メンテナンス中はチャットとお問い合わせフォームが使えず、電話も情報を参照できないため具体的な案内はできないとされていました
契約更新や支払いは再開しましたが、20時10分の時点でも一部の決済手段はメンテナンス中なので、期限が近い方は確かめておくと安心です

メンテナンス中のお知らせには「本対応は当社サービスに対する不正アクセスの発生に伴うものではございません」ともありました
止めた理由は不正アクセスではないとの説明です
利用者のサイトが無事だった保証とは別の話

同じ夜、ロリポップ!は22日3時5分に、一部のサーバーで利用者のサイト自体を一時的に止めると告知しています
エックスサーバーは、利用者のサイトの表示とメールは止めませんでした

21日16時の停止から22日20時10分の再開まで

公式ニュースの「主な対応経過」をもとに、流れをまとめました

時刻	エックスサーバーの動き
21日 〜12:00	脆弱性の発表前の緩和措置を、自社と利用者のサーバーに適用
21日 16:00	公式サイト・管理画面などを一時停止
22日 1:10	PHP 8.2〜8.5への修正の適用を開始、古いバージョン向けの準備にも着手
22日 6:45	PHP 8.2〜8.5は、対象のすべてのサーバーに適用完了
22日 9:30〜	アカウント管理画面・各種機能を順に再開、新規申し込みも再開(ドメイン関連を除く)
22日 12:00	PHP 7.4〜8.1の適用完了
22日 14:00	PHP 5.6〜7.3の適用完了
22日 20:10〜	各種サービスサイトを順に再開

※公式Xの投稿の時刻は、この表と数分ずれるものがあります(6:44・12:08・14:03)

修正版が出ていない古いバージョンについて、エックスサーバーは22日1時22分の公式Xで「弊社独自の修正を進めております」と説明していました
公式の修正版がある8.2〜8.5から当てて、古いバージョンは独自に作った修正を後から当てた流れです

ただ、PHP公式は、緩和策は攻撃の経路を減らすだけで安全にはならないとしています
8.2〜8.5は22日6時45分まで、7.4〜8.1は12時まで、5.6〜7.3は14時まで、この状態でサイトが動いていました
5.5以下は、まだ途中です
20時10分の時点でも、修正の作成と検証が続いています

管理画面は9時半から順に再開しましたが、12時8分の公式Xでも、アクセスが集中して一部つながりにくいと案内されていました
私も昼は入れませんでした
20時10分の時点では、サーバーパネルも再開(一部の機能はメンテナンス中)となっています

借りているサーバーのPHPは、10時までに全部入れ替わっていた

エックスサーバーの共用サーバーには、サーバーパネルの「PHP Ver.切替」で選べるように、いくつものバージョンのPHPが1台の中に並んで入っています
サイトが使うのは、そのうちドメインごとに選んだ1つだけ

22日の8時43分と21時27分の2回、SSH(サーバーに直接つないで操作する方法)で私が借りているサーバーに入り、並んでいるPHPのバージョンを1つずつ確かめました

PHPの系列	入っていたバージョン	ファイルの日時
8.5	8.5.12	10月22日 6:16
8.4	8.4.27	10月22日 6:16
8.3	8.3.36	10月22日 6:16
8.2	8.2.35	10月22日 6:16
8.1	8.1.34	10月22日 10:00
8.0・7.4	8.0.30・7.4.33	10月22日 10:00

8.2〜8.5は、どれも修正版の番号でした
ファイルの日時は4つとも6時16分で、6時45分の「適用完了」のお知らせの約30分前

8.1以前は、8時43分の時点ではまだ入れ替わっていませんでした
21時27分に見直すと、8.1・8.0・7.4のファイルは10時0分に入れ替わっていて、組み立てた日時も22日の4時台に変わっていました
番号は8.1.34のまま

8.1以前は、修正されても番号が変わりません
公式の新しい版が出ない系列に、エックスサーバーが独自の修正を当てたためと考えられます

どれもサーバーに入っているファイルの話で、自分のサイトがこのうちどれを使っているかは、次の節のサイトヘルスで確かめられます
javeo.jpが使っていたのは、修正版の8.3.36でした

アクセスログ(サイトへのアクセスの記録)も見ました
POST(データの送信)が続いた記録はあっても、似た形のアクセスは19日・20日にも来ていました
php2shellを狙ったものかは判定できず
アクセスログには送られたデータの中身が残らないので、ログだけで攻撃の有無を見分けるのは難しいと感じています

※XServer VPS・XServerビジネス・シン・レンタルサーバーなど、ほかのサービスの扱いは未確認
VPSはPHPを自分で入れて管理するサービスなので、共用サーバーとは事情が違うはずです
使っている方は、各サービスのお知らせを見てください

エックスサーバーの利用者がこのあと点検すること

最初に確かめたいのは、サイトが使っているPHPのバージョンです
8.2〜8.5なら修正版に入れ替わっているはずで、8.1以前なら8.2以上への切り替えを考える場面

自分のサイトのPHPが何系か、すぐに答えられますか？

自分でやらなくていいこと 暫定策の設定は試さない

修正版が出る前には、PHPの設定で穴をふさぐ暫定策もネットに出回っていました
共用サーバーの利用者は、次の3つには手を出さないのがおすすめです

• php.iniや.user.iniでsession.upload_progressを切る
• .htaccessでPHPの設定を書き換える・PHPを止める
• WordPressのメンテナンスモードで守ろうとする

共用サーバーの利用者が自分でやっても、効かないか逆効果になりやすいものばかりです

• session.upload_progressを切る方法は、同じ日のうちに単体では完全な対策にならないと訂正されています(窓の杜)
  PHP公式も、この種の設定はphp.iniやサーバー側で入れるものとして、.user.iniには頼らないよう書いています
• .htaccessでPHPの設定を書き換えると、PHPの動かし方によっては500エラー(サイトが表示できない状態)の原因に
  止め方を間違えると、PHPのファイルの中身がそのまま見えてしまうこともあります
• PHP公式によると、攻撃はWordPressなどのアプリのコードが動く前に起きうるため、PHPの上で動くメンテナンスモードでは防げません
  サーバー側でサイトへのアクセスそのものを止める一時停止(ロリポップ!が一部のサーバーでしたもの)とは別物です

PHP本体の修正は、エックスサーバーが当てています(5.5以下はまだ作業中)
利用者が自分で設定をいじると、サイトが表示できなくなる危険のほうが大きいと思います

エックスサーバーとWordPressの組み合わせを一から整理したいときは、契約からテーマの設定までの手順を別の記事にまとめています

まとめ PHPのバージョンを確かめてから、サイトの点検へ

php2shellは、PHP本体に見つかった2件の脆弱性です
エックスサーバーは22日6時45分にPHP 8.2〜8.5、14時までに5.6〜8.1の修正の適用完了を発表していて、残るのは5.5以下です

やることを4つに絞ると、次のとおり

• サイトヘルスでPHPのバージョンを確かめる
• 8.1以前なら、プラグインとテーマの対応を見てから8.2以上(できれば8.3以上)へ
• 知らない管理者と、覚えのないファイルの更新がないか見る(怪しいファイルは消さない)
• エックスサーバーのお知らせを、ときどき読む

WordPressやプラグインの更新だけでは、PHP本体の穴は直りません