WordPressホスティングの「セキュア」は本当か？実検証が明かした真実
WP Tavernのポッドキャスト「Jukebox」に、WordPressセキュリティ企業PatchstackのMaciek Palmowski氏が出演した。同氏はWordCamp Europe 2026で「Testing the promise: does secure hosting deliver?」と題した講演を行い、ホスティング会社が掲げる「セキュアホスティング」の実態を検証した結果を発表した。
テストには30の既知のプラグイン脆弱性を用い、複数の主要ホストで同一条件のペネトレーションテストを実施した。結果は衝撃的で、WordPress固有の攻撃の大半が防御をすり抜けるというものだった。ここではポッドキャストの内容を基に、テストの詳細と、そこから得られる実務への教訓を解説する。
「セキュア」の看板をどう検証したのか
この調査のきっかけは、Patchstackが公開したWordPressセキュリティレポートに対する、WordPress共同創設者Matt Mullenweg氏の反応だった。WP TavernのポッドキャストでPalmowski氏は、「ホスティング会社がすでに対処しているのではないか」という趣旨の問いを受けたと述べている。同社はこれに対し、感覚ではなくデータで示す必要があると判断し、実環境でのテストに踏み切った。
30の既知の脆弱性と標準化手法
テストは2段階で行われた。最初の小規模な試験で、すでに「攻撃の80%が成功する」という結果が出たため、範囲を拡大した本試験が実施された。
- 対象: 30種類以上のプラグイン脆弱性。いずれもPatchstackのバグ報奨金プログラムを通じて報告され、攻撃手順（PoC）が確立しているもの。
- 環境: 複数の大手ホスティング会社で、提供されているすべてのセキュリティ機能を有効化した上でテスト。
- 脆弱性の種類: ファイルアップロード、パストラバーサル、SQLインジェクションなど、WordPressプラグインに典型的なものからEC向けまで幅広く選定。
つまり、現実に存在し、攻撃手法も公開されている脆弱性を「ホスティングがどこまで防げるか」を公平に調べたものだ。
この設計により、「マーケティング上のうたい文句」と「実際の防御力」の差が浮き彫りになった。
検証結果が示すギャップ
本試験の結果、WordPressに特化した攻撃の約70〜80%がホスティングの防御を通過した。Palmowski氏は「問題があるとは思っていたが、ここまで大きいとは」と語っている。
同じセキュリティツールでも結果はバラバラ
興味深いことに、同じサードパーティ製セキュリティツール（例としてCloudflareが示唆された）を導入しているホスト間でも、防御の成否に大きな差が出た。これは「どのツールを入れるか」より「どのように設定・運用するか」の重要性を示している。
この差は、設定の積極性と利便性のトレードオフにも関係する。攻撃を厳しくブロックすれば誤検知が増え、ユーザー体験を損なう可能性がある。一部のホストはユーザーへの影響を恐れて設定を緩めていると考えられる。
ホストの「その後の対応」にも差
テスト後、Patchstackは全対象ホストに結果を通知し、どの攻撃が通過したかを共有した。Palmowski氏によると、一部のホストは速やかに設定を修正し、防御力を大幅に改善した。一方で、通知後も何も手を打たなかったホストも存在したという。
「問題があること自体よりも、それを指摘された後の行動のほうが重要だ」と同氏は強調する。セキュリティに終わりはなく、発見→修正のループを回せるかどうかが本質的な強さを決める。
スイスチーズモデルと多層防御
Palmowski氏は、理想的なセキュリティを「スイスチーズモデル」で説明した。どの防御層にも穴（欠陥）は存在する。重要なのは、複数の層を重ねることで、全体として穴をふさぐことだ。
このモデルから言えるのは、ホスティングの防御は重要な第1・第2層だが、それだけでは不十分という点だ。特に第2層の「WordPressアウェア」な保護がないホストでは、第1層だけに頼ることになり、テストのように攻撃が素通りしてしまう。
AI時代の攻撃スピードとパッチ未適用問題
2026年のセキュリティ議論でAIの話題は避けられない。Palmowski氏は「攻撃の高速化」と「パッチ未適用率の高さ」の2点をリスクとして挙げた。
脆弱性公表から攻撃開始まで5時間
Patchstackの内部データによると、脆弱性が公表されてから実際に攻撃が観測されるまでの平均時間は約5時間だ。数年前はもっと長かったが、AIによる攻撃コードの自動生成がこの時間を劇的に短縮している。
「毎週の手動更新で大丈夫」というアドバイスは、2026年においてはほぼ無力だ。攻撃は日単位や週単位ではなく、時間単位で動いている。リアルタイムの防御か、少なくとも自動更新と組み合わせた仕組みが求められる。
50%の脆弱性は公表時点で未パッチ
さらに深刻なのは、発見された脆弱性の約半数が、ベンダーへの通知から30日が経過しても修正されずに公表されている事実だ。これは「とにかく更新すれば安全」という前提を崩す。更新したくてもパッチが存在しないケースが大量にあるからだ。
→ 30日間の修正猶予
STEP 2 未修正のまま公表（ケースの約50%）
→ 平均5時間で攻撃開始
STEP 3 パッチ不在のまま攻撃が拡散
このタイムラインを見れば、「プラグイン開発者が対応してから更新すればいい」という姿勢がいかに危険かがわかる。パッチが存在しない期間こそ、ホスティングレベルでの脆弱性ブロックや仮想パッチが有効になる。
ホスティング選びで問うべき質問
では、利用者や代理店はどのようにホスティングを評価すればいいのか。Palmowski氏は「WordPressに特化したセキュリティ層の有無を確認すること」が最初の一手だと述べる。
「WordPressアウェア」かどうかを見極める
営業担当者やドキュメントに「Webアプリケーションファイアウォールを備えている」とだけ書かれている場合は要注意だ。これはPHP全体に対する汎用防御であり、WordPressのプラグイン固有の脆弱性を検知できるとは限らない。
- 具体的な質問例: 「御社のセキュリティは、WordPressの特定プラグインの脆弱性を検知・ブロックする機能がありますか？」
- 答えられない、または「WAFで対応」とだけ返ってくる場合は、WordPressアウェアな層が存在しない可能性が高い。
- 逆に、特定のセキュリティパートナー（Patchstack、WPScanなど）と連携していると明言できるホストは、少なくともその層を意識していると判断できる。
「すべてを守る」という表現に注意
Palmowski氏は、ホスティング会社が「セキュリティは全てお任せください。追加ツールは不要です」と断言する場合に警戒が必要だと指摘する。同氏の言葉を借りれば、「現実には、どの防御層も完璧ではない」のだ。
「『当社はこの層を担当しますが、最終的なサイト運用のセキュリティはお客様の責任です』と明言するホストのほうが、かえって誠実で信頼できる」とPalmowski氏は評価する。完璧をうたうマーケティングよりも、限界を認めつつ強みを説明する姿勢が、これからの「セキュアホスティング」には求められる。
この記事のポイント
- 複数ホストでの実検証で、WordPress固有の攻撃の70〜80%が防御を通過していた。
- 同じセキュリティツールでも設定や運用次第で結果が大きく異なる。
- 「WAFがあるから安全」ではなく、WordPressのプラグイン構成を理解した層が必須。
- 脆弱性公表から平均5時間で攻撃が始まる現状では、手動更新だけでは不十分。
- 「スイスチーズモデル」に基づき、ホスティングの防御と自社の運用プロセスを重ねる必要がある。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験