Blastmail and Cuenote FC Breaches: Japan's Email SaaS Week

Two Japanese bulk email platforms disclosed intrusions within days of each other in October 2026: Ymirlink's Cuenote FC (detected 16 October) and Rakus Light Cloud's Blastmail (stopped 21 October). Customers that never touched either system lost subscriber lists. If you send mail through either, confirm your exposure, warn recipients and harden against impersonation now.

This is a software as a service supply chain story. The organisations now writing apology notices, including city halls, a prefectural police force, an energy company, a toy maker and a regional bank's partner, did not run the breached servers. They rented a mail delivery platform, uploaded their subscriber lists, and those lists left with the attacker. The post below sets out what each provider has published, a minute level timeline, every concrete detail the primary notices give (data fields, counts, systems, contact channels, the spoofed sender examples Ymirlink published), step by step detection and remediation for customers and recipients, lessons for anyone who runs a multi tenant platform, and what would have helped. For the wider context of this month in Japan, see our round up of the October 2026 Japanese breach wave and our earlier piece on third party risk after the IDCF Cloud ransomware incident.

The short version

Sources for every row are the providers' own notices, linked in the Sources section. Nothing published so far connects the two intrusions to each other or to the same attacker.

What happened

Cuenote FC (Ymirlink)

Ymirlink sells the Cuenote family of messaging products in Japan. Its 19 October timely disclosure on the Tokyo Stock Exchange's TDnet, titled as a first report on unauthorised access to its systems, says a member of staff noticed unauthorised access to part of the system in the early hours of Friday 16 October. Its access records showed that a program vulnerability was exploited, that the attacker obtained the credentials Ymirlink's support and quality control staff use for the service, installed a malicious program that output data from a database, and tried the same credentials on other systems. The Technical details section below breaks this chain down step by step. Ymirlink isolated the servers, fixed the program, removed the staff credentials from other systems, added detection and reported to investigative authorities, and plans a detailed investigation with outside experts.

On scope, the disclosure says unauthorised access and data output were confirmed on five systems in total, and that the company estimates about 9 million records including email addresses were output across those five. The Japanese word used is 延べ (nobe), which means a cumulative count with duplicates included. It is not a count of people. An update to the notice on Cuenote's own site at 19:05 the same evening added one clarifying line: the affected systems are five systems on the Cuenote FC dedicated ASP plan (専用ASPプラン), the hosted plan where Ymirlink runs a dedicated environment for a customer.

The disclosure says the effect on results for the year ending December 2026 is under review. ITmedia NEWS, citing Ymirlink's website, reports that the Cuenote series sends about 8.9 billion emails and SMS messages a month and has more than 2,900 system contracts. Those are platform wide figures, not breach figures.

Ymirlink has not named the vulnerable program, said when the access began, or listed which customers' environments were among the five.

Blastmail (Rakus Light Cloud)

Blastmail is a bulk email service run by Rakus Light Cloud. Rakus, the parent, published its first report on 21 October: suspicious access had been detected, Blastmail had been stopped in an emergency from 00:30 that morning, the cause and scope were under investigation, and the company had already reported to the Personal Information Protection Commission (PPC) and to JIPDEC, the body that runs Japan's PrivacyMark scheme. It also said other Rakus and Rakus Light Cloud services were not affected.

Rakus's second report, the same day, moved from "suspicious access" to confirmed theft. According to Rakus:

• An external party broke into two of Rakus Light Cloud's API servers and executed commands on them.
• From there it connected to the sales management system and to the service database, and took data out.
• From the sales management system, data on every Blastmail contract holder was taken: company name, contact name, phone number, email address, billing email address, and contract and payment history, among other items.
• For some customers, delivery related information such as recipient lists also leaked.
• Rakus Light Cloud does not hold credit card numbers.
• The route into the API servers is still under investigation.

Blastmail's own notice page, which Rakus Light Cloud has updated several times a day since, adds that the admin screen and the API have been unavailable since 00:30 and that mail delivery stopped at about 01:00 on 21 October.

