ホームページ制作会社・保守担当向け：PHP脆弱性（php2shell）の確認チェックリストと顧客への説明

自分が契約している、または管理を任されているサーバーだけを確認してください。当サイトは独立した個人運営のサイトで、PHP Group・php.netとは無関係です。サイトやサーバーへアクセスして検査することはありません。

先に結論

• 制作会社・保守会社の最初の仕事は、預かっているサイトの一覧を作り、サイトごとにPHPのバージョンと契約先（サーバー会社）を記録することです。IPA（情報処理推進機構）も、開発・運用しているプログラムのうちPHPを利用しているものの棚卸しを、可能な範囲で行うよう呼びかけています（IPA 事前注意喚起、2026年10月22日確認）。
• 優先順位の先頭は、PHP公式のサポートが終わっている系統（7.3以下、7.4・8.0・8.1）を使っているサイトです。これらの系統には、番号つきの修正版（リリース版）がありません。7.4・8.0・8.1向けには、PHPセキュリティチームがソースのブランチのみの最小限のバックポート（新しい版の修正を古い版に移すこと）を用意していますが、リリースはありません。7.3以下については、告知に修正の記載がありません（php.net 告知、2026年10月22日確認）。IPAも、修正プログラムが提供されないバージョンを使っている場合は、サポートされているPHPへの更新や、対策済みの製品・サービスへの移行を検討するよう求めています（IPA 注意喚起、2026年10月22日確認）。
• 顧客には、確認できた範囲と、次にやることを伝えます。PHPのバージョンや契約先の発表を確認した結果は、「攻撃を受けていないことの保証」にはなりません。JPCERT/CCも、ログなどの攻撃の痕跡が確認されない場合でも、攻撃を受けていないと断定することはできないとしています（JPCERT/CC 注意喚起、2026年10月22日確認）。

今回の脆弱性は、PHPの重大な脆弱性2件（CVE-2026-109618・CVE-2026-109619、通称php2shell）です。PHP公式の修正版は PHP 8.2.35・8.3.36・8.4.27・8.5.12 です。経緯や仕組みの概要はphp2shellの解説にまとめています。このページでは、攻撃の手順や具体的な設定値などの細部には触れません。

公式機関が言っていること（制作・保守の立場から）

IPAの注意喚起には、長期間更新していないシステムでは、更新に伴うアプリケーションの改修や動作確認が必要になるほか、開発時の資料やノウハウの不足、担当者の不在、保守契約の終了などで対策が難しくなっている場合がある、とも書かれています。顧客への説明（下の「顧客への説明文のひな形」）では、この点を作業範囲や費用の相談につなげます。

ステップ1：預かっているサイトの一覧を作る

最初に、サイトごとに1行の一覧（スプレッドシートで十分です）を作ります。この段階では、まだPHPのバージョンが分からなくてかまいません。分かるところから埋めます。

• 納品後に保守契約が終わっているサイトも、一覧には入れておきます。IPAも、保守契約の終了が対策を難しくしている場合があると述べています。
• 契約者が顧客本人で、こちらにログイン権限がないサイトは、「顧客に確認を依頼」と記録します。第三者のサーバーに、許可なくログインしないでください。
• IPAは事前注意喚起（2026年10月21日）で、利用しているすべての製品について、内部でのPHPの利用有無を個別に確認することまでは求めていません。まずは自社が制作・運用しているサイトから始めます。

ステップ2：サイトごとにPHPの情報を集める

集めるのは、次の3つです。

1. Webサイトで実際に使われているPHPのバージョン（系統だけでなく、最後の番号まで）
2. 契約先（サーバー会社）の名前とプラン
3. ドメインごとの設定（共用サーバーの場合）

注意：コマンドの結果と、Webで動いているPHPは違うことがあります

mixhostの公式ヘルプは、TerminalやSSHで実行されるphpと、Webサイトの閲覧時に実行されるphpは別物のため、php --version で出る番号と、phpファイルを使った確認方法で出る番号が異なることがあると説明しています（mixhost ヘルプ、2026年10月22日確認）。WP-CLIの公式ドキュメントも、wp cli info で使われるphp.iniは、一般にWebとは違うものだと説明しています（WP-CLI、2026年10月22日確認）。共用サーバーでは、まず管理画面の設定値かWebからの確認を優先してください。

環境別の取り方

Linuxのパッケージ版の確認コマンドは、次のとおりです。

# Debian / Ubuntu
dpkg-query -W -f='${Package} ${Version}\n' 'php*-cli' 'php*-fpm' 'libapache2-mod-php*' 2>/dev/null

# RHEL / AlmaLinux / Rocky Linux / Fedora
rpm -qa | grep -i '^php'

管理画面にPHP設定がない・見つからないとき：確認用ファイル

SSHが使えず、管理画面でも分からない共用サーバーでは、次の1行のファイルを公開ディレクトリに置き、ブラウザで開いて確認できます。当サイトとしては、第三者に見つかりにくい名前にしておくことをおすすめします（これは当サイトの助言で、mixhostのヘルプやphp.netの記載ではありません）。PHP公式マニュアルでは、phpversion() は現在のPHPのバージョンを文字列で返す関数とされています（php.net）。

