【2026年10月24日時点】PHP2Shell対策:レンタルサーバー利用者が確認したい5つのこと
作成日:2026.10.24
PHP2Shellへの対応で、自社サイトの何を確認すればよいか迷うWeb担当者向けに、確認する順序を解説します。さくら・エックスサーバー・ロリポップ!の公式案内をもとに、利用者に必要な作業の判断、サイトの点検、問い合わせ文、古いPHPの更新を計画する際の注意点をまとめました。
目次
PHP2Shellという名前で、PHPの重大なセキュリティ上の問題が報じられています。「うちの会社のホームページは大丈夫?」「自分で何か設定を変えないといけない?」と、気になっているWeb担当者の方もいるかと思います。
まず確認したいのは、契約しているサーバー会社の公式発表です。共用レンタルサーバーでは、会社側でPHPの修正を行っている場合があります。ニュースやSNSだけで判断して、管理画面のPHP設定を慌てて変更する必要はありません。
ただし、「レンタルサーバーだから何もしなくてよい」という意味でもありません。自社の契約が対応の対象に含まれるか、利用者に必要な作業があるかを確認しましょう。
この記事は、サーバーの専門知識を持たずに自社サイトを管理している方向けに、確認する順序をまとめたものです。事業者の対応状況は2026年10月24日に公式情報を確認した内容です。その後の変更については、各社の最新のお知らせを優先してください。
PHP2Shellは、どんな問題?
PHPは、サーバー上で動き、Webページの表示やフォームの処理などを行うソフトウェアです。WordPressで作られたサイトでも使われています。
今回のPHP2Shellは、PHPに見つかった、外部から不正なプログラムを実行されるおそれがある問題です。このようなセキュリティ上の弱点を「脆弱性(ぜいじゃくせい)」と呼びます。2026年10月21日にPHPの開発元が問題と修正版を公表し、JPCERT/CCも対策と被害の有無の確認を呼びかけています。
確認の中心になるのは、サイトを動かしているPHPに修正が適用されているかどうかです。WordPress本体や、機能を追加する「プラグイン」の更新も必要な保守ですが、サーバー側のPHPの修正とは分けて確認する必要があります。
自社サイトで確認したい5つのこと
1. 契約しているサーバー会社とサービス名
契約メール、請求書、サーバーの管理画面などで、会社名だけでなく、サービス名とプラン名まで確認します。制作会社にまとめて依頼している場合は、その会社に聞いてみてください。
ドメイン、つまりサイトのアドレスを管理している会社と、サイトを置いているサーバー会社が違うこともあります。「ドメインの請求書がこの会社だから」と決めつけず、サイトを動かしているサーバーの契約を確認しましょう。
あわせて、契約が「共用レンタルサーバー」なのかも確認します。共用レンタルサーバーは、一般にサーバー会社が用意した環境を借りて使うサービスです。一方、VPSや、利用者側で管理する専用サーバーなどでは、PHPの更新を自社や保守会社が行う必要があります。同じ会社のサービスでも、対応する人が変わります。
契約の種類が分からなければ、「PHPの修正は御社で行う契約ですか。それとも、こちらで手配する必要がありますか」と聞くとよいかと思います。
2. サーバー会社の公式なお知らせ
契約先の公式サイトにある「お知らせ」「メンテナンス情報」などで、PHPの脆弱性への対応を確認します。検索結果の短い説明だけで済ませず、告知の本文を開いてください。
- 自社のサービス名・プランが対象に入っているか
- 使っているPHPについて、修正が完了しているか
- 利用者側の作業や、サイトの動作確認が求められているか
- 最初の発表後に、追記や別のお知らせが出ていないか
「対応済み」という見出しだけで判断せず、対象や注意書きまで読むのが大切です。確認したページのURLと日付をメモしておくと、社内への説明や問い合わせにも使えます。
3. 自社サイトで使っているPHP
サーバーの管理画面にあるPHPの設定を確認します。サイトのアドレスごとに設定が分かれている場合もあるので、自社サイトの設定を見ているか確かめてください。ここでは、まず表示されているバージョン番号を控えます。
バージョン番号が古いままでも、未対策とは限りません。例えばエックスサーバーは、PHP 5.6〜8.1について、バージョン番号を変えずに今回の問題を修正したと案内しています。こうした対応があるため、番号だけを見て安全かどうかを判断せず、事業者の説明と照らし合わせます。詳しくは後述の公式告知を参照してください。
設定の場所が分からない場合は、無理に探したり変更したりせず、サーバー会社や制作・保守会社へ確認すれば大丈夫です。全部の項目が分かってからでないと問い合わせられない、ということはありません。
4. 自分で行う作業があるか
自社の環境について修正済みと確認でき、追加の操作も求められていなければ、今回の対策のためだけに急いでPHPを別のバージョンへ切り替える必要はありません。
一方、未対応のものが残っている、自社が対象か分からない、利用者側の作業が案内されている場合は、速やかにサーバー会社や保守会社へ確認してください。設定だけで攻撃を受けにくくする応急措置と、PHPそのものの修正は同じではありません。
なお、PHPの開発元は10月23日にも追加の案内を出しています。特定の設定とプログラムの組み合わせに関するもので、ファイル送信の進み具合を記録する機能を一時的に無効にするよう勧めています。共用サーバーの利用者は独自判断で設定を変えず、「この追加案内について、自社の環境で作業が必要か」も事業者に確認しましょう。
5. サイトの主な機能が動いているか
公式告知で求められている確認に加え、自社サイトで使っている主な機能も点検します。例えば、次のような項目です。
- トップページや主要なページを表示できるか
- 問い合わせフォームを送信でき、担当者にメールが届くか
- 会員向けページや管理画面にログインできるか
- ファイルを添付・送信する機能が使えるか
フォームのテストは担当者と調整し、「動作確認用」と分かる内容で行います。顧客の個人情報を使ったり、実際の注文や請求が発生する操作を不用意に試したりしないようにしてください。
ただし、普通に表示できることと、不正アクセスを受けていないことは別です。動作確認だけで「被害なし」とは判断できません。
さくら・エックスサーバー・ロリポップ!の公式案内
2026年10月24日に確認した、10月21日公表の問題への対応は次のとおりです。これは各社の告知の要約で、すべてのサービスに共通する案内ではありません。契約先のリンクを開き、自社のサービスとPHPが含まれるか確認してください。
| 事業者・対象 | 公式案内の内容 | 確認したい点 |
|---|---|---|
| さくらのレンタルサーバなど | 10月22日更新の告知で、対象サービスの管理画面から選べるすべてのPHPへの対応が完了し、利用者の緊急対応は不要と案内しています。 | さくらのPHP脆弱性への対応状況で対象サービスと関連するお知らせを確認します。VPS・クラウドなどは別サービスなので別途確認が必要です。 |
| エックスサーバーのレンタルサーバーなど | 10月23日追記の告知では、PHP 5.6〜8.5の修正が完了。PHP 5.1〜5.5は過半数のサーバーで完了とされ、すべての完了とは案内されていません。 | エックスサーバーの対応状況と対象サービスを確認します。PHP 5.1〜5.5の利用者は、自社の環境の修正完了を待ってください。 |
| ロリポップ!レンタルサーバー | 10月22日の告知で、古いPHPを含め修正を適用してサイト表示を再開したと報告。あわせて、一部機能の無効化とサイトの動作確認を案内しています。 | ロリポップ!の修正内容と利用者へのお願いを確認し、フォームやファイル送信などを点検します。古いPHPからの切り替えも求められています。 |
上の表は、10月23日の追加案内を含むすべての問題について、3社とも対応が完了したと保証するものではありません。ロリポップ!は関連する機能の無効化を明記していますが、自社で追加作業が必要かは、各社の最新の案内に従ってください。
確認結果に応じて、次の行動を決める
| 確認できた状況 | 次にすること |
|---|---|
| 自社の契約・PHPまで修正済みと確認できた | 告知と確認日を記録し、追加の指示に従って主要機能を点検します。 |
| 未修正、対応中、自社が対象か分からない | 速やかにサーバー会社へ確認し、必要な対策と完了予定を相談します。 |
| VPSなど、自社や保守会社が管理する契約だった | サーバー管理者に連絡し、修正と追加案内への対応を依頼します。 |
| 書き換えた覚えのない内容、見知らぬページへの移動などがある | 不正アクセスの可能性も含めて、すぐにサーバー会社・保守会社へ連絡します。 |
不審な変化がある場合は、気づいた日時、該当ページのURL、画面の様子を控えてください。自分でファイルを消したり、バックアップへ戻したりする前に、調査に必要な記録を残す方法と、公開を止める必要があるかを相談しましょう。サーバーに残るアクセスなどの記録は「ログ」と呼ばれます。「調査に必要なログを保存してほしい」と伝えると話が進めやすくなります。
JPCERT/CCの注意喚起でも、攻撃の痕跡が見つからなくても被害がないと断定できないとしています。PHPの修正が済んだかどうかとは別に、調査や継続した確認を専門の担当者へ相談してください。
分からないときに使える問い合わせ文
PHPの修正状況はサーバー会社へ、サイトの動作やPHPを切り替えた場合の影響は制作・保守会社へ聞くのが基本です。ただし、契約によって担当範囲が違うので、分からなければ普段の窓口へ相談して構わないと思います。
サーバー会社への問い合わせには、例えば次のような文面が使えます。不明な項目は「不明」のままで大丈夫です。
件名:PHPの脆弱性への対応状況についての確認
当社サイトについて、PHP2Shell
(CVE-2026-109618、CVE-2026-109619)への対応を確認したく、ご連絡しました。
サイトURL:
契約サービス・プラン名:
管理画面に表示されているPHPバージョン:
確認した公式お知らせのURL・確認日:
現在のサイトの動作状況・気になっている変化:
以下について教えてください。
・当社の契約環境に、今回の修正は適用されていますか。
・PHP公式の10月23日の追加案内も含め、利用者側の作業は必要ですか。
・未対応のものがある場合、必要な対策と完了予定を教えてください。
・不正アクセスの有無について、事業者側で確認できる範囲と、
当社や保守会社で調査が必要な範囲を教えてください。
問い合わせは公式のサポート窓口から行い、パスワードは文面に記載しないようにしましょう。不審な変化が起きている場合は、冒頭でその状況と気づいた日時も伝えましょう。
今回の修正と、古いPHPの更新は分けて考える
今回の問題への修正が適用されていても、古いPHPを今後ずっと使い続けてよい、ということにはなりません。開発元のサポートが終わっていれば、今後見つかる別の問題の修正を受けられない可能性があります。
具体的には、2026年10月24日時点では、PHP 8.1と、それより前のバージョンは開発元のサポートが終了しています。「8.1.34」のように8.1で始まるものや、8.0、7.4、5.6などが該当します。管理画面にこれらの番号が表示されていたら、今回の修正状況の確認に加えて、制作・保守会社へ新しいPHPへの移行を相談しましょう。終了したバージョンはPHP公式のサポート終了一覧で確認できます。
また、PHP 8.2も、セキュリティ上の修正を受けられるのは2026年12月31日までです。現在8.2を使っている場合も、今のうちに移行の計画を立てておきたいところです。移行先は、サーバー会社が提供し、自社サイトが動くことを確認できる、サポート期間に余裕のあるバージョンを選びます。最新の期限はPHP公式のサポート期間一覧を参照してください。
例えばロリポップ!は、今回の修正に加えて、サポートが続いているPHPへの切り替えも求めています。
ただ、古いサイトではPHPを切り替えると動かなくなることもあります。新しいPHPで動くかを調べ、必要に応じてプログラムを修正し、フォームや管理画面などを一つずつ確認する作業が必要です。サイトの作りや規模によっては大がかりな対応になり、制作・保守会社へ依頼しても、すぐに完了できるとは限りません。
サポート終了の直前になってからではなく、早めに制作・保守会社へ相談し、費用と作業期間を確認して、余裕を持った計画を立てましょう。サイトのデータや設定のバックアップ、事前の動作確認、切り替える日程も含めて相談するとよいかと思います。なお、今回の脆弱性が未修正の場合は、移行計画とは別に、当面の安全を確保する方法を速やかにサーバー会社・保守会社へ確認してください。
まずはサーバー提供会社の公式発表を読み、自社の契約に当てはまる対応を確認すること。その上で、必要な修正や点検を担当者につなぐこと。この順序で進めるのがよいかと思います。
奈良市を拠点に、27年以上の経験を持つフリーランスWebエンジニア、阿部辰也です。
これまで、ECサイトのバックエンド開発や業務効率化システム、公共施設の予約システムなど、多彩なプロジェクトを手がけ、企業様や制作会社様のパートナーとして信頼を築いてまいりました。
【制作会社・企業様向けサポート】
Webシステムの開発やサイト改善でお困りの際は、どうぞお気軽にご相談ください。小さな疑問から大規模プロジェクトまで、最適なご提案を心を込めてさせていただきます。
ぜひ、プロフィールやWeb制作会社様向け業務案内、一般企業様向け業務案内もご覧くださいね。
PHPで外部APIのフォールバックとキャッシュを実装する:該当なしと通信失敗を分けて扱う
2026.10.23
外部APIの「該当なし」と通信失敗を区別し、代替APIへ切り替える条件と取得結果のキャッシュをPHPで実装します。架空の商品情報APIを使い、問い合わせ回数・待ち時間の制限、キャッシュの有効期限・無効化、モックによる動作確認を解説します。
Laravelのコードレビューで遅いSQLの候補を洗い出す
2026.10.02
Laravelのコードレビューで、ループ内のDBアクセスやEloquentのN+1、大量取得、検索条件とインデックスなど、性能問題につながりやすい箇所を候補として洗い出します。Laravelで発行SQLと実行時間を確認し、MySQLのEXPLAINや実データに近い環境での計測へつなげる方法を紹介します。コードレビューだけではSQLの実行時間を断定できない点も説明します。
Windows 11でDocker Composeを使ってLaravel環境を作る:Container・Volume・Networkの基本
2026.10.01
Windows 11のDocker Desktop上に、DockerfileとDocker Composeを使ってLaravel・PHP・MySQL・Mailpitの開発環境を構築します。ImageとContainerの関係、Bind MountとNamed Volumeによるデータの保存、ポート公開とContainer間通信の違いを実例で確認。LaravelからMySQLへ接続するときに、localhostではなくService名を使う理由も説明します。
PHPでYAML設定を検証する:symfony/yamlとopis/json-schemaの使い方
2026.09.30
symfony/yamlでYAMLを読み込み、opis/json-schemaで必須項目や型、許可する値を検証する方法を紹介します。YAMLのマップをstdClassとして扱う方法や、空のobjectとarrayの違い、信頼できないYAMLを扱う際の注意点も解説します。