ブログのセキュリティを強化したら、今度は自動投稿の仕組みが止まってしまいました。
一つ直したら、別のところに問題が出る。
まるでピタゴラスイッチです。
きっかけは、2026年10月にニュースになったPHPの深刻な脆弱性でした。
サーバー会社が管理画面へのアクセスを一時停止するほどの問題だったので、自分のブログは大丈夫なのかと気になったんです。
それからサーバーの状態を確認し、WordPressのセキュリティを点検。Wordfenceというプラグインを導入したところまではよかったのですが、その後、思わぬところでトラブルが発生しました。
今回は、そのときに何が起きて、どうやって復旧したのかを記録しておきます。
PHPの問題って、そもそも何が危ないの？
まず、今回のニュースに出てきた「PHP」について、少しだけ説明しておきます。
ホームページやブログを作るとき、よく使われているのが「WordPress（ワードプレス）」という仕組みです。
例えば、ホームページをレストランに置き換えて考えてみましょう。
お店には入口のドアや窓、テーブル、椅子、カウンターなど、お客さんを迎えるための設備がありますよね。メニューを並べたり、注文を管理したりする仕組みも必要です。
WordPressは、こうしたお店の設備や運営の仕組みをまとめて用意してくれるようなものです。
では、PHPは何をしているのでしょう？
こちらは、厨房で実際に働くスタッフのような存在です。
お客さんが料理を注文すると、厨房ではスタッフが必要な材料を取り出し、料理を仕上げます。
ホームページも似ています。
誰かが記事を開くと、PHPが裏側で働き、WordPressに保存されている文章や画像などを組み合わせて、ページを表示するための処理を進めます。
つまり、WordPressがお店を運営する仕組みなら、PHPはそのお店を裏側で動かしているスタッフというわけです。
今回見つかったのは、厨房の後片付けに似た問題
今回のPHPには、外部から細工された情報が送られたとき、処理の途中で不具合が起こる弱点が見つかりました。
例えば、厨房のスタッフに大量の材料と注文書が届いたとします。
作業台はいっぱいになり、とうとう仕事を続けられなくなってしまいました。
そこでスタッフは作業を中断しますが、困ったことに、途中まで使っていた材料や注文書がきちんと片付けられません。
その混乱を悪用されると、本来は受け付けてはいけない指示まで実行してしまうおそれがあります。
今回公表された脆弱性の一つは、こうした状況に似た、メモリ不足時の処理に関する不具合でした。
単にホームページの表示が遅くなるという話ではありません。悪用されれば、外部から不正なプログラムを実行される危険性もある、深刻な問題です。
※これは仕組みをイメージしやすくするための例えです。実際にはPHP内部のメモリ管理に関係する問題で、今回の脆弱性は2件公表されています。
エックスサーバーの管理画面が一時停止。PHPは自動で修正されていた
今回の問題に対して、私が利用しているエックスサーバーでは、修正版が公開される前から予防的な対策が取られていました。
2026年10月21日16時には、サーバーパネルなどの管理画面へのアクセスを一時停止。
その日の夜にPHPの修正版が公開され、翌22日にエックスサーバー側で順次修正が適用されました。
ここは誤解されやすいところですが、私がPHPを手動でアップデートしたわけではありません。
レンタルサーバー側で対策が進められていたんです。
なお、管理画面は一時的に利用できなくなっていましたが、通常のWebサイト表示は継続していたとのことです。
翌日以降、WordPressの「サイトヘルス」で稼働中のPHPバージョンを確認すると、表示されていたのは「PHP 8.3.36」。
今回の問題に対応した修正版でした。
ひとまずPHPの修正は確認できましたが、せっかくの機会なので、サイトの状態ももう少し調べてみることにしました。
アクセスログにも気になる数字が
実は、この前後にサーバーのアクセスログを調べていて、気になる記録が見つかっていました。
ある日のアクセス記録は43万件以上。
しかも、その大部分がサイトマップに関係するURLへのアクセスだったんです。
サイトマップは、検索エンジンなどにサイトのページ構成を知らせるためのものです。
アクセスログを詳しく見ると、通常の読者が記事を読んでいる様子とは違い、特定のプログラムが大量に巡回しているようでした。
もちろん、大量アクセスがあったからといって、すぐに不正アクセスと決めつけることはできません。
今回のPHPの脆弱性を狙った攻撃だったという証拠もありません。
ただ、普段あまり意識していなかったサーバーの裏側を見てみると、思っていた以上にいろいろなアクセスがあるものです。
そこで、サーバー側の対策を確認するとともに、WordPressの内部も点検してみることにしました。
Wordfenceでセキュリティを点検。ところが…
WordPressのセキュリティ対策として導入したのが、Wordfenceです。
不審なアクセスへの対策や、WordPressのファイルに問題がないかを調べるスキャン機能などを備えたプラグインです。
インストール後、設定やスキャン結果を確認していきました。
途中、使っているプラグインやスキャン対象に関する警告も表示されましたが、確認できた範囲では、サイトの改ざんを示す結果は見つかりませんでした。
これで少し安心。
ところが、その後に思わぬ問題が起きます。
Zapierから、WordPressとの接続に問題が発生したという通知が届いたんです。
Zapierは、異なるサービス同士をつないで、作業を自動化できるサービスです。
私のブログでは、WordPressの記事公開をきっかけに、Bufferなどを通じてSNSに投稿する仕組みを使っています。
普段は裏側で動いてくれているので、毎回手作業で投稿する必要がありません。
ところが、Zapierの管理画面でWordPressとの接続を確認すると、状態は「Expired」。
接続が切れていました。
PHPの修正を確認して、WordPressのセキュリティも強化したはずなのに、今度は自動化が止まるとは。
なかなか一筋縄ではいきません。
原因はWordfenceの設定？アプリケーションパスワードを確認
まず、Zapierの再接続画面を開いてみました。
WordPressのURLやユーザー名、パスワードを入力する画面が表示されます。
ただ、そこでむやみに設定をやり直す前に、WordPress側の認証情報も調べてみることにしました。
すると、ユーザープロフィール画面で、気になる表示が見つかりました。
アプリケーションパスワードがWordfenceによって無効化されているという内容です。
アプリケーションパスワードとは、Zapierのような外部サービスがWordPressに接続するために使える、専用のパスワードです。
通常のログイン用パスワードとは別に管理できます。
レストランの例えに戻ると、Zapierは外部から注文や連絡を届けてくれるスタッフのようなもの。
ところが、お店の警備を強化したことで、そのスタッフが使っていた専用の通行証まで無効になってしまった。
そんな状態に近かったようです。
Wordfenceの設定画面を確認すると、「WordPress アプリケーションパスワードの無効化」という項目にチェックが入っていました。
そこで、このチェックを外して設定を調整。
その後、WordPressのプロフィール画面にはアプリケーションパスワードの欄が再び表示され、以前から使用していたZapier用の登録も確認できました。
そしてZapier側の接続状態を確認すると、表示は「Connected」に戻っていました。
無事、WordPressとの接続が復旧したわけです。
今回は新しいアプリケーションパスワードを発行して解決したのではなく、Wordfence側で無効になっていた機能を使える状態に戻したことが、復旧につながったと考えられます。
なお、接続が復旧したことと、停止中のすべてのタスクが正常に再実行されたことは別です。
そのため、Zapの有効状態や実行履歴、保留中のタスクについても確認しました。
自動投稿の場合、何も考えずにまとめて再実行すると、重複投稿になる可能性もあります。
復旧したからといって、すぐに全部動かせばいいわけでもないんですね。
セキュリティ対策は、強くすればそれで終わりではない
今回の一連の作業を振り返ると、ちょっとしたピタゴラスイッチのようでした。
PHPの問題が気になってサーバーを確認する。
アクセスログを調べ、WordPressのセキュリティも点検する。
Wordfenceを導入して対策を強化したら、今度はZapierとの接続が切れる。
原因を探して設定を調整し、ようやく元の状態に戻る。
一つの問題を解決すると、別の仕組みに影響が出ることもあるんですね。
ただ、だからといってセキュリティ対策をしないほうがよい、という話ではありません。
Wordfenceがアプリケーションパスワードを無効にできるのにも理由があります。
使っていない外部連携の入口を閉じておけば、それだけ不必要なアクセス経路を減らせるからです。
一方で、Zapierのように外部連携を利用している場合は、その入口が必要になります。
大切なのは、何を守るための設定なのか、そして自分のサイトでは何が必要なのかを理解しておくこと。
今回のトラブルで、そこを改めて実感しました。
画面の向こう側で、誰かが復旧に奮闘している
今回のPHP問題では、大企業のWebサイトや飲食店のアプリ、行政機関のサービスなど、私たちの身近なところでも一時停止や緊急メンテナンスが相次ぎました。
普段使っているサービスが突然利用できなくなったり、なかなか復旧しなかったりすると、「まだ使えないの？」と思うこともありますよね。
私も利用する側なら、きっとそう思います。
でも、今回、自分のブログを点検していて、少し見方が変わりました。
小さなブログ一つでも、セキュリティの設定を変えたことで、思わぬ外部サービスとの連携が止まってしまったんです。
これが何万人、何百万人もの人が利用するサービスだったら、どうでしょう。
安全性を確認し、修正プログラムを適用し、正常に動くかをテストする。必要なら関連する仕組みも一つずつ確認していく。
単にプログラムを修正すれば終わり、というわけにはいかないはずです。
もちろん、今回停止したサービスのすべてで、私と同じような連鎖トラブルが起きていたわけではありません。
それでも、表からは見えないところで、
「あっちを直したら、今度はこっちが動かない！」
そんな事態に頭を抱えながら、一つずつ正常な状態へ戻そうとしている人たちもいるんだろうな、と想像するようになりました。
サービスを待つ側の不便さがなくなるわけではないけれど、そこには安全性を確かめながら復旧を進めるという、簡単には省略できない作業もあります。
ここまで読んでくださった方も、今度どこかのホームページやアプリで「メンテナンス中」という表示を見かけたら、少しだけ思い浮かべてみてください。
その画面の向こう側では、サービスを正常に戻すために、あくせく奮闘している人がいるのかもしれません。
今回のピタゴラスイッチ騒動で、私がいちばん実感したことは、案外そこだったような気がします。
