infoQ: every member's record taken, and ¥2.87 million in points turned into Amazon gift codes.

What GMO Research & AI has stated

infoQ is a Japanese survey site: members answer questionnaires and earn points that they can exchange for gift codes and other rewards. It is run by GMO Research & AI, part of GMO Internet Group. On 5 October 2026 the company published a notice. GMO Research & AI notice (Japanese).

What happened. A third party accessed infoQ's servers without authorisation. The company has confirmed that members' personal data was taken out. It has also confirmed that some members' points were exchanged for Amazon gift codes without their consent.
Cause. The attacker exploited a vulnerability in software used on the site. The product, the vulnerability and the method have not been named. A security firm is helping with the investigation.
How many. Up to 948,498 records, which the company says is every record of personal data it held as of 5 October.
What was taken. Name, name reading (furigana), gender, date of birth, email address, postal address, phone number, password (encrypted), member ID, and other registration data: nickname, points balance, last survey date and similar usage details.
What was not. The company does not hold credit card numbers or My Number (the national ID number).
Points. 611 accounts had points exchanged for Amazon gift codes, worth ¥2,869,500 in total. The company will make the full amount good.
Other services. No unauthorised access to the company's other services has been found. Business clients' data was not included, but some survey work for clients has been affected by the outage.
Members. The company is emailing affected members individually from 5 October. It recommends changing the password on any other service that shares the infoQ password, and warns of fake emails, SMS and calls in the name of the company or infoQ.

Figure 1. Found through a member's inquiry, stopped in steps over the same day. Times are JST. Original graphic.

infoQ's site shows only a notice and points to the company statement. The company has apologised that the site at first described the shutdown as "emergency maintenance", when the real reason was this incident. infoQ (Japanese).

What changes in the security review

Points are cash, and gift codes are cash that cannot be recalled

Editorial assessment. 611 accounts and ¥2,869,500 average out at about ¥4,700 per account. That is a small loss for the company, which is paying it back. The lesson is in how it happened. Points that can be exchanged for an Amazon gift code are as good as cash. Once a code is issued and used, it cannot be pulled back.

The company stopped exchanges at 11:24 on 3 October. It blocked the attack path at 14:15 and took the site offline at 15:00. Stopping the cash-out first, while the investigation went on, was the right order. But the trigger was a member's inquiry, not an alert.

For anyone running a points, rewards or wallet service, check four things:

Monitor redemptions as payments. Alert on volume per hour against your baseline, on many accounts redeeming in a short window, and on accounts that redeem their whole balance soon after a sign-in from a new device or address.
Make redemption a sensitive action. Ask for re-authentication or a one-time code before issuing a gift code, and email the member every time one is issued.
Hold new patterns. A short delay before a first redemption, or one after a change of email or password, gives a monitoring team time to act.
Keep a kill switch ready. Decide in advance who can stop all exchanges, and test that it works without taking the whole site down.

One vulnerability, every record

Editorial assessment. The company says one software vulnerability let the attacker take all of its personal data. That suggests the part of the site that was exploited could read the whole member table. A public-facing application rarely needs that.

Least privilege for the application's database account. The web tier should read one member's row at a time, not export the table.
Alert on bulk reads. Large result sets or long runs of sequential IDs from the application account should stand out.
Patch and inventory the software stack. The company has not named the product. Whatever it was, a single flaw in it became a full-database breach.

"Encrypted" passwords: ask what that means

The notice says the passwords were encrypted. Japanese breach notices often use that word for one-way hashes too, so it does not say which was used.

Editorial assessment. The difference matters. A reversibly encrypted password is only as safe as the key, and the key may sit with the application that was breached. A salted, slow hash (bcrypt, scrypt, Argon2) holds up far better. A fast or unsalted hash does not. Until GMO says which it used, treat infoQ passwords as at risk, as the company itself does when it advises changing reused passwords.

What is not known is how the 611 exchanges were made: by signing in to members' accounts, or by acting on the site directly through the vulnerability. The notice does not say.

A complete profile, ready for fraud

Name, reading, gender, date of birth, address, phone number and email address make a full identity profile. Survey panel members are used to receiving many emails about rewards.

Editorial assessment. Expect phishing and SMS that quote this data. The most convincing lure will be about the compensation: "complete this form to receive your reimbursed points". The company has said it will make the points good. Members should wait for its email and check it against the official notice, not follow links in messages that ask for sign-in details or payment information.

Saying "maintenance" during an incident

Editorial assessment. Taking the site down quickly was correct. Calling it "emergency maintenance" for two days was not, and the company has apologised for it. Members whose points had just been taken were left without an explanation. Prepare a holding statement for this case in advance: "We have stopped the service while we investigate a security problem. More information by [time]."

Which teams should act

