---
title: "infoQの不正アクセスと最大94万件の漏えい｜ポイント不正交換を止める交換機能の設計"
url: "https://www.issoh.co.jp/tech/details/18164/"
published: 2026-10-07
updated: 2026-10-07
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# infoQの不正アクセスと最大94万件の漏えい｜ポイント不正交換を止める交換機能の設計

GMOリサーチ&AIは2026年10月5日、同社が運営するアンケートサイトinfoQが第三者の不正アクセスを受け、最大94万8,498件の会員の個人情報が外部に持ち出されたと公表しました。一部の会員のポイントが本人の意思によらずAmazonギフトコードに交換された被害も、611件・2,869,500円分確認されています。本記事で整理するのは、公式発表に基づく経過と漏えい項目、そして会員が今日やる点検です。後半では、換金できるポイント交換を狙われた構図を踏まえ、交換機能を止める仕組みと不正な交換を拾う検知のコードを示します。

## まとめ：infoQの不正アクセスで公表された事実と会員・開発者が取る対応

公式発表で確定しているのは、サイトで使っていたソフトウェアの脆弱性を悪用されて侵入されたこと、同社が保有する会員の個人情報の全件が持ち出しの対象になったこと、611件のポイントが不正にギフトコードへ交換されたことです。クレジットカード情報とマイナンバーは、もともと保有していないとされています。不正に交換されたポイントは同社が全額を補填します。

会員がまず手を付けるのは、infoQと同じパスワードを使っている他のサービスの変更です。開発者が点検したいのは、自社サイトの交換機能を、サイト全体を止めずにすぐ止められるかという点になります。

| 項目        | 公表されている内容       |
| --------- | --------------- |
| 不正アクセスの開始 | 2026年10月2日以降    |
| 確認        | 10月3日午前         |
| ポイント交換停止  | 10月3日11時24分     |
| サービス停止    | 10月3日15時        |
| 対象件数      | 最大94万8,498件     |
| 不正交換      | 611件・2,869,500円 |
| 脆弱性の種類    | 未公表             |

## 公表内容の時系列｜10月2日の侵入から3日15時のサービス停止までの経過

### 会員の問い合わせで発覚した10月3日午前から攻撃経路の遮断までの流れ

