深夜の緊急パッチはこれからも続く。WordPress サイトを静的化するという備え方

2026年の夏から秋、緊急対応が続きました

WordPress や PHP でサイトを運用している方にとって、2026年の夏から秋は落ち着かない時期だったのではないでしょうか。深刻な脆弱性の公表と緊急の更新が、数週間おきに続きました。

なかでも PHP2Shell は、修正版の公開が日本時間23時前だったこともあり、多くの企業が深夜にパッチを当てることになりました。大手の Web サービスやゲームが、予防のために事前のメンテナンスに入ったことも話題になりました。

この記事では、一連の対応を振り返りながら、「パッチを速く当てる」だけでなく「パッチを当てる場所を減らす」という備え方を考えます。

PHP2Shell では何が問題だったのか

PHP2Shell は、ログインなどの認証をしなくても、外部からサーバ上で任意のコードを実行されるおそれのある脆弱性でした。技術的な仕組みは専門の解説に譲り、サイトを運用する立場から押さえておきたい点を3つに絞ります。

Web リクエストを処理する PHP がすべて対象だった

特定のプラグインやアプリケーションの問題ではなく、PHP そのものの脆弱性でした。そのため、Web からのリクエストを PHP で処理しているサイトであれば、WordPress かどうかを問わず対象になりました。

古いバージョンにも存在し、正式な修正がないものもあった

発見者によると、この脆弱性は少なくとも10年前のバージョンから存在していたとされています。一方で、PHP が正式にセキュリティ更新を提供しているのは 8.2 以降です。PHP 7 系や 8.0、8.1 には最低限の修正コードが用意されたものの、通常のアップデートとしては提供されていません。古い PHP のまま動いているサイトは、手の打ちようが限られる状態になりました。

修正版が出る前から攻撃が始まっていた

脆弱性の情報は修正版の公開前から出回り、公開を待たずに攻撃が観測されていました。PHP の公式アナウンスも、修正版へのアップデートが唯一の完全な対策だとしています。設定の工夫で完全に防ぐ方法はなく、「更新できるかどうか」がすべてを分けた、と言ってよいと思います。

対応に詰まったサイトに共通していたこと

デジタルキューブにも、PHP や WordPress の脆弱性対応をきっかけにしたご相談が続いています。お話を伺うと、対応に詰まった理由には共通点がありました。

誰が更新するのか決まっていなかった

外部の制作会社がつくったまま、保守の担当者がいないサイトは少なくありません。そもそも自社のサイトが PHP で動いていることを意識しておらず、「更新すべき対象」として認識されていなかった、ということも起こります。

OS が古く、PHP をバージョンアップできなかった

サーバの OS が古いままだと、PHP を新しいバージョンに上げる前に、サーバそのものを入れ替える必要があります。脆弱性が公表されてから慌てて対応しようとしても、その日のうちには間に合いません。

保守会社への依頼に時間がかかった

保守を外部に委託していても、依頼してから対応までに時間がかかるケースがあります。設定変更の見積りが出るまでに時間がかかった、というお話を伺ったこともあります。

夜間に動ける体制がなかった

PHP2Shell の修正版が公開されたのは、日本時間の夜でした。平日の日中しか動けない体制では、翌朝まで脆弱な状態が続くことになります。

こうした状況は、取引先から求められるセキュリティチェックへの回答にも影響します。詳しくは「取引先のセキュリティチェックシート、WordPress サイトの項目にどう答えるか」（リンク）でも整理しています。

「速く当てる」だけでは追いつかなくなっている

脆弱性が見つかったら、修正版をできるだけ速く当てる。これは今も変わらない基本です。ただ、その前提となる状況が変わりつつあります。

PHP2Shell は AI を使って発見したとされています。原因になった処理の弱点は以前から指摘されていたものの、実際に悪用するのは難しいと考えられてきました。AI によって、そうした「悪用しにくいはずの弱点」が実際の攻撃手法に変わるまでの時間が、大きく縮んでいます。

WordPress でも、脆弱性の報告が1年で大幅に増えたとして、2026年8月にコアのセキュリティを強化する取り組みが発表されました。夏から秋にかけての緊急リリースの連続は、その流れの中で起きています。

見つかる脆弱性が増え、公表から攻撃までの時間が短くなれば、パッチを当てる回数も、急がなければならない場面も増えます。管理しているサイトの数だけ、夜中にも休日にも同じ作業が発生します。ただし、人手と時間には限りがあります。

「当てる場所」を減らすなら、公開側に PHP がない Shifter がオススメ

パッチを速く当てる努力とあわせて考えたいのが、パッチを当てなければならない場所そのものを減らすことです。その方法のひとつが、WordPress サイトの公開側を静的化することです。

