EPARKリラク＆エステ、予約・顧客管理基盤「PeakManager」のDB侵害で最大約3,300万レコードが漏えいの可能性 — 攻撃者は保存データを削除

項目	内容
発生日	不正アクセスの発生時期は未公表／検知: 2026年7月27日（不正アクセスおよび顧客情報の削除を確認）
公表日	2026年7月31日（第一報）／親会社の説明: 2026年8月4日
対象組織・業界	株式会社EPARKリラク＆エステ（リラクゼーション・エステサロンの予約サイト運営／株式会社EPARKの連結子会社／専門サービス〈美容〉）
攻撃手法	予約・顧客管理プラットフォーム「PeakManager」の一部データベースへの不正アクセス → 保存データの窃取の可能性および削除（初期侵入経路は未公表）
情報源	EPARKリラク＆エステ 公式 第一報（2026年7月31日）、株式会社EPARK（2026年8月4日）、Security NEXT（2026年8月5日）、INTERNET Watch（2026年8月）

概要

リラクゼーション・エステサロンの予約サイトを運営する株式会社EPARKリラク＆エステ（株式会社EPARKの連結子会社）は2026年7月31日、予約・顧客管理プラットフォーム「PeakManager」の一部データベースが不正アクセスを受け、保存されていた顧客情報が削除されていることを確認したと公表しました。

漏えいの可能性がある情報は、データベース上のレコード数で約3,300万レコード。含まれる項目は氏名、生年月日、性別、住所、電話番号、メールアドレス、暗号化されたパスワード等の個人情報で、クレジットカード情報およびマイナンバーに関する情報は含まれないとされています。

なお公表は「レコード数」ベースであり、実際の対象人数は調査中です。同一人物の複数予約が別レコードとして計上されうるため、レコード数と対象人数は一致しません。

PeakManager は加盟サロン向けの予約・顧客管理基盤であり、影響はサロン利用者に及びます。親会社の株式会社EPARKは2026年8月4日、同社および EPARK ブランドを展開する各事業会社のシステム・情報基盤に対して不正アクセスが行われたものではないと説明し、被害範囲が当該子会社のシステムに限定されるとしています。

経緯

• 発生時期: 不正アクセスの開始時期は公式には公表されていません
• 2026年7月27日: PeakManager の一部データベースへの不正な方法によるアクセス、および当該データベースに保存されていた顧客情報が削除されていることを確認
• 検知後: データベースの復旧、当該環境の運用停止とバックアップへの切替、不正アカウントの停止、認証情報の変更、新サーバー・新データベースへの移管を実施（移管は完了と公表）
• 2026年7月30日: 個人情報保護委員会へ報告
• 2026年7月31日: 第一報を公表。外部専門機関と連携して事実関係・影響範囲・原因の調査を継続
• 2026年8月4日: 親会社の株式会社EPARKが、EPARKブランド各事業会社の基盤への不正アクセスではない旨を説明
• 2026年8月5日: Security NEXT が報道

また報道では、ダークウェブ上のハッキングフォーラムに、2026年7月19日に PeakManager のドメインへ侵入し約3,200万行規模の顧客データを取得したと主張する投稿が確認されたとされています。この主張の真偽および当該事案との関係は、同社の公表では確認されていません。

原因

判明している事実: PeakManager の一部データベースに対し「不正な方法によりアクセスが行われた」こと、および当該データベース内の顧客情報が削除されていたこと。初期侵入経路・悪用された脆弱性・攻撃者の身元はいずれも公表されておらず、同社は外部専門機関と連携して調査中としています。

考えられる原因（推測）

以下は公表事実から考えられる仮説であり、同社が公表したものではありません。

1. 「削除」が伴っている点が示す到達深度: 単にデータを読み出したのではなく、データベースに保存されていた顧客情報が削除されていました。これは攻撃者が参照権限にとどまらず、書き込み・削除権限を持つ状態でデータベースへ到達していたことを示します。アプリケーションの入力経路を通じた読み出しだけでは通常こうはならず、データベースへの直接的な到達（管理系インターフェース、露出したデータベースポート、あるいは高権限の資格情報の悪用）が考えられます。
2. 削除の目的として想定される2つの動機: ひとつは証跡と復旧手段の破壊で、被害組織が「何が持ち出されたか」を侵害されたデータベース自身から再構成できなくする効果があります。もうひとつは恐喝の圧力で、窃取したデータを人質に取ったうえで元データを消すことで交渉力を高める形態です。ダークウェブでの犯行声明が報じられていることは後者の構図と整合しますが、同社の公表では言及がありません。
3. 暗号化されたパスワードは「安全」ではない: 公表では「暗号化されたパスワード」とされていますが、保護方式（ハッシュアルゴリズム、ソルトの有無、ストレッチング回数）は公表されていません。方式が弱い場合、オフラインでの解析により平文が復元される可能性があります。他サービスで同じパスワードを使い回している利用者は、変更が必要な状態にあると考えるべきです。
4. プラットフォーム型サービスに集約されたデータ量の意味: 約3,300万レコードという規模は、多数の加盟サロンの利用者データが単一の基盤に集約されていたことを示します。サロンごとに分散していれば1店舗分の被害で済んだデータが、基盤の1点侵害で全体に及ぶ構造です。