[GMOリサーチ&AIのお知らせ（2026年10月5日）](https://gmo-research.ai/pressroom/notice/notice-20261005)によると、不正アクセスは10月2日（金）以降に行われていたことが、後の調査で分かりました。発覚のきっかけは、10月3日（土）午前の会員からの問い合わせです。調べた結果、不正アクセスが確認されました。

同日は11時24分にAmazonギフトコードとGMOポイントへの交換を止め、14時15分に攻撃経路を遮断し、15時に外部からinfoQへのアクセスを遮断してサービスを停止しています。停止後のサイトは「緊急メンテナンス」と案内されていましたが、実際は本件への対応による停止でした。同社は説明が遅れたことも詫びています。

検知が社内の監視ではなく会員の問い合わせだった点は、他社にとっても点検の材料になります。どのログで侵入の痕跡を追うかは[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)で整理しています。

### 原因はサイトで使っていたソフトウェアの脆弱性｜種類は未公表のため推測しない

公式発表は原因を、第三者が当社サイトで使用していたソフトウェアの脆弱性を悪用して侵入したもの、と説明しています。セキュリティ専門会社の協力を得て調査を続けている段階です。製品名やCVE番号、脆弱性の種類は示されていません。

そのため本記事では、特定の製品や手口に結び付けた推測はしません。読み取れるのは、外部に公開しているサイトの部品1つの欠陥から、会員情報の全件と換金できる機能の両方に手が届いたという構図です。調査の進め方と依頼先の選び方は[フォレンジック調査とは](https://www.issoh.co.jp/column/details/2812/)で解説しています。

## 漏えいした項目と不正交換の中身｜94万8,498件の全件と611件のギフトコード

### 保有する全件が対象になった意味とカード情報・マイナンバーの扱い

対象件数は最大94万8,498件で、10月5日時点で同社が個人情報を保有している全件です。項目は氏名、フリガナ、性別、生年月日、メールアドレス、住所、電話番号、暗号化されたパスワード、会員ID、ニックネームや保有ポイント数、最終回答日などの利用状況に関する情報とされています。

全件が対象ということは、最近使っていない会員の情報も含まれるということです。[個人情報保護法](https://laws.e-gov.go.jp/law/415AC0000000057)第22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを事業者に求めています。退会者や長期の休眠会員まで持ち続ける設計の見直しは、[タイムズカーの不正アクセスと退会者まで残さない保管設計](https://www.issoh.co.jp/tech/details/17925/)で扱いました。

パスワードは「暗号化されたもの」と書かれていますが、方式は示されていません。鍵で元に戻せる暗号化か、一方向のハッシュ化かで破られにくさが変わります。違いは[ハッシュ化とは（暗号化との違いとパスワード保管）](https://www.issoh.co.jp/column/details/13487/)で説明しています。

### Amazonギフトコードへの不正交換611件・約287万円と全額補填の方針

公表文によると、611件・2,869,500円分のポイントが本人の意思によらずAmazonギフトコードに交換されました。1件あたりに直すと平均約4,700円です。同社は不正に交換されたポイントの全額を補填するとしています。

ギフトコードは発行された時点で第三者に渡り、取り消しが難しい換金手段です。会員情報の持ち出しは後から被害が広がるのに対し、ポイント交換は侵入された当日に金銭の被害が確定します。どの会員が対象だったのか、交換がどの経路で行われたのかは公表されていません。

## infoQ会員が今日やる点検｜パスワード使い回しの解消と偽メール・SMSの見分け方

### 同じパスワードを使う他サービスの変更順と身に覚えのない交換の申告

同社は、パスワードは暗号化されているものの、念のためinfoQと同じパスワードを他のサービスで使っている場合はそちらを変更するよう勧めています。変更の順番は、パスワード再設定の受け口になるメールアカウント、決済や送金に関わるサービス、通販やポイントのサービスの順が目安です。

身に覚えのないポイント交換に気付いた場合は、問い合わせ窓口への連絡を求めています。対象の会員には10月5日から順次メールで個別に連絡するとの案内です。過去の流出に自分の情報が含まれていないかは、[個人情報流出チェックの方法](https://www.issoh.co.jp/column/details/3085/)で調べ方を紹介しています。

### infoQやGMOを装うメール・SMS・電話への対応と問い合わせ窓口の受付時間

同社は、当社やinfoQを装った不審なメール、SMS、電話への注意を呼びかけています。今回は氏名と住所、電話番号、メールアドレスがそろって持ち出されたため、本人の名前を正しく書いた偽の連絡が届きえます。名前が合っていることは本物の証拠になりません。

「ポイント補填の手続き」をうたって入力画面へ誘う連絡には、記載のURLを開かずに対応してください。本件の窓口はinfoQサポートセンターで、メールは24時間受け付け、対応時間は平日10時から18時です。偽の連絡で入力させる手口は[フィッシング詐欺とは](https://www.issoh.co.jp/tech/details/13548/)で、届いた文面の照合先は[フィッシング対策協議会](https://www.antiphishing.jp/)で確かめられます。

## 換金できるポイント交換を止める設計｜緊急停止スイッチと1日上限・流量監視

### 交換停止から経路遮断まで約3時間の差が示す機能単位で止める仕組み

時系列で目を引くのは、11時24分の交換停止が、14時15分の攻撃経路の遮断より約3時間早かったことです。原因の特定と遮断には時間がかかります。その間も換金できる機能を動かし続ければ、金銭の被害は増え続けます。

サイト全体を止めずに交換だけを止めるには、交換処理の入口で毎回参照するフラグを、デプロイなしで切り替えられる場所に置いておく必要があります。設定ファイルに書いてあって再デプロイが要る形では、深夜や週末に間に合いません。ポイントの付与・失効・交換の全体の仕組みは[ポイント管理システムとは](https://www.issoh.co.jp/column/details/15899/)で整理しています。

### Pythonとsqlite3で書く交換の再認証・1日上限・全体流量での自動停止

[OWASPのTransaction Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transaction%5FAuthorization%5FCheat%5FSheet.html)は、送金のような重要な操作を、ログインとは別の認可で、取引ごとに一意の資格情報を使ってサーバー側で確かめるよう求めています。次は[Pythonのsqlite3](https://docs.python.org/3/library/sqlite3.html)だけで書いた例です。停止フラグ、交換ごとの再認証、会員ごとの1日上限、全会員の流量が閾値を超えたら自動で止める処理を入れています。数値は説明用です。

```
# ポイント交換の緊急停止スイッチ・1日上限・全体流量での自動停止（Python標準ライブラリのみ）
import sqlite3
from datetime import datetime, timedelta

db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE flags (name TEXT PRIMARY KEY, enabled INTEGER NOT NULL);
CREATE TABLE members (id INTEGER PRIMARY KEY, last_answer_at TEXT);
CREATE TABLE exchanges (id INTEGER PRIMARY KEY, member_id INTEGER, points INTEGER, created_at TEXT);
INSERT INTO flags VALUES ('point_exchange', 1);
""")

DAILY_CAP = 3000      # 1会員あたり24時間の交換上限（ポイント）
GLOBAL_HOURLY = 50    # 全会員合計で1時間に許す交換件数。超えたら自動で止める

def exchange(member_id, points, reauth_ok, now):
    if not db.execute("SELECT enabled FROM flags WHERE name='point_exchange'").fetchone()[0]:
        return "停止中"
    if not reauth_ok:  # 登録メール宛てのワンタイムコード等で、交換のたびに本人確認する
        return "再認証が必要"
    since = (now - timedelta(hours=24)).isoformat()
    used = db.execute("SELECT COALESCE(SUM(points),0) FROM exchanges WHERE member_id=? AND created_at>=?",
                      (member_id, since)).fetchone()[0]
    if used + points > DAILY_CAP:
        return "1日上限超過"
    hour = (now - timedelta(hours=1)).isoformat()
    if db.execute("SELECT COUNT(*) FROM exchanges WHERE created_at>=?", (hour,)).fetchone()[0] >= GLOBAL_HOURLY:
        db.execute("UPDATE flags SET enabled=0 WHERE name='point_exchange'")  # 人の判断を待たずに止める
        return "全体流量超過で自動停止"
    db.execute("INSERT INTO exchanges (member_id, points, created_at) VALUES (?,?,?)",
               (member_id, points, now.isoformat()))
    return "交換完了"

# 検証用データ：休眠会員60人が短時間に交換を試みる
now = datetime(2026, 10, 3, 9, 0)
for i in range(1, 61):
    db.execute("INSERT INTO members VALUES (?, ?)", (i, (now - timedelta(days=400)).isoformat()))
print(exchange(1, 500, False, now))
print(exchange(1, 2000, True, now), exchange(1, 2000, True, now))
results = [exchange(i, 1000, True, now + timedelta(seconds=i)) for i in range(2, 61)]
print(results.count("交換完了"), results[-1], exchange(2, 100, True, now + timedelta(minutes=5)))
```

Python 3.14.6（SQLite 3.53.1）で実行すると、1行目は`再認証が必要`、2行目は`交換完了 1日上限超過`、3行目は`49 停止中 停止中`になります。50件目までは通り、51件目で流量の閾値に達してフラグが落ち、以降の交換はすべて止まります。

自動停止は正規の会員の交換も止めるため、閾値は平常時の1時間あたりの件数を数週間分集計し、その数倍に置くのが目安です。止まったら担当者に通知し、人が確認してから戻す運用にします。会員ページへの大量アクセスそのものを入口で抑える設定は[オズモールの不正アクセスと大量アクセスを止める設計](https://www.issoh.co.jp/tech/details/18140/)で扱っています。

### 最終回答日から休眠会員の交換を拾うウィンドウ関数のSQLと閾値

infoQの漏えい項目に「最終回答日」があるように、アンケートサイトは会員の利用状況を自前で持っています。長く回答していない会員が急に交換を始めるのは、本人以外が使っている兆候の1つです。次のSQLは上のコードの続きで、最終回答日から180日以上空いた会員の直近1時間の交換を、[SQLiteのウィンドウ関数](https://www.sqlite.org/windowfunctions.html)で件数と順番付きで取り出します。

```
# 検知：最終回答日から180日以上空いた会員が、直近1時間に交換した件数と順位
rows = db.execute("""
SELECT e.member_id, e.points,
       COUNT(*) OVER () AS dormant_total,
       ROW_NUMBER() OVER (ORDER BY e.created_at) AS seq
  FROM exchanges e JOIN members m ON m.id = e.member_id
 WHERE julianday(e.created_at) - julianday(m.last_answer_at) >= 180
   AND e.created_at >= ?
""", ((now - timedelta(hours=1)).isoformat(),)).fetchall()
print(rows[0], rows[-1])
```

実行結果は`(1, 2000, 50, 1) (50, 1000, 50, 50)`で、休眠会員による交換が1時間に50件あったことを示します。PostgreSQLやMySQL 8.0以降でも`COUNT(*) OVER ()`は同じ書き方で動き、日付の差だけは各DBの関数への置き換えが必要です。この件数を数分おきに集計し、平常時を超えたら上のフラグを落とす形にすれば、検知と停止がつながります。

## 採用の判断と次の備え｜交換機能を持つサイトが先に直す条件と報告期限の実務

### ポイント交換の多段防御を優先すべきサイトの条件と過剰になる場面

ギフトコードや電子マネー、他社ポイントへの交換を提供している、交換がログイン状態だけで完了する、交換だけを止める手段が無い、の三つのうち一つでも当てはまるなら、停止フラグと交換ごとの再認証を先に入れるべきです。どれも、侵入された当日に金銭の被害を確定させない対策だからです。

反対に、ポイントが自社サービス内の値引きにしか使えず、第三者が受け取れる形に換えられないなら、流量での自動停止まで作り込むのは過剰です。その場合は1日上限と再認証で足ります。パスワードの保管方式の移行は[OWASPのPassword Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)を基準に、[ホワイトエッセンスの不正アクセス](https://www.issoh.co.jp/tech/details/18163/)でscryptへの移し替えをコードで示しました。

### 速報3〜5日以内の個人情報保護委員会への報告と調査が続く間の公表の分け方

[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的をもって行われたおそれがある行為による漏えい等や、本人の数が1,000人を超える漏えい等は報告の対象です。速報は発覚から3〜5日以内、確報は30日以内、不正目的の場合は60日以内とされています。infoQは10月3日の確認から2日後の10月5日に報告しました。

この発表は、原因の詳細が未確定の段階でも、件数、項目、不正交換の額、補填の方針、取引先の情報が対象外であることを1本で示しています。一方で、停止当初の「緊急メンテナンス」という案内は後から訂正が必要になりました。止めた理由は早い段階で正しく書く方が、会員の問い合わせを減らせます。類型の見分け方は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で解説しています。

### 自社サイトの交換機能と保有データを点検する順番と依頼先の選び方

点検は三つの順で進めます。最初に、ギフトコードや他社ポイントへの交換、出金など、第三者が受け取れる形に換える機能を洗い出し、それぞれを単独で止める手段があるかを確かめます。次に、交換のたびに再認証を求めているか、会員ごとの上限と全体の流量を見ているかを確認してください。最後に、最終利用日から一定期間を過ぎた会員の情報を消す規則があるかを数えます。

公開サイトが使うソフトウェアの脆弱性と、侵入された後に交換機能や会員情報までどこまで届くかを第三者の目で確かめたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、交換処理の認可の抜けを含めて点検できます。

## よくある質問

infoQの不正アクセスについて、会員と開発者から出やすい質問をまとめました。

### infoQの不正アクセスでどの情報が漏えいしましたか？

公式発表によると、氏名、フリガナ、性別、生年月日、メールアドレス、住所、電話番号、暗号化されたパスワード、会員ID、ニックネームや保有ポイント数、最終回答日などの利用状況に関する情報です。件数は最大94万8,498件で、同社が個人情報を保有している全件にあたります。クレジットカード情報とマイナンバーは保有していないとされています。

### 不正に交換されたポイントは戻りますか？

同社は、本人の意思によらずAmazonギフトコードに交換されたポイントを全額補填するとしています。確認されている被害は611件・2,869,500円分です。身に覚えのない交換に気付いた場合は、infoQサポートセンターに連絡してください。補填の手続きをうたって入力を求める連絡は偽物の可能性があるため、公式発表に載った窓口から確かめます。

### infoQのパスワードは変更したほうがよいですか？

infoQはサービスを停止しており、外部からのアクセスも遮断されています。変更を勧められているのは、infoQと同じパスワードを使っている他のサービスです。使い回しがある場合は、メールアカウントと決済に関わるサービスから順に変更し、二要素認証を有効にしてください。

### infoQはいつ再開しますか？

10月5日時点で再開日は示されていません。同社は、調査の結果を踏まえて再発防止策を講じ、安全性を確認したうえで再開するとしています。調査結果と再発防止策は改めて知らせるとされているため、公式のお知らせ一覧で続報を確認してください。

### 自社のポイントサイトは何から見直せばよいですか？

最初に、ギフトコードや他社ポイントへの交換だけをデプロイなしで止められるかを確かめてください。止められないなら停止フラグを入れてください。次に、交換のたびの再認証と、会員ごとの1日上限、全体の流量での自動停止を加えます。あわせて、長く使われていない会員の情報を持ち続けていないかを点検します。

## 関連記事

- [ホワイトエッセンスの不正アクセスと約105万アカウントの漏えい｜予約サイトから基幹システムへ広げない設計](https://www.issoh.co.jp/tech/details/18163/)：公開サイトの脆弱性から会員情報の全体に届いた事例
- [オズモールの不正アクセスと最大44万件のメールアドレス｜海外からの大量アクセスを止める設計](https://www.issoh.co.jp/tech/details/18140/)：会員ページへの大量アクセスを抑える設定
- [タイムズカーの不正アクセスと免許証画像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/15899/)：ポイントの付与・失効・交換の全体像

---

出典: [infoQの不正アクセスと最大94万件の漏えい｜ポイント不正交換を止める交換機能の設計](<https://www.issoh.co.jp/tech/details/18164/>)（株式会社一創）