Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Get Started ↗ JA
Home / Critical Brief / No. 154
No. 154 Critical Brief · Agent Authority Proof

Yumirlink: In the Cuenote FC email delivery service, a vulnerability exposed support staff credentials and data including email addresses was output from databases (company's first report)

Nothing checks a provider staff login against which customer's request it is for

~9Mrecords
Records containing email addresses that Yumirlink estimates were output (cumulative, including duplicates). The deduplicated number of people has not been disclosed
5systems
Single-customer (dedicated ASP plan) Cuenote FC systems managed by Yumirlink where unauthorized access and data output were confirmed. Which customers they belong to has not been disclosed
10-16→10-19
From confirming the unauthorized access to the first public report
CountryJapan
Incident date2026-10-16
Published2026-10-23
AuthorsLemma Critical Team
Contents
  1. 01TL;DR
  2. 02What happened
  3. 03Timeline — disclosure and response
  4. 04Why it wasn’t stopped
  5. 05How to counter this
  6. 06Sources

TL;DR

  1. 01What happened

    On October 19, 2026, Yumirlink disclosed unauthorized access to part of its Cuenote FC email delivery service, with personal data taken out. Through a program vulnerability, attackers obtained support and quality staff credentials, installed a malicious program and output data from databases — about 9 million records with email addresses across five single-customer systems, by the company’s estimate.

  2. 02Why it was hard to tell

    The credentials belonged to the provider’s staff, not to a customer. The attackers also tried them on other systems, and Yumirlink says it removed the staff information from other systems.

  3. 03The missing layer

    Yumirlink noticed early on October 16, and its access logs showed the data had already been output. What failed was the layer that checks a provider staff login against which customer’s request it is for.

What happened

The service
Cuenote FC is an email delivery service companies and local governments use to send newsletters and notices in bulk. Five systems managed by Yumirlink on the “dedicated ASP plan”, which gives each customer its own system, were affected (per Yumirlink).
The route
Through a program vulnerability, attackers obtained support and quality staff credentials for the service. They installed a malicious program and output data from databases, and used the staff credentials to attempt authentication to other systems (per Yumirlink).
Not disclosed
Which program was vulnerable, when the intrusion began, how many staff and what rights they had, whether MFA was used, whether the data output used the staff credentials, whether the attempts on other systems succeeded, and which customers the five systems belong to.
What was output
Information including email addresses, about 9 million records cumulative (estimate). The deduplicated number of people has not been disclosed. Some customer and municipal disclosures list names, company names, industry and internal ID numbers.
Customer and municipal disclosures
Dai Nippon Printing (honto) was told that newsletter subscribers’ name, email address and ID number may have leaked. Saitama Prefecture said data on 669 parties in a newsletter run by its contractor may have leaked. NTTPC said no impact was confirmed but could not be ruled out. Others said no leak was confirmed.
Yumirlink’s response
It immediately cut the affected servers off the network, built and applied a fix for the vulnerability, and removed the staff information from other systems. It reported to investigators and is investigating with outside experts. Its support site says customers must now register source IP addresses for the admin console and API.

Glossary
Cuenote FC — Yumirlink's email delivery service, used by companies and local governments to send member notices and newsletters in bulk. The "dedicated ASP plan" gives each customer its own system.
Support and quality staff — Staff at the provider (Yumirlink) who handle customer inquiries and check quality on customer systems.
Credentials — The ID, password and the like used to enter a system. If taken, they can be used with the owner's rights.

Exhibit 1The sequence, as disclosed

The stopping point is ④. Had each provider staff login been matched to which customer's request it was for, authentication to systems with no request would not go through. Whether the attempts on other systems succeeded, and how ③'s output was done, have not been disclosed.

Attacker
1
Exploits a program vulnerability

Which program has not been disclosed.

Attacker
2
Obtains support and quality staff credentials

The provider's staff.

Attacker
3
Installs a malicious program and outputs data from databases

Five systems, about 9 million records (estimate).

Attacker
4
Tries other systems with the staff credentials

Whether it succeeded has not been disclosed.

Timeline — disclosure and response

  • Early morning, Yumirlink staff confirm unauthorized access on some systems. The servers are immediately cut off the network.
  • From around 14:15, San-yo Shimbun’s news-alert emails can no longer be delivered (per San-yo Shimbun). In its second notice the next day, the paper linked this to its delivery contractor, Yumirlink.
  • Yumirlink posts a notice on its support site and files its first report at 17:05. At 19:05 it adds Cuenote FC and the five dedicated-ASP-plan systems to the version on its own site.
  • Saitama Prefecture, NTTPC, municipalities and others disclose the impact on their users. Oe Town in Yamagata adds at 11:00 the same day that no leak was confirmed.
  • Dai Nippon Printing discloses a possible leak of honto customer data.

The facts rest on Yumirlink’s first report and on customer and municipal disclosures (all primary). Yumirlink’s report says in its body that taking the data out “was confirmed”, while its heading speaks of “systems that may have leaked”. It says the staff credentials were “used” only for the attempts on other systems; for the data output it says a malicious program was installed. As of October 23, no second report had been issued.

After disclosure

  • Yumirlink: Lists fixing the vulnerability, deleting the staff credentials and setting up detection of malicious programs as preventive measures. It says it does not currently accept settings that allow access to the admin console and API from any source. The impact on earnings is under review.
  • Customers and municipalities: Some paused and resumed delivery, and some cut their link to the delivery system. They warn about spoofed email.

Why it wasn’t stopped

This case was not only about a vulnerability. The provider’s staff credentials, once taken, were also used in attempts to authenticate to other systems, without being tied to any customer’s request for work.

The core of this case
The provider's staff credentials, not tied to any customer's request for work, were also used in attempts to authenticate to other systems.
Exhibit 2The detection–proof gap

Proof here means checking, before provider staff enter a system, that "this customer has requested this work", and recording that. Detection means noticing after unauthorized access has happened.

Proof layer · absentBefore entering, match the login to a customer's request
The gapLogins to other systems
were attempted
Detection layer · noticedSpots the access and cuts the servers off
STEP 1
Credentials taken
STEP 2
Tried on other systems
STEP 3
Noticed 10-16
STEP 4
Staff info removed

Detection worked: Yumirlink cut the servers off and removed the staff information from other systems. But “holding provider staff credentials” and “this customer has requested this work” are separate facts, and the disclosures show no layer matching the first to the second. That distance is the detection–proof gap, and it is a structural one.

The same structure appears in ConnectWise’s app identities (a vendor’s credential let operations in customer tenants go through); there an app changed permissions, here a person’s staff login reached toward systems outside its assignment.

How to counter this

Each time provider staff enter a customer’s system, match it to which customer’s request the work is for. Then stolen credentials alone cannot open systems with no request. This is not a substitute for detection; it sits in front of it.

Industries and operations to watch

IndustryGovernment & public sector
Local governments that send notices and business newsletters through outside delivery services. When a contractor holds the contract, it is hard for the government to see where the recipient list sits and on which plan.
IndustryProcurement & supply chain
Companies that entrust member and customer newsletters to a delivery SaaS, sometimes syncing names and internal IDs for delivery.
OperationAccounts & permissions
Managing provider staff accounts placed in your delivery environment, and source settings for the admin console and API.

Do today’s controls close it?

ControlThis caseWhy
Fixing the vulnerabilityPartialIt closes the entry, but fixing it alone does not change what a credential holder is allowed to do.
Customers’ MFANot relevantThe credentials taken were the provider’s staff credentials.
Restricting source IPs for the admin console and APIPartialIt narrows the customer-side entry. Whether it would stop provider staff logins is not clear from the disclosures.
Intrusion detectionPartialIt noticed after the access logs showed the output had happened.
ControlsWhat is needed
  1. Tie staff logins to the customers and work they are assigned. Do not keep staff information on every system at all times. Removing it from other systems, as Yumirlink did, points this way.
  2. Match each entry to a customer’s request before letting it through. Refuse logins not tied to a request, such as an inquiry number, even with the right password, and time-limit the ones allowed.
  3. Record which request led into which customer’s system. Keep it separately from the provider, in a form customers can check later: in other words, as proof.
CheckChecklist

Three things to confirm in your organisation about SaaS that holds your data, such as email delivery

  • Have you limited the admin console and API to your own IP addresses, rather than leaving them open to all?
  • Does your recipient list carry fields you don’t need for delivery, such as names, industry or internal IDs?
  • Is there an agreement that the provider will tell you, after an incident, whether you were affected?

Note: if a malicious program on the server reads the database directly, data can be output without passing this check; it cannot be said that this mechanism would have stopped the roughly 9 million records here. Misuse within an assigned customer’s request also passes. How the data was output and whether the attempts on other systems succeeded have not been disclosed yet. If follow-up reports reveal them, this Brief will be revised.

Sources

  1. Primary, timely disclosureYumirlink Report on unauthorized access to our systems (first report)2026-10-19, Japanese · release.tdnet.info/inbs/140120261019553124.pdf
  2. Primary, company disclosureYumirlink Report on unauthorized access to our systems (first report, 19:05 update)2026-10-19, Japanese · cuenote.jp/information/news/unauthorizedaccess
  3. Primary, support siteYumirlink Cuenote ASP service: report on unauthorized access (service status)2026-10-19, Japanese · cuenote.ne.jp/2026/10/20260619
  4. Primary, customer disclosureDai Nippon Printing Possible leak of customer data due to unauthorized access at an outside contractor2026-10-21, Japanese · 2dfacto.co.jp/pdf/honto_20261021_001.pdf
  5. Primary, customer disclosureNTTPC Possible leak of email addresses and other data following unauthorized access at Yumirlink2026-10-20, Japanese · nttpc.co.jp/press/info/2026/10/202610201600
  6. Primary, municipal disclosureSaitama Prefecture Possible personal data leak following unauthorized access at Yumirlink2026-10-20, Japanese · pref.saitama.lg.jp/a0903/news/page/news2026102001
  7. Primary, municipal disclosureOe Town Unauthorized access at the company running the town’s registered email system2026-10-20, Japanese · at 11:00 added that no leak was confirmed · town.oe.yamagata.jp/news/2001
  8. Primary, customer disclosureSan-yo Shimbun Suspension of email delivery services (second notice) and unauthorized access at a contractor2026-10-19, Japanese · c.sanyonews.jp/release/2026/10/20261019230413
1 more (reporting, analysis)
  1. PressNHK Email delivery company for businesses and local governments breached, 9 million records may have leaked2026-10-19, Japanese · news.web.nhk/newsweb/na/nd-20261019de61855

References: “The last layer left in AI-era cyber defense”

The same method elsewhereSee all 12 "Account takeover" cases Get new cases and checks like these by email

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Lemma Critical Team. (2026).
"Yumirlink: In the Cuenote FC email delivery service, a vulnerability exposed support staff credentials and data including email addresses was output from databases (company's first report) — Nothing checks a provider staff login against which customer's request it is for".
Lemma Critical Brief No.154. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/154-yumirlink-cuenote-support-credential-db-export/
Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma attaches cryptographic proofs to data and AI execution, so the receiving side can confirm authenticity without asking the issuer. Detection stays; a proof layer is added in front of it.