Security Guides

#shared hosting #incident response #backup #multi-factor authentication #Japan

Your Web Host Was Breached — What Can You Actually Do?

Sakura Internet's final report: 951 hosting accounts, a three-year intrusion, unhashed initial passwords. What is confirmed, what is not, and what customers should do today.

Published 2026-08-18 Updated 2026-09-21 Last verified 2026-09-10 21 min read

Who this is for: anyone running a site or mailbox on shared hosting. This guide is about the case where you did nothing wrong and your provider was the one compromised. It is based on public information — the provider's own disclosure and reporting on it — and contains no attack techniques.

This article uses the 2026 Sakura Internet case to work through what a customer can actually do when the provider they pay is the one that got breached. The case detail comes after the steps. If you are not sure whether you are affected, do steps 1 and 2 anyway.

Do this first (in order — skip what does not apply)

If you have a Sakura Internet account at all, you may be in scope — hosting customer or not

What the second report implicates is the sales management system that holds contract records, and the company's FAQ states that scope is not limited to rental server customers. A domain-only, VPS-only, or long-dormant member registration can be in scope. Guidance has moved on from the first report's "we will contact you individually if action is needed" to concrete precautionary advice. If that is you, do step 1 today.

Change any password you reused elsewhere (highest priority)

The FAQ update of 21 August set the priority explicitly. The member console requires two-factor authentication at login, so "a password alone cannot log in, and there is no strong need to change it immediately". What the company does urge strongly: if the same password is used on other web services, change it on those other services. What needs protecting is not the lock that leaked, but the other doors the same key opens — that is how a provider-side incident usually turns into your incident. A password manager is what makes that audit tractable.

If you are still using the initial password from sign-up, change it today

The 10 September report disclosed a category of data that had not been mentioned before: some initial server passwords for the shared hosting service, and some administrator initial passwords for the VPS product. The company describes these as "not hashed".

That distinction decides everything. Hashed means the original password is hard to recover — which is why the 30 member-ID passwords are handled as a precaution rather than an emergency. Unhashed means a password that was read is a key that still works. The company is contacting affected customers directly and asking them to change any initial password still in use.

The test is simple: if you changed your password at any point after signing up, this does not apply to you. If you cannot remember changing it, or you are still using the credentials from the welcome message, change it today — and check whether that same password is in use anywhere else with a password manager. Why leaving an issued password in place is risky in general is covered in password habits that actually matter.

Change your server and mail passwords, and check your second factor

For hosting customers the company names the server (FTP) password and mail account passwords, and recommends changing those as a precaution. Check your two-factor settings while you are there, and move from emailed codes to SMS or an authenticator app — in an incident where mail data itself may have been read, a code sent to that mailbox is a weak second factor. The FAQ also asks customers to confirm that the registered email address and phone number still work, and to clean up accounts they no longer use. Do all of it by going to the official site yourself, never through a link in an email. The hashed-password exposure named so far covers 30 accounts, but customers cannot tell whether they are among them — which is exactly why acting pre-emptively is rational.

Inventory the secrets on that server and move them

Look for .env files, database dumps, backup archives, config files holding API keys, customer CSVs — anywhere in or near the published directory. What this incident lists as possibly exposed is precisely "information stored within the customer area". Assume anything sitting there has been read. For layout specifics see keeping .env out of reach on shared hosting and what must never sit in a public directory.

Separate your hosting credentials from everything else

Control panel, FTP/SSH, mail and database passwords should exist nowhere else, so one exposure does not travel. Put multi-factor authentication on the control panel, and prefer passkeys where offered. A password manager is what makes this sustainable.

Keep a backup outside the provider

If the provider is the compromised party, backups held inside that same provider lose some of their trustworthiness. Keep a copy locally or at an unrelated provider — and one you have actually restored from once. The model is in backup and recovery essentials (the 3-2-1 rule).

Check the three signals, and expect phishing

The checks the company asked customers to run: unfamiliar files or administrator accounts, unexplained changes to your site or application, and logins or mail sends you cannot account for. Expect a wave of phishing impersonating the hosting company — the company states plainly that it never asks for passwords, credentials or card details by email or phone. The FAQ added on 2 September names support@sakura.ad.jp as the sender of its notices — treat that as grounds to reject a mismatch, not as proof that a match is genuine, since sender addresses can be forged. Do not follow links in those emails; go to the official site yourself.

What was disclosed (from the company’s own statements)

Sakura Internet Inc. disclosed unauthorised access on 17 August 2026, followed with a second report on 19 August, and on 10 September published its investigation results and remediation plan. The most important thing in that final report is not the headcount — it is how long this had been running. Everything below comes from the company's own statements and its FAQ.

