Unauthorized Access to Some ConoHa WING (GMO Internet) Web Servers (426 Accounts): Data in Customers' Web Server Areas Affected, and What Site Owners Should Do Today

The company says it has contacted affected customers individually "at the email address registered as contract information", and that customers who have not been contacted are not affected.

Check the spam folder as well as the inbox. If a web agency signed the contract for you, or you registered with an old address, the email should have gone there. Log in through the official site you open yourself to see which address is registered, or ask the contact point in the notice (listed under "What happened" below).

The company warns about phishing emails that take advantage of this incident, and says it never asks customers for passwords or credit card details by email. It also asks customers to check the sender and content of the individual notices before acting on them.

After a hosting incident, fake emails are likely, with wording such as (our examples) "your account is affected and must be reset" or "please confirm your contract", leading to pages made to look like the login screen. Do not log in through links in emails; open the official site from a bookmark or your own search (see what phishing is).

The company says it has sent affected customers the details and the "actions we would like you to take" by individual email. That content is not public, so this article cannot repeat it. Before acting, confirm the email is genuine as in step 2: check through the official site, not the links in the email.

The data concerned is "data stored in customers' web server areas". The notice does not say whether it was taken, but this site recommends treating it as possibly read or altered. Changing credentials costs less, in effort and risk, than leaving them in an unknown state.

• The database user name and password in WordPress's wp-config.php (after changing the database password, put the same value in wp-config.php)
• API keys for outside services (payments, email delivery, maps and so on) in .env and similar files: reissue them in each service's dashboard and disable the old keys
• WordPress administrator passwords and the secret keys (salts) in wp-config.php; regenerating the salts logs everyone out
• FTP and SSH passwords and keys, and any public keys registered on the server
• Backup files kept on the server (such as database exports): treat the credentials and personal data in them as read too

Make the changes from a computer you have scanned with antivirus software. To rethink where configuration files live, see keeping .env off the public web on shared hosting; for handling API keys, see .env and API key basics.

The company says it removed the malicious programs on September 18. Even so, it is worth checking for yourself that no change you did not make remains in your site. The access began on September 3, so focus on changes since then.

• In the file manager, sort the public folder by modification date and look for files changed on dates you did not touch, or PHP files inside image folders
• In WordPress's user list, look for administrators you did not create, and for plugins or themes you did not install
• In the control panel's scheduled jobs (cron), look for entries you did not add

Where and in what order to look, by environment, is in how to check if your website or server was hacked. If you find something unfamiliar, copy it before deleting it and contact the company. If your site kept other people's personal data, such as contact-form submissions or member records, also read that article's section on when personal data may have leaked.

Per the company, member, contract and payment data were managed in an environment separate from the affected servers and were not leaked. It is an example of a general idea: keeping things in separate places narrows how far a breach of one part can reach.

You can do the same on your own site. Do not leave database exports or old backups in the web server area, issue API keys with only the permissions they need, and keep configuration files outside the public folder. How to check is in did you leave a secret file in a public directory?

By the published dates, 13 days passed between the start of the access (September 3) and detection (September 16). That is a difference between two dates, not a judgment on whether detection was slow. Still, whether you notice changes on your own site when something happens on the provider's side depends on what you have in place.

An easy first step: once a week, export the list of WordPress administrator users and the list of PHP files in the public folder, and compare them with the previous week. Anything new is a reason to start looking. For hardening WordPress as a whole, see WordPress security — a production hardening reference.

In this incident, the way to learn whether you are affected is an individual email to the address registered on the contract. If that is still a web agency's address or one you no longer use, you will miss it. Check now, while nothing is wrong, that the registered address is one you read and that the provider's emails are not going to spam.