対策

組織が学ぶべきこと

1. データベースへの「直接到達経路」を棚卸しする: アプリケーション経由の入力検証を固めても、データベースそのものに管理系の到達経路が残っていれば意味を失います。管理インターフェースの公開範囲、踏み台以外からの接続可否、高権限アカウントの数と保管場所、そして「アプリケーション用アカウントに DELETE 権限が必要か」という最小権限の見直しを、資産単位で確認する必要があります。

2. ログとバックアップは、侵害されうる環境の外側に置く: 本件では顧客情報が削除されていました。侵害された環境の中にしかログや世代バックアップがない構成では、削除と同時に「何が起きたか」を説明する手段も失われます。 監査ログを書き込み後に改変できない領域へ転送しておくこと、バックアップを侵害環境から到達できない場所に世代保持しておくことは、復旧の手段であると同時に説明責任の手段です。同社がバックアップへの切替と新環境への移管を実施できたことは、この備えが機能した側面といえます。

3. 「レコード数」でしか語れない状態を避ける: 公表が約3,300万レコードというレコード数ベースで、対象人数が調査中となっているのは、被害の性質上やむを得ない面があります。ただし平時から、どのテーブルにどの個人情報項目が何件あるか、一意の個人を特定する鍵は何かを把握しておけば、公表の初動で示せる精度は上がります。データマッピングは規制対応の書類作業ではなく、有事の説明速度を決める準備です。

4. プラットフォーム提供側は、加盟事業者への説明経路も設計対象: 基盤を利用する加盟サロンは、自らの顧客に説明する立場に置かれます。何をいつどの粒度で伝えるかを、加盟事業者向けの経路として事前に用意しておくことが、現場の混乱と誤った説明の拡散を防ぎます。

ヤグラの視点 — 修復か再構築か：復旧は速くても、説明は長期化する

本件は、復旧の面では速い判断が下されています。侵害された環境の運用を止め、バックアップへ切り替え、不正アカウントを停止し、認証情報を変更し、新サーバー・新データベースへの移管まで完了させています。修復（同じ環境を直して使い続ける）ではなく再構築（環境を捨てて作り直す）を選ぶ判断は、攻撃者の残存を確実に排除するうえで有効な選択です。

しかし復旧の速さと、説明の速さは別の指標です。本件で難しいのは、攻撃者が顧客情報を削除していったことです。侵害されたデータベースは、もはや「何が入っていたか」を自ら証言してくれません。だから公表は「約3,300万レコード」というレコード数にとどまり、実際に何人の、どの項目が漏れたのかは調査中のままです。環境を作り直すことはできても、失われた事実を作り直すことはできません。

ここから引き出せる教訓は明快です。環境を再構築できる備え（世代バックアップ、構成のコード化）と、環境が消えても事実が残る備え（改変不可能な領域への監査ログの外部保全、横断的なアクセス記録の収集）は、別々に用意しなければなりません。前者がなければ事業が止まり、後者がなければ説明が止まります。そして後者は、侵害が起きてから始めることが原理的に不可能な唯一の投資です。データベースへの認証・クエリ・大量読み出し・削除といった操作の記録を、対象システムの外側に集約して継続的に監視しておくこと。これが「何を失ったか」を語れる状態を守ります。→ ヤグラ AI SOC

今後の対応

• 初期侵入経路・悪用された脆弱性の公表
• レコード数から実際の対象人数への特定、および漏えい確定範囲の確定
• 「暗号化されたパスワード」の保護方式と、利用者へのパスワード変更要請の有無
• ダークウェブで確認されたとされる犯行声明との関係、恐喝の有無
• 加盟サロンおよび利用者への個別通知の進捗
• 漏えいした氏名・住所・電話番号を用いた二次被害（なりすまし連絡、フィッシング、SMS詐欺等）の発生有無

判明次第、本記事に追記します。

更新履歴

日時	内容
2026-08-06	第一報を公開