Japanese cloud, hosting and data center operator Sakura Internet has confirmed possible unauthorized third party access to the internal sales management system that holds its contract and membership records, placing as many as 1,360,563 member accounts within the scope of the incident. The disclosure came in a second-report advisory published by the company on 19 August 2026 and was picked up the same day by BleepingComputer, ZDNET Japan and MLex. All three, along with the company itself, use the same figure of 1,360,563, so there is no dispute over the headline number, though Sakura is explicit that this is the maximum population under investigation and not a confirmed victim count. The company says no data exfiltration has been confirmed, that credit card data was not stored in the affected system, and that its forensic work with an external specialist firm is ongoing. Sakura Internet is a designated domestic provider under Japan's Government Cloud programme, which makes this a strategically significant incident well beyond its customer list.
What Happened
The story runs across two disclosures. On 17 August 2026, Sakura published an initial notice covering unauthorized access to customer environments on its Sakura Rental Server service. Per that notice and the @IT write up of it, the company detected an anomaly in a managed server environment on 9 August 2026, opened an investigation, and established that an attacker had moved through Sakura's own managed environment into a subset of rental server customer areas. Unauthorized logins were confirmed against 583 accounts. Malware was found installed on some servers. Sakura stated the attacker was in a position to access both customer information and information falling under Japan's constitutional and telecoms law protection for the secrecy of communications, a legally weighty category in Japan that triggers reporting to the Ministry of Internal Affairs and Communications. The company stressed, and @IT reinforced, that "was able to access" is not the same as "viewed or took," and that the specifics remain under investigation.
Two days later, on 19 August, the second report landed. While running containment and scoping the blast radius, investigators found evidence of possible unauthorized access to a separate system: the sales management platform that stores contract and membership information for Sakura's services. That system is architecturally separate from the service delivery environments for Sakura Cloud and the other product lines, so the company is not claiming its cloud platform itself was compromised. But it is the system of record for who its customers are.
There is one factual point where the reporting and the primary statement do not line up, and it matters. Sakura's own advisory and ZDNET Japan both state that the sales management system access occurred before 9 August, with 9 August being the date the rental server intrusion was detected. BleepingComputer and Undercode News instead describe attackers as having "accessed the IT system on August 9." The company's own version should carry the weight here: 9 August is a detection date, not a confirmed intrusion date, and the sales system activity predates it. Whether the two events are the work of the same actor, or connected at all, is explicitly listed by Sakura as still under investigation.
A separate caution on sourcing: Undercode News published this under a headline claiming "136 Million Accounts." That is a mistranslation of the Japanese 136万 (1.36 million). The body of that same article correctly gives 1,360,563. The figure is 1.36 million, not 136 million.
What Was Taken
Nothing has been confirmed as taken. That is the company's position and it is consistent across every source: Sakura states that as of the second report, no external removal of data has been verified. It is also the point most likely to change as forensics progress, and absence of confirmed exfiltration is not evidence of no exfiltration.
What is confirmed is exposure potential. For the sales management system, the total population of member records possibly affected is 1,360,563 accounts, a figure that Sakura notes already includes the rental server customers disclosed on 17 August, so the two numbers should not be added together. Bitdefender's write up gives the most granular field list of any source: member IDs, names, company and department information, addresses, phone numbers, email addresses, dates of birth, gender, subscribed services, contract periods and billing amounts. MLex independently corroborates names, email addresses, contract details and billing information, which supports the broad shape of that list.
On credentials, Sakura confirms that hashed password data for "some customers" was potentially accessed, and defines hashing in the advisory as a form from which the original password is difficult to recover. Bitdefender is the only source to attach a number, reporting that hashed passwords for 30 accounts may have been affected. That figure appears in no other source, including the company statement, and should be treated as single sourced until Sakura confirms it. Sakura states plainly that it does not store credit card information, so no card data is in scope.
For the earlier rental server incident, the disclosed exposure categories are narrower and vaguer: information stored within customer areas, and user identifiers. Since those are customer controlled file systems and databases, the actual sensitivity depends entirely on what each affected customer was hosting.
Why It Matters
This is a supply chain exposure wearing the clothes of a routine data breach. Sakura Internet is not a consumer brand with a leaky marketing database; it is core Japanese digital infrastructure, running web hosting, VPS, public cloud, dedicated servers, data centers and GPU compute, and it was selected as a domestic provider for the Government Cloud initiative specifically to reduce Japanese dependence on foreign hyperscalers. A breach of the system that catalogues who its customers are, what they subscribe to, and what they pay is an intelligence product in its own right, regardless of whether a single byte was exfiltrated.
The escalation pattern is the second lesson. The 17 August disclosure looked contained: 583 accounts, malware removed, credentials invalidated, four major service lines confirmed unaffected. Forty eight hours of continued scoping turned that into a 1.36 million account membership database question. Defenders and customers who calibrated their response to the Monday numbers were working from a picture that was about to expand by four orders of magnitude. Treat early incident scoping from any provider, including your own, as a floor rather than a ceiling.
Third, the contract and billing data set is unusually well suited to follow on attacks against Sakura's customers. Names, company and department, contract periods, subscribed services and billing amounts give a social engineer everything needed to construct a convincing renewal or billing dispute pretext against a named individual at a named company. Sakura's own customer advisory flags exactly this, warning about phishing that piggybacks on the incident and stating that the company will never ask for passwords, credentials or card details by email or phone.
The Attack Technique
Initial access vector is not established. Sakura says the intrusion route, timing and full scope of both events remain under investigation, and no source names a threat actor, malware family, or exploited vulnerability. What can be stated from the primary disclosures:
The attacker reached rental server customer environments by transiting Sakura's own managed environment, which points to compromise of provider side access rather than customer by customer credential stuffing. Malware was installed on some servers, though its type has never been specified, and Sakura says it has since been removed. Unauthorized logins were confirmed against 583 accounts, and the attacker reached areas where customer accounts and traffic secrecy protected information were accessible. Sakura invalidated all credentials believed to have been used in the intrusion, which is the clearest signal available that valid credentials were part of the chain.
Undercode News frames the incident as illustrating the use of legitimate access to operate from inside trusted systems. That is a reasonable reading of the credential invalidation and the lateral movement into a separate business system, but it is that outlet's analysis rather than a Sakura finding, and no source has confirmed how those credentials were obtained. Anyone building detections off this incident should treat "valid credential abuse into an adjacent internal business system" as a working hypothesis, not a confirmed TTP.
What Organizations Should Do
If you are a Sakura Internet customer, work through the company's own checklist against your hosted environments: look for files or administrator accounts you did not create, unexpected changes to websites and applications, and login or outbound mail activity you cannot account for. Sakura is notifying affected customers individually via registered email addresses, but do not wait to be told before you audit.
Rotate credentials on the assumption hashes are in play. Sakura confirms possible access to hashed passwords and Bitdefender reports the affected count as 30. Hashing raises the cost of recovery, it does not eliminate it, and it does nothing for passwords you have reused elsewhere. Change the Sakura password and every other account sharing it, and enable multi factor authentication where the service supports it.
Brief your staff on incident themed phishing now. The exposed field set includes names, company and department, contract periods and billing amounts, which is exactly the raw material for a targeted invoice or renewal lure. Reinforce that Sakura will not request credentials or card data by phone or email, and give people a fast internal route to report suspicious contact.
Audit your own provider to business system boundaries. The pivotal detail here is that a compromise of hosting infrastructure surfaced possible access to a separate CRM and billing platform. Verify that your customer records, contract and billing systems require distinct credentials and distinct network paths from your production and operations environments, and that a foothold in one does not authenticate into the other.
Instrument bulk read activity on your systems of record. A 1.36 million record membership store should generate a high confidence alert on unusual query volume, off hours access, or export activity, independent of whether the account performing it is legitimate. Detection built on credential validity alone would not catch this pattern.
Rehearse the scope expansion. Build into your incident response plan the explicit assumption that day one scoping will be wrong and low. Define who re communicates to customers and regulators when the number moves, and make continued blast radius investigation a named workstream that runs after containment closes, not a task that ends with it.
Sources: Sakura Internet hack exposes data of up to 1.36 million accounts | さくらインターネット、販売管理システムへの不正アクセスの可能性--最大136万アカウントに影響の恐れ - ZDNET Japan | 当社システムへの不正アクセスに関するお知らせ（第二報） さくらインターネット | 当社レンタルサーバーサービスの一部環境に対する不正なアクセスについて さくらインターネット | Sakura Internet hack may affect 1.36 million accounts | Japan's Sakura Internet says 1.36m customer accounts ... | Sakura Internet Breach Exposes Potentially 136 Million Accounts in... | さくらインターネットで583アカウントに不正ログイン 「顧客領域」まで到達：マルウェアも設置 - ＠IT