RAKUS has confirmed that attackers stole customer information from its subsidiary's Blastmail email-delivery service, including contract-holder records and some mailing lists. The incident also disrupted government communications: Yamagata Prefecture reported that newsletter registration and delivery were unavailable after the supplier's emergency shutdown.
This is not a newly disclosed October 29 intrusion. RAKUS published its second incident notice on October 21, 2026; an October 28 addition says impact on other RAKUS cloud services and information leakage involving their customers had not been confirmed. That distinction matters: a significant supplier breach is not evidence that every product in the same corporate group was compromised.
What the supplier confirmed
According to RAKUS's original notice, an external party entered two API servers, executed commands, connected to the sales-management system and service databases, and took data outside the company. The entry route remained under investigation in the notice.
RAKUS says information belonging to all contract holders was taken from the subsidiary's sales-management system. The listed fields include company and contact names, telephone numbers, email addresses, billing email addresses, and contract and payment histories. It says the subsidiary does not hold credit-card numbers. Separately, email-delivery information, including recipient lists, was exposed for some customers; the notice does not establish that every customer's list was stolen.
The reviewed sources do not provide a total affected-record count or an initial intrusion date. They also do not identify a vulnerability, ransomware operator, or attacker attribution. This is a supplier data breach, not a confirmed compromise of software distributed to customers.
Disruption is confirmed; individual list exposure needs its own evidence
Yamagata Prefecture's October 22 statement independently confirms an operational consequence: after Blastmail's emergency shutdown at 00:30 Japan time on October 21, newsletter registration and delivery were unavailable. That statement does not confirm that prefectural subscribers' information was exfiltrated.
These notices describe service conditions at the time they were issued. They should not be read as a verified live outage dashboard or a statement that service remains unavailable today. Customers need current restoration instructions through established supplier channels.
Actions for small businesses and government contractors
- Identify what the supplier held. Inventory mailing lists, segmentation fields, customer contacts, billing contacts, and any exports uploaded to the service. Ask for a tenant-specific account of confirmed exposure rather than applying the broadest possible interpretation to every recipient.
- Prepare for credible impersonation. Contact and contract details can make fake renewal, billing, or incident-response messages more convincing. Verify payment changes and recovery instructions using a previously known contact method, not a telephone number or link supplied in an unexpected email.
- Preserve your own evidence. Retain vendor notices, support correspondence, relevant account activity, campaign records, and list-upload histories. Record what was known and when, while limiting access to copies containing personal information.
- Separate continuity from exposure response. Use a verified website or another approved communication channel for service updates. Before moving to another mailing provider, review data minimization, recipient consent and suppression lists; an outage is not a reason to duplicate sensitive audience data without controls.
- Review connected access proportionately. Inventory integrations and credentials associated with the service, and follow verified containment instructions. The reviewed notices do not establish that all customer passwords or integration secrets were stolen; avoid substituting unsupported assumptions for a scoped investigation.
Bulwark assessment
A newsletter platform holds more than a distribution mechanism: it can hold a map of customers, partners and professional relationships. For an SMB or government contractor, that map can support targeted social engineering even when no intrusion into the organization's own systems has been demonstrated.
The practical response is to manage two tracks independently: determine which data was exposed, and maintain a trustworthy way to reach the audience. Track supplier assertions by date and scope. RAKUS's October 28 statement that other cloud services had no confirmed impact narrows the public evidence; it does not replace tenant-specific findings or prove every related environment safe.
For future supplier reviews, ask how mailing-list data is isolated from billing systems, how administrative access is logged, what customer-specific evidence can be supplied after an incident, and how communications continue if the delivery platform must be shut down. Those are resilience questions, not claims about additional failures established in this investigation.
Original sources and limits
- RAKUS: October 21 second incident notice, with October 28 scope addition (Japanese).
- Yamagata Prefecture: October 22 newsletter-service notice (Japanese).
This report relies on the supplier's confirmed theft findings and the prefecture's independent disruption notice. Neither establishes a complete recipient-level exposure count. Recommendations above are Bulwark's defensive assessment, not evidence that follow-on attacks have occurred.