Team	Practical next step
IT operations	For any points or rewards service you run: add redemption alerts, re-authentication before issuing gift codes, issue notifications and a tested switch to stop exchanges. Check that the application's database account cannot read the whole member table.
SIEM / SOC	Watch for credential stuffing against your own sign-in pages in the coming weeks. infoQ members who reuse passwords include some of your users. Use the hunts below.
Email security	Expect lures about infoQ, survey rewards and point compensation. Run the mail hunt below and brief staff.
Legal / privacy	Review how your own notices describe an outage caused by an incident. Check what "encrypted" means for passwords in your systems before you ever have to write it in a notice.
Third-party risk	If you commission surveys from GMO Research & AI, expect delays and ask for its findings. The company says client data was not affected; confirm what respondent data it holds for your projects.

IOCs and hunting

No indicators are published. GMO Research & AI has not named the software, the vulnerability, IP addresses or domains. None should be inferred.

The hunts below look for what usually follows a leak like this: credential stuffing with reused passwords, and phishing in infoQ's name. All are illustrative and were not run against live data. Table and field names were checked against Microsoft Learn and Splunk documentation on 6 October 2026.

1. Credential stuffing against Microsoft Entra ID. Microsoft Sentinel, SigninLogs. It finds addresses that failed to sign in to many different accounts within an hour. Set the threshold above your normal pattern; shared exits such as proxies and mobile carriers can produce noise.

// Illustrative; not run against live data. Microsoft Sentinel, SigninLogs.
// IP addresses that failed sign-in to many distinct accounts within one hour.
let Threshold = 20;  // distinct accounts per IP per hour; tune to your baseline
SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType != "0"
| summarize Accounts = dcount(UserPrincipalName), Failures = count(),
    Apps = make_set(AppDisplayName, 5)
    by IPAddress, Hour = bin(TimeGenerated, 1h)
| where Accounts >= Threshold
| join kind=leftouter (
    SigninLogs
    | where TimeGenerated > ago(14d)
    | where ResultType == "0"
    | summarize SuccessfulAccounts = make_set(UserPrincipalName, 20) by IPAddress
    ) on IPAddress
| project Hour, IPAddress, Accounts, Failures, Apps, SuccessfulAccounts
| order by Accounts desc
| take 200

Any row with entries in SuccessfulAccounts needs attention: the same address that failed across many accounts also signed in successfully to some.

2. The same pattern in Splunk. Uses the CIM Authentication data model, so it works across sources that are mapped to it: VPN, web applications, identity providers. The data model must be populated and, for speed, accelerated.

| tstats summariesonly=false count AS failures dc(Authentication.user) AS accounts
    FROM datamodel=Authentication WHERE Authentication.action="failure" earliest=-14d latest=now
    BY Authentication.src _time span=1h
| where accounts >= 20
| rename Authentication.src AS src
| sort 0 - accounts
| head 200

3. Mail that mentions infoQ. Microsoft Defender XDR advanced hunting, EmailEvents (Defender for Office 365). It lists recent inbound mail that names infoQ or GMO Research, grouped by sender domain, so you can review who is sending it. GMO's notice gives infoq-support@gmo-research.ai as its contact address; it does not list sending domains, so check any other domain before trusting it. Japanese text is matched with contains, because has relies on word boundaries that Japanese text lacks.

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting.
// Inbound mail that mentions infoQ or GMO Research, summarised by sender domain.
EmailEvents
| where Timestamp > ago(14d)
| where EmailDirection == "Inbound"
| where Subject contains "infoQ" or SenderDisplayName contains "infoQ"
    or Subject contains "GMOリサーチ" or SenderDisplayName contains "GMOリサーチ"
    or Subject contains "ポイント補填"
| summarize Messages = count(), Recipients = dcount(RecipientEmailAddress),
    Subjects = make_set(Subject, 5), Actions = make_set(DeliveryAction, 3)
    by SenderFromDomain, SenderDisplayName
| order by Messages desc
| take 100

Read the results with these limits in mind:

A match is a lead, not proof. Check the account owner, the source and the timing.
No match is not proof that nothing happened. Stuffing may be slow and spread across many addresses, and lures may go to personal mail or SMS that you cannot see.
These hunts look at your environment. None of them sees infoQ's systems.
SigninLogs; EmailEvents; Splunk CIM Authentication data model.

If you are an infoQ member

Change the password on every other service where you used your infoQ password. Use a different one for each.
Wait for GMO's email about your account and any compensation. Check it against the official notice before acting.
Do not give passwords, card numbers or gift codes to anyone who contacts you about infoQ or points.
Report exchanges you did not make to infoQ support at infoq-support@gmo-research.ai.

What remains unknown

Which software and which vulnerability were exploited.
How passwords were protected: reversible encryption or a one-way hash, and with which algorithm.
How the 611 exchanges were made: through members' accounts, or directly through the vulnerability.
When the access began exactly, and whether it started before 2 October.
Why one flaw exposed every record, and what limits the application had on database access.
When infoQ will reopen.

Sources and updates

All sources were read on 6 October 2026. The ITmedia article was the prompt for this article; facts come from GMO Research & AI's notice. This article will be updated when the company publishes its investigation results. No corrections so far.

30-second briefing