当サイトは、アフィリエイト・アドセンス広告を掲載しています。広告があるサイトであると知っていただければ幸いです。

消費者庁が、2023年10月1日から施行予定である景品表示法の規制対象(通称:ステマ規制)にならないよう、配慮して記事を作成しています。もし問題のある表現がありましたら、問い合わせよりご連絡ください。

参考:令和5年10月1日からステルスマーケティングは景品表示法違反となります。 | 消費者庁

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のページは更新されることがあるため、最新の情報をご確認ください。

参考情報