From 14:00 on 22 October the company began contacting customers whose delivery data had leaked. On 23 October it reported 288 such contracts, all contacted by 14:00 that day. On the morning of 24 October it said its internal investigation was complete and the number had risen to 344, and by 13:20 it said all 344 had been contacted. An outside forensic investigation continues, and the company warns the figure may still change. The service restart date is "undecided", and the next update was scheduled for 10:00 on Sunday 25 October.

Rakus's precautionary pause of seven other services

Late on 21 October Rakus paused seven other cloud services, its corporate site, and the product and support sites for all its services. Its news release names the seven: Rakuraku Hanbai, Rakuraku Kintai, Rakuraku Jido Otai, Rakuraku Mail Marketing, ChatDealer, Kurumeru and Raku Tel. The release calls this a preventive step "in light of recent cyber attack risk" and says no unauthorised access or leak had been found in those services. A notice on the Rakuraku Meisai product site gives the time as about 21:30 on 21 October and describes the trigger as a serious vulnerability found in software the company uses. Everything was back on 22 October, with the Meisai product site reopening at about 11:00.

On 22 October Rakus also published a status table for "the PHP vulnerability" in the news. It lists the same seven services as "addressed" and six others (Rakuraku Seisan, Meisai, Seikyu, Denshi Hozon, Saiken Kanri and Jinji Romu) as "no action needed", and says no service was affected. An incident timeline aggregator identifies this as the PHP2Shell pair, CVE-2026-109618 and CVE-2026-109619. Blastmail does not appear in that table.

Rakus has not said that the Blastmail intrusion involved PHP2Shell or any PHP flaw, and neither does anything else we read. Please do not read a link into the overlap of dates. Our PHP2Shell explainer covers that vulnerability on its own terms.

Timeline

All times are Japan Standard Time (UTC+9) as published. Where a source gives only a date, the time column says so.

Who is affected

Customers named in their own notices

Each of the organisations below published its own notice. We list only what each one says about itself.

Two points stand out. First, giftee and Tamiya were told they were outside the 288, but the count rose to 344 the next morning, so both said they would keep watching. Second, every one of these notices warns recipients about mail impersonating the organisation, which is the most likely harm from a leaked list.

Others reported by aggregators and press

An incident timeline aggregator lists about 30 linked notices under the Blastmail incident, including Aomori Prefectural Police (a crime prevention mail magazine), Hiroshima Prefecture (a consumer protection mail magazine), the cities of Ichinoseki, Kagoshima, Kasugai, Kyoto, Nanjo, Shimonoseki, Tokamachi, Utsunomiya, Yokohama (three separate notices) and Yuzawa, Toyama and Yamanashi prefectures, and Nagoya Bank, whose notice concerns an outside mail service used by a defined contribution pension firm it works with. NHK reported on 23 October that Hiroshima Prefecture and Hiroshima City announced possible leaks of mail magazine subscribers and prize draw applicants; the part of the NHK article we could read does not name the mail platform. According to press reports collected by the same aggregator, JR Shikoku announced on 22 October a possible leak of about 30,000 tour website members; we could not fetch JR Shikoku's own notice.

For Cuenote FC, a Japanese security consultancy's incident page reports that Saitama Prefecture announced a possible leak of 669 parties' details (business name, contact name, email and industry; for individuals, name, email and industry) through a contractor that ran a smart agriculture information site, and that a telecom services company issued a precautionary notice to its users. That page also notes a two layer chain in the Saitama case: the prefecture outsourced to a contractor, and the contractor used Ymirlink. We have not fetched those organisations' own notices, so treat these as reported, not confirmed.

Who is not affected, as far as anyone has said

Rakus says its other services were not affected. Rakus Light Cloud holds no card numbers. Every customer notice we read says its own network was not involved. Cuenote customers outside the five dedicated ASP plan systems are, on Ymirlink's current account, not in scope, but no customer list has been published, so ask your account contact.

Technical details

Neither provider has published a CVE, a malware hash, an attacker IP address or a named vulnerable component. What follows is every concrete, defender useful detail the primary sources do give, with the source for each.

Cuenote FC: disclosed attack chain

Systems: "Cuenote FC dedicated ASP plan, 5 systems in total" (Cuenote notice, 19:05 update). Volume: about 9 million records including email addresses, cumulative, estimated (TDnet disclosure). Data fields beyond "including email addresses" are under investigation.

Blastmail: disclosed attack chain

