Attackers don’t target WordPress sites at random. They target them at scale, running automated scans across millions of sites to find known vulnerabilities. Hundreds of thousands of those sites are actively compromised at any given moment.
The good news is that breaches follow predictable patterns. Understanding those patterns makes them easier to prevent and, failing that, easier to recover from.
We’re looking at both sides of that equation. We’ll show you how to recognise the signs of a compromised site and work through a structured five-step recovery process. Finally, we’ll go over what needs to change before you relaunch.
Is your WordPress site at risk?
WordPress itself isn’t the problem. The core software has a dedicated security team and receives regular patches. The real risk usually comes from plugins.
Plugins extend what WordPress can do, but each one adds code that attackers can probe for weaknesses. Tens of thousands of plugins are available, and not all of them receive timely security updates.
When a vulnerability surfaces in a popular plugin, attackers build automated exploits and scan the web within hours of public disclosure.
That’s what makes WordPress sites a consistent target. It’s not that the platform is poorly built. Instead, the plugin ecosystem creates a vast, constantly shifting attack surface that’s difficult to monitor without the right tools.
If your site runs plugins, and virtually every WordPress site does, it’s worth understanding what a breach looks like and what to do if one happens.
Why WordPress sites are constantly targeted
Attackers don’t choose targets based on how big or valuable a site looks. They choose them based on what software they’re running and whether that software has a known, unpatched flaw.
Plugins are the real attack surface
Thousands of plugin and theme vulnerabilities are disclosed every year. Nearly half of them never receive a patch from the developer at all, either because the plugin has been abandoned or because the developer is slow to respond.
That’s not a minor gap. An unpatched vulnerability in a plugin installed on millions of sites gives attackers a reliable, repeatable entry point. They don’t need to break anything, either. They just need to find a site that hasn’t updated yet.
Two recent examples illustrate how serious this gets:
- CVE-2025-24000 exposed a broken access control flaw in the Post SMTP plugin. It let any logged-in user, even subscribers, view email logs with password reset links, enabling admin account takeovers. A patch was released in June 2025, yet over 200,000 sites remained vulnerable weeks later.
- In June 2024, attackers executed a supply chain attack after gaining control of JavaScript library Polyfill.io’s domain. Many sites load it from a CDN, which allowed the attackers to modify the script and redirect mobile users to malicious sites. Over 110,000 sites were affected. The script was designed to evade detection by admins and analytics tools.
How fast attackers move after disclosure
The window between a vulnerability being made public and the first exploit appearing in the wild is often measured in hours.
Attackers monitor the same security feeds that developers do. When a high-impact vulnerability drops, automated scanning tools get updated quickly and start probing for unpatched sites almost immediately.
Waiting a few days to apply an update isn’t a minor delay. For high-severity vulnerabilities, it can be long enough for your site to be compromised before you’ve even seen the notification.
The true cost of a compromised site
The immediate damage is visible enough. A hacked site might serve malware to visitors, redirect users to spam pages, or get blocklisted by search engines. But the longer-term costs are harder to recover from.
Search rankings can take months to recover, and some site owners report that traffic never fully returns to pre-breach levels. A sudden drop in organic visibility isn’t always algorithmic. Sometimes it reflects a trust penalty that follows a security incident.
There’s also a legal dimension that’s easy to overlook. If your site collects personal data from users in the EU, a breach that exposes that data triggers a 72-hour notification obligation under GDPR. Missing that window can result in regulatory penalties on top of the reputational damage.
Taking a breach seriously reflects what the evidence shows about how these incidents play out for site owners who don’t have a recovery plan in place.
How to tell if your site has been hacked
By the time you notice something is wrong, the breach may have been active for days or weeks. The most damaging infections are the ones designed to stay invisible to the person running the site.
What visitors see before you do
The most common visible symptom is redirects. It could be that visitors land on your site and get pushed to a spam page or a scam offer. You don’t see it because you’re logged in.
Malware campaigns like DollyWay, which infected over 20,000 sites, often exclude logged-in admins, showing them a normal site while redirecting other visitors. If you suspect redirects, test your site from an incognito window while logged out, or ask someone on a different network to check.
Other visitor-facing signs include unfamiliar pop-ups, injected banner ads, and pages that appear in Google’s index that you never created.
Admin panel red flags
Log into your WordPress dashboard and check for admin accounts you don’t recognise. Attackers routinely create backdoor accounts to maintain access after the initial intrusion. Also look for recently modified plugins or theme files, particularly ones you haven’t touched.
If you’re locked out of your admin panel entirely, that’s a strong indicator that your credentials have been changed by an attacker.
Google warnings vs “Not Secure” labels
These two things aren’t the same. A “Not Secure” label in the browser address bar means your site isn’t running HTTPS. It’s a configuration issue, not evidence of a breach.
A Google Safe Browsing warning is different. If visitors are seeing a red interstitial warning before reaching your site, Google has flagged it for malware or deceptive content. You can check your site’s status directly via Google’s Safe Browsing tool and through Google Search Console, which will flag security issues if your site has been compromised.
The signs designed to stay hidden
Some infections leave no obvious trace.
SEO spam injections add hidden links and pages to your site to manipulate search rankings, visible to crawlers but not to you. Malware can disable security plugins to prevent detection. File timestamps can be manipulated to make recently altered files appear untouched.
These techniques exist because staying hidden extends how long an infection remains useful to the attacker. A clear-looking dashboard isn’t confirmation that your site is clear.
5 steps to recover a hacked WordPress site
Recovery is all about closing the entry point, eliminating any remaining persistence mechanisms, and ensuring you don’t restore the infection along with your backup.
Step 1: Isolate and stop active damage
Put your site into maintenance mode or take it offline. This limits the harm to visitors while you work and prevents the attacker from making further changes. Contact your host if you need help restricting access at the server level.
If Google has flagged your site, don’t rush to request a review. Do that after cleanup, not before.
Step 2: Scan for malware
Don’t rely on external scanners that fetch your site over HTTP. They can only see what a browser sees, which means they’ll miss server-side malware entirely.
Use a server-side scanner like ShieldPRO’s MAL{ai}, which scans the actual files on your server. This is important because malicious code is often injected into PHP files, configuration files, and locations that an external checker never touches.
Step 3: Reset all credentials
Change every password connected to the site. That means WordPress admin accounts, your hosting control panel, SFTP credentials, and your database password. Check for admin accounts you don’t recognise and delete them.
Also rotate any API keys or secret keys stored in wp-config.php. If the attacker had access to your server, assume they’ve read that file.
Step 4: Replace files and verify backups
Deleting malicious files isn’t enough.
Take, for example, when research on DollyWay at GoDaddy Security found that nearly half of compromised sites still had at least one backdoor installed at the time of cleanup.
Backdoors are designed to survive standard removal attempts, and some malware reinfects the site on every page load if a single compromised file remains.
Replace WordPress core files with fresh copies from WordPress.org. Do the same for any plugins and themes where possible.
If you’re restoring from a backup, verify when it was taken. Restoring an infected backup doesn’t fix anything.
ShieldBACKUPS stores backups off-site, separate from your host, with no credentials on the WordPress site.
It runs automatically, keeps multiple restore points, and allows a single zip download. Included in ShieldPRO Plus and higher tiers at no extra cost.
Check the backup date against any indicators of when the breach started, and treat the restored files with the same scrutiny as the live ones.
Step 5: Harden before you relaunch
Cleaning a site and relaunching it in the same state it was in before the breach is how reinfection happens. Before you bring things back online, harden the site:
- Update everything, including WordPress core, every plugin, every theme. If a plugin hasn’t been updated by its developer in over a year, consider replacing it.
- Remove anything you’re not actively using. Inactive plugins and themes are still executable code. Delete them rather than leaving them deactivated.
- Tighten file permissions. WordPress files should be set to 644 and directories to 755. wp-config.php should be more restrictive still.
- Enable two-factor authentication on all admin accounts. A compromised password alone shouldn’t be enough to get in.
- Consider whether your current hosting environment gives you adequate visibility into file changes. Shared hosting limits what you can monitor. If this breach exploited that limitation, it’s worth addressing before the next one.
Hardening is the baseline you return to after an incident and maintain between them. The sites that get reinfected are usually the ones that skipped this step.
How ShieldPRO closes manual recovery gaps
Manual cleanup is better than nothing. It’s also slow, easy to get wrong, and it leaves the underlying vulnerabilities in place.
Most site owners who clean a hacked site manually do so without knowing how the attacker got in, which means they’re relaunching into the same conditions that allowed the breach.
Where manual cleanup falls short
The core problem with manual recovery is that it’s reactive. You’re working from visible symptoms, not a complete picture of what changed and when. Without file-level monitoring in place before the breach, you’re making educated guesses about which files to trust.
That’s before accounting for the time involved. A thorough manual cleanup on a compromised site takes hours. Done under pressure, with incomplete information, the margin for missing something is significant.
Blocking the entry points behind 91% of breaches
Plugins account for 91% of disclosed WordPress vulnerabilities, according to Patchstack’s security report. The majority of successful breaches exploit flaws that already have a patch available. The site just hasn’t been updated yet.
ShieldPRO’s vulnerability scanner checks your installed plugins against known vulnerability data and flags anything that needs attention. Auto-upgrade handles the update automatically, without waiting for you to log in and action it manually.
The window between a patch being available and it being applied on your site is where most attacks land. Closing that window is the most direct form of plugin protection available.
The audit log as your full incident record
When a breach happens, the audit log tells you what changed, when, and under which account. That’s the information you need to establish a reliable recovery point and to satisfy any reporting obligations under GDPR.
Continuous monitoring after cleanup
Cleanup isn’t the end. Reinfection is a genuine risk, and catching it early limits the damage.
ShieldPRO has you covered on this front:
- MAL{ai} runs AI-based malware scanning with a detection accuracy of 80 to 90%. You can also configure it to scan as frequently as once per hour.
- File Locker monitors wp-config.php for unauthorised changes.
- Automatic core file repair replaces modified WordPress core files without requiring manual intervention.
Together, these close the gap between cleaning a site and actually keeping it clean.
Our backdoor guide covers where backdoors typically hide and how to find them. Our malware removal guide walks through the full file replacement process.
Secure your site before the next attack
Most breaches don’t announce themselves. By the time you notice something is wrong, the infection has often been active for days.
MAL{ai} runs AI-powered malware scans directly on your server, with high detection accuracy rates of 80 to 90% and a scan frequency of up to once per hour. It’s the difference between finding a problem on your terms and finding it after Google does.
ShieldPRO combines MAL{ai} with vulnerability scanning, auto-updates, file monitoring, and off-site backups in a single plugin. If you’re running a WordPress site without it, you’re managing that risk manually.
Check out ShieldPRO today and stop the next breach before it starts.
Frequently asked questions
How does the VexTrio redirect scheme work?
VexTrio is a traffic direction system that operates as a criminal affiliate network. Compromised WordPress sites are enrolled as nodes in the network, which routes visitor traffic through a chain of redirects to malicious destinations, including phishing pages and scam sites.
The initial compromise typically happens through a vulnerable plugin. Once the malicious code is in place, VexTrio’s system determines where each visitor gets sent based on their location, device, and browsing profile.
How did the Post SMTP vulnerability enable admin takeovers?
The flaw was in the plugin’s REST API, which checked whether a user was logged in but didn’t verify their permission level. A low-privileged subscriber account could access the email logs, find a password reset email sent to an administrator, and use that link to take over the admin account.
Is “Not Secure” the same as being hacked?
No. A “Not Secure” label means your site is running HTTP instead of HTTPS, which means data passed between your site and visitors isn’t encrypted.
It’s a configuration issue, not a sign of compromise.
Fix it by installing an SSL certificate, most hosts provide one free of charge.
A Google Safe Browsing warning is different and does indicate your site has been flagged for malicious content.