April 2023 – March 2026
(established in the final report) The window in which unauthorised access to the sales management system took place. The company states it "confirmed that it occurred between April 2023 and March 2026" — roughly three years.
July 2025 onwards
(established in the final report) Traces of suspicious activity believed to date from July 2025 or later were found in the shared hosting environment.
9 Aug 2026
An anomaly was detected on a maintenance server for the shared hosting service, and the investigation opened. That is where detection started — the activity in the sales management system had already ended five months earlier.
During the investigation
Confirmed that a third party had reached some customer environments by way of the company's management environment, and that malware had been placed on some servers.
Immediately after confirmation
Containment: credentials invalidated, access blocked, malware removed.
17 Aug 2026
First report (583 accounts), plus reports to the Ministry of Internal Affairs and Communications, the Personal Information Protection Commission and other authorities.
19 Aug 2026
Second report: possible access to the sales management system, 1,360,563 member accounts potentially in scope, and a dedicated FAQ page.
10 Sep 2026
Investigation results and remediation plan: the count rises to 951 accounts, the intrusion window is fixed, some initial passwords are disclosed as unhashed, and the company concludes that no clear grounds were found linking the two events.

1,360,563

member records potentially in scope — NOT a confirmed breach count

951

hosting accounts possibly viewed or taken (up from 583 in the final report)

accounts whose hashed password data may have been accessed

~3 years

how long the sales-management intrusion ran: April 2023 to March 2026

What may have been exposed, per the company's published table

951 hosting accounts (up from 583 in the final report): User identifiers and data stored in the customer area — mail data, website data, log data and other files held in the customer area
1,360,563 member accounts: Contract records — member ID, company name, department, address, name, phone number, email address, date of birth, gender, fax number, contracted services, contract period, billing amounts and similar
30 of those accounts: Hashed password data (the company defines this as data from which the original password is difficult to recover)
Payment card data: The company states it does not store card data, so none was exposed
Unhashed initial passwords: Some initial server passwords for the shared hosting service and some administrator initial passwords for the VPS product. The final report states these were "not hashed", and the company is asking customers still using an issued initial password to change it
Exfiltration: The final report states that "no clear facts confirming that data was taken outside the company have been identified", and that no publication on the internet or dark web has been observed
Who is in scope: The FAQ states plainly that scope is not limited to rental server customers — anyone with a member registration is being examined

Do not misread the 1.36 million (updated for the final report)

1,360,563 is the count of member records potentially in scope, not a confirmed leak — the company's FAQ says explicitly that there is no finding that all of them leaked. It is not a reason for comfort either. Four points drive what you actually do. (1) The intrusion path is still unpublished even in the final report — the company states it is withholding technical detail on the intrusion path and system configuration to avoid enabling copycat attacks. (2) "Possible access" is not "was exfiltrated". (3) The hashed-password exposure covers 30 accounts — expect that figure to get conflated with the 1.36 million in secondhand coverage. (4) But the unhashed initial passwords are a separate item, newly disclosed on 10 September, and that one is actionable today. Do not upgrade unknowns into facts, and do not read "unconfirmed" as "fine".

Why customer-side hardening does not stop it

Attacker

↓ entry path not disclosed

Provider management environment

↓ descends from here

Your environment

files / database / mail

What a customer can deploy

strong passwords, patched apps, IP limits — none of them sit on that path

When the intrusion comes from above, none of the defenses a customer can deploy sit on the path.

The only variable you hold is what is sitting in that area. So the goal is not "keep them out" but "make being read survivable".

Outside your control

The intrusion into the provider's management environment
Attackers reaching your area through that management path
Learning about it promptly — here, eight days passed between detection and disclosure; taking time to investigate before disclosing is normal, and in the meantime customers had no way to know

Yours to decide

What you store there — secrets, personal data, keys
Whether that password also works somewhere else
Whether your only backup lives inside the same provider
Whether you have any means of noticing something is wrong

This site's view: shrinking what you'd lose beats changing your contract

Every incident like this produces the advice "leave shared hosting, get a VPS". We do not recommend that reflex. A VPS does isolate you further, but it also hands you full responsibility for OS and middleware patching; without the operational capacity to keep up, the result is a neglected server that becomes its own entry point. This site itself runs on infrastructure it does not have to itself, and the operating principle there is "make it survivable if that host is read" — secrets held as environment variables managed outside the published tree, credentials scoped per purpose, and the canonical copy of backups and published content kept elsewhere. The contract type is not a defense; it is one variable that sets your blast radius.

How the disclosure evolved — first report to final report