<?php echo phpversion();

確認できたら、すぐにファイルを削除してください。 phpinfo() を使う方法もありますが、その出力にはPHPのバージョンのほか、サーバー情報、環境、パス、構成オプション、HTTPヘッダなどが含まれます（php.net）。顧客への報告やチャットに、phpinfoの画面を貼り付けないでください。mixhostのヘルプも、確認後にファイルを削除するよう案内しています。

主なレンタルサーバーの、記録の単位と手順の入口

各社の画面の細かい手順は、個別のガイドと公式マニュアルにまとめています。ここでは、一覧に記録するときに間違えやすい点だけを挙げます（2026年10月22日確認）。画面の名称は変わることがあるため、実際の操作は必ず公式マニュアルに従ってください。

PHPのバージョンを見る画面の一般的な探し方は、PHPバージョンの確認方法にもあります。

契約先の公式発表も、サイトごとの記録に入れる

共用サーバーでは、PHPの本体は契約先が更新します。管理画面の数字だけでは、修正が入っているか分かりません。会社によっては、修正を適用してもバージョン番号を変えないためです（たとえばmixhostは、適用後も番号は変わらないと案内しています）。一覧の「契約先」の行に、公式発表のURLと確認日を入れてください。次の表は、当サイトが記録している国内のホスティング各社（レンタルサーバーのほか、VPSの会社を含みます）の公式発表です。表の各行に、出典と確認日時が表示されます。

表の「発表なし」「未確認」は、対応されていないという意味ではなく、確認した時点で公式の発表が見つからない、または発表の本文に記載がないという意味です。ここにない会社は、各社のお知らせページを直接確認してください。全体はホスティング別 対応状況にあります。

ステップ3：優先順位をつける

件数が多いときは、次の順で進めます。これはあくまで当サイトの目安であり、公的機関が定めた順序ではありません。実際の順序は、顧客との契約内容や、サイトの重要度に合わせて調整してください。

PHPの系統ごとの公式サポートの状況は、次のとおりです。

サポート終了の系統は、番号だけでは修正の有無を判断しないでください。契約先やOSの提供元が、独自に修正を提供している場合があります。詳しくはPHP 7.4・8.0・8.1 サポート終了のガイドをご覧ください。

集めたバージョンは、当サイトのチェッカーに貼り付けると、本サイトのデータ（公式発表から作成）と、ブラウザの中だけで照らし合わせられます。入力した内容が当サイトに送られることはありません。ただし、共用サーバーでは会社が修正を適用したかどうかを手元の数字だけでは判断できません。判定結果は、契約先の発表と合わせて記録してください。

ステップ4：更新するときの注意（作業側の準備）

更新や移行を行うときの準備です。

1. バックアップを取る。 サイトのファイルとデータベースの両方を取ります。WordPressの公式ページも、バックアップがあれば何か起きたときに元の時点へ戻せると説明しています（WordPress.org サポート）。
2. テーマ・プラグインの対応を確認する。 同じ公式ページは、PHPのバージョン更新は通常問題ないはずだが、保証することはできないとしています。ロリポップ!のマニュアルも、WordPressでは、テーマやプラグインが変更後のPHPバージョンに対応しているか事前に確認するよう案内しています。
3. 戻し方を確認する。 さくらのマニュアルは、動作に不具合がある場合は古いバージョンを選び直せば元の環境に戻せるとしています。一方、ロリポップ!のマニュアルには、PHP 7.1未満から上げた場合は変更前のバージョンに戻せないという記載があります。戻せるかどうかは、会社ごとに先に確認してください。
4. 反映までの時間を見込む。 ロリポップ!のマニュアルは、設定変更から反映まで5〜10分ほどかかるとしています。
5. 更新後は再起動し、表示を確認する。 VPSなどでは、PHPを動かしているサービス（PHP-FPMやApache）を再起動してから、トップページ・主要ページ・問い合わせフォームなどを開いて確認します。再起動しないと、古いプロセスが動き続けることがあります。

JPCERT/CCは、十分なテストを行ったうえで、速やかに修正済みバージョンを適用するよう求めています。テストと速やかさの両立が難しいサイトは、優先順位の上位から先に進めてください。

顧客への説明文のひな形

専門用語を使わず、「何が起きたか」「確認できたこと」「次にやること」の順に書きます。【　】の部分を、サイトごとに書き換えてください。次の点は、文面に書かないでください。

• 攻撃の手順や仕組みの細部（対策に必要ではなく、悪用の手がかりになり得ます）
• 「問題ありません」「被害はありません」といった断言（確認できたのは、確認できた範囲だけです）
• 作業の完了日や費用の確約（調査してから伝えます）

ひな形A：対応を確認できたサイト（契約先が修正を適用したと発表している場合）

件名：【ご報告】PHPの脆弱性に関する、貴社サイトの確認結果