Data exposed, field by field

The right hand column matters most for recipients. A delivery list holds whatever the sender chose to upload for merge fields, so the exposure varies by sender. JAPEX's investor invitation list, for example, included postal address and phone; Tamiya's included age only when it appeared in the message.

Reading the counts

• "About 9 million" (Cuenote FC) is a cumulative estimate of output records with duplicates, across five systems. It is not a number of people or of customers.
• 288 and then 344 (Blastmail) are numbers of contracts whose data beyond the contract record leaked, according to Rakus Light Cloud's internal investigation. They are not numbers of people. The company says the figure may change as the outside investigation proceeds.
• "All contract holders" (Blastmail) covers the sales management data. Rakus Light Cloud has not published how many contract holders it has.

Indicators and verification points

Ymirlink published one set of concrete indicators, on 20 October: spam sent using its domain while impersonating third parties. Ymirlink says it never instructs mail like this to be sent from its domain. It did not say whether this spam is connected to the breach, so treat it as a parallel warning, not proof of misuse of stolen data.

Ymirlink's advice: do not reply, click links or scan QR codes; delete the message; if you have already engaged with it or suffered a loss, contact your local police.

Legitimate contact channels, useful for checking whether a "breach notice" you receive is real:

Note that Ymirlink's breach mailbox is on cuenote.ne.jp, while the spoofed spam used cuenote.jp. Both are Ymirlink domains. Do not treat a sender domain alone as proof either way; check the notice on the official site.

PHP2Shell: what is and is not connected

The Cuenote intrusion was detected on 16 October, five days before the PHP security releases. Blastmail was stopped at 00:30 on 21 October. Neither provider has named its entry point. If you want the PHP2Shell details for your own estate, see how to find and patch every PHP runtime after PHP2Shell and how Japan and South Korea responded.

Regulatory mechanics in Japan

• The PPC's guidance says a leak that must be reported should be reported promptly once discovered, with a final report within 60 days of discovery where the leak may have been caused for an unlawful purpose, as an intrusion like this would be.
• Rakus Light Cloud offers to file a joint report to the PPC with each affected Blastmail customer. Customers apply through a form linked from the Blastmail joint report page by Thursday 29 October 2026.
• Rakus Light Cloud says it confirmed with the PPC that a joint report will not be treated as late even if it passes the usual window for the preliminary report.
• A joint report covers the PPC only. Customers whose delivery lists leaked must still notify the affected individuals themselves. Customers that hold the PrivacyMark must report to JIPDEC separately.
• Ymirlink's disclosure says it reported to investigative authorities. A security consultancy's incident page notes that, as of 21 October, the disclosure did not mention a PPC report.

How an email platform breach reaches you

A bulk email platform holds your account record (company, contact, billing, payment history), your recipients (addresses plus whatever merge fields you used), and a place in your SPF record. When an attacker reaches the shared back end, every tenant is exposed at once. In Cuenote FC's case the shared element was a support credential that worked across systems; in Blastmail's, an API tier that could reach both the billing system and the tenant database. Neither provider has said sending infrastructure or signing keys were misused.

The likely harms are targeted phishing to your recipients about events they really signed up for, invoice fraud aimed at your finance team using real contract history, fake breach notices pointing to lookalike sites, and the regulatory work of reporting and notifying.

Detection: step by step

These steps are for organisations that send mail, and for IT teams protecting recipients.

1. Find out whether you use either platform

Teams often do not know which marketing tool holds which list. Check four places.

DNS. Look at your SPF records for any include that points at a bulk email provider.

for d in example.co.jp news.example.co.jp; do
  echo "== $d"; dig +short TXT "$d" | grep -i "v=spf1"
done
# Look for include: entries naming an email delivery provider,
# for example anything containing "blastmail" or "cuenote".
dig +short TXT example.co.jp | grep -iE "blastmail|cuenote"

Mail headers. Open a recent campaign as received in an outside mailbox and read the headers. The Return-Path, the d= value in DKIM-Signature and the first Received hops show which platform actually sent it.

Code and configuration. Search your repositories for integrations that push lists or trigger sends through an API.

git grep -n -i -E "blastmail|cuenote" -- .
# Across an organisation on GitHub:
gh search code "blastmail" --owner your-org
gh search code "cuenote" --owner your-org

