10月21日から22日にかけて、いろいろなサービスが突然「メンテナンス中」になりました。
レンタルサーバーや一部の WordPress だけでなく、ネットショップを提供する BASE やお買い物アプリの PAY ID など、使おうと思ったサービスにログインできれず、びっくりされた方もいらっしゃると思います。
ペライチは公開中のユーザーのページごと一時閉鎖してましたね。
私の身近では、行きつけのスーパー「エブリイ」の会員証アプリが使えなくなってました。
レジスタッフの方の指示に従ってレシートを持ってサービスカウンターへ行くと、別のスタッフの方が会員番号と利用金額を手書きで控えてくださり･･･
ひぇ～！！
これ全部、後で手入力してくださるんですか？！
と伺うと、「後ほど本部が入力するみたいです～。汗」とおっしゃってました。
なんとまぁ･･･大変だ･･･！
PHP の影響がこんなところまで･･･！
ちなみに･･･
▼この ありがたすぎる お詫びディスカウント･･･
我が家がエブリイへ買い物に行ったのは25日なので、「全品５％OFF」の恩恵にはあずかれませんでした。泣
５％はデカいね。
６人家族だからいっぱい買うもんね。
さて、エブリイの５％OFF は諦め、気を取り直して･･･
WordPress を預かるレンタルサーバー会社は対応さまざま。ユーザーのサイトごと一時期クローズしていたサーバーもありました。
このサイトがお世話になっているエックスサーバーさんでは、管理画面やウェブメールのログイン画面にアクセスすると、緊急対応中の表示になってました。
きっかけは、たくさんのウェブサイトやサービスの裏側で動いている「PHP」というプログラムに重大なセキュリティ上の弱点が見つかったこと。
SNS でも大変な騒ぎになっていたので、ご存じのことと思います。
高市総理がポストされるほどの事態でしたから。
このニュースをお聞きになって、
WordPress もテーマもプラグインも最新にしてるから大丈夫！
うちのブログは平常どおりちゃんと見えてるよー！
そう思われた方にも知っておいていただきたいことがあります。今回の問題は、WordPress の更新だけで対応できるものではなかったからです。
何が起きていたのか。
サーバー会社はどう対応してくれたのか。
そして私たちはこれから自分の WordPress サイトをどう守っていけばよいのか。
お預かりしているサイトをチェックしながら、私自身が感じたことも含めてお伝えします。
PHP の問題は WordPress だけの話ではありませんでした
PHP は、WordPress を動かす土台の一つです。画面には見えなくても、記事や設定を読み込み、ページを表示する裏側で働いています。
「更新」といえば、ダッシュボードに出てくる WordPress 本体・テーマ・プラグインの更新を思い浮かべますよね。けれど、それらを動かすサーバーにも、別のプログラムや設定があります。
ブログを書くために触っている WordPress と、その裏側で動いている PHP。さらに、それを動かすサーバーの仕組み。管理する場所も更新担当も別々です。
レンタルサーバーの場合、利用者は管理画面で PHP の系列を選べるようになっていますが、提供されている PHP 本体に修正を取り込む作業はサーバー会社が担当します。
今回、多くの方にとって最初に必要だったのは、契約先の対応を確かめることでした。
その PHP に、条件によってはログインしていない外部の人に勝手なプログラムを動かされるおそれのある弱点が見つかりました。
レンタルサーバーの PHP 本体を修正する作業は、基本的にサーバー会社が担当します。私たちは、公式案内で対応状況や利用者へのお願いを確かめましょう。
今回、公表されたのは、CVE-2026-109618 と CVE-2026-109619 という２つの脆弱性でした。CVE というのは弱点を区別するための番号です。
１つは、PHP がメモリ不足になったときの処理に関係するもの。もう１つは、ある通信の処理で使った内部の情報が不適切な状態で残り、後の通信の処理で使われてしまう問題です。
条件は異なりますが、どちらも外部からプログラムを実行される危険につながります。
プログラムを実行されると、権限や環境によっては、サイトを改ざんされたり、不正なプログラムを設置されたり、情報を持ち出されたりする可能性があります。
だから、「見た目に変化がない」イコール「安心」とは判断できません。
ただ、PHP を使っているすべてのサイトが等しく危険、というわけでもありません。構成や設定によって、影響の受け方は変わります。
PHP を使っているサービスは、皆さんが思っている以上に身近にあります。
私がメルマガの配信に使わせていただいているマイスピーでも緊急メンテナンスが案内されました。
ネットショップの BASE や、お買い物アプリの PAY ID でも、緊急メンテナンスが行われました。
ペライチでは、10月21日22時50分から22日0時15分まで、公開中のページを含む全サービスを止めてメンテナンスを行い、公式の修正版を適用したと報告しています。今回の件による被害は確認されておらず、利用者側で設定を変える必要もないそうです。
お仕事のやりとりに使う Chatwork も、PHP の重大な脆弱性への予防的な対策として、10月21日23時ごろから22日0時15分ごろまでサービスを停止したと案内しています。あの日は Chatwork も使えなくなってました。
また、Canva も、2018年の公式技術ブログで、開発の一部に PHP を採用していることを紹介しています。Canva の主要な開発言語が PHP という意味ではありませんが、皆さんが普段使うサービスの、見えない部分にも使われてるんです。
なお、Canva の PHP 採用例は、2018年の技術紹介です。今回の件で Canva が停止した、あるいは被害を受けたと確認したものではありません。
旅行ゲームの「ワールドクエスト」は、古い仕組みのため十分な対策が取れないとして、利用者の情報を守るためにサービスを終了すると発表しました。
「更新すれば終わり」では済まず、サービスを続けるかどうかまで考えなければならなかった運営者さんもいたのです。
対応に関わった OpenAI は、ホワイトハウスの関係組織や米国のサイバーセキュリティ当局などと連携したと説明しています。
それだけ大きな範囲に影響する、世界規模の対応が必要な出来事でした。
そうなんです。実は、ホワイトハウスのウェブサイトも WordPress でできてるんですよ。
WordPress 公式の紹介ページにも掲載されてます。私たちのブログと同じ仕組みが、こんなところでも使われてるんですよ。
ただし、サービスを一時的に止めたことと、実際に被害を受けたことは、同じではありません。被害を防ぐために、修正が済むまで止める判断もあります。
公開を止める判断も、止めずに守る判断も、とても重い仕事
公開されている利用者のページまで一度すべて止めたペライチ。
この対応について、私は「被害を防ぐために、ここまで踏み込んだんだな」と受け止めました。
修正が完了するまでの間、問題のある PHP に外部から通信が届く状態を止めることは、侵入や改ざんを防ぐための有効な判断です。
高市総理の発信でも、サイトやサービスの一時停止もリスク低減の方法として挙げられてましたね。
公開ページを止めることは、必ずしも「対応に失敗した」ということではありません。守るために止める、という判断もあるのです。IPA の案内でも、有効な暫定対策が難しい場合は、外部からのアクセス遮断やサービスの一時停止が必要か判断するよう説明されています。
ただし、これは「画面に【メンテナンス中】と表示すれば安全」という意味ではありません。
PHP が動く構成のまま、WordPress のプラグインなどでメンテナンス画面を出すだけでは、その手前で処理される今回の弱点を防げるとは限りません。
問題のある PHP への通信を遮断する、必要な修正を適用するなど、仕組みの側で対応する必要があります。
だから、利用者のサイトと情報を守るために全ユーザーのページの公開を止めたペライチの判断は正しかったと思っています。
ただ、どの会社でも全面停止だけが正解だったわけではありません。構成や、先に用意していた防御策によって、選べる方法は変わります。
エックスサーバーさんをはじめ、多くのレンタルサーバーが利用者のサイトを稼働させたまま安全対策を行い、修正を適用したという対応には感謝の気持ちでいっぱいです。
どのサービスも、どのサーバーも、寝ずの対応だったと思います。感謝に堪えません。本当におつかれさまでした。
なお、サイトを止めなかった理由や各社の技術的な判断の内訳まで外から推測して決めることはできません。「止まっていないから無対策」「止めたから劣っている」とは考えず、何を守るために、どんな対策をしていたかを確認する必要があります。
ログイン対策や WordPress の更新だけで防げなかった理由
今回の弱点は、WordPress のログイン画面のパスワードを当てられる、という種類のものではありません。PHP 開発元は、「構成によっては、WordPress などのアプリケーションの処理が始まる前に攻撃の影響が出る」と説明しています。
WordPress の中に入ってから働く対策だけで、その手前にある PHP 本体の問題にまで対応できるわけではないのです。
PHP の中で何が壊れていたのか、どんなサーバー構成で特に危ないのかといった技術的な内容はまた別の記事でご紹介いたします。ここでは、利用者として知っておきたいことだけお伝えしますね。
今回の脆弱性は２件とも危険度が最大10の評価で 9.2 の「Critical（緊急）」です。研究では、不正なプログラムを動かされるだけでなく、PHP 処理中のメモリーからパスワードなどの情報を読み取られる可能性も示されました。ファイルが書き換えられていなければ安心、とは言い切れないのです。
同じ弱点でも、検証環境によって結果に違いがありました
Wordfence から届いた警告では、同社が PHP と WordPress の検証環境で２件を調べた結果も案内されていました。以下に検証結果を説明した公式記事のリンクを置いておきます。
Wordfence が行なった検証では、CVE-2026-109619 について、特別に設定した環境ではコードの実行までできたものの、別の通常ビルドでは同じテストがクラッシュにとどまった、といった違いが報告されています。
簡単に言うと、「同じ弱点でも、検証環境によって、不正なプログラムを動かせた場合と、PHP が停止する結果にとどまった場合があった」ということです。止まるだけなら問題ない、という意味ではありません。
もう一方の CVE-2026-109618 では、未修正の PHP と修正後の PHP で挙動の違いを確認したものの、Wordfence の検証ではコード実行まではできなかった、とのこと。
大切なのは、「このテストでは再現できなかった」と「弱点がない」は同じ意味ではない、ということです。環境に合わせて攻撃方法が変わる可能性があり、未修正のサーバーをそのままにしてよい理由にはなりません。
一方で、弱点があるという情報を見ただけで、ご自身のサイトがすでに侵入されたと決めつける必要もありません。重要なのは、使っている環境に修正が入っているかを確かめ、サイトの状態をご自身で確認することです。
AI は、弱点を見つけて守る側でも使われています
今回、もう１つ知っておいていただきたいことがあります。
それは、「重大な弱点の発見にも AI が活躍している」という事実です。
OpenAI の公式説明によると、Calif の研究者が同社の AI を使って PHP の重大な弱点を発見しました。Wiz も、独自に同じ２件を見つけて報告しています。
OpenAI の把握では、攻撃者より先に発見したため、修正や防御の準備を進める時間を確保できた、とのこと。
ただし、「先に発見して準備できたこと」と、「修正版が届くまで一度も悪用されなかったこと」は別です。
今回の脆弱性に関していえば、公開前にも攻撃の試みが観測されました。修正を届ける途中で何が起きたのかは、次の章で詳しくお話しします。
ここで大切なのは、「弱点が見つかった」という知らせだけで、その仕組みを使うのをやめると決めないこと。
見落とされていた危険や深刻さが判明していなかった問題を見つけて調べ、確かめられたからこそ、守る側が対策を準備できた、という側面もあります。
見るべきは、問題を調査して修正する仕組みが動いているか。自分が使っているものに修正が届いているか。そして実際に適用されているか。
問題が見つかり、修正が届く仕組みが動いている。一方、開発が止まって修正を受け取れなかったり、更新を放置したりしていれば、弱点は残ったままです。
AI が進歩し、攻撃側の手が早くなり、巧妙になっていく。でも、攻撃側にとって便利になった AI は、これまで見つけにくかった弱点を早期に見つけ出し、修正につなげる取り組みにも有用です。
弱点を見つける作業が進めば、今まで知られていなかった問題も表に出てきます。ニュースで「脆弱性が見つかった」と聞く機会が増えることには、守る側が問題を見つけられるようになった面もあるわけです。
Wordfence の2026年4月の報告でも、同社に寄せられる脆弱性の報告で、研究者が AI を活用したと申告する割合が増えている、と説明されています。
少なくとも、脆弱性を調べる研究の現場で、AI の利用が広がっていることが分かります。
そして、研究者様だけでなく、修正する開発者様、利用者へ知らせる役割の方々がいらっしゃいます。
各種 SNS では、また「WordPress 使うのやめたほうがいい」ムーブが起こってましたね。笑
こういうことがあると、すぐ WordPress は叩かれる。
おもしろいな、と思って見ています。
WordPress には、世界中の開発者やセキュリティの専門家などが貢献しています。WordPress のセキュリティについての公式説明でも、問題の報告を受け、関係者が対応する仕組みが紹介されています。
WordPress は、プログラムの中身が公開されているオープンソースのソフトウェアです。開発元の中だけで完結せず、世界中の人がコードを確かめ、問題を報告し、改善に参加できる。この開かれた仕組みも、WordPress を、そして WordPress のセキュリティを支える力となっています。
PHP を支える人たちも、WordPress を守り、よりよくするために関わる人たちも。問題を見つけ、被害を防ぐために、たくさんの人が動いてくださっています。修正を受け取れることに、あらためて感謝したいと思います。
しかも WordPress は無料ですからね？！
無料なのにめちゃくちゃ手厚い✨
ただし、脆弱性を見つけただけで、世界中のサーバーが自動的に安全になるわけではありません。修正を作り、それぞれの環境で検証し、実際に動いているものへ適用するところまで進める必要があります。
AI が発見を助けてくれることと、そのサイトで安全に対応を進められること。その間にも、たくさんの仕事があるのです。
脆弱性のニュースが増えたことを、そのまま
- WordPress への AI 攻撃が増えた
- WordPress は危険
と決めつけて不安をあおる投稿は、ずいぶん乱暴な話です。弱点の発見が増えたという数字だけでは、攻撃や被害が増えたかどうかまでは分かりません。
AI の力は攻撃にも使われる。攻める側も、守る側も、進歩する。いたちごっこのような攻防は、間違いなくこれからも続きます。
新しい情報を知り、必要な対応をする。地道ですが、その積み重ねが、ますます大切になると私は思っています。
発見して終わりではなく、世界中へ修正を届ける対応だった
大きな問題だと聞いても、「自分のブログでは何も起きてない。いつもの更新と何が違うの？」と思われるかもしれません。
今回は、PHP を利用する多くのサービスで、修正版を待ち、公開後すぐに取り込めるよう準備する必要がありました。修正版を配付する側も、サーバー会社も、ウェブサービスの運営者も、それぞれに対応しなければならなかった。
OpenAI の説明では、同社は公開までの過去２か月にわたり、PHP の開発者、研究者、セキュリティ事業者らと対応を進めていたとのことです。修正を主導したのは PHP の開発側で、関連する組織が検証や準備、連絡調整を支えたとされています。
ホワイトハウスの関係組織などとの連携も、こうした広い範囲の対応の中で説明されています。世界中で使われる土台の問題では、一つの会社が直したら終わり、とはならないのですね。
ただ、経緯を調べてみると、「世界中が協力して、無事に修正版を届けられました」というきれいなお話だけでは終わりませんでした。公開資料を読んで、特に知っておいていただきたいと思ったのは、次の３つです。
- 脆弱性２件のうち１件（CVE-2026-109618）につながる問題の兆候は2024年の監査の対応中にも見つかっていたのに、悪用できることまでは確かめられず、修正の判断が止まっていたこと。PHP Foundation 自身が「構造的な失敗」と認めています。
- 公開の直前に情報が外に出て、予定が１日前倒しになったこと。さらに、決められた時刻より前に修正版を配った会社もあり、関係者の判断が分かれました。
- 修正版の公開より前の2026年10月17日付で攻撃の試みが観測されていたこと（AWS の報告）。ただし、その通信が実際のサイトへの侵入に成功したかどうかは、この報告だけでは分かりません。
その後、IPA の10月27日の追記では、今回の２件が、米国の CISA による「悪用が確認された脆弱性」の一覧に掲載されたことも案内されています。IPA の最新の案内も併せてご確認ください。
発見から公開までの日付、関係した会社それぞれの説明、まだ分かっていないことは、別の記事にくわしくまとめました。経緯を確かめたい方は、こちらをどうぞ。
PHP の重大な脆弱性、発見から公開までの経緯を記録しておきます
守ってくださった方への感謝と問題の振り返り
修正し、検証し、配付し、それぞれのサーバーへ適用してくださった皆さま。大きな混乱の中で、利用者への案内を続けてくださった皆さま。その仕事に、本当に感謝しています。
守ってくださった皆さんへの感謝と、問題を振り返ること。どちらも大切にしたいと思います。
「世界中が協力したから丸く収まった」としてしまうと、今回の問題から学べることを取りこぼしてしまいます。
PHP のセキュリティ担当者の説明でも、AI で問題の報告が増える一方、誤報や重複を確かめ、修正を判断する人の仕事が欠かせない、とされています。見つける力だけでなく、修正して届ける体制を支えることの重要性も見逃せません。
古い PHP まで対応する難しさ
今回、公式の新しい修正版が公開されたのは、8.2・8.3・8.4・8.5 の各系列だけです。それより古い PHP は、開発元の通常のサポートが終わっています。
7.4・8.0・8.1 には、緊急の最小限の修正の部品（ソースコードの修正分）が公開されました。ただし、7.3 以前に向けた修正コードは、PHP の開発元からは公開されていません。今後も古い版に修正が出るという約束もありません。
とはいえ、古いものをすべて新しい系列へ切り替えればよい、というほど簡単でもありません。古いプログラムやテーマ・プラグインの組み合わせでは、新しい PHP に切り替えた際に動かなくなる場合があるからです。
一方で、弱点を持ったまま使い続けることもできない。サーバー会社は、古い系列向けの修正を取り込んだり、自社で作って検証したりしながら、利用中のサイトへの影響も確かめる必要がありました。
この記事で確認した国内の大手レンタルサーバー各社は、古い版にも修正を適用したと案内しています。公式の通常サポートが終わった版まで対応してくださるのは、本当にありがたいことです。
心からの感謝と敬意を表します。
修正版が公開された瞬間に全社・全サーバーで同じように対応が終わるわけではありません。ご自身の契約先が、どの範囲まで、どういった方法で対応したのかを確認しましょうね。
今回の弱点は、WordPress やテーマ・プラグインを最新にしているサイトにも関係するものでした。そして今回は古い PHP まで直してもらえましたが、次も同じとは限りません。ロリポップやヘテムルも、この機会に PHP 8.2 以降へ切り替えるよう案内しています。
ところが、切り替えたくても、開発が止まったテーマやプラグインが新しい PHP に対応していないと、サイトが動かなくなることがあります。古い PHP から抜け出せない原因が、サイトの中にある場合もあるんです。
ヘテムルの案内でも、WordPress を使っている方に、テーマやプラグインの開発や更新が続いているかを確かめるよう書かれていました。
エックスサーバー・さくらのレンタルサーバ・ロリポップ・ConoHa WING などの対応状況
まずは、ご自身が契約しているサーバー会社の公式案内を確認してください。
ここでは、エックスサーバー・さくらのレンタルサーバ・ロリポップ・ConoHa WING の発表と、ヘテムルのサイト停止の経緯、海外の大手の対応をご紹介いたします（ロリポップと ConoHa WING は2026年10月23日朝、エックスサーバーは10月28日、さくらのレンタルサーバと海外の2社は10月29日に確認）。
※ 対応状況は更新されますので、リンク先の最新情報も併せてご確認ください。
エックスサーバー
お客様のサーバーを稼働させたまま安全対策を行い、10月26日6時20分までに、PHP 5.1〜8.5 の対象となるすべてのサーバーへの対応が完了した、と案内されました。
PHP 8.2〜8.5 は同じ系列の修正版に更新し、PHP 5.1〜8.1 は利用者が設定しているバージョンを変えずに修正パッチを適用したそうです。
今回の対策として、急いで PHP のバージョンを変更する必要はないとも説明されています。古い番号のままでも、慌てなくて大丈夫です。
ただし、XServer VPS などの VPS は対象外です。OS や PHP を利用者自身が管理するため、ご自身での更新が必要と案内されています。
今回の一時停止は主に公式サイトや管理画面など。ご利用サーバーのウェブサイト表示やメールソフトでの送受信には影響がないと説明されています。
さくらのレンタルサーバ
コントロールパネルで選べるすべての PHP（8.3／8.2／8.1／8.0／7.4／5.6／5.4／5.3／5.2）に対応済み、と案内しています。利用者が緊急にすることはない、とのこと。
PHP 8.1 以下はバックポート（修正を取り込む方法）で対応したため、バージョンの番号は変わっていません。バージョンだけで未対応と判断しないようご注意を。
ロリポップ
全バージョンの PHP に対して、公式の修正版や旧バージョン向けの修正を適用し、10月22日13時ごろ、お客様のサイト表示を再開したと案内しています。
公式の修正が出ていない PHP 5.3〜7.3 は、公式の修正内容をもとに自社で修正を作り、検証して適用した、とのこと。
修正が完了するまでの間、一部サーバーでサイトの表示を停止した経緯や、その判断の理由も説明されています。
また、今回の対策により、PHP の一部機能が無効になっています。再開後は、表示だけでなく、お問い合わせフォームやファイルのアップロードなどが正常に動くかどうかも確認するよう案内されています。
また、古い PHP を使い続ける場合の注意も喚起されているので、ご利用中の方はご確認くださいね。
ConoHa WING
10月22日20時45分に緊急メンテナンスを終了し、提供中のすべての PHP バージョン（5.6〜8.5）に修正パッチを適用した、と案内されています。
こちらは、PHP のバージョン番号を変えずに修正を取り込む方法です。サイトヘルスの画面で古い番号が表示されていても、それだけで未対応とは判断できません。
今回の件について、利用者自身が PHP のバージョンを変更する必要はない、とも説明されています。
ヘテムルの一時停止と「502」表示について
ヘテムルも、修正を適用するまでの間、一部サーバーで利用者のサイト表示を停止しました。公式の経緯報告では、緩和策だけで攻撃を完全に防げない可能性があり、サイトとデータの保護を優先したと説明しています。10月22日11時24分に、サイト表示を再開したとのことです。
サイトを１件ずつ見ていくより、すぐに守ることを優先してサーバー単位で止めたため、PHP を使っていないサイトなども表示できなくなっていたようです。止めることで守られる一方、影響が広くなる判断だったことも分かります。
主宰コミュニティにヘテムルをご利用中のメンバー様がいらっしゃり、「私のサイトが502となっていてアクセスできないんです。泣」とご相談いただきました。
いつも見えていた自分のサイトが、見慣れない英語と数字になる。状況がつかめなければ、不安だと思います。
502は、「HTTP ステータスコード」という、通信の結果を表す番号の一つです。「502 Bad Gateway」は、入り口で通信を中継するサーバーが、奥で処理するサーバーから正常な応答を受け取れなかったことを示します。
例えば、PHP を処理する仕組みの停止や障害などで、サーバー間の通信が正常に成立しない場合にも、この表示になることがあります。
ただし、502だけを見て、今回の対策のためなのか、別の障害なのか、侵入されたのかまで判断することはできません。
用語の詳しい説明は以下のページでご確認いただけます。
なお、ヘテムルは事前のお知らせに、「安全な運用に支障があると判断した場合、予告なく利用者のサイトを停止・制限する可能性がある」と記載していました。
「何の告知もなかった」とは言えません。それでも、そのお知らせに気づかないまま突然サイトが見えなくなれば、驚くと思います。
突然エラーが出ても、あわてて WordPress の設定を変えたり、プラグインを消したりしようとせず、まずは契約先の公式案内を確認してくださいね。
海外の大手レンタルサーバーの対応
海外の大手も少しチェックしてみました。
世界最大級の Hostinger（ホスティンガー）は、出回っていた攻撃を先にブロックしてから修正を適用し、日本時間の10月22日15時44分ごろ、VPS 以外のすべてのサーバーで適用を終えたと案内しています。
世界大手の GoDaddy（ゴーダディー）も、WordPress 向けの管理型ホスティング、通常のウェブホスティング、Windows ホスティングで、すべての PHP バージョンに修正を適用したと説明しています。併せて、PHP 8.1 以前は開発元の通常サポートが終わっているため、8.2 以降への切り替えを計画するよう勧めています。
いずれも、VPS は利用者自身での更新が必要です。
今回紹介した各社では、事業者が PHP を管理するプランは事業者が修正し、利用者自身が管理する VPS は利用者が更新する、という対応でした。
使っているサーバーのお知らせを一度 見ておくと安心ですね。
会社ごとに、同じ言葉で「メンテナンス」と案内していても、止めた機能や、修正の適用方法、利用者に確認してほしいことは同じではありません。ご自身の契約先の説明を読むことが大切です。
公式案内を見るときは、「対応済み」という言葉だけで安心せず、対象の PHP、停止・再開した機能、利用者へのお願い、ここまで読んでみてください。
例えば、サイトが表示できるようになっていても、管理画面のすべての機能が戻っていない場合もあります。フォームやアップロードなど、普段使っている機能への影響も見ておくことが、事業用サイトでは特に重要です。
PHP の更新や復旧に関する案内はサーバー会社へ、WordPress 内の構成や更新後の動作確認は普段の保守担当者へ、というように、確認先も、内容に合わせて考えてみてください。
緊急時にこそサービスの質が見えると感じた
今回、私がとても心強く感じたのは、エックスサーバーさんの情報の出し方でした。
ピカイチでしたね✨
- 今、何が起きているのか。
- 何を止めていて、どこまで対応が進んでいるのか。
- これから何をするのか。
- 次の情報を、いつ、どこで確認できるのか。
当夜の特設ページでは「おおむね2時間ごとに進捗を報告する」という案内があり、過去のお知らせも追えるようになっていました。
私は当夜、サーバー会社の動向を見ながら、お預かりしているサイトの確認をしていました。次の報告の見通しが分かるだけでも、待っている間の不安は違います。
「この時間になったらこのページを確認する」という、ある程度の見通しが立っていること。以前のお知らせが残されていて、経過や進捗を追えること。作業が終わっていなくても、その説明があることで、こちらも次の判断がしやすくなります。
利用者が何度も画面を開き直して、何も変わっていないお知らせを見つめている。その状態が続くのは、なかなか不安です。
緊急時の情報の出し方も、サービスの大切な一部なんですよね。
私が見ていた中では、エックスサーバーさんの対応はピカイチだったな～と！
一方で、最初の「メンテナンスを行います」という案内から、続報がなかなか出ないと、
今いったいどうなってるんだろ･･･？
何かしたほうがいいのか、黙って待ってれば大丈夫なのか、不安になりますね。
利用者に個別のメールが届いている場合もあるでしょうし、公開されている画面だけで、裏側の作業の良し悪しまで決めることはできません。
とはいえ、状況が分かる説明があるかどうかで、信頼は大きく変わります。
深夜にも早朝にも更新される情報を見て、担当の皆さん、眠れているんだろうか･･･と心配せずにはいられませんでした。私自身も、睡眠時間を削りながら、各社の動向とクライアント様のサイトの状態を追ってました。
普段は見えにくい仕事です。けれど、こういうときにこそ、誰がどう見ていてくれるか、どんな説明をしてくれるかが分かる。緊急時にこそサービスの質が問われるな、と感じました。
10月19日のゼロリスの件は、別の記事にまとめました
PHP の問題の少し前、10月19日には、私がお預かりしているゼロリスの会員サイトでもセキュリティインシデントがありました。こちらは外部管理サービス経由の不審なプラグイン設置を調べた、別の事件です。今回の PHP の脆弱性と、原因や対策を混ぜずにお伝えしたいので、別記事にしました。
WordPress の外部連携から受ける影響や、オーナーが AI で対応を試みた経緯、現場で判断する仕事については、こちらをお読みください。
ゼロリスの会員サイトで起きたインシデント－WordPress の外側にも目を向ける理由
今、ご自身のブログで確認していただきたいこと
「普通に見えているから大丈夫」と安心する前に、まずはサーバー会社の公式案内で、今回の対策がどうなっているかを確認してください。すでに保守をお願いしている方は、担当の方に尋ねてみてくださいね。
今お使いの PHP のバージョンは、WordPress の管理画面で確認できます。
- ダッシュボード →「ツール」→「サイトヘルス」を開く
- 「情報」タブを開く
- 「サーバー」の項目を開く
- 「PHP バージョン」を確認する
PHP 公式が今回 公開した修正版は、8.2.35／8.3.36／8.4.27／8.5.12 です。同じ系列では、これら以降の修正版が目安になります。
10月23日には、PHP公式から、特定の設定とプログラムの組み合わせで起こり得る別の問題（CVE-2026-115560）についても追加案内が出ています。
上記の２件に対応したバージョンだということのみで、この追加案内まで対応済みとは判断できません。PHP公式の追加案内と、契約先の最新情報も合わせて確認してください。
ただし、ConoHa WING のように、番号を変えずに修正を適用するサーバーもあります。
mixhost も同様の方法で対応したと案内しています。
数字だけで判断せず、サーバー会社の説明とセットで確認してください。よく分からないまま設定を変えるのではなく、まずは確認。あるいは有識者に相談。
ここは少し分かりにくいですね。
例えば PHP 8.3 系なら、今回の公式修正版は 8.3.36 ですが、事業者が修正を取り込んでいる場合は、それより前の番号のままでも、今回の２件に対応していることがあります。
反対に、「8.3だから新しそう」という系列だけの確認では、修正が入ったかどうかは分かりません。
「自分のバージョンは何か」「契約先はその環境にどう対応したと説明しているか」を併せて確認する必要があります。
また、今回の修正が入ったからといって、古い PHP をこれから先も使い続けてよい、というわけではありません。今回の対策を確認した後、普段の更新や、サポートが続いている系列への移行をどうするかも、落ち着いて相談しておきたいところです。
対応可能です。
ご相談くださいな。
この機会に、ご自身のサイトの健康状態を見直されるようおすすめいたします。
- WordPress・テーマ・プラグインの更新を長く放置していないか
- 使わなくなった WordPress や、役目を終えたデータベースがサーバーに残っていないか
- 覚えのないユーザーや、いつの間にか追加されたテーマ・プラグインがないか
- サイトの表示や、お問い合わせ・予約など大切な機能に異常がないか
- バックアップが定期的に取れていて、必要なときに戻せるようになっているか
- 不審な変化が起きたときに、確認できる記録が残る状態になっているか
見慣れないものがあっても、すぐに削除するのは待って。本当に必要かどうかを確認したり、調査のために記録を残したりしたのちに対応を決めます。
PHP の対応確認とサイトの中の点検は別モノ
ここまでの話をご自身のサイトに置き換えて考えるときは、次の３つを確かめてみてください。
【１】これから同じ弱点を悪用されない状態になっているか
今回なら、実際に使っている PHP に必要な修正が適用されているか、まずは確認。
サーバー会社や環境の管理者の対応情報が重要です。
【２】サイトに不正な変更などの気になる痕跡がないか
意図しないユーザーやプラグインが追加されていないか。ファイルに不審な変更がないか。ログに気になる操作がないか。こちらは、現在のサイトや残っている記録を見ていく確認です。
弱点を塞ぐ修正は、すでに行われた操作を自動的に取り消してくれるものではありません。サイトの中を確認すべき理由はここにあります。
サイトの中を確かめるとき、手がかりになるのがバックアップです。今のデータを見れば、不正なプログラムや改ざんが今も残っていないかを調べられます。以前のデータと比べれば、どのファイルや設定が、バックアップを取った間に変わったのかを追う手がかりになります。
今のデータだけでは、過去に入り込まれて、何も残さず消されたケースまでは確かめられません。
10月21日は脆弱性の公表日ですが、AWS は10月17日に攻撃の試みを観測したと報告しています。「21日より前のバックアップなら安全」とは決められません。17日より前なら安全、という境目でもありません。
バックアップは、保存件数や保存期間の設定によって、古いものから消えていきます。いつの分が残っているかを今のうちに確かめて、必要な分は手元に保存しておいてください。
【３】普段のサービスを続けられる状態か
サイトが表示できるか、お問い合わせや予約などが使えるか、バックアップが取れているか。修正の適用状況とは別に、運用を続けるために確認すべきことがあります。
この３つを一緒にして「見えているから全部大丈夫」「修正済みだから、ほかもすべて確認済み」としないこと。
ご自身で見るときにも、誰かに任せるときにも、この３つを１つずつ見ていくと、今どうなっているのかがつかみやすくなります。
ログがないことだけで、何もなかったとは言えません
ログは、どの記録が、いつからいつまで残っているかによって、判ることが変わります。保存されていない期間や、そもそも記録していない操作まで、後から確認できるわけではありません。
また、悪いことをしようとした通信の記録があっても、それだけで侵入が成功したとは限りません。防御で止められた記録なのか、実際にログインやファイルの変更があったのかを、ほかの情報と合わせて見ます。
反対に、記録が見つからなかったからといって、過去に何も起きていないと保証することもできません。
点検する際は、
- どの期間の何を確認したか
- その範囲で何が見つかったか
- 分からない部分は何か
これらを明確にお伝えすることも大切にしています。
「脱 WordPress」と、不安だけで決める前に
今回の PHP の問題をきっかけに、WordPress から別の仕組みへの移行を勧める SNS の投稿が山ほど。
「私の WordPress も危ないの？」「今すぐやめたほうがいい？」と、不安を煽られたのではないかしら、と感じています。
今回の PHP の脆弱性は本当に怖いもの。
軽く扱ってよいものではありません。
ただ、PHP に重大な弱点があったことから、すべての WordPress 利用者は別のサービスへの移行を検討すべき、というのは暴論だな、と感じています。
AWS の10月21日の報告では、公表後に攻撃の試みが広く見られるようになったとしています。ここでいうのは「攻撃の試み」のことで、「実際に侵入されたサイトが多数ある」と発表したわけではありません。AWS は、観測した攻撃が実際の環境で成功したかどうかは不明だと説明しています。
PHP を使わない仕組みも比較して選ぶもの
投稿で移行先として紹介されていた EmDash は、PHP ではなく TypeScript を使い、プラグインを隔離して動かす設計になっています。こうした仕組みの違いは、比較するときに大切な点です。
PHP を使わない部分なら、今回の PHP 本体の弱点の対象にはなりません。けれど、だからといって、今後セキュリティ上の問題が起きない保証はありません。
移行が合うサイトもあるでしょう。使いたい機能、更新する人にとっての使いやすさ、移行と運用の費用、バックアップや障害時の対応まで含め、ご自身に合うものを比較して選ぶ必要があるかなと思います。
しかし比較・判断が非常に難しい･･･。
WordPress を続けるにしても、他へ移るにしても、自分のサイトを守る仕事は続きます。
声の大きい見知らぬ人の意見に右往左往させられないようご注意くださいね。
【注意喚起】点検を勧めてくる営業は根拠の確認を
以前、WordPress の無料点検の営業を受けた方から、「この説明を信用してお願いしてよいのだろうか」という相談を受けたことがあります。
今回の PHP の一件より前のお話ですが、このたびの PHP の脆弱性ニュースで、その営業をかけてきた方がまた動き始めるんじゃないかな～と心配しています。
営業の内容は、
- AI がこっそり侵入し、痕跡を残さず去っていく
- こうしたことが今年の６月から急増している
といった話を組み合わせ、WordPress の無料点検を勧めるものでした。
怖い言葉が並ぶと、「今すぐ見てもらわなくちゃ」と思わされるかもしれません。詳しくない方なら、なおさらです。
「AI を使った攻撃だった」と、何をもとに判断したのか。「６月から急増した」という話は、誰が、何を調べて発表したのか。まずは、そこを確かめたいですね。
それに、そもそも「AI による攻撃」って、どうやって確かめたんでしょう？
AI を使ったかどうかを確かめるには、攻撃者側の記録など、アクセスログ以外の根拠も必要です。
被害サイトの通常のアクセスログだけで、「AI を使った攻撃だった」と断定することは、できないと言っていい。情報を盗んで目立つ痕跡を残さない、という動きは、従来のプログラムでもできます。
「サイバー攻撃が増えた」
「WordPress への自動攻撃が増えた」
「AI を悪用する攻撃者が増えている」
といった話をくっつけても、「６月から、痕跡を残さない AI の侵入が急増」という説明の裏付けにはなりません。
Wordfence などの「AI を利用した脆弱性研究の報告が増えた」というデータも、被害サイトへの AI 攻撃が急増したことを示す数字ではありません。
メルマガではもっと詳しく発信する予定です。
私には、その人がどんな意図で案内したかまでは分かりません。
けれど、別々の事象を交ぜた説明を本気で正しいと思っているなら、サイトを預かる者としての知識レベルに強い疑問を感じます。
分かった上で怖がらせて申し込ませようとしているなら、それもそれで大問題。非常に悪質です。
無料か有料かより、何をどう調べるかを聞いてみてください
こういう大きな出来事があると、不安に乗じた案内が届くこともあると思います。
無料だから危険、有料だから安心、ということではありません。まず、次のことを聞いてみてください。
- その説明の根拠になる公式情報や調査報告はどこにあるのか
- 自分のサイトの何をどの期間の記録で調べるのか
- 調べて判ること、分からないこと
- 誰がどの権限でサイトやサーバーに入るのか
- 点検の結果、修復が必要になった場合の費用や追加作業をどう決めるのか
説明を聞いても分からないときは、その場で決めないで。今回の相談者様のように、別の専門家に説明を見てもらうという方法もあります。
私にご相談いただく場合も、同じです。何を調べ、どこまで判るのか。分からないことは何か。そこをご説明した上で、必要な対応を一緒に考えたいと思っています。
通常は自分でメンテナンス。難しいところはプロに任せる
今回の PHP 本体の問題は、多くのレンタルサーバー利用者にとって、自分で修正できるものではありませんでした。
それでも、普段からできる備えはあります。
いつもの状態を知っていれば、異変に気づくのも早い。構成や設定を把握していれば、確認も復旧も進めやすい。使えるバックアップがあれば、復元という選択肢を持てます。
例えば、普段は誰が管理画面を使っているか、どんなプラグインを入れているか、外部のどのサービスとつないでいるか。そうしたことが分かっていれば、いつもと違うものを見つけるスピードも、見つけたときの確認も、迅速です。
バックアップも、「取ってある（つもり）」で終わらせず、それがどこに保存されていて、どの範囲を戻せるのか、そこまで把握しておきたいところです。問題が起きた後に取ったバックアップでは、問題が起きる前の状態に戻せません。
サイトを公開したときからのことを知っている担当者と、初めて見るサイトを緊急に引き受ける担当者では、最初に必要な確認も変わります。日ごろから見ていることは、更新する作業だけでなく、いざというときの判断を支える備えにもなるのです。
家が火事になってから入れる保険はありません。備えあれば憂いなし。
保守をご契約いただき、信じてお任せくださっているクライアント様のサイトは全力でお守りします。
お任せいただいているからこそ、普段からサイトの状態を把握し、こうした有事の際には動向を見守り、必要な確認をする。それが私の仕事です。
そして同時に、【ブログの学び舎ふくろう】では、「月額保守を解約できる」をミッションにしています。
必要な知識を身につけ、自分のサイトの状態を知り、自分でお手入れができるようになる。月に１回、一緒に確認する「月イチWP メンテ部」も、そのために開催しています。
自分の WordPress サイトを普段から把握し、自分で守る。その力をつけていただきたいと思っています。
自分ではそこまでできない。時間が取れない。見方はわかるがどう判断してよいか分からない。そんな場合はお任せください。そのために私たちプロがいます。
自分で守っていきたい方を支えることも、安心して任せたい方のサイトをお預かりすることも、私にとってはどちらも大切な仕事です。
三度のゴハンより WordPress が好き。
だから、WordPress に泣く人を見たくないのです。
「一度、今の状態を見てほしい」という方へ
- しばらく中を見てないので、ここらで一度、確認しておきたい。
- 気になることはあるけど、自分では判断できない。
- 真実を知るのが怖くて後回しにしてきたが、今回の騒動を受けて、にわかに不安になった。そろそろ重い腰を上げようかな･･･。
そんな方は、WordPress とサーバーの点検をご相談いただけます。
今回ご案内している点検は、普段の「WordPressの健康診断」や、いま開発中の簡易点検プラグインとは別で、私が個別に中を確認するものです。
WordPress の更新・設定・ユーザー・テーマ・プラグインの状態に加え、サーバーの内部とデータベース、ログもつぶさに観察し、不審な痕跡がないかを確認します。
普段の「WordPressの健康診断」では、更新や設定など、これからの運用のために状態を整える確認が中心。今回は、それに加え、改ざんや意図しないプログラムの設置などが行われた痕跡がないかも、残された記録と照らし合わせて見ていきます。
レンタルサーバーでは、利用者から見られるところとサーバー会社に確認しなければ分からない領域があります。その判断も明確にします。
たくさんの情報を確認するため、もちろん AI の力も借ります。ただ、AI の回答だけで「問題なし」と決めるのではなく、記録の時刻や内容、サイトの構成、実際のファイルやデータベースと照らし合わせて私が判断します。
確認できる範囲は、残っている記録の期間や内容によって変わります。「過去の被害が一切なかった」と保証するものではありませんが、どこまで分かったか、何が気になるかを、分かる言葉でお伝えします。
サーバー移転を検討されるに至った方も、お声がけください。
メルマガを読んでくださっている方は、メールにご返信いただくと私に届きます。「WordPress の点検をお願いしたい」とお知らせください。
大切なブログを、安心して続けていくために。今回を、ご自身のサイトを見直すきっかけにしていただけたらと思います。