【顧客名】 ご担当者様

いつもお世話になっております。【自社名】です。

2026年10月21日、ホームページを動かすプログラム「PHP」の提供元が、重大な脆弱性2件の修正版を公開しました。放置すると、外部の第三者にサーバー上でプログラムを実行されるおそれがあるとされています。

当社でお預かりしている貴社サイト【URL】について、PHPのバージョンと、サーバーの契約先の対応状況を確認しました。

■ 確認した内容（【確認日】時点） ・PHPのバージョン：【系統・番号】 ・サーバーの契約先：【会社名】 ・契約先の発表：【発表日】に、この脆弱性への対応（修正の適用）を完了したと発表しています。【発表のURL】

契約先の発表に基づき、現時点で新たにお願いする作業は確認できていません。契約先の発表が更新された場合や、状況が変わった場合は、改めてご連絡します。

■ ご理解いただきたいこと ・上記は、当社が【確認日】時点で確認できた範囲のご報告です。不正なアクセスを受けていないことを保証するものではありません。 ・今後も、PHPの更新が必要になる場合があります。継続的な保守の体制についても、あわせてご相談させてください。

ひな形B：更新・移行が必要なサイト（サポート終了の系統など）

件名：【重要】PHPの脆弱性に関する、貴社サイトの確認結果とご相談

【顧客名】 ご担当者様

いつもお世話になっております。【自社名】です。

2026年10月21日、ホームページを動かすプログラム「PHP」の提供元が、重大な脆弱性2件の修正版を公開しました。放置すると、外部の第三者にサーバー上でプログラムを実行されるおそれがあるとされています。

当社でお預かりしている貴社サイト【URL】について、PHPのバージョンを確認しました。

■ 確認した内容（【確認日】時点） ・PHPのバージョン：【系統・番号】 ・状況：この系統は、PHP公式のサポートが終了しており、番号つきの修正版（リリース版）が提供されていません。【契約先が独自の修正を適用したと発表している場合は、その旨と発表のURL。なければ「契約先の対応発表は確認できていません」】

■ ご相談したいこと ・サポートされているPHPへの更新（移行）をおすすめします。 ・古いPHPからの移行では、サイトのプログラムの改修や、動作確認が必要になる場合があります。作業の範囲と費用は、調査のうえで別途お見積りします。 ・更新が終わるまでの間の暫定的な対策（アクセスの制限など）も含めて、進め方を相談させてください。【　】月【　】日までに、ご都合のよい日時をご返信ください。 ・今後も継続して更新できるよう、保守の体制や予算についても、あわせてご相談させてください。

■ ご理解いただきたいこと ・上記は、当社が【確認日】時点で確認できた範囲のご報告です。不正なアクセスを受けていないことを保証するものではありません。 ・更新の作業では、事前にバックアップを取り、作業の日時を相談したうえで進めます。作業中や作業後に、表示に不具合が出る可能性があります。

説明するときの補足

• 「確認できた範囲」を具体的に書く。 「PHPのバージョンを確認した」「契約先の発表を確認した」のように、何を見たのかを書きます。見ていないもの（たとえばアクセスログ）は、確認していないと書いてかまいません。
• 顧客の担当者だけでなく、決裁者にも届くようにする。 IPAは、更新・移行と、その後の維持管理に必要な人員・予算・保守体制を確保できるかを、事業責任者や経営層も含めて検討するよう求めています。費用や契約の話は、決裁できる人にも伝わる形で出してください。

確認した結果を記録する

説明文の内容は、あとから見返せるように、サイトごとに記録します。JPCERT/CCは、ログなどの痕跡が確認されない場合でも攻撃を受けていないと断定できないとしており、記録には「問題なし」ではなく「何を、いつ、どう確認したか」を残します。

• 記録に書く判断は、「当社の確認範囲では対応を確認できた」のような形にとどめ、「問題なし」とは書かないでください。
• 侵害が疑われる場合は、関連するログなどの証拠を保全したうえで、影響範囲の調査や、そのシステムの隔離など、必要な対応を行うよう、JPCERT/CCは求めています。調査の細部はJPCERT/CC 注意喚起の「侵害調査」の項を参照してください。
• 修正版への更新に加えて、不審なプロセスの実行、外部への通信、不審なファイルの作成など、侵害を示すほかの痕跡も確認し、継続して監視することも、JPCERT/CCは求めています（同じ注意喚起）。

ご自身でバージョンの確認や更新の進め方を整理する時間がない場合は、環境に合わせた手順をメールでまとめる対応プランもあります。サーバーへのログインや代行作業は行いません。

関連ページ

• php2shellの解説と、緊急対応
• PHP脆弱性の対策まとめ：今すぐやる順番
• PHPバージョンの確認方法
• レンタルサーバーのPHP脆弱性対応
• WordPress編
• Ubuntu・Debian編
• PHP 7.4・8.0・8.1 サポート終了のガイド
• 修正バージョン表、ホスティング別 対応状況、チェッカー