WordPress site hacked? What to do first, and how to stop it

Why were so many WordPress sites hacked in October 2026?

Because attackers came in from three directions in a single week, and two of them came through tools people trust. None of them needed the site owner to do anything daft.

• A poisoned update. Some copies of Rank Math SEO PRO version 3.0.123, downloaded between 15 and 16 October, carried malware. Updating to the clean 3.0.124 removes the plugin, not the attacker.
• Stolen keys. The company behind the UpdraftPlus backup plugin found its own website had been breached over the weekend of 17 and 18 October. Attackers then used stolen UpdraftCentral keys, which let people manage sites remotely, to install backdoor plugins.
• A flaw underneath everything. On 21 October, PHP, the programming language WordPress runs on, released emergency fixes for two critical flaws nicknamed PHP2Shell. They let an attacker run code on your server without logging in, whatever plugins you use.

What does a hacked WordPress site look like?

Often, exactly like a normal one. Here’s a real example from that week, with the client details left out.

In the early hours, before any PHP patch existed, an automated tool hit a handful of sites we look after. They sat on different hosting companies and fell within seconds of each other. On each one, the tool created a new administrator account, then used it to slip one line of JavaScript into the theme.

That script showed visitors a fake “verify you are human” box, dressed up to look like Cloudflare, telling them to paste a command into their computer. Anyone who did would have installed malware that steals saved passwords. Security people call this trick ClickFix.

The script was cloaked, so the owner, our team and automated scanners all saw a clean site. Only ordinary visitors saw the trap. We restored the sites from backups taken before the attack, then swept every other site we manage. The lesson stuck: “the site looks fine” proves nothing.

What should you do if your WordPress site is hacked?

Work through these seven steps in order. Skipping ahead is how sites get reinfected.

1. Contain it

Ask your host to take the site offline or put a holding page up at server level. A maintenance-mode plugin isn’t enough, because some attacks reach the server before WordPress even loads.

2. Save the evidence

Before you change anything, take a full copy of the hacked files and database. Label it clearly and note when you first spotted the problem. Your insurer, a specialist or the Information Commissioner’s Office may need it later.

3. Change every key

Change every password connected to the site, not just your WordPress login:

• Hosting control panel and SFTP accounts
• The database password, updated in your site’s configuration file
• Every WordPress user with Editor access or above
• The email account linked to your admin user, since that’s where password resets land
• API keys stored in the site, such as payment, email or CRM connections

Then revoke application passwords, disconnect remote management tools, log every user out and change your WordPress security keys (the “salts”). That kicks out any session the attacker still holds.

4. Check who’s in the house

Open the Users screen and look for administrators you don’t recognise. Then check the plugins list for anything you didn’t install, especially names made of random letters and numbers.

5. Restore or clean

If you have a clean backup from before the attack, restoring is usually the quickest route. Worth knowing: a restore is not a clean-up. It changes no passwords or keys, so repeat step three afterwards.

No clean backup? Then you need fresh copies of WordPress core and every plugin and theme, a check of the uploads folder for code files, and a check of the database for injected scripts. Miss one backdoor and the attacker walks straight back in. If that sounds like a lot, it’s worth getting a professional to take over your site.

6. Find out how they got in

Weak password, out-of-date plugin, an old account nobody remembered? Start with your security plugin logs and your host’s server logs. Until you know the way in, you haven’t really fixed anything.

7. Tidy up with Google and your customers

Check Google Search Console for security warnings and, once the site is clean, request a review. If personal data may have been exposed, you may need to report it to the ICO within 72 hours under UK GDPR.

How do you stop your WordPress site being hacked again?

With layers of protection and someone actively watching, not just monthly updates. October showed why: in one case the update was the attack, and in another there was no update to install yet.

The scale isn’t shrinking either. Patchstack counted 11,334 new WordPress vulnerabilities in 2025, with 91% of them in plugins.

Put a firewall in front of WordPress

A web application firewall (WAF) blocks malicious requests before they reach your site. It needs to sit at your host or with a service like Cloudflare. A security plugin such as Wordfence is still worth having for scans, two-factor logins and alerts, but it runs inside WordPress, so it can’t stop a flaw in PHP itself.

In our case, the sites that were hit had no firewall or security plugin at all, and the sites that held did. It’s a small sample, so treat it as a pattern rather than proof.

Harden the settings nobody sees

• Switch off the dashboard file editor. Our attacker edited theme files through it. One line in the configuration file (DISALLOW_FILE_EDIT) turns it off.
• Clear out old files. Forgotten backup zips, database exports and debug settings hand attackers a head start.
• Check your security rules actually run. Many hosts use nginx, which ignores the .htaccess files a lot of security advice relies on.

Fewer keys, stronger locks

Keep administrator accounts to the bare minimum and give everyone else Editor access. Switch on two-factor authentication for every administrator and editor, and check for new admin accounts monthly. We cover more of this in our guide to common WordPress security mistakes.

Patch in hours, not weeks

Check your PHP version under Tools, Site Health, Info, Server. The PHP2Shell fixes are in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 [CHECK: confirm no later PHP release before publishing]. Ask your host to confirm the patched build is actually running. Good WordPress hosting will tell you without being chased.

Backups you’ve actually tested

Keep daily backups off the server, with enough history to go back before an attack. Then test a restore. A backup you’ve never restored is a hope, not a plan.