# My WordPress Site Was Hacked: What to Do on xCloud

> Your WordPress site on xCloud was hacked? Keep the evidence, find what changed with Integrity Monitor, restore a clean backup or clean the site, and close the way in.

If your WordPress site on xCloud was hacked, work in this order: **keep the evidence, find what changed, remove the attacker's way back in, then restore or clean the site**. xCloud gives you the tools to see changed files, read your site's logs and restore backups. The malware cleanup itself is your task or a security specialist's, because it is not part of standard xCloud Support.

Signs of a hacked site include spam pages or posts you didn't write, redirects to other sites, admin users you don't know, a Google "This site may be hacked" warning, or an abuse report from your host or Cloudflare. If xCloud has already suspended the site after an abuse report, read [why xCloud suspends a site or server](/docs/why-xcloud-suspends-a-site-or-server-billing-and-abuse/) first: the steps below are also how you get it back.

## What xCloud support can and can't do

**xCloud Support helps you use the hosting tools. It does not remove malware.** This follows the [xCloud support scope](/docs/how-xcloud-support-scope-works-for-different-services/).

| Support can help with | Outside standard support |
| --- | --- |
| Checking that your server and site are online in xCloud | Removing malware or backdoors |
| Reviewing the logs and events xCloud shows | Forensic cleanup or finding exactly how the attacker got in |
| Pointing out suspicious signs from a hosting point of view | A guarantee that the site is fully clean |
| Guidance on restoring a clean backup | Repairing search rankings or blocklist reputation |
| Guidance on changing passwords, SSH/SFTP users and database passwords | Fixing plugin or theme code |
| Guidance on updates, the firewall and vulnerability scans | |

When the cleanup is more than you can do yourself, hire a WordPress security specialist or a malware-removal service. Give them the evidence from Step 1.

## Step 1: Keep the evidence before you change anything

Don't delete strange files or wipe the site yet. Deleting first destroys the clues that show how the attacker got in, and without them the same hole stays open.

1. Write down when you first noticed the problem and every change you make from now on.
2. Open the site and go to **Site Monitoring → Logs**. In **Select log type**, choose the access log (**Nginx Access Log** or **OpenLiteSpeed Access Log**, depending on your server), then the error log, and click **Download** for each. In the **Download Site Log** window, click **Download** again. The log file downloads to your computer. Logs rotate, so older lines disappear over time.
3. Check **Site Monitoring → Events** for recent actions on the site, such as restores, updates or setting changes.
4. On a paid plan, take a copy with **Site Backup → Previous Backups → Backup Now**. On the Free plan, download the files over SFTP instead, because **Site Backup** is locked. Keep this copy apart from your clean backups and never restore it: it contains the malware.

![Click 'Download' after choosing Nginx Access Log in Site Monitoring → Logs](/_landing/docs/my-wordpress-site-was-hacked-what-to-do-on-xcloud-image-1.png)

## Step 2: Find what changed with Integrity Monitor

**Integrity Monitor shows WordPress core and plugin files that differ from the official WordPress.org copies.** Open the site and go to **Security → Integrity Monitor**, then click **Scan Now**. When the scan finishes, expand **WordPress Core** and **Plugins** to see each flagged file.

![Click 'Scan Now' in Security → Integrity Monitor](/_landing/docs/my-wordpress-site-was-hacked-what-to-do-on-xcloud-image-2.png)

Read the results as clues, not as a verdict:

- **A core file that is modified or should not exist** is a strong sign. Attackers often hide files in `wp-admin` and `wp-includes`.
- **A flagged plugin** may have been changed by the attacker, or you may have edited it yourself.
- **What it can't see:** premium or custom plugins (they have no WordPress.org checksums), themes, the `uploads` folder and the database. A clean result here does not mean the site is clean.

For more on reading the results, see [how to verify WordPress checksums](/docs/verify-wordpress-checksums/).

## Step 3: Close the way back in

Do this before you clean or restore. Otherwise the attacker can return through the same door.

