[1/2] Japan’s Data Breaches Keep Coming. What Is Behind the “Chinese AI” Headlines?

Reporting cutoff: October 24, 2026. Part 1 of 2. The disclosure register is retained as a separate reference.

Order lunch. Book a trip. Look for a job. Make a donation to a town you care about.

None of these is an unusual thing to do. Now imagine receiving a notice saying the information you entered may have leaked. If several services send similar notices, simply remembering what you registered, and where, becomes a task in itself.

That is the uncomfortable setting for Japan’s October 2026 breach disclosures. Even Furusato Choice, operated by Trustbank as a portal for Japan’s hometown-donation tax program, reported that 4,454,097 membership records had been taken. The company identified the intrusion on October 19 and announced it the following day. Trustbank’s disclosure

One service is already a serious matter. Then comes another headline: a Chinese-developed AI tool may have been used in attacks against Japanese companies.

Suddenly, separate incidents appear to have a single explanation.

There is evidence of attackers using AI. Yet it does not establish that every breach announced this month involved the same tool, the same operator, or the same weakness. I wanted to follow the mechanisms behind the headlines, beginning with what the public evidence actually tells us.

What does “Chinese-developed” establish?

On October 15, Japan’s computer security incident coordination center, JPCERT/CC, said its investigation of attack infrastructure had identified AI use in vulnerability scanning and API attacks. An API is an interface through which an application asks a server to do something. The observed activity also targeted services outside Japan. JPCERT/CC’s investigation

An October 20 Jiji Press report described findings by Japanese security firm GMO Cybersecurity linking the Chinese-developed penetration-testing tool ARTEX to attacks on Japanese companies. This is reporting on a security company’s investigation. It does not let me attach ARTEX to every organization in the disclosure register. Jiji Press via nippon.com

I find it useful to keep four questions separate:

• Where was the tool developed? Establish the software’s origin.
• Was AI used in an attack? Look for execution records or comparable evidence.
• Who operated it? Attribution requires identifying an individual or organization.
• Was a state involved? That needs evidence connecting the operation to a state.

A tool’s place of development does not establish its operator’s nationality. Chinese-language records do not, by themselves, establish an identity either. The testing framework and the model it calls are also different components. A short label such as “Chinese AI” can hide that distinction.

These are distinctions I apply when reading the evidence. They matter because a claim about software can easily become an unsupported claim about people.

The screen is only part of the system

Sourcenext, known in Japan for selling PC software, provides one concrete starting point with its October 15 disclosure. The company said an attacker had misused its membership-information API. The potentially affected scope was 22,519,960 records. That figure is not a verified count of people whose complete records were stolen. Sourcenext’s disclosure

A service may have a tidy interface and a login screen. The question remains: what can someone obtain from the server behind that interface?

As a general design principle, authentication establishes who the caller is. Authorization establishes whether that caller may perform this operation on this particular information. Being recognized at a building’s entrance does not give you permission to enter every room. Establishing which check failed in a particular incident requires further evidence.

OfferBox, operated by i-plug, is a graduate recruiting service where employers approach students after viewing their profiles. It illustrates a different problem. Its operator said names and email addresses were included in network responses even though the normal interface did not display them. It attributed the behavior to a configuration error. That disclosure should not automatically become another AI intrusion in a headline count. i-plug’s disclosure

“We do not display it” and “we do not send it” are different promises. Anyone who builds software may find that distinction a little uncomfortable. I think it is a useful discomfort.

JPCERT/CC’s advisory also calls for API authentication, authorization, and access controls. It discusses multiple observed methods; it does not identify a single vulnerability as the cause of all the incidents. JPCERT/CC’s advisory

The supplier behind the familiar name

The next part of the story is further from the screen.

IDARE, a Japanese service combining prepaid shopping payments with tools for setting money aside, reported a breach affecting 129,659 current and former customers after attackers exploited a vulnerability in external software used for customer-support work. The access occurred during August and September. An October disclosure does not necessarily describe an attack that began in October. IDARE’s disclosure

