---
title: "VOISINGの不正アクセスと約17万件の漏えい｜BIツールの既知脆弱性とパッチ適用の期限設計"
url: "https://www.issoh.co.jp/tech/details/18174/"
published: 2026-10-08
updated: 2026-10-08
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# VOISINGの不正アクセスと約17万件の漏えい｜BIツールの既知脆弱性とパッチ適用の期限設計

2.5次元アイドルグループ「いれいす」などを手がけるVOISINGは2026年9月30日、社内で使っていたBIツールへの不正アクセスについて第四報を公表し、漏えい件数を約17万件と確定させました。原因は、BIツールに存在した既知の脆弱性への修正が攻撃に間に合わなかったことだと同社自身が分析しています。本記事で整理するのは、第一報から第四報までの時刻ごとの公表内容と、利用者が今やる点検です。後半では、同じ構図を自社で避けるための脆弱性情報の受信、深刻度別の適用期限、BIに渡す個人情報の仮名化、大量取得の検知を、動かせるコードで示します。

## まとめ：VOISINGの不正アクセスで確定した事実と利用者・BI運用者が今やること

確定しているのは、8月10日1時2分頃にBIツールへの不正アクセスが始まり、8月16日18時47分から20時21分にかけてツール内のデータがダウンロードされたこと、漏えい件数が約17万件であることです。項目は氏名、住所、電話番号、メールアドレス、生年月日、性別、購買履歴、決済金額の記録、サービス加入状況、推しの選択情報です。クレジットカード番号とログインパスワードに相当する情報は、そもそもこのシステムに保持していませんでした。

BIツールの製品名とCVE番号は公表されていません。利用者は便乗した偽の連絡への警戒と、生年月日や電話番号から作ったパスワードの変更を先に済ませます。BIツールを運用する企業にとっての論点は、修正の公開から適用までに何日かけてよいかを決めていたかどうかです。

| 項目         | 公表されている内容              |
| ---------- | ---------------------- |
| 侵入開始       | 2026年8月10日1時2分頃        |
| データ取得      | 8月16日18時47分〜20時21分     |
| 遮断         | 8月17日1時55分             |
| 漏えい件数      | 約17万件（第四報で確定）          |
| 外部公開       | SNSで10件・特定サイトに約5万件の可能性 |
| 決済情報・パスワード | 保持しておらず対象外             |
| 製品名・CVE    | 非公表                    |

## 公表内容を時刻で確認する｜8月10日の侵入から9月30日の第四報まで

### 侵入から取得まで6日・取得終了から検知まで3時間半という空白

