PHPに重大な脆弱性が見つかっても、レンタルサーバーの利用者である私には、その修正を自分で入れることができません。事業者の対応を待つことになります。
では、待っている間は、ブログをいつもどおり公開しておくしかないのでしょうか。
今回、私はConoHa WINGの「ディレクトリアクセス制限」を使いました。記事や画像を削除したのではなく、一時的にブログを開けない状態にした記録です。
修正版を待っている間にも、攻撃されるかもしれない。だから私は、ブログを公開したまま待つのではなく、一時的にアクセスを制限することを選びました。次に同じような状況になったときのために、その判断と、実際に確認できたことを残しておきます。
修正を待つ間、アクセスより防御を選んだ
ブログを運営している以上、読んでもらいたい気持ちはあります。けれど、今回はアクセスを失ってでも、防御を優先したいと考えました。なんせPHPの脆弱性がかなりやばいものだったからです。
自分ではPHPに修正を入れられない。それでも、外からのアクセスを制限することなら、利用者側でできるのではないか。そう考えて選んだのが、ブログの入口を閉じる方法でした。
ここでいう防御は、修正プログラムの代わりではありません。対応を待つ間、公開を制限しておくという判断です。サイトを消すわけでも、サーバーを解約するわけでもありません。
当時の事業者の案内や、利用者から何が見えていたかについては、ConoHa WINGとエックスサーバーのPHP脆弱性対応を比較した前の記事にまとめました。今回は、そのとき自分がしたことに絞って書きます。
.htaccessは面倒そうだったので、管理画面の機能を選んだ
アクセスを制限する方法として、.htaccessというファイルを自分で編集する案もありました。ただ、私には少し面倒に感じたので、そこでConoHa WINGの管理画面から設定できる機能を選びました。
ディレクトリは、サイトのファイルを置くフォルダーのことです。ディレクトリアクセス制限では、そこへアクセスした人にユーザー名とパスワードを求めます。こうした仕組みをBasic認証と呼びます。
WordPressがページを表示するときは、PHPが動きます。このアクセス制限では、その前にユーザー名とパスワードを確認します。認証に失敗したアクセスは、通常ここで止まります。
PHPを動かしてから「メンテナンス中です」と表示するプラグインとは、止める場所が違うわけです。
ただし、制限が効いていないページは止められません。また、認証に失敗したときのエラー画面をPHPで表示する設定なら、そのPHPは動きます。
.htaccessに全拒否の設定を書く方法も、Webサーバー側でアクセスを止めます。Basic認証は正しい認証情報があれば通すのに対し、全拒否は通さない設定です。
ディレクトリ制限後は、自分もブログを開けなくなった
管理画面の『＋ディレクトリ』から、ブログのディレクトリを制限対象に追加しました。
このあと認証用のユーザー名とパスワードを登録する手順になっています。私はそれを登録しませんでした。その状態では、私自身もブログを開けなくなりました。もちろんConoha Wingの設定画面は開けるので、そこは安心してください。
この状態でブログを見てみてると、表示されないことが分かります。
試したURLではちゃんと閲覧が制限されていました。今回の脆弱性をこの設定で防げたと実証したわけではありません。また、ユーザーを登録せずに使う方法は公式ガイドの案内にはないため、このまま真似するための手順としては紹介しません。
それでも、利用者側の管理画面から公開を制限でき、自分も入れなくなるところまでは確かめられました。「何もせずに待つ」以外の行動を取った、というのが今回の体験です。
後日、制限を解除して通常表示を確認した
後日、アクセス制限を解除し、ブログが普段どおり開くことを確認しました。
解除する場所は、ブログの中ではなくConoHaの管理画面です。ディレクトリアクセス制限の右横にあるゴミ箱を押して、制限を解除します。簡単です。
自分ではPHPを修正できないからといって、レンタルサーバー側の修正を待つだけでは、その間に悪意のある攻撃を受ける可能性があります。
だから私は、修正対応を待つ間の選択肢として、ブログへのアクセス制限を考えています。多少のアクセスを犠牲にしてでも、今回のようなヤバめのPHPの脆弱性の場合は特に。
次も脆弱性の影響や事業者の案内を確認して、公開を制限するか判断したいと思います。そして解除する前には、自分の環境への修正が完了しているか、事業者の案内を確認します。
＊関連記事
PHPの脆弱性を修正前に予告するのは危険なのか。AIの研究から考えたこと
＊参考資料
ConoHa：ディレクトリアクセス制限の設定をする（認証ユーザーの登録と制限の解除手順）https://support.conoha.jp/w/directoryaccess/
ConoHa：PHPの脆弱性への弊社対応完了のお知らせ・2026年10月22日（番号を維持した修正の適用）https://www.conoha.jp/wing/news/?ap=2015054909&btn_id=wing-news--news_wing-news
Apache：Request Processing in the Apache HTTP Server 2.4（認証・認可とハンドラーの処理順）https://httpd.apache.org/docs/current/en/developer/request.html
Apache：ErrorDocument（エラー応答を別のURLで処理する設定）https://httpd.apache.org/docs/2.4/mod/core.html#errordocument
CloudLinux：Apache mod_lsapi PRO（PHP処理を受け渡すモジュールの説明。実装の検討には公開配布ソースも参照）https://docs.cloudlinux.com/cloudlinuxos/cloudlinux_os_components/#apache-mod-lsapi-pro
コメント