PHPのニュースを見て、先日調べたアクセスログを思い出した

2026年10月24日の朝、PHPの脆弱性について話していて、少し前に自分で書いた記事を思い出しました。

技術ノートがどのくらい読まれているかを知りたくて、公式サイトのアクセスログを調べた話です。短時間に集中した約1,000件は、不審なPHPファイルを探すアクセスと考えられるものでした。その調査から、公式サイトのWAF設定も見直しました。

先に自分のサイトを調べ、経緯を記事にしていた。その後で、PHPの重大な脆弱性が公表された。今朝になって、二つの出来事が自分の中でつながりました。

もちろん、以前の不審なアクセスが今回の脆弱性を狙っていたと分かったわけではありません。ニュースを受けて自社の状態を確かめるとき、先に残していた記録が手掛かりになったのです。今回はその気づきと、10月22日の朝に書いた暫定記録の続きを残します。

最初は、土木設計の記事が読まれているかを知りたかった

DXFや配筋図、CAD、BIM/CIMなど、本業に近い記事へどのようなアクセスがあるのか。以前の調査は、そんな疑問から始まりました。

生のログを見ると、10月5日の約3分42秒間に、一つのアクセス元から1,000件の要求がありました。要求先は999種類で、不審なPHPファイルを機械的に探す動きと整合していました。応答はすべて301で、別のURLへの転送を示します。調べたログで追えたのは転送までで、その先の応答は確認できていません。

数字を読者の閲覧数として扱いかけたところから、ログの中身とWAFの設定まで確認した経緯は、1,000アクセスを調べた記事にまとめています。10月14日に公式サイト側のWAFを有効にし、17日に記事を公開しました。

その後、21日にPHP公式が二つの重大な脆弱性を公表しました。識別番号はCVE-2026-109618とCVE-2026-109619です。

10月5日の探索と、21日に公表された脆弱性との因果関係は分かっていません。 当時のアクセスが何を狙っていたかは、要求されたファイル名だけでは確定できません。今回つながったのは、以前の調査で知った公式サイトの構成と、ニュースの後に確認するべき場所です。

10月22日朝の暫定記録に、続きができた

PHPのニュースを受けて確認した朝のことは、自社サイトと試作環境を分けて確認した記事に書きました。確認できた範囲を午前7時時点で区切った暫定記録です。

手元の本体サイトの公開用データは、HTMLなどを中心とした静的な構成で、PHPファイルは見つかりませんでした。一方、試作中の開発環境にはPHPを使う処理がありました。ただし、手元のデータだけでは、公開サーバー上に古いファイルが残っていないかまでは分かりません。

そこで公開側を見ようとしましたが、お名前.comのファイルマネージャーには502エラーが出ていました。その朝は管理機能の復旧、事業者による修正の適用状況、公開ファイルの確認を次の課題として残しました。

当時の記事を読み返し、その後に分かったことも続けて記録したくなりました。古い記事の午前7時時点の記録はそのまま残し、ここからは後日に確認した結果です。

お名前.comはRSプランへの修正完了を告知した

お名前.comの公式告知では、10月22日20時45分時点で対象サーバーへのセキュリティパッチ適用が完了したと案内されています。対象には、当社が契約しているRSプランが含まれます。ファイルマネージャーも同日18時30分ごろに再開したと記されています。

告知によると、今回の修正は、利用中のPHPのバージョン番号を維持したまま、修正プログラムを取り込む方法で適用されました。利用者がPHPのバージョンを切り替える操作は不要とされています。

私は最初、管理画面に出るバージョン番号を見れば、修正済みか判断できるのではないかと考えました。しかし、この方法なら番号が以前と同じでも、修正が取り込まれている場合があります。今回確認の根拠にしたのは、表示上の番号だけではなく、契約中のRSプランが公式の完了告知に含まれることです。

これは事業者が発表した対応状況を確認した結果です。私がサーバー内部のパッチ適用を直接検査したわけではありません。PHP本体への修正は事業者が担い、当社では告知が契約中のサービスに当てはまるかを確かめました。

管理画面が戻り、公開ファイルを確認できた

10月23日15時45分には、ログイン後の管理画面とファイルマネージャーを開けました。前日の502で止まっていた確認を、ここから進められるようになりました。管理画面ではRSプランの契約と、PHP 8.5の表示を確認しています。

ファイルを見た範囲では、本体サイトの公開フォルダー直下にPHPファイルはありませんでした。開発側にはPHPを使う処理が残っています。前日は手元の制作データしか見られませんでしたが、今回は公開側のファイルも確認できました。ただし、これだけでサーバー内の全ファイルを調べ尽くしたことにはなりません。

同日15時53分までに、開発側の処理についても、認証に関わるコードが存在するところまで読みました。確認したのはコード上の状態で、実際に認証が期待どおり働くかは試験していません。開発環境はまだ本格稼働前なので、そこは次の確認として残します。

事業者の修正完了告知を確認し、管理画面が使える状態に戻り、本体と開発側のファイルを分けて見ることができました。緊急時にどこから確認を再開すればよいかは整理できたため、ここでいったん区切ります。開発側の動作試験や、公開環境全体の安全性確認が終わったという意味ではありません。

さらに、10月23日付のPHP公式の追加案内には、特定の設定とアプリケーションの動作が重なった場合に関する注意も載っています。CVE-2026-115560として、次の通常の修正版で詳しい案内を出すとされています。当社の環境がその条件に当てはまるかは、この記事の確認では判断していません。引き続き開発元と事業者の案内を見ていきます。

契約先と管理担当を確かめるところから

今回のニュースを見て、自社のホームページはどうだろうと思った方は、まず、どこのサービスを使い、誰が管理しているかを確かめるところから始められると思います。

レンタルサーバーを使っているなら、契約中のプランが事業者の対応対象に含まれているか、修正がどこまで進んだかを公式のお知らせで見る。制作や保守を外部へ委託しているなら、自社サイトでPHPを使っているか、事業者の対応に加えて委託先の確認や作業が必要かを尋ねる。表示上のバージョン番号だけでは判断できない場合もあります。

今回はお名前.comの告知で当社のRSプランに対する対応を確認できました。ほかの契約先でも同じ方法で修正されるとは限りません。分からないところは管理担当者やサーバー事業者へ確認する方が確かです。

私も、ニュースを自分の会社に置き換えてみたことで、確認する相手と場所が具体的になりました。まずは契約先と公式のお知らせを見る。それも、自社の状態を知る一歩になります。

小さな記録が、後日の判断材料になった

アクセスログを調べていたとき、知りたかったのは土木設計の記事がどのように読まれているかでした。そこから不審なアクセスに気づき、サーバーの設定を見直した。その過程を記事に残していたので、今回のニュースを受けて以前の調査へ戻れました。

10月22日朝の暫定記録にも、後から確かめる事項を残していました。その後、事業者の修正完了告知、ファイルマネージャーの復旧、公開側のファイル確認が加わりました。記録があったことで、今回の確認の続きをどこから始めればよいかが分かりました。

一方で、今回見た範囲の外には、開発側の認証試験や、サーバー全体の状態など、まだ確かめることが残っています。記録は結論を早めるためではなく、確認できたことと次に調べることをつなぐために使う。 今回の出来事で、その価値を改めて感じました。