レンタルサーバー会社が責任を持つのは、サーバーという「土台」までです。その上に入れたWordPress・テーマ・プラグイン・ユーザーの管理は、持ち主の担当です。サーバー側のWAFは役に立ちますが、Patchstackの調査では、一般的なサーバー側の防御が止められたのは攻撃の12〜26%でした。サーバーの機能は「保険の一つ」と考え、更新・削除・別の場所へのバックアップは自分で続けるか、誰かに任せる必要があります。
結論:サーバーの防御は「一部」しか止められない
「レンタルサーバーにセキュリティ機能が付いているから大丈夫」と考えている方は少なくありません。たしかに、サーバー会社はサーバーそのものを守るために多くの手間をかけています。ただ、WordPressの公式ドキュメントははっきりと、ホスティング会社はサイトが載っている基盤(インフラ)には責任を持つが、あなたが選んで入れたアプリケーションには責任を持たないと書いています。そして、侵害の多くはアプリケーション、つまり持ち主が管理する部分が原因だとしています。
この記事では、どこまでがサーバー会社の担当で、どこからが自分の担当なのかを整理し、サーバー側の防御がすり抜けやすい攻撃と、足りない分の補い方を順番に見ていきます。WordPressのセキュリティ対策の全体(更新・入口・バックアップ)はWordPressのセキュリティ対策で解説しているので、ここでは「サーバー任せにしていいか」に絞ります。
サーバー会社と持ち主、どこで担当が分かれるか
マンションにたとえると分かりやすくなります。サーバー会社は建物の管理会社です。オートロックや外壁、共用部分の点検はしてくれますが、部屋の中で誰に合鍵を渡したか、窓を開けっぱなしにしていないかまでは見てくれません。
| 層 | 主な中身 | 担当(一般的な共用レンタルサーバーの場合) |
|---|---|---|
| 建物 | サーバー機器、OS、Webサーバー、ネットワーク | サーバー会社 |
| 共用の設備 | サーバー全体のWAF、通信量の多い攻撃への対策、SSLの仕組み | サーバー会社(使うかどうかの設定は持ち主のことも多い) |
| 部屋の設備 | どの版のPHPを使うか、データベースの作成 | 持ち主が管理画面で選ぶ形の契約もある |
| 部屋の中 | WordPress本体・テーマ・プラグインの更新、ユーザーとパスワード、置いたファイル | 持ち主 |
| 非常時の備え | サーバーとは別の場所のバックアップ、ログの確認、被害時の連絡先 | 持ち主(サーバー会社の機能は補助) |
この表は、WordPress公式の解説と一般的な共用サーバーの作りをもとに当ラボが整理したものです。VPSや専用サーバーでは「建物」の多くも持ち主の担当になります。WordPress公式は、Webサーバーやサーバーのソフトも最新に保つよう書いていますが、共用サーバーではそこはサーバー会社の仕事です。
レンタルサーバーがしてくれること
名前や細かい中身は会社によって違いますが、多くの共用レンタルサーバーには、次のような守りの仕組みがあります。
- サーバー本体の更新と監視:OSやWebサーバーのソフトの修正を当てる、機器の異常を見張る
- WAF:よくある攻撃の形(SQLインジェクションなど)を含む通信を、サーバーの入口で止める
- 大量アクセスへの対策:短い時間に集中する通信を絞る
- SSL(HTTPS)の証明書:無料の証明書を自動で更新する
- 自動バックアップ:一定の期間、サーバー全体やサイトのデータを残す
- 利用者どうしの分離:同じサーバーの他の契約者から、自分のファイルが見えないようにする
2026年10月にPHPに重大な脆弱性(PHP2Shell)が見つかったときも、WordPress公式は「あなたのホスティング会社はすでにPHPの更新やWAFのルールの追加に取りかかっているかもしれない」と書いています。サーバー会社の対応が、更新までの時間を稼いでくれる場面は実際にあります。
してくれないこと
一方で、次のことは基本的に持ち主がやる必要があります。
| してくれないこと | 放っておくと起きること |
|---|---|
| プラグイン・テーマ・本体の更新 | 公開された穴を突かれる。Patchstackの報告では、大量に悪用され始めるまでの時間(重み付けした中央値)は5時間 |
| 使っていないプラグインやサイトの削除 | 停止しただけのプラグインや古いサイトのファイルが、入口として残る |
| PHPの版の切り替え | サポートの切れた版で動き続ける。WordPress公式も、PHPの更新はサイトの持ち主がすぐ行うよう呼びかけている |
| ユーザーとパスワードの管理 | 辞めた人のアカウントや、使い回しのパスワードから入られる |
| 公開フォルダに置いたファイルの管理 | 設定ファイルの控えや、バックアップの圧縮ファイルを外から持ち出される |
| 「戻せる」ことの確認 | いざというとき、汚染されていない時点のバックアップが残っていない |
5つめの例は大げさな話ではありません。JPCERT/CCは2026年10月、国内組織への不正アクセスについての注意喚起の中で、標的ごとに既知の脆弱性を探して攻撃を試すケースを挙げ、脆弱性がなくても管理の不備を突いて「環境設定ファイルやバックアップファイルの窃取など」を試みている可能性があるとしています。サーバーの防御は、持ち主が自分で公開した場所に置いたファイルまでは守れません。
サーバー側の防御が止めた攻撃の割合(調査データ)
WordPressのセキュリティ企業Patchstackは、2026年2月に更新した年次報告で、レンタルサーバー各社の防御を実際に試した結果を紹介しています。試験は2回行われ、範囲が違います。
| 試験 | 対象 | サーバー側の防御が止めた割合 |
|---|---|---|
| 1回目 | 実際に悪用が知られている、WordPress特有の脆弱性への攻撃 | 12% |
| 2回目 | 範囲を広げ、WordPress以外でも見られる一般的な脆弱性も含めた攻撃 | 26%(攻撃全体のうち) |
報告からは、ほかに次のことも読み取れます。
- サーバー内のWAFは、WordPressに限らない一般的な脆弱性に対しては、いくらかよい結果だった
- 似た防御の組み合わせでも、サーバー会社によって結果は大きく違った
- 2025年に見つかったWordPress関連の脆弱性は11,334件で、91%がプラグイン、9%がテーマ。本体は6件で、いずれも優先度の低いもの
- 46%の脆弱性は、公表の時点で開発者の修正が間に合っていなかった
つまり、狙われる穴の大半はプラグインとテーマ、つまり「部屋の中」にあり、サーバーの入口の防御はその多くを見分けられていません。同じ報告は、プラグインの更新だけに頼ることもできないとして、公表から短い時間で働く自動の防御を用意するよう呼びかけています。
なぜサーバーのWAFをすり抜けるのか
サーバーのWAFは、主に「攻撃らしい形」の通信を見て止めます。たとえば、入力欄にデータベースへの命令を混ぜ込むような通信です。ところが、WordPressのプラグインで多い穴は、そういう分かりやすい形をしていないことがあります。
- 権限の確認漏れ(アクセス制御の不備):本来は管理者しか使えない機能を、ふつうの会員や未ログインの人が呼び出せてしまう穴です。Patchstackの報告では、2025年に最も悪用された種類で、通常のログイン済みの通信と見分けがつかず、攻撃らしい文字列も含まないため、従来のWAFでは防ぎにくいとされています。
- そのプラグイン固有の入口:プラグインごとに独自の受け口があり、サーバー全体の共通ルールでは、どれが危ない呼び出し方かを知りようがありません。
- 正しいパスワードや鍵での侵入:漏れたパスワードや、外部サービス用の鍵で入られると、通信は正規の利用と同じに見えます。
- サーバーの中で動くもの:一度入り込んだ不正なプログラムや、持ち主自身が置いた危ないファイルは、入口の検査を通りません。
サーバーのWAFは「よくある形の攻撃を広く浅く止める」のが得意で、「このサイトのこのプラグインの、この使い方は危ない」と判断するのは苦手、と考えると実態に近くなります。
足りない分を補う方法
足りない分は、サイトの中とサイトの外の両方から補います。
- 数を減らす
使っていないプラグイン・テーマ・古いサイトを削除します。停止ではなく削除です。同じ契約に置いた試作用のサイトも見直します。 - 更新を止めない
本体・テーマ・プラグインの自動更新を使い、PHPはWordPress公式が推奨する8.3以上を目安に選びます。今の版は「ツール」→「サイトヘルス」→「情報」→「サーバー」で確かめられます。 - 公開フォルダを掃除する
サーバーのファイルマネージャーで、.zip・.sql・.bak・wp-config.phpの控えなど、置いた覚えのある古いファイルが公開フォルダに残っていないか確かめ、不要なものは消します。 - バックアップを別の場所にも残す
サーバーの自動バックアップに加えて、日付ごとのコピーをサーバーとは別の場所に保管し、戻し方を一度試しておきます。 - サイトの外にも門番を置く
Cloudflareなどを手前に置くと、サーバーに届く前に怪しい通信やログイン画面への攻撃を減らせます。具体的な設定はWordPressを残したままCloudflareで守るで解説しています。 - 続けられないなら、攻撃される場所を減らす
点検を続ける人がいない場合は、保守を頼むか、WordPressをやめる方法も検討します。選択肢はWordPressからの乗り換え先5つを比較で比べています。
IPAも、2026年10月のPHPの脆弱性についての注意喚起で、対応後の維持管理の体制を確保できる見通しが立たない場合は、今の仕組みを続けることを前提にせず、移行や機能の縮小、公開の終了も含めて検討するよう案内しています。
サーバー会社に確かめたい8つの質問
契約しているサーバーが何をしてくれるのかは、マニュアルを読むか、問い合わせると分かります。次の8つを確かめておくと、自分で補う範囲がはっきりします。
- WAFは初期設定でオンか。WordPressのどの攻撃を対象にしているか
- 自動バックアップは何日分残るか。戻すのは無料か、ファイルとデータベースを別々に戻せるか
- PHPの版は誰が切り替えるか。サポートの切れた版を選べるままになっていないか
- 重大な脆弱性が出たとき、利用者への連絡はどこに届くか(管理画面・メール)
- 不正なファイルを見つけたとき、サーバー会社は止めるだけか、知らせてくれるか
- アクセスログとエラーログを、何日分見られるか
- 同じサーバーの他の利用者とは、どのように分けられているか
- 被害が起きたとき、どこまで調査・復旧を手伝ってくれるか(費用を含めて)
答えを聞いて「思ったより自分の担当が多い」と感じたら、それが補う必要のある部分です。
よくある質問
サーバーの管理画面で「WAF」がオンになっていれば、プラグインの更新は後回しでもよいですか?
おすすめしません。Patchstackの調査では、一般的なサーバー側の防御が止められたWordPress特有の脆弱性への攻撃は12%でした。WAFは更新までの時間かせぎにはなりますが、プラグインの穴そのものはふさがりません。更新を先に考えてください。
サーバー会社の自動バックアップがあれば、自分でバックアップを取らなくてよいですか?
それだけに頼るのは危険です。保存される期間や戻せる範囲は会社やプランで違い、不正なプログラムが潜んでいる期間が長いと、残っているのが汚染された時点だけになることがあります。WordPress公式も、日付ごとのスナップショットを信頼できる場所に保管するようすすめています。サーバーとは別の場所にも残しましょう。
PHPのバージョンは、サーバー会社が上げてくれるのではないのですか?
契約によっては、使うPHPの版を持ち主が管理画面で選ぶ形になっていて、自動では上がらないことがあります。WordPress公式も、サーバー会社の対応を確かめたうえで、必要ならすぐにPHPを更新するよう呼びかけています。今の版は、WordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」で確かめられます。
同じサーバーに置いている別のサイトが攻撃されたら、こちらにも影響しますか?
影響することがあります。WordPress公式の解説は、共用サーバーでは他のサイトが侵害されると、自分のサイトも巻き込まれるおそれがあるとしています。同じ契約の中に使っていない古いサイトを置いたままにしないことが、いちばん手軽な対策です。
サーバーを「セキュリティが強い」会社に替えれば解決しますか?
サーバー側で止められる攻撃は増えるかもしれませんが、WordPressの中身の管理は替えた先でも持ち主の担当のままです。Patchstackの調査でも、似た防御の組み合わせでもサーバー会社によって結果が大きく違ったとされており、会社選びだけで解決するとは言えません。
更新や点検を続ける人がいない場合は、どうすればよいですか?
保守を外部に頼む、Cloudflareなどを手前に置いてサーバーの外でも守る、WordPressをやめて攻撃される場所そのものを減らす、のどれかを検討してください。IPAも、維持管理の体制を確保できる見通しが立たない場合は、移行や機能の縮小、公開の終了も含めて検討するよう案内しています。
参照元
- WordPress Advanced Administration Handbook:Hardening WordPress(2026年10月14日更新)
- WordPress.org:Requirements(2026年5月7日更新)
- WordPress.org News:Critical PHP Security Release(2026年10月)
- Patchstack:State of WordPress Security in 2026(2026年2月25日更新)
- JPCERT/CC:直近で相次いでいる国内組織における不正アクセスに関する注意喚起(2026年10月8日公開、10月23日更新)
- IPA:PHP2Shell(CVE-2026-109618、CVE-2026-109619)に関する注意喚起(2026年10月22日公開、11月2日更新)
- 最終確認日:2026年11月4日
URLを送るだけで、外から確認できる範囲でWordPressやPHPの状態と危険度をお返しします。