PHP2shellとは?VPS上の個人ブログを止めて移行した判断

2026/10/21、PHPの重大な脆弱性「PHP2shell」(CVE-2026-109618、CVE-2026-109619)の修正版が公開されました。
ConoHa VPSでWordPressのブログを運営している私は、その日のうちにVPSを停止し、サーバーを移行することにしました。
この記事では、専門家ではない個人ブログ運営者として、何を調べ、どう判断したかを記録します。
当時の私の判断であり、安全を保証するものではありません。
背景:VPSのメンテナンス負担
実は、この脆弱性の前から、VPSのメンテナンスが負担になっていました。
OS、PHP、WordPress、プラグインの更新を、すべて自分で行う必要があります。
記事を書く時間より、サーバーを守る時間のほうが長くなり、手が回らなくなっていました。
当時の環境は次のとおりです。
- PHP:7.4系(サポート終了)
- WordPress:6.0系
IPAも、長く更新していないシステムは、対策が難しくなりやすいと案内しています。
まさに私の状況でした。
「マネージド型のサーバーに移して、記事を書くことに集中したい」と考え、移行先を調べ始めていました。
そこに今回の脆弱性が重なり、移行を決断しました。
PHP2shellの概要
IPA(独立行政法人情報処理推進機構)の注意喚起によると、PHPに2件の脆弱性が報告されているとのことです。
- CVE-2026-109618:メモリ不足(OOM)時のエラー処理に起因する脆弱性
- CVE-2026-109619:リクエストの処理に関連する脆弱性
悪用されると、遠隔の第三者に任意のコードを実行される可能性があります。
この2件の組み合わせが「PHP2shell」と呼ばれています。
影響を受けるのは、修正版より前の8.2〜8.5系とのことです。
修正版は、8.2.35、8.3.36、8.4.27、8.5.12です。
また、調査に関わったWiz社によると、PHP 5.4以降は、少なくとも1件の影響を受けるとのことです。
2026/10/26(現地時間)には、米国のCISAが、この2件を「悪用された脆弱性」のカタログ(KEV)に掲載しました。
一方で、IPAは、国内での攻撃被害の事例は把握していないとしています(2026/11/2更新版)。
詳しくは、IPAの注意喚起をご覧ください。
最初の説明文の印象
私が最初に見た説明は、「メモリ不足のエラー処理に起因するデータ破損」「解放済みメモリの再利用」でした。
正直、データが壊れる程度の話に見えました。
ところが、IPAの注意喚起を読むと、悪用された場合に任意のコードを実行されうるとのことでした。
短い説明文だけで判断せず、一次情報で確認することが大切だと思いました。
対応の流れ
| 日付 | 出来事 |
|---|---|
| 2026/10/21 | 修正版の公開を知り、23:50ごろにVPSを停止 |
| 2026/10/24 | 接続許可ポートをSSHのみに設定し、17:08にVPSを起動。調査とバックアップを実施 |
| 2026/10/24 | 侵入の痕跡は見つからず、クリーン移行を決定 |
| 2026/11/02 | ConoHa WINGへ移行し公開 |
停止の判断
2026/10/21の夜にこの情報を知り、その日のうちにVPSを停止しました。
当時のPHPは7.4系で、修正が提供されないバージョンでした。
IPAは、そのような場合、サポートされているPHPへの更新か、対策済みのサービスへの移行を検討するよう案内しています。
また、有効な暫定対策が難しければ、アクセス遮断やサービスの一時停止も判断するよう求めているとのことです。
サイトがしばらく見られなくなる損失より、乗っ取られるリスクのほうが重いと思いました。
そのため、止めることを選びました。
調査のためにVPSを起動する際は、次のように対策しました。
- ConoHaのパネル「接続許可ポート」で、SSH(22)だけを許可
- Webを閉じ、HTTPとHTTPSへの接続がタイムアウトすることを確認
侵入調査
公開していた期間に侵入されていないか、2026/10/20以降を中心に、サーバーにログインして確認しました。
| 確認項目 | 結果 |
|---|---|
| WordPress本体とプラグインを公式の配布物と照合 | 一致(動作上の差のみ) |
| 2026/10/20以降に更新されたPHPファイル | 1件(通常動作で生成されたもの) |
| 画像フォルダ内のPHP | なし |
| 管理者の増減、アプリケーションパスワード、不審なセッション | いずれもなし |
| アクセスログ | ログイン失敗が約1万回、成功は2件 |
成功の2件は、IPアドレスが変わる回線のため、IPだけでは自分のものか断定できません。
2026/10/17と2026/10/21に自分でログインした記憶があるため、自分の操作と判断しました。
移行方針の判断
結果として、侵入の痕跡は見つかりませんでした。
ただ、痕跡が見つからないことは、安全の証明にはならないと思います。
そこで、調べる前に判断の基準を決めておきました。
- 異常がなく、外部に公開されていなかったと言える:そのまま移行
- 判断できない:クリーン移行
結果は「判断できない」側でした。
クリーン移行の内容は次のとおりです。
- 入れ直す:WordPress本体、プラグイン、親テーマ(公式の配布元から)
- 持ち出す:記事データ、画像、自作のカスタマイズ
IPAも、維持管理を続ける見通しが立たない場合は、保守を受けられるサービスへの移行などを検討するよう呼びかけています。
移行先は、サーバー管理から解放されるConoHa WINGにしました。
ConoHaは、WING側のPHPに修正を適用したと案内しています。
旧サーバーを再公開しなかった理由
移行までの間、旧サーバーを一時公開すれば、検索順位の低下は抑えられたかもしれません。
それでも再公開しなかったのは、修正が提供されないPHPのままでは、攻撃にさらされるからです。
IPAも、脆弱な状態での運用を放置しないよう呼びかけています。
順位は後から戻せますが、乗っ取りの被害は戻せないと考えました。
結果として、サイトは2026/10/21の23:50ごろから、2026/11/2に移行先で公開するまで、約12日間停止しました。
VPS運用者向けの確認項目
VPSでは、PHPの更新を自分で行うのが基本です。
確認したい項目は次のとおりです。
- 実際にサイトを動かしているPHPのバージョン(ログインして使うPHPとは別の場合があります)
- 修正版以上か(8.1以前は、サポート版への更新か移行を検討)
- OSの更新後に、PHPのプロセスを再起動したか
- 更新できない場合、ネットワーク側の設定でWebを遮断できるか
緩和策は、IPAが紹介しているPHP公式のアドバイザリに記載があります。
あくまで、更新や移行までの暫定対策です。
まとめ
メンテナンスが追いつかない環境は、事故が起きる前に手放したほうがよいと実感しました。
今回学んだことは次の5点です。
- サポートが終わったPHPには、修正が提供されない
- メンテナンスが追いつかない構成は、事故の前に見直す
- 短い説明文だけで判断せず、一次情報で確認する
- 調べる前に、判断の基準を決めておく
- 完全な安全は証明できないため、確認した範囲を記録する
次は、ConoHa WINGへの移行手順を別の記事に投稿予定です。
なお、IPAのページは更新されることがあるため、最新の情報をご確認ください。










ディスカッション
コメント一覧
まだ、コメントがありません