Finance and procurement. Search invoices and card statements for either provider. Departments, local branches and outside contractors often buy these services on a card without telling IT, which is exactly how a prefecture can end up two contracts away from the breached system.

2. Check what the provider has told you

• Blastmail: Rakus Light Cloud says all 344 contracts with delivery data leaks were contacted individually by 13:20 on 24 October, and all contract holders' sales management data was taken. If you are a Blastmail customer and have not been contacted, your contract record was still taken; check the spam folder of the contact and billing addresses on file, then confirm through support@blastmail.jp.
• Cuenote FC: ask your Ymirlink account contact whether your environment is one of the five dedicated ASP plan systems, or use the dedicated line 03-6820-0088.
• Ask your contractors. If a vendor runs a newsletter, survey or event registration for you, ask which mail platform they use.

3. Hunt for impersonation in your own mail flow

Microsoft 365 (Exchange Online PowerShell):

Connect-ExchangeOnline
Get-MessageTraceV2 -SenderAddress "info@cuenote.jp" `
  -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date) |
  Select-Object Received, RecipientAddress, Subject, Status

Google Workspace: in Gmail search, or in the admin console's email log search:

from:info@cuenote.jp subject:(ご利用確認のお願い OR 利用内容確認のご依頼)

Postfix or other Linux mail relays:

grep -h "from=<info@cuenote.jp>" /var/log/mail.log* | head

Also search for mail that uses your own brand in a breach context, such as subjects containing your organisation's name plus "お詫び" (apology) or "確認" (confirmation), arriving from domains you do not own.

4. Watch the finance side

Because Blastmail contract and payment history was taken for every customer, brief your accounts payable team. Any request to change bank details, settle an "unpaid" invoice or re-enter card details for Blastmail, Rakus or Ymirlink should be checked by phone using a number you already have, not one in the message.

5. Seed your lists

If you send to large lists, add a few unique, monitored addresses (canary addresses) to each list and each platform. Mail arriving at one of those from anyone other than your provider is direct evidence a specific list is being misused, and it tells you which platform it came from.

Remediation: step by step

If you are a Blastmail customer

1. Read the latest update on the Blastmail status page; it is updated at least daily, weekends included.
2. Decide on PPC reporting. If you want the joint report, apply through the form on the joint report page before 29 October. If you hold the PrivacyMark, report to JIPDEC yourself.
3. Notify recipients whose data was on a leaked list. A joint PPC report does not cover this.
4. Publish a notice on your own site and point recipients to it, so they can verify any mail claiming to be from you. Natori City's notice is a good model: it tells people to check the official site rather than follow links in an apology mail.
5. When the service returns, reissue any API key or password your integrations use, and review the users on your Blastmail account. Rakus Light Cloud has not said that credentials were taken; treat this as a precaution, and follow the provider's own instructions if it publishes any.
6. Plan for the outage. The restart date is open. If you send transactional or emergency mail through Blastmail (one city's emergency and disaster mail service is among the notices), move that traffic to another channel now rather than waiting.

If you are a Cuenote FC customer

1. Confirm with Ymirlink whether your environment is one of the five affected systems.
2. If it is, find out which fields your lists held and work out your reporting duty. Ymirlink has said the details of the output data are still being investigated, so ask for the field list for your environment specifically.
3. Brief recipients and your support desk about the spoofed info@cuenote.jp mail, and add a quarantine rule for the published subjects.

New-TransportRule -Name "Quarantine Cuenote impersonation (Ymirlink 20 Oct)" `
  -From "info@cuenote.jp" `
  -SubjectContainsWords "ご利用確認のお願い","利用内容確認のご依頼" `
  -Quarantine $true

4. Ask how operator access to your dedicated environment works now. The disclosed chain ran through a support credential; it is fair to ask whether support access is now separate per customer and how it is logged.

For any sender, whichever platform you use

1. Enforce DMARC on your sending domains so that lookalike mail fails, and check where you stand:

dig +short TXT _dmarc.example.co.jp
# Aim for p=quarantine or p=reject once all legitimate senders pass SPF or DKIM.