VOISINGの[第一報（2026年8月18日）](https://voising-official.com/news/931)によると、不正アクセスの開始は8月10日1時2分頃です。データの取得は8月16日18時47分から20時21分の約1時間半に集中し、同社が事態を確認したのは同日23時55分、システムの停止とネットワークからの遮断は8月17日1時55分に完了しました。

時刻を並べると二つの空白が見えます。侵入からデータ取得までの約6日間、異常は見つかっていません。取得が終わってから検知までにかかった時間も、3時間半という長さです。攻撃者は入ってすぐに持ち出したのではなく、6日かけて中を確かめてから一気にダウンロードしたと読めます。この6日間に気づける仕組みがあれば、取得そのものを止められた可能性があります。

### 第二報の最大約17万人から第三報の外部公開検知までの公表内容と経緯

[第二報（8月20日）](https://voising-official.com/news/936)は対象人数を最大約17万人の暫定値として示し、アカウントパスワードの漏えいはないと明記しました。[第三報（8月24日）](https://voising-official.com/news/937)では、8月22日11時頃にSNS上で、8月23日10時頃に特定のサイト上で個人情報の公開を検知したと報告しています。公開を確認できたのは10件で、特定サイトには約5万件が置かれている可能性があるとしました。

約5万件と約17万件の関係は、第四報の時点でも説明されていません。5万件が全体の一部なのか、別の集計なのかは分からないため、本記事では両方の数字をそのまま扱います。

### 第四報が認めた侵入の原因と攻撃者のアカウント・APIキーの扱い

[第四報（9月30日）](https://voising-official.com/news/1015)は、BIツールに存在した既知の脆弱性に対する修正の適用が、脆弱性情報の公開から攻撃までの時間軸に間に合わなかったことを直接の原因としています。対応としては、修正プログラムの適用、関連するパスワードとアクセスキーの無効化、攻撃者が作成したアカウントとAPIキーの無効化を挙げ、侵害された環境は復旧せずに廃棄しました。

攻撃者が自分用のアカウントとAPIキーを作っていた点は見逃せません。脆弱性を塞いでも、作られた入口が残れば再侵入されます。環境ごと廃棄して作り直す判断は、侵入期間が6日あって何を仕込まれたか確かめ切れない状況では妥当です。

## 漏えいした項目を仕分ける｜推しの情報と保護者が決済する会員の扱い

### 氏名・住所・生年月日と推しの選択情報が組み合わさることで生じる危うさ

個々の項目は一般的な会員情報ですが、組み合わせると性質が変わります。住所と生年月日に、どのタレントを応援しているかと購買履歴が付くと、本人に向けて関心事を突いた連絡を作れます。限定グッズの当選、ファンクラブの更新、イベントの追加販売といった文面は、受け取る側が開きたくなる内容です。

推しの選択情報は要配慮個人情報には当たりませんが、ファンにとっては知られたくない場合もある情報です。漏えい対象には退会済みや休眠中の利用者も含まれており、何年も前に使っていた人にも届きうる点に注意が要ります。

### 未成年の会員と決済者が別人の場合に家庭内で共有しておく漏えいへの対応

第二報は、決済者が本人以外の保護者や家族である場合、案内メールの内容を決済者に共有して相談するよう求めています。10代のファンが多い領域では、登録者は子ども、支払いは保護者という形もよくある決済の形態です。偽の請求や返金を装う連絡は、決済者である保護者に届く可能性もあります。

家庭内で共有しておくのは、VOISINGから正規の連絡が来る経路と、本件に関して電話やSMSで支払いや口座情報を求められることは想定しにくいという点の二つです。

## 利用者が今やる点検手順｜偽の連絡の見分け方とパスワードの見直し

### VOISINGを装うメール・SMS・電話への対処と問い合わせ先

VOISINGは、同社や関連企業を装ったフィッシングメール、SMS、迷惑電話への注意を呼びかけています。不審な連絡が来たら、本文中のURLは開かず、添付ファイルも開かずに削除します。確かめたいときは、届いた連絡に書かれた連絡先ではなく、公式サイトから専用の問い合わせフォームへ進んでください。

同社はお詫びメールの内容が分かる形でSNSに投稿しないよう求めています。メールの体裁がそのまま偽メールの見本になるためです。SNS上に出回っている画像やデータの転載も控えてください。

### 生年月日や電話番号から作ったパスワードと暗証番号を変える範囲

ログインパスワードは漏えいしていません。ただし第二報は、漏えいした可能性のある生年月日や電話番号から推測されやすいパスワードや暗証番号を使っている場合、VOISINGと他社のサービスの両方で変更するよう求めています。誕生日の4桁、電話番号の下4桁、名前と誕生日の組み合わせは、名簿を持つ攻撃者が最初に試す候補です。

変更の優先順位は、パスワード再設定の受け口になるメールアカウント、決済に使うサービス、チケット販売やフリマのように換金できるアカウントの順です。

## BIツールの既知脆弱性を塞ぐ体制｜KEVの受信と深刻度別の適用期限

### 製品名が非公表でも参考になる同時期に起きていたBIツールの悪用状況

VOISINGは製品名を明かしていないため、どの脆弱性が使われたかは特定できません。参考になるのは同時期の状況です。米国CISAの[Known Exploited Vulnerabilities（KEV）カタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)は、実際に悪用が確認された脆弱性の一覧で、2026年10月4日版で1,734件が登録されています。この中には、Metabaseの[CVE-2026-72898](https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf)が2026年8月11日に追加され、対応期限が8月14日と設定されています。

これをVOISINGの事案と結び付ける公表はありません。ここから言えるのは、BIツールの脆弱性は公開から数日で悪用が始まりうるという一点です。同じ時期にMetabaseの脆弱性が使われた事例は[LEAN BODYの不正アクセス](https://www.issoh.co.jp/tech/details/18168/)で、版の確認方法とあわせて解説しています。

### KEVのJSONフィードから自社の製品だけを拾うPythonスクリプト

第四報が再発防止策の最初に挙げたのは、脆弱性情報の受信体制です。小さく始めるなら、自社で動かしている製品の一覧とKEVの[JSONフィード](https://www.cisa.gov/sites/default/files/feeds/known%5Fexploited%5Fvulnerabilities.json)を突き合わせ、直近に追加されたものだけを通知します。

```
import json, sys, urllib.request
from datetime import date, timedelta

FEED = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
INVENTORY = {("Metabase", "Metabase"), ("Apache", "Superset"), ("Grafana Labs", "Grafana")}
days = int(sys.argv[1]) if len(sys.argv) > 1 else 14

req = urllib.request.Request(FEED, headers={"User-Agent": "kev-watch/1.0"})
with urllib.request.urlopen(req, timeout=30) as res:
    feed = json.load(res)

since = date.today() - timedelta(days=days)
hits = [v for v in feed["vulnerabilities"]
        if (v["vendorProject"], v["product"]) in INVENTORY
        and date.fromisoformat(v["dateAdded"]) >= since]
for v in sorted(hits, key=lambda x: x["dateAdded"]):
    print(v["dateAdded"], v["cveID"], v["product"], "dueDate:", v["dueDate"])
sys.exit(1 if hits else 0)
```

2026年10月8日に取得したフィードで動かすと、既定の14日では該当がなく終了コード0、引数で70日に広げるとCVE-2026-72898が1行出て終了コード1になります。`INVENTORY`の表記はKEVの`vendorProject`と`product`に合わせてください。毎朝cronで回し、終了コード1のときだけチャットへ通知すれば、受信の仕組みとしては足ります。CVE番号の読み方は[CVEとCWEの違い](https://www.issoh.co.jp/tech/details/5119/)で整理しています。

### 脆弱性の深刻度と公開範囲で修正の適用期限を決める基準と判断責任者

受信しても、適用の期限が決まっていなければ後回しになります。第四報は深刻度に応じた対応期限の規定と判断責任者の明確化を掲げました。期限は深刻度だけでなく、インターネットから到達できるかどうかで分けるのが実務的です。

| 条件                  | 適用期限の目安     | 判断者      |
| ------------------- | ----------- | -------- |
| KEV登録済み・外部から到達可能    | 48時間以内か一時遮断 | 当番の技術責任者 |
| CVSS 9.0以上・外部から到達可能 | 72時間以内      | 当番の技術責任者 |
| CVSS 7.0以上・社内からのみ到達 | 14日以内       | システム管理者  |
| それ以外                | 定期メンテナンスで適用 | システム管理者  |

一番上の行で効くのは「一時遮断」の選択肢です。検証が間に合わないなら、修正を当てるまで外部からの接続を止めてよいと事前に決めておきます。CISAが設定するKEVの対応期限は米連邦機関向けですが、CVE-2026-72898では追加から3日でした。判断に迷った担当者が上長の承認を待つ間に数日が過ぎる、という形を避けるため、期限と同時に決める人を名指ししておきます。

## BIに渡す個人情報を減らす設計｜仮名化ビューと大量取得の検知

### 会員IDをHMACで置き換えて氏名や連絡先を見せないビューの作り方

第四報の再発防止策には、BIツール上の個人情報の仮名化と最小化が入っています。分析に氏名や電話番号は要りません。PostgreSQLであれば、元のテーブルには触らせず、仮名化したビューだけをBIツール用のユーザーに見せる形が作れます。会員IDは[pgcryptoのhmac関数](https://www.postgresql.org/docs/current/pgcrypto.html)で置き換え、鍵はBI用ユーザーが読めない場所に置きます。

```
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE SCHEMA secret;
CREATE TABLE secret.pseudo_key (k text NOT NULL);
INSERT INTO secret.pseudo_key VALUES ('ここに32文字以上の乱数');

CREATE SCHEMA bi;
CREATE VIEW bi.member_orders AS
SELECT
  encode(hmac(m.member_id::text, (SELECT k FROM secret.pseudo_key), 'sha256'), 'hex') AS member_key,
  (date_part('year', age(current_date, m.birth_date))::int / 10) * 10 AS age_band,
  m.prefecture,
  m.oshi,
  o.amount,
  date_trunc('month', o.ordered_at)::date AS order_month
FROM members m
JOIN orders o ON o.member_id = m.member_id;

CREATE ROLE bi_reader LOGIN PASSWORD 'change-me';
GRANT USAGE ON SCHEMA bi TO bi_reader;
GRANT SELECT ON bi.member_orders TO bi_reader;
```

[CREATE VIEWのドキュメント](https://www.postgresql.org/docs/current/sql-createview.html)にあるとおり、ビューが参照するテーブルへの権限はビューの所有者で判定されます。そのため`bi_reader`は`members`や鍵のテーブルを直接読めず、ビューの列だけが見えます。権限の付け方は[GRANTのドキュメント](https://www.postgresql.org/docs/current/sql-grant.html)を参照してください。生年月日は10歳刻みの年代に、注文日時は月単位に丸めています。このSQLは手元でPostgreSQLを起動できず未実行のため、構文は公式ドキュメントに基づくものです。導入前に検証環境で確かめてください。

単純なSHA-256ではなくHMACにしているのは、会員IDが連番だと総当たりで元に戻せるためです。鍵が漏れない限り、ビューの中身だけでは本人に戻せません。法律上の仮名加工情報として扱う場合の要件は[仮名加工情報とは](https://www.issoh.co.jp/column/details/17443/)で整理しています。

### 時間帯ごとの応答量で一括ダウンロードを見つけるアクセスログ集計の例

VOISINGの事案では、データの取得が1時間半に集中していました。BIツールの前段にリバースプロキシを置いていれば、接続元ごと・1時間ごとの応答バイト数を数えるだけで、この種の一括取得は浮かび上がります。次はnginxのcombined形式のアクセスログを集計する例です。

```
import sys
from collections import defaultdict

THRESHOLD_MB = 50
total = defaultdict(int)
with open(sys.argv[1], encoding="utf-8", errors="replace") as f:
    for line in f:
        try:
            ip = line.split(" ", 1)[0]
            hour = line.split("[", 1)[1][:14]
            status, size = line.split('"', 2)[2].split()[:2]
        except (IndexError, ValueError):
            continue
        if status == "200" and size.isdigit():
            total[(ip, hour)] += int(size)

alerts = [(k, v) for k, v in total.items() if v > THRESHOLD_MB * 1024 * 1024]
for (ip, hour), size in sorted(alerts, key=lambda x: -x[1]):
    print(hour, ip, f"{size / 1048576:.1f}MB")
sys.exit(1 if alerts else 0)
```

模擬ログで動かすと、18時台に90MBを取得した接続元だけが出力され、毎時2MB程度の通常の利用、403の応答、形式の崩れた行は数えません。閾値を決める基準は、1週間ほど測って把握した通常の利用の最大値です。15分ごとに直近のログへ回せば、取得の途中で気づける可能性が出てきます。痕跡を遡って調べる手順は[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)が使えます。

### BIツールをインターネットに直接公開する構成をやめる判断と見送る場面

第四報は、社内ツールをインターネットへ直接公開しない構成への見直しも挙げています。社内の分析にしか使わないBIツールなら、VPNやゼロトラスト型のアクセス制御の内側に置き、ログイン画面を外から見えなくするのが筋です。こうすれば脆弱性が公開されても、攻撃者は入口にたどり着けません。

例外は、取引先や外部の委託先にダッシュボードを見せる必要がある場合です。このときも、外部向けには集計済みの値だけを出す別のインスタンスか埋め込みを用意し、個人情報に届く本体は閉じておきます。逆に、社員数十人で個人情報を一切つながないBIなら、構成の作り直しより先に上の期限表とKEVの受信を整えるほうが効果は大きいと判断します。

## 漏えい等報告と点検の段取り｜運用者が侵害時と平時に決めておくこと

### 個人情報保護委員会への報告対象となる四つの類型と速報・確報の期限

[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、報告の対象は要配慮個人情報の漏えい等、財産的被害のおそれがある個人データ、不正の目的をもって行われたおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等（民間事業者）の四類型です。速報は発覚から3〜5日以内、確報は30日以内で、不正目的の場合は60日以内とされています。

VOISINGは発覚の2日後に第一報を出し、個人情報保護委員会への報告と警察への相談を進めています。BIツール経由の外部攻撃であれば、件数にかかわらず該当するのは不正目的の類型です。報告書式の埋め方は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で解説しています。

### 自社のBIツールと分析基盤を点検する順番と外部に任せる検査の範囲

点検の順番は、外部から到達できるBIツールと管理画面の洗い出し、各製品の版と未適用の修正の確認、BIがつないでいるデータベースのユーザーと参照範囲の棚卸しです。最後に、管理者アカウントとAPIキーの一覧を出し、作成者と作成日が説明できないものを止めます。VOISINGの事案で攻撃者がアカウントとAPIキーを作っていたことを踏まえると、この確認は版の更新と同じ重さで扱うべきです。

攻撃面を継続的に把握する考え方は[CTEMとは](https://www.issoh.co.jp/tech/details/13277/)が参考になります。BIツールを含む外部公開面の検査や、データベース権限の見直しを外部に任せたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で入口から接続先のデータまで通して確認できます。

## よくある質問

VOISINGの不正アクセスについて、利用者とBIツールの運用者から出やすい質問をまとめました。

### VOISINGのサービスはこのまま使い続けても大丈夫ですか？

第四報によると、脆弱性への修正は適用済みで、侵害された環境は廃棄され、攻撃者が作ったアカウントとAPIキーも無効化されています。9月30日時点で関係機関から二次被害の報告はないとしています。続ける場合も、生年月日や電話番号から作ったパスワードは変更し、同社を装う連絡には応じないでください。

### クレジットカードの停止やパスワードの変更は必要ですか？

クレジットカード番号とログインパスワードに相当する情報は、不正アクセスを受けたシステムに保持されておらず、漏えいの対象外です。カードの停止は必須ではありません。ただし生年月日や電話番号から推測できるパスワードや暗証番号を使っている場合は、VOISINGと他社サービスの両方で変更が求められています。

### 退会済みや昔の会員も対象に含まれますか？

退会済みや昔の会員も対象です。対象はVOISING ID、VOISING CONNECT、VOISING ONLINE STORE、いれいす公式ファンクラブ「いれらぶ」、旧VOISINGアカウント、旧オンラインストアの利用者で、退会済みや休眠中の人も入ります。対象者には登録メールアドレス宛てに個別の連絡が送られています。

### 悪用されたBIツールはMetabaseですか？

悪用されたBIツールの製品名は非公表です。第四報も製品名とCVE番号を記載していません。同時期にMetabaseのCVE-2026-72898がKEVに追加されていますが、VOISINGの事案と結び付ける公表はなく、断定できる材料はありません。自社でMetabaseを使っている場合は、事案と関係なく版を確かめてください。

### 自社のBIツールは何から点検すればよいですか？

最初の確認対象は、インターネットから直接ログイン画面に到達できるBIツールがないかという点です。次に稼働中の版と未適用の修正、BIがつなぐデータベースユーザーの権限、管理者アカウントとAPIキーの一覧を順に確認します。並行して、KEVの受信と深刻度別の適用期限を決めておくと、次の脆弱性公開に間に合わせやすくなります。

## 関連記事

- [LEAN BODYの不正アクセスと約44万件の取得｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用](https://www.issoh.co.jp/tech/details/18168/)：同時期にBIツールの脆弱性が使われた事例と版の確認手順
- [Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】](https://www.issoh.co.jp/tech/details/16142/)：セルフホストのBIを本番構成で運用するときの前提
- [タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計](https://www.issoh.co.jp/tech/details/17925/)：退会者のデータまで対象になった同系統の事例
- [Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し](https://www.issoh.co.jp/tech/details/17839/)：事業者側の侵害で利用者が回す点検手順の比較に
- [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：BIツールを含む外部公開面の点検を外注するときの判断材料

---

出典: [VOISINGの不正アクセスと約17万件の漏えい｜BIツールの既知脆弱性とパッチ適用の期限設計](<https://www.issoh.co.jp/tech/details/18174/>)（株式会社一創）