Sakura Internet, provider of Japan’s government cloud, discloses a breach affecting up to 1.36 million accounts

August 9, 2026. Attackers access the sales management system of Sakura Internet, one of Japan’s largest cloud providers. August 17, 2026, the company publishes its first notice. August 19, 2026, it discloses the scale: up to 1,360,563 member accounts potentially compromised. No exfiltration is confirmed yet — but the perimeter already says the essential part.

Sakura Internet is no ordinary host. It was selected in March 2026 as a domestic provider for Japan’s Government Cloud program, specifically to reduce the country’s dependence on foreign hyperscalers. A breach at this provider is therefore a strategic event, not merely a commercial one.

Access to the sales management system

The affected system is the one that stores customer contracts and membership information. It is not the hosting infrastructure itself — the VMs, storage, or network — but the layer that records who the customer is, with what contact details and under what contractual terms.

That distinction matters for risk assessment. This kind of data does not let an attacker encrypt a disk or pivot to a hypervisor, but it feeds exactly what follows a breach of this kind: targeted phishing, identity theft, and password-reset attempts backed by real information.

The announced range — up to 1,360,563 accounts — remains provisional: the investigation is ongoing and the exact number of exposed accounts has not been finalized.

Found by accident, during another intrusion

The discovery path is worth pausing on. Access to the sales management system was discovered during the investigation of a separate breach, at the Sakura Rental Server service.

That first intrusion looked less severe on the surface: 583 accounts suffered unauthorized logins, with access to customer-facing systems and the installation of malware on the company’s systems. Sakura revoked the abused credentials and removed the malware. But digging further, investigators uncovered the far larger exposure in the sales management system.

The lesson is classic and rarely applied: one breach often hides another. The post-incident investigation did not just fix the visible intrusion — it revealed the real one.

What the compromise contains — and what it does not

On content, Sakura Internet offers reassurance on two specific points: passwords are hashed — “hard to decipher even if stolen” — and the compromised system stores no credit card information.

Both assurances are real but do not close the risk. A hashed password can still be cracked if it is weak and the algorithm is old; and the absence of card data does not prevent the reuse of email addresses, phone numbers, and contractual details for targeted phishing.

Above all, the company says no data exfiltration is confirmed at this stage. Caution is warranted here: absence of evidence is not evidence of absence, and ransomware operators sometimes publish months after the initial intrusion. No ransomware or extortion actor has claimed the attack so far, and Sakura reports no service disruption.

A sovereign cloud is not an invulnerable cloud

The Sakura Internet case illustrates a common confusion: cloud sovereignty protects against geopolitical dependence and the extraterritorial reach of foreign law — it does not protect against poor security hygiene or an exposed sales management system.

Japan’s Government Cloud program selected Sakura for legitimate strategic reasons: keeping sensitive data on national territory and under national jurisdiction. But an intrusion into the billing system of a sovereign provider is a reminder that the weak link in a cloud chain is almost never the hypervisor — it is often the business system running alongside it, less monitored, less segmented, less patched.

For a cloud customer, the distinction is operational: you must assess a provider’s security beyond its datacenter, across its entire administrative surface — CRM, customer portal, support, billing. That is where your teams’ credentials flow.

Three questions to ask your cloud provider

The phrase “passwords are hashed” deserves scrutiny, because everything depends on the algorithm. A salted bcrypt or argon2 hash with a high work factor resists brute force for a long time; an unsalted MD5 or SHA-1 falls in a few hours on consumer hardware. Sakura did not specify the algorithm — so affected customers should change their password rather than bet on the hash’s strength, and never reuse it anywhere else.

Japan is not alone on this path. Europe is pushing Gaia-X and its trusted providers, France certifies SecNumCloud, and other Asian countries are building sovereign clouds for the same reasons. The Sakura case is a reminder that sovereignty answers a question of jurisdiction and dependency, not of operational security: a sovereign provider is still a company with business systems, employees, and passwords — and that surface is where this intrusion happened.

Note also the lag: the access dates to August 9, the disclosure to August 19. Ten days — the window during which an uninformed customer could not rotate their credentials. Fast, honest disclosure from a cloud provider is itself a security criterion.

Concretely, ask any cloud provider — sovereign or not — three questions: where your teams’ credentials and contractual data are stored; which algorithm protects passwords; and what segmentation separates business systems from the hosting infrastructure. A provider that cannot answer those three precisely is not necessarily less secure — but you have no way to know.

For a customer, those three answers turn “up to 1.36 million accounts” from an abstract headline into a concrete, individual risk you can act on today. And if the provider’s customer portal still does not offer MFA, treat that as a red flag on its own — a portal without MFA in 2026 is an incident waiting to happen.

Verdict

This intrusion has not delivered its final verdict — no confirmed exfiltration, no claim. But it has already delivered its lesson: a sovereign cloud provider can be as exposed as a foreign hyperscaler, and an intrusion does not need to touch the servers to be serious.

The unresolved part remains attribution. No actor has claimed the intrusion, and the absence of service disruption points to a quiet operation rather than noisy ransomware. That is the least comfortable scenario: an intrusion aimed at collecting contractual data can stay silent for months before the data resurfaces — in targeted phishing, extortion, or resale. Today’s calm should not be read as harmlessness. The broader point for every cloud buyer is unchanged: a provider’s datacenter certification says nothing about the security of the business systems that hold your team’s identities. Ask about both, or assume the worst.

If you are a Sakura Internet customer, three actions are immediate: rotate your passwords and enable MFA on the portal, watch for targeted phishing — the exposed contractual data makes fake messages credible — and demand written confirmation from the vendor of the exact scope of the affected data. Do not settle for the “passwords are hashed” line: ask which algorithm.

For everyone else, the case is a warning. The next intrusion into a cloud provider will probably not hit the core of the cloud — it will hit the business system that surrounds it. Evaluate your providers on that surface, not just on their hypervisor SLA.

References

• BleepingComputer, “Sakura Internet hack exposes data of up to 1.36 million accounts”, August 19, 2026.
• Sakura Internet, “Notice regarding unauthorized access to our sales management system”, August 19, 2026.
• Sakura Internet, announcement of selection for Japan’s Government Cloud, March 27, 2026.