2. Remove stale includes from SPF for any platform you no longer use. A forgotten include still authorises that platform to send as you.
3. Trim what you upload. If a campaign only needs an email address, do not upload age, address or member ID as merge fields. The JAPEX and Tamiya notices show that what leaks is whatever the sender put on the list.
4. Keep a register of which platform holds which list, who owns it, and where the provider publishes incident notices.

If you received mail from an affected sender

• Do not follow links in any apology or "confirm your details" mail. Go to the sender's official site and look for the same notice.
• Do not reply to or scan QR codes in mail like the samples Ymirlink published.
• Expect more convincing phishing about events you really signed up for. Be suspicious of urgency and payment requests.

If you run a multi tenant platform yourself

Both disclosed chains are short, and both point at design choices any software as a service team can check this week. Neither provider has said these controls were missing; this is a checklist for your own platform.

1. No shared operator credential across tenants. Issue support access per tenant, just in time, with short expiry and strong authentication.
2. The API tier cannot reach the back office. Public API servers should have no route or database credentials for billing and sales systems.
3. Command execution on API hosts is an alarm. Alert on new executables, unexpected child processes of the application server and new outbound destinations.
4. Bulk reads page someone. A full export from a tenant database or sales system should never be silent; log query volume per service account.
5. Key tenant data separately, so one foothold yields less.
6. Know what the internet facing tier runs. Keep a current software bill of materials for every API host and rebuild when a fix ships.
7. Rehearse the emergency stop and the customer update cadence.
8. Be able to answer "which fields did my lists contain" by query, per tenant, so notification does not wait on manual review.

What changed since first reports

• Blastmail scope grew. The first report said only "under investigation". The second confirmed theft of all contract holders' records and some delivery lists. The number of contracts with delivery data leaked went from 288 (23 October, 10:00) to 344 (24 October, 10:00) once the internal investigation finished.
• Cuenote scope was clarified, not changed. The 19:05 update on 19 October added that the five systems are on the dedicated ASP plan. No later update to the breach notice was on Cuenote's site when we checked on 24 October.
• Two customers that said they were clear are now waiting again. giftee and Tamiya both said they were outside the 288 on 23 October; the count rose afterwards.
• Rakus's other services went down and came back. The precautionary pause on the night of 21 October ended the next day with no unauthorised access found.
• PHP2Shell entered the conversation. Both providers published PHP vulnerability statements on 22 October. Neither tied its breach to PHP.

Open questions

• What was the Cuenote "program vulnerability", and is it in Ymirlink's own code or in a third party component?
• How did the attacker get into Blastmail's API servers, and when did access begin?
• Which customers' environments were among Cuenote's five systems, and how many distinct people are in the 9 million records?
• How many contract holders does Blastmail have in total?
• Were any sending credentials, DKIM keys or API keys exposed on either platform?
• Is the spoofed info@cuenote.jp spam connected to the breach, or a coincidence?
• When will Blastmail restart, and what changes come with it?
• Are the two incidents connected? Nothing published says so.

What would have helped

Practices any team can use

• A live register of every platform that holds your personal data, including ones bought by departments or contractors, with the provider's notice URL and a named owner.
• Data minimisation in uploads, and deleting lists from the platform after a campaign where possible.
• Contract terms for incidents: notification time, a per tenant field list on request, and help with regulatory reporting, like the joint report Rakus Light Cloud now offers.
• DMARC enforcement, clean SPF and canary addresses, so impersonation fails and misuse is traceable.
• A pre written recipient notice that points people to your official site.
• For platform operators, the eight point checklist in the previous section.

Where Safeguard fits

Be clear about the boundary first. Safeguard cannot see inside Blastmail or Cuenote FC. They are hosted services run by other companies, and nothing Safeguard does would have stopped an attacker inside those platforms or prevented these leaks. What Safeguard can do sits on either side of that boundary.

On your side, as a customer of email platforms:

