PHP脆弱性対策：WordPressサイトのセキュリティ対策と一般公開再開までの記録

人工知能

はじめに

2026年10月、PHPに関するセキュリティ情報をきっかけに、私が運営する個人サイト「AIオトコの娘宝典」(https://wing-sky-nine.com/)のサーバー環境とWordPressのセキュリティ設定を見直しました。

当初はPHPのバージョンを確認して更新する程度の作業を考えていましたが、実際にはWordPress本体、プラグイン、テーマの更新から、バックアップ、パスワードの変更、アクセス制限、セキュリティ診断まで、かなり大がかりなメンテナンスになりました。

今回の記事では、実際に取り組んだセキュリティ対策と、その過程で発生した問題、学んだことをまとめます。

なお、今回の作業は脆弱性情報を受けた予防的な対策と環境の見直しです。サイトが実際に不正侵入を受けていたと確認されたわけではありません。

現在のPHPがサポート終了していた

最初に確認したのは、サーバーで使用しているPHPのバージョンです。

PHPは、WordPressを動かすためのプログラミング言語です。WordPress本体やプラグインの多くはPHPで記述されているため、PHPの安全性はWebサイト全体の安全性に関わります。

調べたところ、私のサイトではPHPはかなり前のバージョンを使用して更新せずに放置していました。しかも公式サポートが終了しています。サポートが終了したバージョンには、原則として新たなセキュリティ修正が提供されません。

つまり、サーバーで動いているからといって、安全に使い続けられるとは限らないということです。

そこで、PHPを推奨されているバージョンへ更新することにしました。

今回の作業で最初に学んだのは、サイトの安全性を維持するには、WordPress本体だけでなく、その下で動くPHPなどのソフトウェアにも目を向ける必要があるということでした。

更新作業のため、サイトを一時的に非公開にする

次に、メンテナンス中に一般の訪問者がサイトへアクセスしないよう、一時的なアクセス制限を行いました。

最初はサーバー側の設定でアクセスを遮断し、その後、Basic認証を使用する方法に切り替えました。

Basic認証とは、Webページを表示する前にユーザー名とパスワードの入力を要求する認証方式です。サイトの更新や動作確認の際に、一般の訪問者によるアクセスを制限しながら管理者が作業するために利用できます。

ただし、Basic認証は万能な防御策ではなく、通信自体を暗号化するHTTPSの代わりにもなりません。

サイト全体にBasic認証を設定すると、外部サービスからのアクセスも制限されることがあります。この点は後のサイトヘルス診断で実際に問題となりました。

WebファイルとMySQLデータベースをバックアップする

WordPressの更新作業には、バックアップが欠かせません。

WordPressのサイトは、大きく分けて次の二つから構成されています。

Webファイル：WordPress本体、プラグイン、テーマ、画像など

データベース：投稿記事、ユーザー情報、設定、コメントなど

どちらか一方だけを保存しても、元のサイトを完全に復元できるとは限りません。

そこで今回は、サーバーのバックアップ機能やファイル転送ソフトなどを利用して、WebファイルとMySQLデータベースの保存状況を確認しました。

バックアップ処理は、開始しただけで安心してはいけません。処理が完了していること、必要なデータが含まれていること、復元可能な形式であることを確認する必要があります。

バックアップには記事や設定だけでなく、個人情報や認証情報が含まれる場合もあります。そのため、バックアップファイル自体も適切に保護する必要があります。

PHP、WordPress、プラグインを更新する

バックアップやアクセス制限の準備を進めたうえで、PHPとWordPressの更新に取り組みました。

PHPを推奨バージョンへ更新し、WordPress本体も更新しました。続いて、インストール済みのプラグインを確認し、更新可能なものをアップデートしました。

WordPressには多くのプラグインがあります。お問い合わせフォーム、SEO、画像最適化、アクセス解析、セキュリティ対策など、さまざまな機能を簡単に追加できるのが魅力です。

一方で、プラグインもプログラムである以上、脆弱性が発見されたり、新しいPHPとの互換性に問題が生じたりすることがあります。

PHPを更新したことで警告が発生

PHPの更新後、一部のプラグインの古いコードに由来する警告が表示されました。具体的には、PHPの特殊なメソッドに関する警告です。

PHPはバージョンアップによって仕様やエラーの扱いが変化することがあります。そのため、古いPHPを前提に作られたプラグインが、新しいPHPでは警告を出す場合があります。

この問題は、該当するプラグインを更新することで解消しました。

警告が表示されたからといって、直ちに不正アクセスやマルウェア感染が発生しているとは限りません。エラーの原因を調べ、プラグインの更新状況や互換性を確認することが大切です。

PHPに加え、WordPress本体とプラグインも、互換性を考慮しながら更新する必要があると感じました。

Cocoonテーマも更新する

WordPressでは、テーマによってサイトのデザインや表示機能が構成されています。

私のサイトでは、日本製のWordPressテーマ「Cocoon」を使用しています。今回はCocoonも更新しました。

WordPressのテーマは、単に色やデザインを設定するだけのものではありません。PHPを使用した表示処理や各種機能を持つこともあるため、テーマ側のメンテナンスも必要です。

更新の際には、親テーマと子テーマの関係や、独自に行ったカスタマイズへの影響にも注意しました。

プラグインだけでなく、テーマについても適切に管理することが、WordPressサイトを長期的に運営するうえで重要です。

サーバーとWordPressの認証情報を見直す

ソフトウェアの更新に続いて、認証情報の見直しを行いました。

WordPressを運営する際には、管理画面のログイン情報だけでなく、サーバー管理、FTP接続、データベース接続など、複数の認証情報を使用します。

これらはそれぞれ異なる役割を持っています。例えば、WordPress管理画面のパスワードを変更しても、サーバーやFTPのパスワードが自動的に変更されるわけではありません。

そこで、認証情報の変更や管理方法の確認を進めました。

データベース接続用のパスワードを変更する際は、WordPress側の接続設定との整合性にも注意が必要です。認証情報の取り扱いを間違えると、セキュリティ上の問題だけでなく、サイト自体がデータベースに接続できなくなることもあります。

今回の作業で、こうした仕組みについても改めて理解を深めました。

WAFやログイン保護などの設定を確認する

続いて、サーバーとWordPressのセキュリティ設定を見直しました。特に確認したのが、WAF（Web Application Firewall）です。

WAFは、WebサイトへのHTTPリクエストを検査し、SQLインジェクションやクロスサイトスクリプティング（XSS）など、特定の攻撃を検知・遮断するための仕組みです。

一般的なファイアウォールとは異なり、Webアプリケーションへの攻撃を対象にしている点が特徴です。

ただし、WAFが有効でも、すべての攻撃を防げるわけではありません。正常な通信を誤って遮断する場合もあるため、設定後にはサイトの動作確認も必要です。

このほか、WordPressの管理者アカウント、ログイン履歴、ログイン試行制限、サーバー内の不審なファイルなどについても確認を進めました。

ここで重要なのは、古いソフトウェアの更新と、不正アクセスの痕跡調査は別の作業であるという点です。

WordPressやPHPを最新版にしても、それだけで過去の改ざんや不正ファイルの存在が否定されるわけではありません。

逆に、エラーや警告が出ているというだけで、必ずしも侵入が発生したとはいえません。

セキュリティ対策では、確認できた事実と推測を区別することが大切だと感じました。

サイトヘルス診断で分かったこと

WordPressには、システムの状態を調べる「サイトヘルス」という機能があります。

管理画面の「ツール」から利用でき、WordPressやPHPのバージョン、更新状況、サーバーの構成、外部との通信などについて診断できます。

今回も、更新作業の終盤にサイトヘルスを利用しました。多くの項目が正常と判定された一方、いくつかの警告や改善提案も表示されました。

Basic認証が外部サービスの通信に影響

特に印象的だったのは、WordPress.comとの接続に関するHTTP 401エラーです。

HTTP 401は、認証情報がない、または適切でないためにリクエストが拒否されたことを示すステータスコードです。

今回はメンテナンス用に導入したBasic認証が、外部サービスとの通信を妨げていた可能性が高いと考えられました。

これは、メンテナンス中のサイトでは起こり得る現象です。

ただし、HTTP 401エラーの原因はBasic認証だけとは限りません。セキュリティプラグインやサーバー側の制限など、ほかの原因も考えられます。

今回の経験から、サイトヘルスの結果は単純に警告の数だけで判断するのではなく、その時点でのサイトの運用状態を踏まえて解釈する必要があると学びました。

サイトヘルスに表示される改善提案には、緊急性の高いものだけでなく、性能改善や追加設定に関するものもあります。

すべての提案を無条件に適用するのではなく、実際の利用状況やほかの機能への影響を確認することが重要です。

一般公開を再開する

一連の更新と確認作業を終えた後、最後にサイトのアクセス制限を解除しました。

その際、管理者としてログインしているブラウザだけではなく、Chromeのシークレットウィンドウを使って表示を確認しました。

シークレットウィンドウでは通常のブラウザに保存されたログインセッションを引き継がないため、一般の訪問者に近い条件でサイトを確認できます。

実際にサイトへアクセスしたところ、Basic認証のパスワード入力を要求されず、ホームページが正常に表示されました。これで、サイトの一般公開を再開できたことを確認しました。

もっとも、トップページが表示されたからといって、サイトのすべての機能やセキュリティ上の問題が解消したことまで保証されるわけではありません。

今後も、記事表示、画像、お問い合わせ機能、各種プラグインの連携、サイトヘルスなどを定期的に確認していく必要があります。

今回の作業を振り返って

今回のメンテナンスを通して感じたのは、WordPressのセキュリティ対策が単一の機能や設定だけで完結するものではないということです。

PHP、WordPress本体、プラグイン、テーマ、Webサーバー、データベース、管理者アカウントなど、さまざまな要素が組み合わさって一つのサイトが動いています。セキュリティを維持するには、これらを継続的に管理する必要があります。

今回の作業は多くはChromeブラウザのOpenAI公式で提供されている拡張機能のChatGPTを利活用しながら進行し、当初の予想以上に時間がかかりましたが、サイトの運用環境を総合的に見直す機会になりました。

もちろん、今回の対策で今後のセキュリティリスクが完全になくなったわけではありません。サイトを運営し続ける限り、セキュリティ対策も続けていく必要があります。

今後も定期的に更新状況とバックアップを確認しながら、サイトの運営を続けていきたいと思います。

同じようにWordPressで個人サイトを運営している方にとって、今回の記録が少しでも参考になれば幸いです。

参考資料

タイトルとURLをコピーしました