Key takeaways

  • Yumil Link, whose Cuenote FC service sends bulk email for companies across Japan, has explained how attackers took a cumulative 47.86 million records from 49 client systems, Japan's third-largest breach of 2026.
  • In the first five systems, the attackers used a program vulnerability to plant a program, read databases directly, and spread to other servers using a maintenance and QA account that existed on every platform.
  • In 42 more, they did something quieter. They stole the sessions of people who were logged in at the time, entered the admin screen as them, and downloaded data with its ordinary CSV export. It looked like normal admin work, and was found only nine days after the attack was first noticed, by reviewing every system's logs.
  • The leaked address books held more than email addresses: 226,158 hashed passwords, and 420,419 sets of login details for a client's service that had closed in February 2026.
  • Yumil Link is removing standing shared admin rights and restricting admin screens and APIs by IP address, which some environments did not have.

What happened#

Yumil Link's three reports, of October 19, October 26 and November 11, give this timeline:

Date Event
Oct 16, 06:49 A Yumil Link staff member notices something wrong with their own account on one system and starts looking
Oct 16, 10:10 It identifies an attack through a vulnerability and blocks the attacking IP address
Oct 16, 20:46 A fix for the vulnerability is applied to all platforms
Oct 17–18 Malicious programs are found on four more systems. One shows a login with the support and QA account
Oct 18 It starts deleting that account from every platform, stops all systems in the affected data center, briefly blocks all overseas access, and adds IP restrictions to admin screens and APIs "where none had been set"
Oct 18, 20:25 Five minutes after new monitoring goes live, it catches a program being planted on another system, "System 07"
Oct 19 Reports to the police and the privacy regulator. First report: 5 systems, about 9 million records
Oct 22 Starts a review of every system's login and operation records
Oct 25, 21:45 Finds 42 more systems where data was exported
Oct 26 Second report: 49 systems, 51.63 million records
Nov 11 Third report: 47.86 million after removing duplicates and records not actually exported; two methods described

Each Cuenote FC system that leaked was dedicated to a single client company. Of 81 systems the attackers tried, the three shared by several companies leaked nothing; 49 of 78 dedicated systems did. Yumil Link says the unaffected environments "did not meet the conditions for the attack", without saying what those conditions were.

Two ways in#

Method 1: plant a program, read the database, move on. The attackers used a program vulnerability to put a malicious program on the server, connected directly to the database at the core of the system and exported data. From there they moved across an internal management network to other servers. Yumil Link names the shared maintenance and QA account, present on every platform, as what made that spread possible. Its first report adds that the attackers obtained the credentials of its support and QA staff through the vulnerability and tried them on other systems.

Method 2: steal a session, use the export button. The vulnerability also gave the attackers the temporary session information of legitimate users who were logged in at the time. With those sessions, they entered the admin screens of other systems as those users, without needing a password, and downloaded address books with the screen's own CSV download. In these systems, Yumil Link says, there was no planted program and no direct database access, and the activity "at first glance looked like legitimate administrator operations". It does not describe the vulnerability being exploited in each of them; they were entered with sessions stolen elsewhere.

Yumil Link presents the two as one attack, not two. Both started from the same vulnerability, its fix on October 16 addressed both, and it says the sessions used in the second method were stolen "from the initial foothold". It has not said who the attackers were, only that they came from overseas IP addresses.

That is why the count jumped. The first report counted only systems with the obvious signs of intrusion. The 42 systems found later showed none of them; they were found only after a review of web access and authentication logs reconstructed which sessions had been used by whom.

Yumil Link still has not named the vulnerability. Its second report called it a flaw in a library. The first item on its list of fixes is strict input validation in file access processing, which, in our reading, suggests the flaw lay in how the program handled files.

How a session is stolen from the server#

When someone logs in to a web service, the server issues a session ID, a long random string, and the browser sends it back with every request. The server checks it against its own record of who is logged in. After login, the session ID is the proof of login. The password, and any second factor, are checked only once, when the ID is issued. Anyone who holds a valid ID can put it in their own browser and be treated as that user.

Session IDs are usually stolen in one of two places:

  • On the user's side, by malware that copies browser cookies, or by a script injected into a page. This works one user at a time, and better habits and device security on the user's side can help.
  • On the server's side. The server keeps a record of every active session: in memory, in files, in a database or in a cache. Most widely used web frameworks store session IDs there in readable form, as the key used to look them up. Some now store only a hash of each ID, as is standard for passwords, but that is not yet the norm. An attacker who can read the server's files or data can collect the sessions of everyone logged in at that moment. Session IDs also turn up in access and debug logs, and a program planted on the server can read them from incoming requests.

A variant stores no sessions on the server at all, and instead signs the session data into the cookie with a secret key. That removes the store, but if the key leaks, an attacker can create a valid session for any user.

Yumil Link says the sessions were stolen "from the initial foothold", a server it had already lost control of, so this was theft on the server's side. It has not said where the sessions were kept or how they were read. A flaw that lets an attacker read files, which its fixes point to, would be enough to read session files. Either way, theft on the server's side means the client staff whose sessions were used need not have done anything wrong, and their own passwords and second factors could not have stopped it.

What was in the address books#

Cuenote FC stores the address books its clients upload to send mail: email addresses, plus whatever fields each client adds for personalizing or targeting messages. The third report breaks down the 47.86 million records by field:

