「PHP2Shell」は、Webサイトを動かすサーバー側のソフト「PHP」に見つかった、2件の重大な脆弱性の通称です。スマホやPCのブラウザーにある欠陥ではないので、サイトを見る側の端末で更新するものはありません。修正が必要なのは、PHPが動いているサーバーを管理する側です。
ただ、閲覧者にも間接的な影響はあり得ます。普段使っているサービスのサーバーが攻撃されれば、登録している情報などに影響が及ぶおそれがあるからです。
この記事は、2026年10月22日（日本時間）に確認したPHP公式の告知、配布元の公式情報、セキュリティ企業の報告をもとにしています。
PHP2Shellで、まず知っておきたいこと
誰が何をする問題なのかは、立場によってはっきり分かれます。
| 立場 | 今回の脆弱性との関係 | やること |
|---|---|---|
| サイトを見るだけの人 | 端末側に修正するものはない。利用中のサービスが攻撃された場合に、間接的な影響を受ける可能性がある | 利用サービスからの案内を確認する |
| サイト所有者（レンタルサーバーや制作会社を利用） | 自分のサイトを動かしているPHPが対象になり得る | サーバー会社・管理会社の対応状況を確認する |
| サーバー管理者 | PHPを直接更新する立場 | 修正版を適用し、PHPを使うサービスを再起動する |
PHP公式の告知は、すべての利用者にただちに更新するよう強く呼びかけています。ここでいう利用者は、PHPをサーバーで動かしている人のこと。ニュースで見かける「すぐに更新を」は、サイトを見ているだけの人に向けた言葉ではありません。
PHP2Shellとは？PHPのどこに問題があるのか
PHP2Shellは、PHP公式が2026年10月21日に修正を公開した脆弱性「CVE-2026-109618」と「CVE-2026-109619」の通称です。悪用されると、ログインしていない第三者が外部からサーバー上でプログラムを実行できるおそれがあります。深刻度を示すCVSS v4.0のスコアはどちらも10点満点中9.2。PHP公式のセキュリティ情報でも「Critical（緊急）」とされています。
PHPは、WordPressをはじめ多くのWebサイトやサービスの裏側で使われているプログラミング言語です。問題はPHP本体にあるため、特定のアプリに限らず、PHPの上で動くサイト全般に関わってきます。
PHPはブラウザーとは別の場所で動く
ブラウザーでページを開くと、サーバーに「このページを見せて」というリクエストが届きます。サーバー上のPHPはそれを受けて、記事の一覧やログイン中の画面などを組み立て、出来上がったページを返す役割です。
ブラウザーが受け取るのは、組み立て済みのページだけ。サイトを見るために、スマホやPCへPHPを入れたり更新したりする必要はありません。今回の修正がサーバーを管理する側の作業になるのは、このためです。
2件の脆弱性で何が起こり得るのか
CVEは、脆弱性ごとに付けられる共通の識別番号です。今回の2件は、どちらもPHPが内部で使うデータの後始末に問題があります。
- CVE-2026-109618：メモリーが足りなくなったときの処理で、作りかけのデータが正常なデータとして扱われてしまう
- CVE-2026-109619：前のリクエストで使った内部データが片付かずに残り、次のリクエストの処理で使われてしまう
どちらも、遠隔コード実行（RCE）につながり得るとされています。外部から送り込んだ命令をサーバーに実行させる攻撃で、成功するとWebサーバーと同じ権限で動けるようになります。サイトのページを書き換えられたり、サイトが扱っている情報を読み取られたりするおそれがあるのは、このためです。
本来は10月22日に公表される予定でしたが、情報が先に外部へ漏れたため、公開は21日に前倒しされました。Amazonの脅威インテリジェンスチームは、公開4日前の10月17日に攻撃の試みを観測したと発表しています。ほかのセキュリティ企業からも、攻撃の試みを観測したという報告が出ています。一方で、攻撃がどこまで成功しているのか、被害がどれくらい出ているのかは、この記事の確認時点ではわかっていません。
どんなサイト・環境が影響を受けるのか
PHP公式によると、対象はWebからのリクエストを処理するすべてのPHP環境です。PHPをWebサーバーで動かす方式には、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどがあり、いずれも含まれます。
攻撃が成り立つ条件は、方式によって異なります。PHP公式が最もリスクが高いとしているのはmod_phpで、サイトのプログラムが動き始める前の段階で攻撃が成立することが実証されています。PHP-FPMでも、サイト側の処理などの条件がそろえば攻撃が成立することが確認されました。ほかの方式も、構成によっては対象になり得るとされています。
影響を受けるのは、PHP 8.5／8.4／8.3／8.2の各系列で修正版より古いもの。8.1以前はPHPプロジェクトによる更新が終わっていますが、事態の深刻さから、PHP公式は7.4〜8.1向けにも最低限の修正を例外的に公開しました。
WordPressだけの問題でもありません。自作のサイトでも、ほかのCMSでも、動かしているPHPが修正されていなければ対象になり得ます。逆に、WordPress本体やプラグインを最新にしても、PHPが古いままなら今回の問題は残ります。
ちょっと余談――あの「阿部寛のホームページ」もメンテナンスに
表示の速さで知られる「阿部寛のホームページ」も、10月22日未明にメンテナンス画面へ切り替わりました。表示されたのは、22日午前2時から緊急メンテナンスを実施するという案内。サイトの公開に使われている「@nifty ホームページサービス」が、PHPの脆弱性対応として21日夜から順次メンテナンスを進めており、その影響とみられています。
サイトそのものが攻撃を受けたとは報じられていません。ページの作りがどれだけシンプルでも、公開を支えるサーバー側が止まれば見られなくなる。今回の問題がサーバー側で起きていることを、思わぬ形で見せてくれました。その後、再び閲覧できるようになったと報じられています。
一般ユーザーはどうすればよい？
サイトを見るだけの立場なら、やることは2つに絞れます。利用しているサービスが止まっていたら再開を待つこと、被害の案内が届いたらその内容に従うこと。
ネット利用を一律にやめる必要があるのか
その必要はありません。修正版の適用やサーバーの再起動といった対策は、どれも管理者がサーバー上で行うもの。サイトを見るのを控えるかどうかと、サーバー側の修正は別の話です。
10月21日夜から22日にかけて、国内でもPHPを使うサービスの緊急メンテナンスが相次ぎました。これは運営側が対策を進めている動きで、メンテナンスの告知は、それだけで被害が出たことを意味しません。使いたいサービスが止まっているときは再開を待ち、状況はそのサービスの公式サイトや公式SNSで確かめるのが確実です。
利用サービスから被害の案内が出た場合
区別したいのは、メンテナンスのお知らせと、不正アクセスや情報漏えいのお知らせです。前者は対策のための作業。後者は、実際に何かが起きた、または起きた可能性があるという知らせです。
被害の案内には、「〜の可能性がある」と書かれている段階と、「〜が確認された」と書かれている段階があります。どちらの場合も、対象になった情報の種類や期間、利用者に求められる対応（パスワードの変更など）は案内ごとに違います。自分で判断して動く前に、まずは案内に書かれた内容に従ってください。
サイト所有者・運営者が確認すること
自分のサイトを持っている人が確かめるのは、そのサイトを動かしているPHPに修正が入ったかどうか。サーバーを誰が管理しているかで、確認先が変わります。
レンタルサーバー・管理会社を利用している場合
PHP本体を自分で入れ替えられないサーバーでは、修正の適用はサーバー会社の作業になります。まずは、契約しているサーバー会社のメンテナンス情報や障害情報に、今回の対応が載っているかを確認します。
告知だけで判断できない場合や、制作会社に保守を任せている場合は、次の点を問い合わせると話が早く進みます。
- 契約中のサーバーで、PHP2Shell（CVE-2026-109618／CVE-2026-109619）の修正は適用済みか
- 自分のサイトが使っているPHPのバージョンにも反映されているか
- 適用後の再起動まで終わり、稼働中の環境に反映されているか
- 使っているバージョンが修正の対象外なら、別のバージョンへ切り替える必要があるか
管理画面でPHPのバージョンを選べるサーバーなら、サポートが終わった古いバージョンを選んだままになっていないかも見ておきたいところです。
自分でサーバーを管理している場合
VPSや自社サーバーでPHPを動かしているなら、更新は自分の仕事です。
Linuxのパッケージで入れている場合は、使っているディストリビューション（配布元）のセキュリティ情報を確認し、修正版のパッケージを適用します。PHP公式によると、主要な配布元には事前に修正が共有されていました。Ubuntuは、サポート中のすべてのリリースで修正版を公開しています（20.04以前はUbuntu Proの延長サポートで提供）。ソースからビルドしている場合の修正版は、PHP 8.5.12／8.4.27／8.3.36／8.2.35です。
更新したら、PHPを読み込んでいるサービスの再起動まで済ませてください。Ubuntuも、パッケージ更新後にPHPを使うアプリケーションの再起動が必要になるとしていて、mod_phpならApacheの再起動が必要です。自動更新が有効な環境でも、再起動しないと動いているプログラムには修正が反映されない場合があります。
WordPress本体の更新とは別の作業です。WordPressの管理画面で最新版と表示されていても、PHPの修正が済んだことにはなりません。
更新で防げるのは、これからの攻撃です。Amazonは、公開前から攻撃の試みがあったことを踏まえ、10月17日以降を調査の対象にするよう勧めています。
修正版の見方と、対策を確認するときの注意
修正済みかどうかは、表示されたバージョン番号だけでは決められません。PHP公式（上流）の修正版と、配布元が独自に修正を取り込んだ版とでは、番号の付き方が違うからです。
| 系列 | PHP公式の修正版 |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Linuxの配布元は、PHPの番号を上げずに、元の版へ修正だけを移植（バックポート）する方法を取ることがあります。たとえばUbuntu 22.04では、PHP 8.1系のパッケージ「8.1.2-1ubuntu2.28」で修正済みです。番号だけ見れば8.1.2でも、中身には今回の修正が入っています。判断の材料にするのは、配布元のセキュリティ情報に載っているパッケージの版です。
PHP公式は、すぐに更新できない場合の設定変更（暫定策）も案内しています。ただし、これは特定の攻撃経路を減らすだけで、それで安全になるわけではないと明記されています。完全な対策は、修正版への更新だけです。
もう1つ、PHP 8.2は2026年12月31日でPHPプロジェクトによるサポートが終わり、それ以降はPHP公式からのセキュリティ修正が出なくなります。配布元が独自に修正を続ける期間は、配布元ごとの案内次第です。今回の修正を入れたうえで、より新しい系列への移行も予定に入れておく必要があります。
状況は動いているため、最新の対応はPHP公式の告知と、利用しているサービスや配布元の発表で確かめてください。
