【PHP2Shell】誰がPHPを直すのか――レンタルサーバー・VPS・自宅サーバーの責任分界
2026年10月、世界中のWebサイトを支えるプログラミング言語PHPに、重大な脆弱性が見つかった。「PHP2Shell」と呼ばれるこの問題は、技術の話であると同時に、「誰が直すのか」という責任の話でもある。
1. 何が起きたのか
2026年10月21日に公表されたのは、次の2件だ。どちらも、ログインしていない攻撃者がリクエストを1回送るだけで、サーバー上でプログラムを実行できる(遠隔コード実行)おそれがある。
- CVE-2026-109618:メモリ不足の状態で処理が中断されたとき、初期化が途中のデータを正しいものとして扱ってしまう
- CVE-2026-109619:前のリクエストが使っていた内部の状態が、メモリを解放した後も残り、次のリクエストで使われてしまう
PHP-FPM、ApacheのPHPモジュール、php-cgi、FrankenPHP、LiteSpeedなど、Webのリクエストを処理するPHPは広く対象になる。修正版は8.2.35、8.3.36、8.4.27、8.5.12。8.1以前はサポートが終わっており、正式な修正版は出ていない。
Amazonのおとりサーバーは、公表の4日前の10月17日に、この穴を突く試みを記録していた。米国のCISAは10月26日、実際に悪用された脆弱性の一覧(KEV)に加えた。IPAは、国内での被害事例は把握していないとしている。また11月2日には、VPN機器やセキュリティ製品の管理画面にもPHPが使われていることを注意喚起に書き加えた。
2. 誰が直すのか
| 環境 | PHPを直す人 | 利用者がやること |
|---|---|---|
| 共用レンタルサーバー | サーバー事業者 | 告知で「対応完了」を確認し、サイトの動作を確かめる |
| VPS・クラウドのサーバー | 自分 | OSのパッケージを更新し、PHPを再起動する |
| 自宅のサーバー・NAS | 自分 | 同上。外部に公開していないかも確認する |
| 制作会社が管理するサーバー | 契約しだい | 保守契約に更新作業が含まれているか確かめる |
| PHPを組み込んだ機器 | メーカー | 機器のファームウェアの更新情報を確認する |
共用レンタルサーバーなら、任せるのが正しい分担
共用サーバーでは、利用者がPHP本体を入れ替えることはできない。たとえばエックスサーバーは、公表前の10月21日昼までに緩和策を入れ、10月26日朝に全対象サーバーへの修正を終えたと告知した。サポートの終わった古いPHPにも、設定のバージョンを変えずにパッチを当てている。
一方で同社は、自社のVPSとクラウドについては「利用者が自分でPHPを更新する」と明記している。同じ会社のサービスでも、契約の形で責任の持ち主が変わるわけだ。自分の契約先の告知は必ず確認したい。
プラグインを使っていなくても、PHP本体は別の話
今回の穴はPHP本体のもので、WordPressを更新しても直らない。逆に、PHPが直ってもWordPressの本体やテーマの穴は残る。プラグインを使っていないなら攻撃される入口は小さいが、本体とテーマの更新は自分の仕事として残る。
自分のサーバーは自分で
VPSや自宅のサーバーは、管理者が自分である以上、業者任せは成り立たない。Debian/Ubuntu系なら、パッケージを更新してバージョンを確かめ、PHPを動かしているサービスを再起動する。
sudo apt update && sudo apt upgrade
php -v
sudo systemctl restart php8.3-fpm # Apacheで動かしているなら apache2
ディストリビューションによっては、バージョンの数字を変えずに修正を取り込んでいる(バックポート)ので、配布元の告知もあわせて確認する。すぐに直せないなら、外部からのアクセスを止めるのがいちばん確実だ。使っていないphpMyAdminや古いテスト用のサイトは、この機会に止めてしまいたい。
3. エンジニアのいない会社がいちばん危ない
今回、本当に困るのは「うちのサイトは誰のサーバーで、PHPは誰が更新するのか」がわからない会社だ。共用サーバーなら事業者が直してくれるが、VPSや社内のサーバー、制作会社に任せたままのサーバーは、誰も手を付けないまま放置されやすい。
必要なのは、何でもできるエンジニアではない。
- サーバー、ドメイン、DNS、PHPやCMS、バックアップの管理者を一人決めて、一覧にしておく
- 外部に任せるなら、保守契約に「セキュリティの更新作業を含むか」を明記させる
- 障害のとき、「自分で直す」「業者に頼む」「いったん止める」を決められる人を置く
IPAも今回の注意喚起で、更新後の維持管理に必要な人員、予算、保守体制を確保するよう求めている。完璧な専門部署より、責任の持ち主が一人に決まっていることのほうが先に効く。
AIに相談しながらサーバーを触れる人
今はAIに聞けば、ログの読み方やコマンドの意味、障害のときの初動まで教えてもらえる。専門のエンジニアを雇えない会社でも、「AIに相談しながら実際にサーバーを触れる人」が一人いれば、「誰もわからないから放置」はかなり防げる。
ただし、実行の責任を持つのは人間だ。削除、再起動、ファイアウォールの変更のように取り消しにくい操作は、AIの提案をそのまま貼り付けず、影響と元に戻す方法を理解してから実行する。変更の前にはバックアップを取り、何をいつ変えたかを記録しておく。
4. 「PHPはもう終わり」なのか
今回の騒ぎの中で、清水亮氏が「QED Script」という新しいサーバー側の仕組みを公開し、話題になった。seL4というマイクロカーネルの上で、機能を絞ったWebAssemblyを動かす。スクリプトは自由にファイルを開いたり、シェルを呼んだり、ネットにつないだりできず、使える機能は署名された方針で決まる。「できないことは、最初からできないようにする」という設計だ。
ただ、作者自身が書いているとおり、現時点で形式的に検証できているのはメモリの境界やアクセス制御など一部の性質にとどまる。スクリプトに添えた証明を検査してから実行を許す仕組みはまだ完成していない。「AIが書いたコードを数学的な証明で信用できる言語」と呼ぶには早い。
筆者の評価は、方向性は筋が良いが、PHPを置き換える段階ではないというものだ。PHPの価値は、膨大な既存のサイトやレンタルサーバーとの相性、扱える人の多さにある。新しい言語がそれを置き換えるには、ホスティング、ライブラリ、保守する人、監査の体制がそろう必要がある。当面の現実的な守りは、今あるPHPを更新し続けることと、誰が更新するのかを決めておくことだ。
出典・参考
- Help Net Security「PHP2Shell: PHP vulnerabilities patched (CVE-2026-109618, CVE-2026-109619)」(2026-10-21)
- IPA「PHPの脆弱性対策について」(2026-10-22、11-02更新)
- エックスサーバー「PHPの脆弱性への対応について」(2026-10-21、以後更新)
- WirelessWire News「QED Script」に関する記事(2026-10)
※内容は記載の日付時点の報道・公表資料によるものです。脆弱性の修正状況は、必ず契約先や配布元の最新の告知で確認してください。