Security Guides
Your Web Host Was Breached — What Can You Actually Do?
When the hosting company itself is compromised, no customer-side setting stops the intrusion. Using Sakura Internet's August 2026 disclosure as the anchor case, this guide separates the confirmed facts from what is still under investigation, and gives you four moves that shrink the blast radius.
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.
What was disclosed (17 August 2026)
Sakura Internet Inc. announced on 17 August 2026 that it had confirmed unauthorised third-party access to part of the customer environment of its shared hosting service, "SAKURA Internet Rental Server". Everything below comes from the company's own published statement.
9 Aug 2026
The company detected an anomaly in a server environment it manages and opened an investigation.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
Public disclosure, plus reports to the Ministry of Internal Affairs and Communications, the Personal Information Protection Commission and other authorities. Individual notices to affected customers began.
- Unauthorised logins
- 583 accounts (company figure; the set of potentially affected environments is still under investigation)
- Possibly exposed
- "Information stored within the customer area" and "user identifiers" (scope still under investigation)
- Reach
- The company confirmed that attackers were in a position to access customer information and information covered by the secrecy of communications
- Tampering
- No customer reports of defacement or tampering at the time of disclosure
- No impact confirmed
- SAKURA VPS, SAKURA Cloud, SAKURA Dedicated Server PHY, Koukaryoku PHY
- Actions taken
- Some features restricted (database upgrade, plan change, migration tools), credentials invalidated, malware removed, forensic investigation, increased monitoring
Read the unknowns, not just the number
Headlines carry the count; the unconfirmed items are what actually drive your decisions. (1) The intrusion path has not been published — "by way of the management environment" is the whole of it. (2) 9 August is the detection date, not the breach date; timing is still under investigation. (3) 583 is the number known so far, and the company explicitly says the investigation continues. (4) "Was in a position to access" is not "was exfiltrated". 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
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
Four things to do today
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. Do not follow links in those emails; go to the official site yourself.
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.
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" (published 17 August 2026) — sakura.ad.jp
- Reporting by INTERNET Watch, ITmedia NEWS and Nikkei (17 August 2026), all based on the statement above
Update log
2026-08-18: First version, based on the confirmed contents of the initial disclosure. The intrusion path, timing and scope are stated to be under continuing investigation; follow-ups will be added to this section as they are published (see the "as of" date at the top of the article).
Read next
- Practice: keeping .env out of reach on shared hosting / backup and recovery essentials / choosing multi-factor authentication
- Terms: what phishing is / what malware is
- Case: the Codecov supply-chain breach (2021) — the same shape, where a trusted path is compromised and customers cannot block it themselves
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.
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.