Incident facts never arrive all at once. In this case, the details that changed what customers should do landed in the FAQ before they landed in a news release. What follows is only what became known later, in order.

What the 2 September FAQ update added

On 2 September the company added several entries to its FAQ. No third press release has been issued, but the information that changes what customers should do lands in the FAQ first. Watching only the press release page will make it look as though nothing is moving.

Cancelling a service is not the same as deleting your account — former customers are in scope too

Asked why people who had already cancelled were receiving notices, the company explained that cancelling a service (ending an active contract) and withdrawing membership (requesting deletion of the member record) are separate procedures, and that member records are retained unless you withdraw. The sales management system that was accessed held exactly those records, so people who no longer use any Sakura service are still in scope.

This is not specific to one provider. A service you stopped using has not deleted your data just because you cancelled the subscription — when it is breached, the accounts you had forgotten about are breached with it. Once a year, take the services you no longer use past cancellation to actual account deletion. Cutting the number of dormant accounts pays off about as much as ending password reuse does. The same "what you retired becomes the hole" shape shows up in subdomain takeover.

"Not confirmed" is not the same as "did not happen"

The new entries draw a boundary around the questions customers actually ask. Every one of them is phrased as "as of now, no such fact has been confirmed", and the investigation is still open. Read them as unresolved, not as denials.

Stated as not confirmed as of 2 September

Mail bodies and received mail: No confirmed fact that message bodies or received mail inside mail accounts were viewed or taken — the second report concerns the system holding contract records
WordPress data, site data, contact form submissions: No confirmed fact that these were viewed or taken by a third party
Domain and DNS settings: No confirmed fact of unauthorised change; the company suggests reviewing your settings in the member console
Per-customer confirmation: The company states it is not in a position to confirm, customer by customer, whether data was viewed or taken. So "I was not contacted" does not mean "I was not affected" — acting precautionarily is the only option available

What the 10 September report established — read the duration, not the headcount

Roughly three years. That is the heaviest fact in the report

The company states that "unauthorised access to the sales management system was confirmed to have occurred between April 2023 and March 2026". In the hosting environment, traces believed to date from July 2025 or later were also found. Yet the anomaly that started the investigation was detected on 9 August 2026 — and it was detected on a maintenance server for the hosting service.

So the activity in the sales management system had already stopped five months before anyone noticed. The headline numbers (1.36 million, 951) travel further because they are easy to quote, but the thing defenders should take from this is the length of time it went unseen. That the company's own remediation list includes "reviewing the scope of security logging, retention periods, and the analysis capability" tells you where it landed for them too.

Newly established on 10 September

Unauthorised access to the sales management system ran April 2023 – March 2026
Hosting-environment traces date from July 2025 onwards
Scope rose from 583 to 951 accounts (368 added by follow-up investigation)
Some initial passwords were not hashed — initial server passwords for shared hosting, administrator initial passwords for the VPS product
No clear grounds were found linking the two events

Still not confirmed, even in the final report

Any clear fact confirming data was taken outside the company
Publication on the internet or the dark web
Secondary misuse, fraudulent use, or financial loss
The intrusion path — explicitly withheld to avoid enabling copycat attacks

This site's view: for a customer, the value of this report is one line about initial passwords

The report lists seven remediation measures, and nearly all of them are things only the provider can do — auditing administrative privileges, widening EDR coverage, rebuilding every server, commissioning external audits. Exactly one passage tells a customer to do something today: the one saying certain initial passwords were not hashed. Faced with a long incident report the instinct is to understand all of it; the more useful habit is the opposite — find the variables you control first. The rest is material for choosing your next provider, not for tonight.

One more thing. "Three years unnoticed" is not a statement about this company being unusual — intrusions found only after a year or more keep being reported, in Japan and elsewhere. Which is why the sane customer-side assumption is that a provider will be breached eventually. That is also why the conclusion of this article does not change: reduce what you would lose.

Sources

The facts above come from the following public records. No inference about the intrusion path, and no claim beyond what has been published.

Sakura Internet Inc., "Regarding unauthorised access to part of our rental server service environment" (first report, published 17 August 2026) — sakura.ad.jp
Sakura Internet Inc., "Notice regarding unauthorised access to our systems (second report)" (published 19 August 2026, updated 18:40 the same day) — sakura.ad.jp
Sakura Internet Inc., "Investigation Results and Remediation Measures Regarding the Unauthorised Access to Our Systems (Third Report)" (published 10 September 2026) — sakura.ad.jp
Sakura Internet Inc., "Notice and FAQ (published 19 August 2026, updated 21 August and 2 September; checked again for this article on 10 September 2026) — help.sakura.ad.jp
Reporting by INTERNET Watch, ITmedia NEWS and Nikkei (17 and 19 August 2026), all based on the statements above

