PHPの脆弱性騒動から考える不動産会社のサイト対策｜ツナガるの対応記録

まず「PHP」と「脆弱性」をひと言で

ホームページを店舗にたとえると、見た目の部分が「売り場」、裏で注文や問い合わせを受け付ける部分が「バックヤード」です。PHPは、このバックヤードの仕事を動かすための言葉（プログラミング言語）です。

問い合わせフォームの送信、物件の検索、会員ページのログイン。こうした「入力を受け取って処理する」部分の多くがPHPで動いています。サイトを更新する仕組みとして有名なWordPressも、PHPでできています。

脆弱性とは、ソフトウェアに見つかった「鍵の不具合」のようなものです。普段は誰も気づきませんが、知っている人にはそこから入り込まれてしまいます。

今回は「裏口から勝手に操作される」種類

今回の脆弱性は、リモートコード実行と呼ばれる種類でした。たとえるなら、外から特別な合図を送るだけで、バックヤードの機械を勝手に操作されてしまう状態です。脆弱性の中でも、最も深刻に扱われる部類です。

厄介なのは、被害の範囲を最初から決めつけられないことです。起こり得ることは、たとえば次のようなものです。

• サイトの書き換え：偽の入力欄や不審な広告を差し込まれる
• 情報の持ち出し：保存されている問い合わせ内容などを抜き取られる
• 踏み台：別のサイトへの攻撃や迷惑メールの送信に使われる

開発責任者は、公表直後の受け止めをこう振り返ります。「この種類は、最悪の場合を前提に動くしかありません。全部を数えてから動いていたら間に合わないからです」

使われている範囲が広い

PHPは、中小企業のホームページから大規模なサービスまで幅広く使われています。自社で直接書いていなくても、CMSや予約システムの部品として動いていることがあります。「うちは関係ない」と言い切るには、自社のサイトの中身を知っておく必要があります。

脆弱性は、多くの場合、修正版と同時に公表されます。ここで気をつけたいのは、公表が「解決の合図」ではなく「時間との勝負が始まる合図」だということです。

探索は機械で行われるため、会社の規模や知名度は関係ありません。条件に当てはまれば、小さな不動産会社のサイトも等しく狙われます。

開発責任者は「一番危ないのは、修正版が出ているのに、まだ入れ替えていない期間です。守りの実力は、この期間をどれだけ短くできるかで決まります」と話します。

不動産会社のサイトは、預かる情報も機能も多めです。そのうえ、更新の担当があいまいになりがちです。

• 預かる情報が重い：問い合わせ、査定依頼、会員登録、採用応募
• 作って終わりになりやすい：制作から数年、古い版のまま動いている
• 部品が多い：物件検索、地図、フォームなどの追加機能を重ねている
• 担当があいまい：サーバー会社・制作会社・社内の誰が更新するか決まっていない
• 管理画面の入口が多い：物件更新のため、複数の社員が日々ログインしている

古い版のPHPは「直す手段がない」

PHPには版ごとにサポート期間があります。期間が終わった版には修正版が出ません。古い版のまま動いているサイトは、公表があっても直せず、新しい版への移行という大きな作業が必要になります。

「サーバー会社がやってくれる」は半分だけ

レンタルサーバーでは、サーバー会社が受け持つ範囲と、自社や制作会社が受け持つ範囲が分かれています。CMSや追加機能、PHPの版の切り替えは、自社側の仕事になることが多い部分です。思い込んだままだと、肝心の部分が誰にも触られずに残ります。

開発責任者はこう話します。「不動産会社の皆さんは、住まいや資産という重い判断をお客様から預かっています。サイトが改ざんされれば、被害を受けるのは訪れたお客様です。セキュリティは制作会社だけの話ではなく、営業の土台そのものだと思います」

ここからは、ツナガるの動きを順に記録します。守りの手がかりを与えないよう、仕組みの細かな構成は伏せ、判断の順番を中心にお伝えします。

24時間体制で、8つのサイト・サービスを並行対応

開発責任者自らが部長を務める、株式会社あどばるのWebサービス事業部では、脆弱性が公表された10月21日（日本時間）から、対応が落ち着いた23日まで、スタッフの交代制で昼夜を問わず24時間体制を敷きました。ツナガるを含む8つのWebサイト・サービスを、並行して確認・対応しています。

開発責任者はこう振り返ります。「サイトごとに仕組みも影響の度合いも違います。だからこそ、途切れずに見続けられる体制が必要でした。うちのメンバーが昼も夜も交代しながら手を止めずにいてくれたことが、今回いちばん心強かったことです」

影響は小さくても、すぐに止める

ツナガるのサービス本体は、PHPもWordPressも使っていません。ただ、サービスを載せているサーバーの環境にはPHPが含まれていました。

直接の影響は小さいと見込まれました。それでも「小さい」のままにはせず、すぐにサービスを止めて確認と更新を行うと決めました。

緊急メンテナンスは10月22日（木）の18時頃から21時10分頃まで。平日の業務への影響を抑えつつ、その日のうちに終えられる時間帯を選びました。作業の後は、主な画面が普段どおり表示されることを確かめてから受付を戻しています。

素早く判断できた理由を、開発責任者はこう話します。「すぐ判断できたのは、自分たちの仕組みが何でできているかを、日頃から一覧で持っていたからです。地味な管理の積み重ねが、いちばん効きました」

土台から部品まで、すべてを見直す

「影響がなかった」で終わらせず、守りを何重にも重ね直しました。主な見直しは次のとおりです。