Data Records
Email address 47,864,147
Member ID 30,500,167
Name 6,665,055
Gender 2,059,658
Postcode 1,823,551
Prefecture 1,212,868
Date of birth 949,217
Phone number 412,794
Password (hashed) 226,158
Address 152,868
Company name 98,381
School name 10,608
Login details for a service a client ran, closed in February 2026 420,419

These are cumulative counts, and one person can appear in several clients' address books. No card data has been found.

Two lines stand out. 226,158 hashed passwords were among the leaked data. Cuenote FC offers sign-up pages and a "my page" where subscribers update their details, which may account for some of them; Yumil Link does not say. And 420,419 sets of login details belonged to a client's service that had been shut down eight months earlier, but whose data was still sitting in the mailing system.

Who was affected#

Yumil Link has not named its clients. Several have published their own notices, including:

  • istyle, which runs the beauty site @cosme: email addresses of about 2.8 million people, on our breach list
  • JR Central, JR West and JR Kyushu, for members of the Shinkansen booking services EX reservation and smart EX. On October 16, Yumil Link had told them EX customers were not affected; on October 26, that data had been viewed or taken
  • The Resona Group banks, the Mainichi Shimbun, Cybozu, ValueCommerce and Impress, according to INTERNET Watch

Spam claiming to come from the card company Saison, sent from Yumil Link's own domain, has also been seen. For how this case compares with four other email delivery services breached in the same weeks, see our analysis of the email vendor breaches.

  • Code: strict input validation in file access processing, revised design and review rules, AI-assisted code review and automated vulnerability detection, and regular outside testing
  • Privileged access: removing shared admin rights left permanently in its systems. Maintenance staff will get the least privilege needed for each task, only for that task, through a gateway that requires multi-factor authentication
  • Monitoring: monitoring of every server with alerts on suspicious files, watched around the clock

A final report will follow when the outside forensic investigators deliver theirs. The effect on earnings is under review.

What we don't know yet#

  • What the vulnerability was, and in which library
  • How sessions taken at the initial foothold could be used on 42 other systems. The attack was first noticed on a staff member's account in what the third report calls an operations management system; whether sessions or logins for many systems passed through it is not stated
  • How a program came to be planted on "System 07" on October 18, two days after the fix was applied
  • What "the conditions for the attack" were, and why dedicated systems met them and shared ones did not
  • Whether clients could see the exports in their own logs
  • Why clients' address books held passwords and data from a closed service
  • Which companies the 49 systems belong to, and how many people are affected after removing overlaps

Our view#

Multi-factor authentication does not protect a stolen session. The second method skipped the login entirely. Once the attackers had a session that had already passed authentication, no password, and no second factor, stood in their way. MFA remains essential, and Yumil Link is right to require it for maintenance access. But services that hold other people's data also need to protect what happens after login: sessions tied to the device or network they began on, short session lifetimes, and fresh authentication before sensitive actions.

A legitimate export is the quietest way out. In 42 of the 49 systems, data left through a button the admin screen offers its users. Nothing was planted, and nothing looked wrong until the logs were rebuilt. The same thing happened at the start of the Arara Message breach, where attackers logged in to a shared admin screen and used its export. Bulk export from any service holding personal data should be treated as a sensitive action: logged in detail, re-authenticated, limited by volume and by where it comes from, and reported to the client account's owner when it happens.

A shared maintenance account is a master key. One account, present on every platform for the vendor's own convenience, turned the compromise of one system into the compromise of others. It is the same weak point we saw across the email delivery vendors, and in attacks on managed service providers generally. Yumil Link's fix, task-by-task access through an MFA gateway, is the right one. It should not have taken a breach.

Clients put more in their mailing vendor than mail needs. The login details of a service that closed in February do not help anyone send a newsletter. Every field a company syncs to a marketing tool is a field that leaks when the tool does, and data from a service that no longer exists should not exist anywhere. Companies using such services should check which fields they upload, and delete address books they no longer use.

What this means for practitioners#

If you run a service that holds customers' data:

  • Treat export as a privileged action. Require fresh authentication, cap volume, alert on unusual exports, and show them in the client's own audit log.
  • Bind and expire sessions. Tie sessions to the client's network or device where possible, keep them short, and invalidate them on any sign of compromise.
  • Remove standing shared accounts. Give staff individual, just-in-time access through MFA, and log it where customers can see it.
  • Restrict admin screens and APIs by source address by default, not as an option.

If you use one:

  • Ask your vendor how its staff access your environment, and whether you can see exports and staff logins in your logs.
  • Upload only the fields your mail uses, and delete address books for services and campaigns that have ended.
  • Treat "not affected" as provisional. As the EX case shows, a vendor's first assessment can change.

Japanese terms at a glance#

Japanese Reading Meaning
メール配信サービス mēru haishin sābisu Email delivery service
不正プログラム fusei puroguramu Malicious program
セッション情報 sesshon jōhō Session information
なりすまし narisumashi Impersonation
正規機能の悪用 seiki kinō no akuyō Abuse of a legitimate function
CSV出力 shī-esu-bui shutsuryoku CSV export
共通保守アカウント kyōtsū hoshu akaunto Shared maintenance account
横展開 yoko tenkai Lateral movement
延べ件数 nobe kensū Cumulative count (may include duplicates)