Ymirlink, whose Cuenote FC service delivers bulk email such as company and local-government newsletters, described a chain involving a software vulnerability, stolen staff credentials, and database exports. Its initial estimate for Cuenote FC was roughly nine million records across five systems, including email addresses. “Records across systems” cannot safely be rewritten as “nine million different people.” Cuenote’s disclosure

Another bulk-email service used by businesses and local authorities is Blastmail. In its October 24, 13:20 JST update, it said recipient-list or other non-subscriber-account information had leaked for 344 contracts, alongside the theft of its contracting customers’ information. That means neither 344 people nor 344 independent intrusions. The operator described access from compromised API servers into other systems; the initial entry route remained under investigation. Blastmail’s update

To the person receiving a newsletter, the sender is a familiar shop or local authority. Another business may provide the delivery infrastructure. The same connections that make a service convenient can also carry the effects of a breach.

Ten organizations publishing notices about one supplier do not necessarily mean ten separate attacks. But counting only the supplier can hide the people affected through those ten organizations. Both views are useful. Neither should silently replace the other.

Is this happening only in Japan?

No. There is direct evidence outside Japan, although it does not provide a comparable worldwide incidence rate.

On October 7, US cybersecurity company CrowdStrike reported ARTEX-assisted activity targeting South Korea’s financial sector, including data exfiltration. The operator remained unidentified. The researchers assessed likely Chinese-language use and a financial motive, while declining to attribute the activity to a known adversary. CrowdStrike’s research

That is enough to reject the idea that Japan is the only target. It is not enough to say Japan and South Korea experienced the same increase in breaches: the observations do not use a shared denominator or a standardized reporting period.

For a broader time window, Claude developer Anthropic’s September 2026 threat-intelligence report describes AI misuse across multiple regions and motives, including the compromise of a French retailer and mail theft involving Ukrainian and European targets. Its main reporting window covers activity from December 2025 to August 2026. Those observations belong in the background, not in an October Japanese victim total. They are vendor-observed cases, not a worldwide census. Anthropic’s report

AI can reduce the effort required to investigate targets and try approaches. Its exact contribution still needs to be established incident by incident. Observing AI use and proving that a particular personal-data breach depended on AI are different claims.

Where defenders can begin

I think the useful starting point is to trace information and permissions before memorizing the newest tool names.

Does information removed from a screen remain in the response? Can a different user obtain the same record? How far would a stolen support credential reach? If a supplier shuts down, who can contact whom?

These are questions I take from the public disclosures, not findings about undisclosed weaknesses at particular companies.

• Check permissions on the server for each operation and the data it touches.
• Alongside vulnerability fixes, review unnecessary public interfaces and excessive privileges.
• Limit the reach of credentials, including maintenance and support access.
• Keep useful investigation logs and monitor unusual retrieval and export activity.
• Confirm supplier contact routes and whether retained information is still needed.

Customers also have practical decisions to make. Before following an alarming notice, check through the app or official website you normally use. Review reused passwords and follow the affected service’s specific instructions. Notices such as IDARE’s warn about follow-up impersonation attempts.

But a customer cannot repair a company’s API or its supplier’s database by being more careful. I do not think the burden belongs on someone who simply wanted to use a service.

The people after the numbers

The accompanying reference register records the disclosures for which this research could check primary material, including suppliers and customer organizations. It distinguishes confirmed information exposure, possible exposure, and notices that do not establish a leak. It cannot capture incidents that have never been disclosed.

I would like to offer a complete national list. The evidence does not support that promise. Filling the gaps with assumptions would make the resulting advice less useful, too.

An address belongs to someone with a home to return to. A résumé belongs to someone looking for their next job. A newsletter subscription may belong to someone waiting for news from their community.

Large numbers draw our attention. Yet the point of protecting information is not to make everyone stop registering for things. It is to let people order lunch, book a trip, and apply for work with reasonable confidence.

In Part 2, we will read representative notices through everyday activities: eating out, booking travel, and looking for work. Beyond headlines about millions of victims, what extra tasks fall on customers? The answer also helps developers and service operators see the ordinary time they should be giving back.

Next: Part 2, “Reading a Shop’s Newsletter Shouldn’t Require Investigating Its Email Provider.”