Sakura Internet: a sales system that held server passwords, accessed from 2023 to 2026.

What is confirmed

Sakura Internet is a major Japanese hosting and cloud provider. It published three notices between 17 August and 10 September 2026, plus a customer FAQ and two password notices. The third notice is its final investigation report. Third notice (Japanese).

Summary card: the headline The sales system held server passwords, beside an illustrative sales system listing 1,360,563 member records, 30 hashed passwords, and two rows marked not hashed: server passwords and VPS initial root passwords

At a glance. Original graphic for this article.

On Sunday 9 August 2026, Sakura detected an anomaly on a maintenance server for its shared hosting service, Sakura Rental Server. The investigation found three things:

Rental server intrusion. A third party reached some customers' environments through Sakura's own management environment, and placed malware on some servers. The first notice said the attacker could reach customer information and information covered by the secrecy of communications. First notice (Japanese).
Sales management system access. The system that holds customers' contract information was accessed by a third party. The final report dates that access to between April 2023 and March 2026.
No link established. Sakura investigated whether the two intrusions are connected and found no clear evidence that they are.

Figure 1. Accessed from April 2023, found in August 2026. Original graphic for this article.

What may have been viewed or taken

The final report and the FAQ give this scope. FAQ (Japanese).

951 rental server accounts. Mail data, website data, logs and other files in the customer's area. The first notice said 583. Additional investigation added 368 that could not be clearly linked to the first group, but were included because an impact could not be ruled out.
1,360,563 accounts in the sales management system. Member ID, company name, department, address, name, phone number, email address, date of birth, gender, fax number, contracted services, contract period and billed amounts. This total includes the 951 rental server accounts and covers every kind of Sakura customer, not only rental server users.
30 hashed member passwords. These may have been viewed.
Passwords stored without hashing. The sales management system also held some initial server passwords for the rental server, and some initial administrator passwords for Sakura VPS.

Sakura holds no credit card information. The final report says it found no clear evidence that data was taken out, no misuse, no secondary harm and no publication on the internet or dark web.

The stored passwords

The password notices set out exactly which credentials were in the sales system:

Server passwords. These were issued at sign-up, or reissued from the member menu, up to 17 August 2026. They cover Sakura Rental Server, Managed Server, Mailbox and Business Mail. A server password signs in to the server control panel, FTP and SSH. On 31 August, Sakura changed every stored server password that was still in use and emailed the new one. Password notice (Japanese).
VPS initial root passwords. Sakura asked affected VPS customers to change any initial administrator password still in use. Contracts from 1 September 2022, when customers began setting their own administrator password, are generally not affected. VPS notice (Japanese); piyolog.

A password the customer had already changed was not stored, so it is not at risk from this incident.

Two other details from the final report

Older traces. Sakura found traces of suspicious activity on the rental server environment that it believes date from July 2025 onwards. It concluded they do not show ongoing compromise or misuse. It could not determine whether they relate to this incident, because older records were limited.

Cancelled is not withdrawn. Former customers received notices too. The FAQ explains that cancelling a service does not delete the member record: Sakura keeps it until the member formally withdraws.

What changes in the security review

A sales system that was also a key store

Editorial assessment. The 1.36 million figure is the headline, but the stored passwords are the lesson. A system built to manage contracts and billing held working credentials for customers' servers: control panel, FTP, SSH and VPS root. Anyone who could read the sales database could read the keys. And Sakura's own reissue function went on storing new server passwords until 17 August 2026.

For any organisation that issues credentials to customers or staff, check four things:

Issue once, keep nothing. Show or send a generated password once, then store only a hash or nothing at all.
Force a change on first use, so an issued password does not stay valid for years.
Do not copy credentials into business systems. A CRM, sales or support system should never hold a password that opens a server.
Look for them. Search back-office databases, tickets and exports for fields that hold credentials. If you find any, they are already a target.

Three years before anyone looked

Editorial assessment. The sales system access was found only because a separate intrusion was being investigated. The earliest access was more than three years before detection. Sakura's own planned measures include a review of the scope, retention and analysis of security logs. Its findings on the July 2025 traces show why: old records were not available to settle the question.

Back-office systems need the same monitoring as production systems: who reads them, how much, and from where. Their logs need to be kept for as long as an attacker might plausibly stay.

What a shared-hosting customer cannot see

The rental server intrusion came through Sakura's management environment. A customer on shared hosting has no sensor on that layer and no logs from it.

Editorial assessment. Plan for your provider's access to your files. On the 951 affected accounts, website data includes configuration files, and those often hold database passwords, API keys and mail credentials. Mail stored on the server may include password-reset links and invoices. Treat secrets kept in hosted files as exposed whenever the provider reports access to customer areas.

Figure 2. What each system held, and what customers should do. Data items from Sakura's notices; the actions are this article's analysis. Original graphic.

For organisations that use Sakura