公開サイトには攻撃される PHP がない

Shifter では、編集は通常の WordPress で行い、公開する際に HTML や CSS などの静的ファイルとして書き出して、CDN から配信します。公開サイトへのアクセスを受けて PHP が動くことはありません。

PHP2Shell や wp2shell は、いずれも Web からのリクエストを受けた PHP や WordPress が攻撃の入口になる脆弱性でした。公開サイトに PHP も WordPress も存在しない構成では、公開サイトへのリクエストを通じてこうした脆弱性を突く経路がありません。

編集用の WordPress は使うときだけ起動する

編集用の WordPress は常に動いているわけではなく、編集するときだけ起動し、使い終われば停止します。起動するたびに URL も変わるため、管理画面が外部から狙われ続けることもありません。

PHP や WordPress の更新は Shifter 側で行う

PHP や WordPress 本体、サーバの OS やミドルウェアは、Shifter 側で最新の状態に保ちます。サイトごとに更新作業をする必要はありません。

PHP2Shell のときの Shifter の対応

PHP2Shell では、Shifter は修正版の公開に先立ち、2026年10月21日（水）15時（日本時間）からメンテナンスを開始し、22日（木）4時に完了しました。メンテナンス後は、WordPress の起動、サイトの編集、Generate（静的ファイルの書き出し）など、ダッシュボードのすべての機能を通常どおり利用できる状態に戻っています。

この間、お客様の側で PHP を更新する作業は必要ありませんでした。また、公開中のサイトは静的ファイルとして配信されているため、メンテナンス中も通常どおり閲覧できていました。

Shifter でも残るリスク

静的化すれば、すべてのリスクがなくなるわけではありません。Shifter を使う場合も、次の点はお客様の側で気をつける必要があります。

編集用 WordPress のアカウント管理

公開サイトが WordPress ではなくても、編集用の WordPress にはログインできる人がいます。パスワードの管理や、退職者・異動者のアカウント削除など、誰が編集できるかの管理は引き続き重要です。

テーマとプラグインの更新

Shifter が最新に保つのは WordPress 本体と PHP などの基盤です。テーマやプラグインを更新するかどうかは、お客様の判断になります。WordPress 本体が新しくなったことで、テーマやプラグインとの相性によって編集画面にエラーが出ることもあります。ただ、その場合でも公開サイトの表示には影響しないため、落ち着いて修正が可能です。

コンテンツに埋め込まれたスクリプト

静的化は、記事の中身までは消毒してくれません。たとえば WordPress 7.1.4 で修正された格納型 XSS のように、悪意のあるスクリプトが記事やページに保存されてしまうと、そのまま静的な HTML として書き出され、公開されます。編集できる人を必要な範囲に絞ることも重要です。

外部サービスのセキュリティ

お問い合わせフォームや検索などを外部サービスに置き換えた場合、その部分のセキュリティは各サービスの提供事業者が担います。どこまでを誰が担うのかは、Shifter の責任共有モデルでご確認いただけます。

向いているサイト、向いていないサイト

公開側に PHP がないということは、公開側で PHP を使う機能も動かないということです。静的化に向いているかどうかは、サイトの性質で決まります。

フォームや検索の置き換え方は、「Shifter で動かない機能と、その代わりの方法」（リンク）で詳しく紹介しています。

動的な機能が欠かせないサイトは、WordPress をそのまま運用しながら、パッチの適用を任せられる体制を整えるのが現実的です。デジタルキューブの Amimoto では、OS やミドルウェアの保守に加え、WordPress のアップデートや監視、監査への対応までをまとめて任せられる Governance Plan も用意しています。

ひとつの会社の中で、サイトごとに選び分けることもできます。更新頻度の低いサイトから Shifter に移し、動的な機能が必要なサイトは Amimoto で運用する、という組み合わせも少なくありません。

次の緊急パッチが来る前に

深刻な脆弱性の公表と緊急の更新は、これからも続くと考えておいたほうがよさそうです。そのたびに、すべてのサイトで夜を徹して対応するのは現実的ではありません。

まずは、自社で運用しているサイトを一覧にして、それぞれの PHP と WordPress のバージョン、更新を担当しているのは誰かを確認してみてください。そのうえで、静的化できるサイトがあれば、次の緊急パッチを待たずに移しておくことをおすすめします。パッチを当てる場所が減れば、本当に守るべきサイトに手を回せるようになります。

Shifter では、フリートライアルで今のサイトを移し、表示や更新の流れを確かめられます。移行の準備や、自社サイトが静的化に向いているかの判断に迷う場合は、個別相談会でお気軽にご相談ください。

• フリートライアルを始める
• 個別相談会に申し込む
• Shifter で動かない機能と代替方法｜フォーム・検索・予約投稿ほか