Update log

2026-09-21: Restructured. The steps now come first so a reader can act, and the first-to-final report sequence is consolidated into "How the disclosure evolved" at the end. No facts were added or changed (the verification date is unchanged).
2026-09-10: Investigation results and remediation plan (third report) folded in. Unauthorised access to the sales management system is now established as running April 2023 to March 2026, with hosting-environment traces from July 2025. Scope rose from 583 to 951 accounts. The company newly disclosed that some initial server passwords for shared hosting and some administrator initial passwords for the VPS product were not hashed, so a step was added (change any initial password still in use, today). The company concluded that no clear grounds link the two events. Exfiltration remains unconfirmed, and the intrusion path is explicitly withheld to avoid enabling copycat attacks.
2026-09-05: FAQ update of 2 September folded in. The company explained that cancelling a service and withdrawing membership are separate procedures, and member records are retained until you withdraw, which is why former customers are in scope. It also drew a boundary around mail bodies, WordPress and site data, contact form submissions and DNS settings ("no confirmed fact" as of that date, with the investigation still open), and stated that it cannot confirm exposure customer by customer. A new section covers all of this, and the sender address used for its notices (support@sakura.ad.jp) was added. The intrusion path is still unpublished; the next announcement is targeted for mid-September 2026.
2026-08-22: FAQ update of 21 August folded in. The member console requires two-factor authentication, so the company says there is no strong need to change that password immediately; what it urges instead is changing any password reused on other services. The steps were reordered accordingly, and server/mail password changes plus second-factor checks are now a separate step. Confirming registered contact details and pruning unused accounts were also added to the FAQ. No third press release has been published as of writing.
2026-08-20: Second report (19 Aug) folded in. Possible unauthorised access to the sales management system holding contract records, with 1,360,563 member accounts potentially in scope (hashed password data for 30 of them). The company's FAQ now recommends a precautionary password change, so that became the first step, and scope is no longer limited to rental server customers. The intrusion path remains unpublished.
2026-08-18: First version, based on the first disclosure.

FAQ

QIf my hosting provider is breached, is it my fault?

No. When attackers reach customer environments through the provider's own management environment, no customer-side setting prevents that intrusion — it is a different situation from a site taken over through a weak password or an unpatched application. What you do control is how much is exposed when it happens: keep secrets out of the web-accessible area, never reuse the hosting password, and hold backups outside the provider.

QWhat should I check right now?

Three things: files or administrator accounts you do not recognise, unexplained changes to your site or application, and logins or outbound mail you cannot account for. Those are the checks Sakura Internet asked its customers to perform. Also treat any urgent-sounding message claiming to be from your hosting company as suspect until you verify it by logging in yourself.

QShould I change my passwords?

Stop reusing them immediately — that helps regardless of any single incident. For the affected service itself, providers usually notify affected customers individually; Sakura Internet stated it will contact affected customers directly if a password change or other action turns out to be required. Check the official website rather than acting on a link inside an email.

QI cancelled the service already, so why did I get a notice?

In an FAQ entry added on 2 September, Sakura Internet explained that cancelling a service and withdrawing membership are two different procedures: unless you withdraw, your member record is retained. The sales management system that was accessed held those member records, so former customers who no longer use any service are also in scope. The company says its notices come from support@sakura.ad.jp and that it never asks for passwords or credentials by email or phone. If a message looks doubtful, do not use its links — open the official page yourself.

QI am still using the initial password issued when I signed up. What should I do?

Change it today. In the 10 September 2026 investigation results, Sakura Internet disclosed that some initial server passwords for its rental hosting and some administrator initial passwords for its VPS product were, in the company's own words, 'not hashed', and it is contacting affected customers to ask them to change any initial password still in use. Hashing makes the original password hard to recover; without it, a password that was read is a key that still works. If you changed your password at any point after signing up, this item does not apply to you.

QWhy did the count rise from 583 to 951 accounts?

Further investigation. The company states that 583 accounts were reported as potentially viewed or taken as of 17 August, and that follow-up work identified a further 368 accounts with the same possibility, bringing the total to 951. It also notes that no clear link was established between those additional 368 accounts and the original event. Counts rising during an investigation is normal in incident response — do not treat a first-report figure as final.

QShould I move from shared hosting to a VPS?

Not automatically. A VPS gives you stronger isolation but transfers OS and middleware patching to you. Without the operational capacity to keep up, you simply create a neglected server with a new set of entry points. What matters more than the contract type is whether losing that server would cost you much at all.