Shared hosting (rental server, managed server, mailbox, business mail). If you received the 31 August email, sign in with the password it gave you and set your own. Update saved passwords in FTP and SSH clients. Change mail passwords too, as Sakura recommends.
On the 951 affected accounts, rotate every secret kept in site files: database passwords, API keys, SMTP credentials, payment and analytics tokens. Check for unknown files, extra administrator accounts and unexpected changes to sites.
Sakura VPS. If the initial root password from a pre-September 2022 contract is still in use, change it, switch SSH to key-only sign-in, and review sign-in logs. If you cannot rule out unauthorised sign-ins, rebuilding the server is the cleaner option.
Everyone with a Sakura member ID. Expect phishing that quotes your real services, contract period or billing. Sakura's notices come from support@sakura.ad.jp, and it says it never asks for passwords by email or phone. The member menu already requires two-step verification. Check which method you use: an authenticator app is stronger than an email code.
Former customers. If you cancelled but never withdrew, your record is still there. Withdraw if you no longer need the account.

Which teams should act

Team	Practical next step
IT operations	Rotate Sakura server, FTP, SSH, mail and VPS root passwords, and every secret stored in hosted site files. Move SSH to keys. Search your own back-office systems for stored credentials.
Third-party risk	List your hosting and SaaS providers. Ask each one whether it keeps issued passwords, how its management plane reaches your environment, and how long it keeps security logs.
SIEM / SOC	Run the hunts below on VPS and hosted-server logs as far back as they go. Alert on password-based root sign-ins and on new script files in web roots.
EDR	Where a VPS has an agent, check for web shells and unknown persistence. Shared hosting has no agent: the shell check below is the substitute.
Legal / privacy	If your users' data sat in hosted site files or mail on an affected account, assess your own notification duties. Sakura's report covers its data, not yours.
Email security	Expect lures that quote Sakura contract and billing details. Treat password-reset or payment requests in Sakura's name with suspicion unless they come from support@sakura.ad.jp and match a request you made.

IOCs and hunting

Sakura withheld technical details, including attack code and IP addresses, to avoid copycat attacks. There are no incident IOCs in this article, and none should be inferred.

The useful hunts are for the use of stored passwords and for changes on hosted servers. All are illustrative and were not run against live data. Look back as far as your logs go: the stored passwords may have been readable since 2023.

Password-based SSH sign-ins on a Linux server (for example Sakura VPS), from Microsoft Sentinel's Syslog table:

// Illustrative. Microsoft Sentinel, Syslog table (auth and authpriv facilities forwarded from the server).
// Lists accounts that signed in over SSH with a password, by source address.
Syslog
| where TimeGenerated > ago(90d)
| where Facility in ("auth", "authpriv") and ProcessName == "sshd"
| where SyslogMessage startswith "Accepted password for"
| parse SyslogMessage with "Accepted password for " User " from " SourceIP " port " *
| summarize Logons = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by Computer, User, SourceIP
| order by FirstSeen asc

If Microsoft Defender for Endpoint runs on the server, successful remote sign-ins as root:

// Illustrative. Microsoft Defender XDR advanced hunting, DeviceLogonEvents (30 days of data).
DeviceLogonEvents
| where Timestamp > ago(30d)
| where ActionType == "LogonSuccess" and AccountName == "root"
| where RemoteIPType == "Public"
| summarize Logons = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp),
    Sources = make_set(RemoteIP, 20) by DeviceName, Protocol
| order by Logons desc

The same SSH check in Splunk, using the Linux add-on's linux_secure source type:

index=YOUR_LINUX_INDEX sourcetype=linux_secure earliest=-90d latest=now
"Accepted password for"
| rex "Accepted password for (?<user>\S+) from (?<src>\S+) port"
| stats count min(_time) AS first_seen max(_time) AS last_seen BY host user src
| convert ctime(first_seen) ctime(last_seen)
| sort first_seen

On shared hosting there is no agent and no central log. Over SSH, list script and configuration files created or changed since July 2025, the start of the older traces:

# Illustrative. Run in your own Sakura Rental Server account over SSH.
# Lists PHP and .htaccess files created or changed since 1 July 2025.
find ~/www -type f \( -name '*.php' -o -name '.htaccess' \) -newermt '2025-07-01' -print | head -200

Read the results with these limits in mind:

A password-based root sign-in is a lead, not proof. Check whether the source address is one you use.
No result may only mean the logs do not go back far enough. The final report itself notes how missing old records limited its own conclusions.
Plugin and CMS updates change many files. Look first at files you do not recognise and at changes outside update windows.
None of these sees Sakura's management environment or its sales system.

What remains unknown

Entry points and methods. Withheld, for both the rental server intrusion and the sales system access.
Whether the two are connected. Sakura found no clear evidence either way.
What was actually viewed. Sakura says it cannot identify which information was viewed for which customer.
How many stored passwords were still in use. Not given.
Why issued passwords were stored, and since when. Not explained.
The July 2025 traces. Their link to this incident could not be established.

Reporting note

Reviewed for public information up to 3 October 2026, 07:46 UTC / 16:46 JST. Facts come from Sakura Internet's three notices, its FAQ, its password notices of 26 and 31 August, and its timely disclosure of 10 September. That disclosure expects a limited effect on results for the year to March 2027. piyolog's summary was used to cross-check the sequence and the VPS contract date. Nikkei xTECH's weekly column by piyokango of 29 September was the prompt for this article; it is subscriber-only and was not used as a source of facts.

This is independent editorial analysis of public statements, not an investigation by SecOpsNomad.

30-second briefing