• Third party risk management (GA). Safeguard's Third-Party Risk Manager lets you keep a vendor directory with risk tiers and contracts, request SBOMs, projects or products from suppliers, score and continuously monitor supplier risk, and receive alerts on events such as a new critical vulnerability or a CISA KEV addition affecting what a supplier ships you. That is a structured version of the register above. It does not detect a vendor breach before the vendor discloses it.
• Your integration code. The services that push lists and trigger sends through a provider's API are code you own. safeguard scan --dir . builds an SBOM and matches it against vulnerability databases, with reachability analysis to rank what your code actually calls; safeguard scan --image <name> does the same for the containers those services run in. Results land as JSON under ./output. In the platform you can see which projects contain a given component and version, which is how you answer "where else do we run this" in minutes.
• Policies and gates. Gates can block, warn, notify or require approval at checkpoints, so a known vulnerable component in a service that handles personal data cannot quietly ship.

On the provider side, if you run a platform like these: an up to date SBOM of every API host image, so you know within minutes which hosts carry an old runtime or library; a policy gate that stops a rebuild from reintroducing it; autonomous remediation pull requests when a fixed version exists (off by default); and the Safeguard CLI's assistant, which edits code and runs commands with your approval under /permissions modes (Ask, Accept edits, Plan, Auto, Strict), plus safeguard exec for CI.

None of that would tell you about an undisclosed bug in a provider's own application code, about a misused support credential, or about a database export. Those need the operational controls in the platform checklist above.

Zero-Day Discovery and Gold

Two GA capabilities are designed for the "vulnerable program" part of this kind of story, in the parts of a stack built from open source packages.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems. Findings are issued as SGZ advisories before they reach public CVE databases. It is aimed at open source packages; a provider's proprietary application code, which is where Ymirlink's "program vulnerability" may sit, is not something it would cover unless that code is published in one of those ecosystems.
• Gold Open Source (gold.safeguard.sh, free, no login) gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API, and a CI gate GitHub Action.
• Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

There is no Gold record for these incidents, because no CVE or component has been published for them. The habit that matters is the one these tools support: build internet facing tiers from patched, signed components pulled from a curated source, know exactly what each host runs, and rebuild fast when something changes.

Common mistakes

• Reading "9 million" or "344" as numbers of people. One is a cumulative record estimate with duplicates; the other counts contracts.
• Assuming you are clear because you were not in the first count. The Blastmail figure rose by 56 contracts overnight, and the outside investigation is still running.
• Assuming a joint PPC report covers recipients. It does not. You still have to notify the people on your list, and PrivacyMark holders still report to JIPDEC.
• Linking the breach to PHP2Shell. Neither provider has done so. Patch PHP because PHP2Shell is serious, not because of this incident.
• Blocking a whole provider domain. Blocking all of cuenote.jp may also block legitimate notices. Quarantine on the published sender and subjects instead, and verify notices on the official site.
• Forgetting contractors. The Saitama case, as reported, ran through a contractor. Ask every vendor that sends mail on your behalf which platform it uses.
• Matching Japanese subjects with raw text filters. Many relays see the subject as a MIME encoded word, so a plain text rule on the raw header can miss. Use your gateway's decoded subject matching.
• Leaving the outage unplanned. If disaster or emergency alerts go through Blastmail, they are not going out. Move that traffic now.

FAQ

Are the Blastmail and Cuenote FC breaches connected?

Nothing published connects them. They hit different companies with different disclosed chains: a program vulnerability and a stolen support credential at Ymirlink, and command execution on two API servers at Rakus Light Cloud. The timing is close, which is why many readers have grouped them, but neither provider has suggested a common attacker or method.

Was PHP2Shell the way in?

Neither provider has said so. Ymirlink says CVE-2026-109618 and CVE-2026-109619 do not affect Cuenote, and Rakus's PHP status table does not mention Blastmail. The Cuenote intrusion was detected five days before the PHP security releases.

I am a Blastmail customer and was not contacted. Am I safe?

Your contract record, including company name, contact, phone, email, billing email and contract and payment history, was taken along with every other customer's. What you may have avoided is a leak of your delivery lists. The count of contracts with delivery data leaked rose once already, so keep watching the status page.

What exactly is "about 9 million" in the Cuenote case?

Ymirlink's estimate of records including email addresses that were output from five systems, counted cumulatively. It includes duplicates, so the number of distinct people is lower and unknown.

What should recipients do?

Treat any apology or confirmation mail from an affected organisation with suspicion. Go to the organisation's official site directly and check for the same notice. Do not enter passwords, card numbers or personal details through links in mail.

Do Blastmail customers have to report to the PPC?

