PHPの緊急対応で、自社サイトの「どこが動いているか」を確認した朝
PHPの重大な脆弱性が報じられ、静的な公式サイトとPHPを使う試作環境を分けて確認しました。お名前.comのファイルマネージャーが502になった朝、確認できたこと、推測、まだできていない対応を記録します。
2026年10月21日の夜、PHPの重大な脆弱性について、修正プログラムの適用を急ぐよう呼びかけるニュースが広がりました。首相も自身の投稿で対応を呼びかけました。セキュリティを専門にしていない私にも、今回は早めに自社の状態を確かめる必要があると伝わるニュースでした。
この記事は、10月22日午前7時時点の暫定記録です。確認内容は午前6時58分までで、その後の対応結果は含めていません。
WordPressを使っていなくても、確認は終わらない
株式会社Creerのホームページは、AIと一緒に作成した静的なサイトです。WordPressは使っていません。そこで最初は、本体サイトについては今回のPHPの問題と直接関係しないのではないか、という話になりました。
ただ、気になったのが試作中の「ラボ」でした。本体とは別に、実験的な機能を置いています。まだ実運用していませんが、そこではPHPを使っていたはずです。
PHPは、サーバー側でプログラムを動かすための仕組みです。脆弱性とは、外部から悪用されるおそれのあるプログラムの弱点を指します。PHP公式のセキュリティ案内では、Webリクエストを処理するPHPに関する重大な問題と、修正版への更新が示されています。
何が困るのか。修正されていないPHPが外部からの要求を受け、攻撃が成立すると、サーバー上で本来許されない命令を実行されるおそれがあります。その結果、保存された情報を盗まれたり、Webページを書き換えられたりする可能性があります。財務省の注意喚起でも、こうした被害の危険性が示されています。これは起こり得る被害の話で、当社で侵入や改ざんを確認したという意味ではありません。
だからこそ、本体サイトの作り方だけを見て自社全体の確認を終わらせず、PHPが動く場所と修正の状況を確かめようと考えました。
静的な本体と、PHPを使うラボを分ける
まず、手元にある本体サイトの公開用データを確認しました。当時の全146ファイルのうちHTMLは120ファイルで、PHPファイルは見つかりませんでした。問い合わせフォームも外部サービスを利用しており、自社サーバー上のPHPで送信処理をする構成ではありません。
ここで分かったのは、手元の本体サイトの公開用データはPHPを必要としないということです。公開サーバーに古いファイルが残っていないことや、サーバー側でPHPが実行できない設定になっていることまで確かめたわけではありません。
振り返ると、AIと一緒に本体サイトを作る際、静的なHTMLを中心とする構成を選んだことが、今回の確認でも助けになりました。会社案内や技術ノートの発信に必要な機能を、この構成で実現できていたため、本体ではPHPを必要とするCMSやプラグインに依存せずに運用しています。
一方、ラボにはPHPを使う処理があり、これまでの記録ではPHP 8.5を利用していました。管理画面の「8.5」という表示だけでは、今回の修正を含む細かなバージョンまでは分かりません。ここは本体サイトと切り離して考える必要がありました。
今回の問題は、アプリケーションの中身だけを直せば済むとは限りません。PHP公式は、修正版への更新を強く勧めています。ただ、当社が利用するレンタルサーバーで、その修正が適用されたかは、この時点で確認できていませんでした。
返事を待つ間に、何ができるか
AIと確認を進める中で、サーバー会社へ問い合わせ、対応状況を確かめる案が出ました。正確な情報を得る手段として必要だと思います。
ただ、この規模のニュースでは、電話がすぐにつながり、個別の回答を得られるとは限りません。問い合わせフォームでも、返事まで時間がかかるかもしれません。私が知りたかったのは、回答を待つ間に自分たちで何ができるか、ということでした。
ラボはまだ業務で使っていません。停止しても、今の仕事が止まるわけではありません。危険性を減らすためなら、一度削除することも考えました。ただ、削除せずに公開だけ止めてデータを残せるなら、その方が戻しやすい。そこで、元に戻せる方法で一時停止できないかを確認する方向になりました。
AIとのやり取りで感じたこともあります。「削除しただけでは安全と言い切れない」という注意は正しい。それでも、同じ注意と問い合わせの提案を繰り返すだけでは、判断は前に進みません。何を守りたいのか、何なら止めても支障がないのか、元に戻せる方法があるのか。そこまで一緒に整理してこそ、実務の助けになると思いました。
ファイルマネージャーが502になった
ラボの公開ファイルを確認するため、お名前.comの管理画面からファイルマネージャーを開こうとすると、「502 Bad Gateway」が表示されました。これは、Webサービスの途中で正常な応答を得られなかったことを示すエラーです。
一瞬、自分の操作が原因かと思いましたが、この時点で行ったのはファイルマネージャーを開く操作だけです。ファイルの一覧に入る前に止まっており、公開ファイルを変更した結果ではありません。また、ファイルマネージャーの502だけで、ラボ自体が停止したとも判断できません。
確認すると、お名前.comの緊急メンテナンス案内が出ていました。予定は10月21日19時から22日10時までで、利用しているレンタルサーバーも対象に含まれています。ただし、案内にある作業内容は「システムの保守作業」です。今回のPHPの問題への対応とは明記されていません。
時間帯が重なっているので、私は関連する対応かもしれないと思いました。しかし、これは推測です。メンテナンスの告知だけで、当社が利用するサーバーのPHP修正が完了したとは判断できません。反対に、案内にPHPと書かれていないから対応していないとも言えません。
公式チャットボットでも尋ねましたが、今回の対応状況や個別サーバーの修正完了までは確認できませんでした。問い合わせフォームは、この時点では送信していません。
午前7時時点で、できたこととできていないこと
確認できたのは、本体サイトの手元の公開用データにPHPがないこと、ラボにはPHPを使う処理があること、そして管理サービスの緊急メンテナンスが告知されていることです。
一方、公開サーバー全体のファイル確認、ラボの一時停止、PHPの修正適用確認は終わっていません。こちらからファイルを削除・移動・アップロードしたり、設定を変更したりもしていません。
感染や侵入が見つかったという話ではありません。この記事は、緊急の注意喚起を受けて予防的に確認を進めた途中の記録です。
管理画面が十分に使えない状態で変更を重ねるより、機能が戻ってから改めて確認する方がよいと、この時点では判断しました。ただし、予定の10時になれば自動的に安全になるわけではありません。管理機能の復旧と、必要な修正の適用は、それぞれ確かめる必要があります。
この後に確認すること
- メンテナンスの終了案内と、ファイルマネージャーの復旧状況。
- 利用中のPHPに今回の修正が適用されているか。細かなバージョン、または事業者からの適用情報。
- 公開サーバーにあるPHP関連ファイルの範囲と、未稼働のラボを一時的に公開停止する方法。
- 対処した場合の操作内容と、本体サイトへの影響の有無。
管理の形によって、確認先も変わる
この朝の記録を、ほかの会社が確認を始める場合に置き換えると、まず「自社のサイトのどこでPHPを使い、誰が管理しているか」を知ることが入口になると思います。IPAの注意喚起でも、PHPを使うものを可能な範囲で確認し、開発元や提供元の情報を確かめるよう案内しています。
- 制作・保守を外部へ委託している場合：委託先に、サイトでPHPを使っているか、今回の修正が必要な場所はどこか、対応と完了確認を誰が行うかを聞く。
- 自社でサイトを管理している場合：手元の制作データだけで判断せず、公開中のサイトでPHPや関連する仕組みを使っている範囲と、修正の適用状況を確かめる。
- レンタルサーバーを利用している場合：事業者のお知らせで契約中のサービスが対象かを見て、PHP本体の更新を誰が担うかを確認する。メンテナンスの告知だけで、自社の対策が完了したとは判断しない。
- 無料の公開サービスやクラウドを利用している場合：無料か有料かにかかわらず、サービス側が保守する範囲と、自分で管理する範囲を確かめる。PHPを実行しない公開サービスや、基盤の更新を提供側に任せられるサービスもあります。一方、自分で作ったアプリやデータの公開範囲、アクセス権は、公開後も確認が必要です。
これらの立場は重なることもあります。制作会社に保守を任せ、別の事業者のサーバーを借りているなら、両者の担当範囲を確かめる必要があります。私も今回は、自分で見られる範囲と、サーバー会社からの情報が必要な範囲を分けて考えました。
今回、自社サイトが「静的なホームページ」だと分かっているだけでは、判断材料が足りないと実感しました。試作機能も含めて、どこで何が動いているかを把握しておく必要があります。
緊急時には、不確かなことを断定せずに、できる判断を一つずつ進めたい。まず対象を分け、止めても支障のないものを見極め、確認できたことと未確認のことを残す。今回はまだ途中ですが、その過程も次の判断に使える記録として残しておきます。