• 実行の土台：サービスを動かす「Node.js」を最新の長期サポート版へ更新
• 使っている部品：サイトを形づくる多数の部品（ライブラリ）を最新の修正版へ
• 画面の仕組み：デザインを組み立てる「Tailwind CSS」を最新の版へ移行
• 見た目の確認：移行の前後で画面を一枚ずつ画素単位で比べ、会員様の画面が変わらないことを確認
• アクセスの安全網：短時間に大量のアクセスが集まったときに自動で抑える仕組みを強化

スピードも意識しました。Node.jsは、ちょうど同じ週にセキュリティ修正を含む最新版が出たところでした。公開を受けてすぐに入れ替えに着手し、検証用の環境で確かめたうえで、間を置かずに本番へ反映しています。

もともと、すぐに被害につながる状態ではありませんでした。それでも、公表済みの弱点を部品ごとに洗い出す点検にかけ、影響の小さい指摘まで一つ残らず解消しました。見直し後の点検結果は0件です。

開発責任者は、この結果をこう受け止めています。「0件になったことより、0件に戻せる体制を確かめられたことに意味があります。弱点は毎日のように見つかります。見つかったらすぐ塞げる状態を保ち続けることが大事です」

会員様へのお知らせ

翌日には、メンテナンスの期間、PHPの脆弱性による影響がないこと、不正アクセスや情報漏えいが確認されていないこと、会員様の作業は不要であることを、お知らせで掲載しました。

影響は小さいと見込めていたのに、なぜ止めたのか。対応を指揮した開発責任者に、判断の理由と、騒動で感じたことを聞きました。以下の「」はすべて本人の言葉です。

「影響が小さい」は、確かめた範囲の見立てにすぎない

「影響が小さいというのは、確かめた範囲の中での見立てです。大きな公表の前後は、便乗した不審な通信も増えます。だからこそ、落ち着いて土台を整える好機だと考えました。後回しにした更新は、次の公表のときに重荷になります」

止める判断のコストは、小さいうちに払う

「数時間のご不便と、万一の被害で失う信頼は、比べるまでもありません。今回、公表直後に止めて確認した事業者も多くありました。分からないまま動かし続けるより、分かるまで止める。私はそれを誠実な判断だと受け止めています」

守りの強さは、自分を知っているかで決まる

「影響の有無をすぐ言い切れるのは、自分たちの仕組みを把握しているからです。特別な防御より先に、自分のことを知っているか。今回いちばん強く感じたのは、この当たり前のことでした」

伝えすぎないことも、守りの一部

「不安が広がると、詳しく説明したくなります。でも、部品の種類や守りの仕組みまで書くと、攻撃の手がかりになりかねません。伝えるのは『影響があるか』『何をしたか』『何をしてほしいか』の三つで十分です」

作業は制作会社や保守会社に任せる場合でも、何を聞けばよいかを知っているだけで対応は早くなります。優先度の高い順に並べます。

1. 仕組みの把握：PHPで動いているか、WordPressなどのCMSか、どんな追加機能があるかを一覧にする
2. 版の確認：PHPやCMSがサポート期間内か、最新の修正版に入れ替わっているかを確かめる
3. 担当決め：サーバー会社・制作会社・社内のどこが何を更新するかを書面にする
4. 不要な機能の削除：昔のキャンペーンページや使っていない追加機能を消す
5. 控えと戻し方：データの控えを定期的に取り、実際に戻せるか一度試す
6. 管理画面を固める：パスワードを使い回さず、2段階認証や接続元の制限を設定する
7. 連絡網：異常に気づいたら、誰に・どの順番で連絡するかを決めておく

いちばん効果が大きいのは、更新を止めないことです。保守契約がない場合は、今回を機に「誰が更新するか」をはっきりさせておくと安心です。

預かる情報を減らすことも、立派な対策です。問い合わせや査定依頼の内容は必要な範囲で保管し、不要になったら自社の個人情報の取り扱いに沿って消去します。持っていない情報は、漏れようがありません。

最初の数時間でやること

慌ててサイトを消すと、何が起きたのかを後から確かめられなくなります。個人情報の漏えい等が起きた場合は、内容によって個人情報保護委員会への報告や本人への通知が法令で求められます。運用は改定されることがあるため、最新の案内を確認し、専門家に相談しながら進めてください。

お知らせに書くこと

影響がない場合でも、短いお知らせを先に出しておくと問い合わせへの対応が一度で済みます。

• 何が起きたか：どのソフトウェアに、いつ脆弱性が公表されたか
• 自社への影響：影響の有無と、確かめた範囲
• 行った対応：メンテナンスの有無と期間
• お願い：お客様にしてほしいこと（なければ「ない」と書く）
• 問い合わせ先：不明点を受け付ける窓口

デジタルの仕組みと人のつながりの使い分けは、「不動産DXとは｜デジタルと対面の使い分けと人のつながりの価値」でも整理しています。

脆弱性は、どのサイトにも起こり得ます。差がつくのは、公表を知ってから動くまでの早さです。

自社のサイトが何でできているかを知る。更新の担当を決める。止める判断とお知らせの型を用意しておく。この三つがそろえば、次の公表でも慌てずに済みます。

まずは明日の朝、制作会社に「うちのサイトはPHPで動いていますか。版はサポート期間内ですか。今回の修正版は入っていますか」とメールを一通送ってみてください。

最後に、開発責任者はこう締めくくりました。「守りは、一度整えたら終わりではありません。続けることでしか保てないものだと思っています」

同業者と知り合う場として、ツナガるが東京都内で定期開催している不動産交流会の予定を不動産交流会・イベント一覧からご確認ください。会員登録は無料です。無料で会員登録する