注記: 本記事における企業名・サービス名の記述は、公開情報および報道に基づく技術的考察であり、事実の断定ではありません。侵害の経路・責任所在は調査中であり、関係各社の公式発表をご参照ください。
はじめに
セキュリティを担当する立場として、最近の攻撃の頻度・多様性にうんざりしつつ、何をしても緊急度が周りには「どこか別の世界のこと」「自分には関わりのないこと」と伝わらず、どうしたものかと悩んでいる。
コロナ禍に十分な準備期間を持てないままリモートワークが開始された際に、VPN ルーターの脆弱性などを突いたロジスティック系や自動車製造の部品サプライヤーなど、サプライチェーンへの攻撃が世界的に大きな影響を及ぼしたことを記憶している。あの時「他人事」だったサプライチェーンへの攻撃が、いま直接的な「自分事」に落ちてきている。
そんな中、2026年4月8日、SUUMO・HOME'S・アットホーム・CHINTAI・オウチーノ・賃貸EXの6サービスに関連するとされる個人情報、約240万行・2.78GBがダークウェブで販売されていることが報じられた。
via. SUUMO, CHINTAI, At Home, HOME’S Suffer Data Breach
この報を聞いた時、元中の人としては、「まず CRM 経由だろうな。どこだろう？」と思った。なぜそう思ったか、そして事案の背景にある技術的な構造について書く。
なお、本記事は確定事実と仮説を意識的に分けて書く。特に断りのない限り、被疑企業・システムの名称を含む記述は 「可能性の検討」であり、事実の断定ではない。
不動産ポータルの裏側にある「CRM」とは何か
一般の方にはなじみが薄いかもしれないので、まず説明する。
不動産会社（仲介業者）は、SUUMO・HOME'S・アットホームといった複数のポータルサイトに物件情報を掲載して集客する。1社だけに出稿するのではなく、複数に同時掲載するのが業界標準だ。
ここで問題がある。ポータルごとに物件の入力項目・フォーマットが異なり、しかも不動産情報は「専有面積」「築年数」「設備」「周辺環境」「法令上の制限」など入力項目が非常に多い。これを各ポータルごとに個別入力するのは現実的ではない。そのため、一括で複数ポータルに出稿できる業務システムが使われる。
問い合わせ側も同じ問題が発生する。SUUMOから来た問い合わせ、HOME'Sから来た問い合わせ、アットホームから来た問い合わせ……これをバラバラに管理するのは大変だ。だから各ポータルからの反響（問い合わせ）を一箇所に集約し、顧客対応・追客・来店管理まで一元化するシステムがある。これが 不動産向けCRM（反響管理システム） だ。
ここで構造的な問題が生まれる。
複数のポータルからの問い合わせを一元管理するということは、そのCRMの中には複数ポータル分のユーザーデータが蓄積されている、ということだ。
今回の漏洩データに含まれるとされる「反響元」というフィールド——そこにはポータル名がタグとして入っている。これはまさにCRMの構造そのものだ。ポータル側が顧客データに「反響元：SUUMO」と書く理由はない。問い合わせを受けた仲介業者のシステムが、どのポータル経由の問い合わせかを記録しているのだ。
「1回のDBダンプ」が示すこと
「規模から見て1回のDBダンプであることは明らか」という指摘がある。
via. https://x.com/singaporetweet2/status/2042073544201535683
2.78GB・240万行、6社分のデータが「1回のダンプ」で出てくる——これはポータル各社を個別に攻撃した痕跡と矛盾する。むしろ、6社分のデータを内包するSaaSのDBを1回取得した、という構造の方が自然だ。マルチテナントSaaSでポータルを反響元フィールドで区別している設計なら、6社分が単一ダンプに含まれるのは当然の帰結になる。
いえらぶGROUPが不正アクセスを認めた（確定事実）
J-CASTニュース（2026年4月9日）の取材で、以下の2点が確認されている。
リクルート（SUUMO運営）のコメント:
「SUUMOへの直接的な攻撃・侵入は確認されておりません」
「データ連携している「いえらぶ社」のシステムにおいて第三者による不正アクセスで情報漏えいがあったことを確認している」
いえらぶGROUP自身のコメント:
「弊社が提供するクラウドサービスにおいて、第三者による不正アクセスを受け、一部の顧客情報が外部へ流出した可能性があることを確認しております」
「当該システムは、ご指摘いただいたSUUMO、CHINTAI、アットホーム、LIFULL HOME'S、オウチーノ、賃貸EX等の各不動産ポータルサイトからの反響情報を管理する機能を有しております」
同社はすでに脆弱性を修正し、「安全な状態であることを確認」とも述べている。また、いえらぶCLOUDは「SUUMO・CHINTAI・アットホーム・LIFULL HOME'S・オウチーノ・賃貸EXなどのポータルサイトからの反響情報を管理する機能を有している」とJ-CASTは補足している。
対応タイムラインとして確認できるのは以下の通りだ。
- 2026-04-06 いえらぶGROUPが不正アクセスの可能性を認識、初動調査開始
- 2026-04-08 本格調査開始、危機対策本部を設置、外部専門機関と連携。同日、公式サイトで第一報を発表
「1回のDBダンプ」という観測と、複数ポータルの反響を一元管理するマルチテナントSaaSという構造は、完全に整合する。
ただし、今回流出したデータの全てがいえらぶCLOUD経由かどうかは、現時点では確認されていない。
行動情報のリスクを論じた記事の中で、流出データの構造から SMOCCA CRM ではないかと推察する声もある。
via. 日本の防犯システムが一段階下がった日～240万人の「住所と引っ越し予定」がダークウェブで商品化された意味～
2026年3月に激化したサプライチェーン攻撃（確定事実）
ここからが本記事のもう一つの主題だ。
2026年3月〜4月、オープンソースのパッケージリポジトリを狙ったサプライチェーン攻撃が相次いだ。これらは確定した事実として記録されている。
Axios npm 侵害（2026年3月31日）
HTTPクライアントライブラリ axios は、フロントエンド・バックエンドを問わず世界で最も広く使われているnpmパッケージの一つで、週あたり1億ダウンロード以上を誇る。Vue.jsプロジェクトでは事実上の標準だ。
3月31日 UTC 00:21、攻撃者はメンテナーのnpmアカウントを乗っ取り、悪意あるバージョン（axios@1.14.1 および axios@0.30.4）を公開した。これらのバージョンには plain-crypto-js@4.2.1 という隠し依存が仕込まれており、インストール時の postinstall スクリプトとして即座に実行される。
マルウェアの動作は: クラウドアクセスキー・データベースパスワード・APIトークンを数秒で窃取し、C2サーバー（sfrclak.com:8000）に送信後、.bashrc/.zshrc に自己を書き込んで持続化し、自己削除する。
悪意あるバージョンが公開されていたのは約2〜3時間。その窓にCI/CDパイプラインが npm install を走らせていた場合、開発者が気づかないまま credentials が流出しうる。
LiteLLM PyPI 侵害（2026年3月24日、TeamPCP）
AIライブラリ litellm のバージョン 1.82.8 に、Python起動時に自動実行される .pth ファイルが仕込まれた。窃取対象は AWS/GCP/Azure のトークン、SSHキー、Kubernetes credentials。LiteLLM は Amazon Bedrock のプロキシとして広く使われるライブラリだ。
タイムラインの一致（仮説）
ここからは仮説の領域であることを明記する。
公開情報から確認できるいえらぶGROUPの技術スタックは: PHP（Laravel）、Vue.js、MySQL、Redis、AWS、GitLab CI。そして同社は Amazon Bedrock を採用していることが公開情報から確認できる。
技術スタック（公開情報ベース）:
| カテゴリ | 内容 |
|---|---|
| バックエンド言語 | PHP（メイン）、JavaScript、Java |
| フレームワーク | Laravel、Zend Framework |
| フロントエンド | Vue.js、jQuery |
| DB | MySQL、Redis |
| インフラ | AWS |
| CI/CD | GitLab（自動ビルド・デプロイ環境あり） |
| 検索 | Elasticsearch、Kibana |
| AI | Amazon Bedrock（Claude 3.5 Sonnet v2） |
タイムライン:
- 2026-03-24 LiteLLM PyPI 侵害 → AWSトークン窃取の可能性
- 2026-03-31 Axios npm 侵害 → DBパスワード窃取の可能性
- （攻撃者の dwell time：認証情報を使った侵入・探索）
- 2026-04-06 いえらぶGROUP「不正アクセスの可能性を認識」（報道ベース）
- 2026-04-08 本格調査開始 / ダークウェブで240万行が販売開始
関連度の評価（推定）
| シナリオ | 蓋然性 | 根拠 |
|---|---|---|
| いえらぶCLOUD の CI/CDパイプラインが Axios@1.14.1 を踏み、DB credentialsが流出 | 中〜高 | タイムライン一致・Vue.js使用・GitLab CI存在・DB passwordsの窃取対象 |
| LiteLLM 侵害で Bedrock 関連 AWS credentials が流出、そこからDB到達 | 低〜中 | Amazon Bedrock 使用は確認済みだが LiteLLM の採用は未確認 |
| SMOCCA CRM も同じ波に巻き込まれた | 不明 | 技術スタック不明。セイルボートがnpm/Pythonを使っていれば可能性あり |
Vue.js を採用しているシステムのCI/CDパイプラインがAxiosの侵害窓（2〜3時間）内に npm install を実行していた場合、DBパスワードが流出しうる。その後6〜8日というギャップは、サプライチェーン侵害後の典型的なdwell timeと矛盾しない。
繰り返すが、これは仮説だ。いえらぶGROUPへの侵害経路がAxios経由であることは現時点では確認されていない。
なぜこれが「他人事」ではないか
Axiosを使ったことがあるエンジニアは世界に何千万人もいる。Vue.jsプロジェクトでAxiosを使っていないプロジェクトの方が珍しい。
問題は、lockfileが固定されていないCI環境や、npm install を定期実行している環境では、2〜3時間の窓だけで感染しうるという点だ。自分が知らない間に、誰かのCI/CDパイプラインがその2時間に走っていたかもしれない。
postinstall スクリプトは便利機能であると同時に、パッケージ公開権限を持つ攻撃者にとっての理想的な実行フックだ。
今回のAxios侵害では: アカウント乗っ取り → 悪意あるバージョン公開 → 世界中のCI/CDパイプラインが一斉にインストール → DB credentials 窃取 → 自己削除、という一連の流れが2〜3時間で完結した。
最低限やっておくべきこと
- lockfileをコミットし、CIでは npm ci を使う（npm install は使わない）
- package-lock.json / pnpm-lock.yaml の変更はレビューする
- postinstall スクリプトを持つパッケージを把握する
- CI/CDの実行環境から本番DBへの直接アクセスを遮断する（credentials の最小権限化）
- Dependabot / Renovate の更新PRは自動マージしない
SaaSとして顧客データを預かっている立場なら加えて:
- 依存パッケージの integrity hash 検証
- CI環境の secrets は動的発行・短命化（AWS IAM Roles for GitHub Actions 等）
- マルチテナントDBのアクセス権限分離
おわりに
かつて不動産ポータルの内側にいた者として、この業界のデジタル化がいかに急速だったかをよく知っている。ポータル各社が競い合い、仲介業者向けのSaaSも次々と生まれた。その利便性の裏で、「複数社分のデータを一手に握るSaaS」という構造が静かに生まれ続けていた。
コロナ禍のサプライチェーン攻撃は「海外の製造業の話」だった。今回の事案は「部屋を探した人全員の話」だ。不動産ポータルのサプライチェーンを狙った（かもしれない）攻撃は、そのサプライチェーンの一部であるソフトウェアをつくるサプライチェーンを起点に行われた可能性がある。
今回の事案がどのルートで起きたかは、まだ完全には明らかになっていない。しかし、2026年3月に実際に起きたサプライチェーン攻撃の規模と精度、そしてタイムラインの一致は、偶然と呼ぶにはあまりに整合的に見える。
「有名ライブラリだから安全」は、もはや成立しない。メンテナーのアカウントが一つ取られれば、そのライブラリを使っている世界中のシステムが同時に狙われる。
マルチテナントSaaSを作る側も、使う側も、この構造的リスクを直視するべきタイミングが来ている。
注記: 本記事における企業名・サービス名の記述は、公開情報および報道に基づく技術的考察であり、事実の断定ではありません。侵害の経路・責任所在は調査中であり、関係各社の公式発表をご参照ください。