1. **Remove unknown administrators.** In WordPress, go to **Users** and delete any admin account you didn't create. Then change the passwords of every remaining admin.
2. **Change the site's server passwords.** In xCloud, open **Access Data → SSH/sFTP** and set a new **Password** for the site user, then click **Save**.
3. **Change the database password.** An attacker who could read `wp-config.php` also has this password. Note the **Database User** shown in the site's **Access Data → Database**. Then open the server's **Database** page, click **Edit** next to that user under **Database Users**, enter a new **Password**, keep the site's database ticked under **Can Access**, and click **Update**. xCloud writes the new password into `wp-config.php` for you, so you don't need to edit the file.
4. **Change other passwords and keys the site uses:** email (SMTP) passwords, payment and API keys in plugins, and the security keys in `wp-config.php` (generate new ones at https://api.wordpress.org/secret-key/1.1/salt/). This signs everyone out.
5. **Turn on two-factor sign-in** for your xCloud account with [two-factor authentication](/docs/two-factor-authentication-set-it-up-and-recover-access-if-you-lose-your-device/).
6. **Find the vulnerable plugin or theme.** Open **Security → Vulnerability Scan** and update or remove anything it flags. See the [vulnerability checker guide](/docs/vulnerability-checker-in-xcloud/).

If you run WP-CLI checks over SSH on a hacked site, add `--skip-plugins --skip-themes`. WP-CLI loads your site's plugins and themes by default, so without those flags it can run the attacker's code:

```bash
wp user list --role=administrator --skip-plugins --skip-themes
wp core verify-checksums --skip-plugins --skip-themes
find wp-content/uploads -name "*.php"
```

A PHP file in `uploads` is a common sign of a backdoor: that folder should only hold images and documents. See [how to run commands on your site and server](/docs/how-to-run-commands-in-your-site-and-server/) for SSH access.

## Step 4: Restore a clean backup, or clean the site

**Restore when you have a backup you trust; clean the site when you don't.**

### When a restore is right

Restoring needs a paid plan: on the Free plan, the **Site Backup** menu is locked. Restore only from a backup taken before the attack started. A backup is not safe just because it is older than the first symptom you saw: attackers often wait days or weeks before anything shows. Compare the backup dates with the earliest suspicious lines in your logs and the dates of the flagged files.

Go to **Site Backup → Previous Backups** and find a backup from before the attack. Click the three-dot (**⋯**) actions button in its **Action** column.

![Click the three-dot actions button in a backup's Action column in Site Backup → Previous Backups](/_landing/docs/my-wordpress-site-was-hacked-what-to-do-on-xcloud-image-3.png)

Choose **Restore Backup** and confirm. See [site backups in xCloud](/docs/site-backups-in-xcloud/) for local and remote backups, and [recreate a WordPress site from backups](/docs/recreate-wordpress-website-from-backups/) if you want to restore into a new site instead.

After a restore, finish Step 3 again on the restored site. The restored copy still has the old vulnerable plugin and old passwords, so update both straight away.

### When you need to clean the site

If every backup may be infected, clean the current site rather than restoring an infected copy. xCloud has no malware cleaner, so use a malware-removal tool or service:

1. Replace WordPress core with a fresh copy of the same version, keeping `wp-content` and `wp-config.php`.
2. Reinstall each plugin and theme from its official source, and delete the ones you don't use.
3. Remove PHP files from `uploads` and code you don't recognise in `wp-config.php` and `.htaccess`.
4. Check the site's cron jobs: open the site and go to **Tools → Cron Jobs**. Delete any job you didn't add.
5. Search the database for injected scripts and spam posts.

Once the files are clean, reset file and folder permissions and repair the site user:

1. Open the site and go to **Site Settings**.
2. On the **Rescue Site** card, turn on **Repair Site User** and **Update Directory Permissions**.
3. Click **Run Now**, then click **Yes, Run Now** to confirm.

You see the message "Site rescue job has been initiated." xCloud then repairs the site on the server. Rescue Site does not scan or clean files. See [reset file and folder permissions with Rescue Site](/docs/reset-file-and-folder-permissions-with-xcloud/).

## Step 5: Check the result and protect the site

1. Click **Scan Now** in **Security → Integrity Monitor** again. WordPress core should now pass.
2. Run **Security → Vulnerability Scan** again and update anything it still flags.
3. Watch **Site Monitoring → Logs** for a few days for the same requests you saw in Step 1.
4. If the site was suspended, reply to the support ticket with what you found and fixed. A person from our team reviews it and lifts the suspension once the site is clean.

For ongoing protection, follow the [WordPress security checklist](/docs/wordpress-security-checklist-for-xcloud/). To get earlier alerts and block attacks on known plugin and theme flaws before you can update them, you can add [Site Security Pro, powered by Patchstack](/docs/set-up-site-security-pro/). It blocks known attacks, but it doesn't remove malware that is already on the site.

## Frequently asked questions

### Will xCloud support clean the malware from my site?

No. Malware removal and forensic cleanup are not part of standard xCloud Support. Support can check your server and site in xCloud, review the logs and events xCloud shows, and guide you on restoring a clean backup, changing passwords and updating WordPress. For the cleanup itself, use a WordPress security specialist or a malware-removal service.

### Does a clean Integrity Monitor or Vulnerability Scan result mean my site is clean?

No. Integrity Monitor compares WordPress core and WordPress.org plugin files with their official copies, so it cannot see malware in uploads, themes, premium plugins or the database. The Vulnerability Scan and Site Security Pro report known vulnerabilities in your plugins, themes and core. Neither one removes malware or proves that it is gone.

### Should I restore a backup or clean the site?

Restore a backup only when you are sure it was taken before the attack started. A backup is not safe just because it is older than the first symptom you saw. If every backup may be infected, clean the current site instead of restoring an infected copy.

### Can malware on one site spread to my other sites on the same server?

Each site on an xCloud server usually runs under its own user, so its files are kept apart from your other sites. One infected site does not by itself mean the others are infected. Still check every site whose files, admin accounts or passwords overlap with the hacked one.

If you run into any issues while recovering your site, feel free to reach out to our [support team](/docs/access-built-in-support-portal-in-xcloud/).