php2shell：中小企業のための対応ガイド

2026年10月23日版。自社の Web サイトを外部の制作会社やレンタルサーバーで運用している、セキュリティ担当者のいない組織に向けて書いています。

何が起きたか

2026年10月21日、PHP の開発元が2件の脆弱性（CVE-2026-109618、CVE-2026-109619）の修正版を公開しました。通称 php2shell。認証なしでサーバー上でコードを実行できる深刻なもので、PHP 5.4 から 8.5 まで、 Web リクエストを処理するほぼすべての PHP に影響します。

修正方法は一つだけ

PHP を修正版に更新する。 それだけです。

WordPress 本体やプラグインを更新しても直りません。PHP そのものの問題だからです。ファイアウォールや WAF は一部の攻撃経路を減らすことはできますが、完全な対策ではありません（PHP 開発元の緩和策も同様です）。

「AI脆弱性診断」の営業メールについて

この数日、次のようなメールが多くの企業に届いています。

10月21日、PHP に重大な脆弱性が公表されました。弊社では「AI攻撃想定・Web脆弱性診断」の特急対応を実施します。 標準納期10営業日、特急対応は最短1営業日。

読むときの要点：

  1. 診断はサーバーの PHP を更新しません。 10営業日かけて「脆弱性があります」というレポートをもらっても、 やることは同じ「PHP を更新する」です。それはレンタルサーバーなら事業者が、自社サーバーなら管理者が行います。
  2. 外部からの診断では PHP の修正状況は確認できません。 事業者は多くの場合バージョン番号を変えずに修正を適用します。 外部からバージョンを見て「未修正」と報告する診断は、その時点で信頼できません。
  3. Web 脆弱性診断そのものが無価値というわけではありません。 自社開発の Web アプリケーションに対して、 落ち着いた時期に、範囲と手法を明示した上で受けるなら意味があります。 ただし「今すぐ」「php2shell だから」という理由で受けるものではありません。
  4. 同様の作業をする無料のオープンソースツール（Strix、Nuclei、OWASP ZAP など）も存在します。 使うには技術者が必要ですが、「AI」を理由に高額になる作業ではありません。

今やること（順番に）

1. 自社のサイトが誰のサーバーで動いているか知る

このサイトのトップページに自社のドメイン（例: example.co.jp）を入力してください。

これで、Web サーバーを運用している事業者（エックスサーバー、さくら、ロリポップ、ConoHa、AWS など）と、その事業者が php2shell についてどう発表しているかが出ます。

ドメインを複数持っている場合（採用サイト、キャンペーンサイト、EC サイト）はすべて確認してください。制作会社が別のサーバーで立てたサイトを忘れていることがよくあります。

2. 事業者の種類で対応が変わる

種類 例 PHP を更新するのは誰か あなたがやること
レンタルサーバー（共用） エックスサーバー、さくらのレンタルサーバ、ロリポップ、ConoHa WING、mixhost 事業者 事業者の公式発表で完了を確認。管理画面で PHP バージョンを確認し、8.1 以前なら 8.2 以上へ切替を計画
VPS・クラウド さくらの VPS、ConoHa VPS、AWS EC2、Lightsail、IDCF あなた、または制作会社・保守会社 誰がサーバーを管理しているか確認し、その人に更新を依頼。内部からの確認には Vuls などが使える
CDN の背後 Cloudflare 見えない 制作会社にオリジンサーバーの場所と更新状況を確認
制作会社の自社サーバー 不明 制作会社 テンプレートで問い合わせ

3. 制作会社・ホスティング事業者に問い合わせる

チェック結果の末尾にテンプレートがあります。聞くことは6つです。

  1. 弊社サイトが稼働している PHP のバージョン
  2. 修正版またはそれと同等の修正パッチの適用状況と、未適用の場合の適用予定日時
  3. PHP 8.1 以前で稼働している場合、サポート対象バージョンへの移行の要否・手順・費用
  4. 10月17日以降の不審なアクセスや侵害の痕跡の有無
  5. 更新作業を実際に担当する会社（再委託先を含めて）と、弊社側の窓口
  6. 更新が終わるまでの間の対策（アクセス制限や一時的な公開停止など）の要否

制作や保守が何社かを経由して再委託されていると、誰が PHP を更新するのかが誰にも分からないことがあります。 5番は、その担当者を一人に決めるための質問です。

4. 未対応のサーバーがあったら

IPA の案内に従い、更新が済むまでアクセス制限や一時的な公開停止を検討してください。多くの国内サービス（レンタルサーバー各社、Chatwork、BASE など）が10月21〜22日に実際にそうしました。数時間サイトが見えないことより、サーバーを乗っ取られることの方がはるかに高くつきます。

更新が必要だと分かっても、すぐに適用できるとは限りません。何年も更新していないサイトは、公式の修正版がない PHP 8.1 以前のままのことがあります。その場合はPHPを上げるだけでは済まず、フレームワークやライブラリの更新と、壊れていないかの動作確認（テスト）が必要になり、数週間かかることもあります。制作会社に作業の範囲と期間を確認し、終わるまでの間はアクセス制限か公開停止で守ってください。利用者を守るための公開停止は、保守を怠った証拠とは限らず、正しい判断であることも多いのです。

5. 侵害の痕跡を確認する

JPCERT/CC は確認の観点として、過去の HTTP 応答に異常に長い PHPSESSID Cookie が設定されていないか、などを挙げています。サーバーのログを見られる人（事業者または保守会社）に、上記テンプレートの4番として確認を依頼してください。

この先のために

今回すぐに直せなかったサイトの多くは、技術ではなく、保守の体制で止まっています。保守・改修・テストは削れる費用ではなく、次に同じことが起きたときにすぐ直すための備えです。落ち着いたら、次を確認してください。

  • 保守契約に「OS・PHP などの更新」が含まれているか、誰が行うかを書面で確認する。
  • このツールの結果を、サイトごとの担当者一覧として残す（Web・DNS・メール・証明書のそれぞれについて、契約先と連絡先）。
  • 古い PHP のまま動いているサイトは、移行の計画と予算を立てる。PHP の各バージョンのサポート期限は php.net で公開されています（ https://www.php.net/supported-versions.php ）。
  • 更新を本番の前に試せる環境（テスト環境）と、動作確認の手順があるかを制作会社に確認する。

このツールにできないこと

  • PHP の修正状況を外部から断定すること。
  • トップページに痕跡がない PHP（管理画面、API、フォーム）を見つけること。
  • 事業者の対応状況をリアルタイムに追うこと。事業者の発表をもとに更新しており、古くなっていることがあります。必ず出典を確認してください。

出典