That depends on the data and the number of people, and is a legal call for each organisation. The PPC's guidance says to report promptly, with a final report within 60 days of discovery where the leak may have been for an unlawful purpose. Rakus Light Cloud offers a joint report if you apply by 29 October.

When will Blastmail come back?

Rakus Light Cloud says the restart date is undecided. Its next update was set for 10:00 on 25 October.

Should we stop using third party email platforms?

No. Running your own bulk mail brings its own risks. Control what you upload, how fast you hear about incidents, how well your domain resists impersonation, and how ready you are to notify people.

Could Safeguard have prevented this?

No. Both breaches happened inside hosted services that customers do not build or run. Safeguard helps customers keep a structured vendor register and monitor supplier risk, scan their own integration code and images, and helps platform operators keep their own internet facing stack inventoried and patched. It does not see inside another company's service.

Is the spoofed info@cuenote.jp mail part of the breach?

Ymirlink has not said so. It published the samples on 20 October as a warning that spam is being sent using its domain while impersonating third parties, and said it never sends such mail. Quarantine it on the published sender and subjects either way.

Fix it without waiting for upstream

Neither of these breaches was caused by an open source dependency that has been named, and the fix for Blastmail and Cuenote FC has to come from their operators. The same discipline still applies to everything you build and run yourself, including the integration services that feed your lists to providers like these and, if you operate a platform, your own internet facing tier.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows Blastmail, Cuenote FC or any of their customers, and none of them would have stopped a breach inside a hosted service.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this incident, you would point the same session at the service that syncs your subscriber lists to a mail provider, run /scan ., and ask it to upgrade whatever vulnerable libraries it finds in that service. It asks before each command.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session appearing in the conversation list, a request for work on your computer, the folder being chosen, and an Approve or Deny decision on each command and file edit, ending with an upgrade done and tests passing. If you operate a platform like these, the same flow would let an engineer ask for the API host image to be rebuilt on a patched base and review every change before it lands.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session sending work to a computer running the CLI and approving a command on the phone with Allow once, Allow for turn or Deny. In an incident week like this one, that is how an on call engineer away from a desk can approve a rebuild of an internet facing service without handing the assistant free rein.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard and read the CLI documentation.

Quick check

Sources

• Ymirlink: report on unauthorised access to our systems, first report (TDnet timely disclosure, 19 October 2026, PDF)
• Cuenote: report on unauthorised access, first report, 19 October 2026 19:05 update
• Ymirlink: warning about spam using our domain and impersonating third parties (20 October 2026)
• Cuenote: PHP vulnerability has no effect on Cuenote services (22 October 2026)
• Blastmail: emergency stop and personal data leak, apology and report (updated 24 October 2026 13:20)
• Blastmail: joint reporting to the Personal Information Protection Commission (23 October 2026)
• Rakus: first report on suspicious access to Blastmail (21 October 2026)
• Rakus: second report on unauthorised access and data leak (21 October 2026)
• Rakus: temporary pause of seven services (21 October 2026)
• Rakus: services resumed (22 October 2026)
• Rakus: status of response to the PHP vulnerability (22 October 2026)
• Rakuraku Meisai: website and partial service pause and resumption (22 October 2026)
• Personal Information Protection Commission: leak reporting guidance
• JAPEX: possible personal data leak from unauthorised access at Rakus Light Cloud (21 October 2026)
• Natori City: possible personal data leak from unauthorised access at Rakus Light Cloud
• Kiho Town: possible personal data leak from unauthorised access at the Blastmail provider
• giftee: possible personal data leak, with 23 October update
• rvsta: data leak from unauthorised access to Blastmail (23 October 2026)
• Tamiya: possible personal data leak from unauthorised access to Blastmail
• ITmedia NEWS: unauthorised access at mail delivery firm Ymirlink, about 9 million records (20 October 2026)
• NHK: Hiroshima Prefecture and Hiroshima City announce possible leaks (23 October 2026)
• Incident timeline aggregator: Rakus unauthorised access, October 2026
• Japanese security news site: Blastmail unauthorised access, all contract holders' data taken
• Security consultancy incident page: Ymirlink Cuenote FC unauthorised access
• Security services firm news summary: Cuenote FC unauthorised access

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.