You log into a client’s WordPress site on Monday morning and the homepage is selling crypto, redirecting visitors, or showing a giant “HACKED” message.
You restore last night’s backup. Everything looks normal again. Then three days later, it happens again.
That second incident is the one that matters.
A WordPress site hacked once can be bad luck. A WordPress site hacked twice usually means the original entry point was never fixed.
And the cause is often much less mysterious than people think. An outdated plugin, a stolen administrator password, an exposed upload function, or a vulnerable piece of software can be enough.
Verizon’s 2026 Data Breach Investigations Report says vulnerability exploitation was involved in 31% of breaches analyzed, making it the leading initial breach vector for the first time in the report’s history.
For a small business site or the 10 client sites you manage on the side, that doesn’t mean you need a security operations team.
You need to know where to look first.
Why does a WordPress site get hacked?
Most WordPress compromises start with one of four things: vulnerable software, stolen credentials, insecure configuration, or an already-compromised hosting environment.
The first one is especially common because WordPress sites are rarely just WordPress.
There’s WordPress core. Then 15 plugins. A theme. Maybe WooCommerce. A page builder. An analytics plugin. A form plugin. An image optimizer. Something for backups. Something else for SEO.
Every extra component is another piece of software that can have a bug.
Take CVE-2024-2024 as a real example. The Folders Pro WordPress plugin had an arbitrary file upload vulnerability that could allow an authenticated attacker with author-level access or higher to upload files to the server, potentially leading to remote code execution. NIST’s NVD lists it with a CVSS 3.1 score of 8.8.
That’s not some theoretical “hackers might find a way” problem.
A vulnerable upload function can become a way to put executable code on your server.
Another example is CVE-2024-9047 in WordPress File Upload. Versions up to 4.24.11 were vulnerable to path traversal that could let an unauthenticated attacker read or delete files outside the intended directory. The NVD lists a CVSS 3.1 score of 9.8.
This is why “I use WordPress, so I just need a security plugin” is not a complete security strategy.
You need to know what is exposed, what is outdated, and whether anything suspicious has already happened.
WordPress site hacked? Find the entry point before restoring it
The most common mistake I see is this:
Restore backup → change the admin password → move on.
That fixes the visible damage. It may not fix the compromise.
If the attacker got in through a vulnerable plugin, restoring the old version simply puts the same door back on the server.
If they stole an administrator password, changing only the WordPress password may leave hosting, FTP, database, Git, or other credentials exposed.
Start with the evidence.
Look at:
- WordPress administrator accounts you don't recognize
- Recently modified PHP files
- New files inside
wp-content/uploads - Unknown plugins or themes
- Scheduled tasks and cron jobs
- Web server access logs
- Failed and successful login attempts
- Changes to
.htaccessor server configuration - Unexpected redirects
- Suspicious JavaScript injected into templates
- New API keys or application passwords
WordPress itself recommends treating things such as search-engine blacklisting, malware warnings, or a disabled site as indicators of compromise, and recommends a pragmatic investigation rather than simply guessing what happened.
If you have SSH access, even a simple command can help you find recently changed files:
find /var/www/html -type f -mtime -3 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
That doesn't prove a file is malicious. It gives you a place to start.
And don't ignore the logs. If you see repeated requests against a plugin endpoint immediately before a strange PHP file appears, you may have found the chain.
The boring WordPress fixes that stop most repeat compromises
Security advice often gets too complicated too quickly.
For a small WordPress site, I'd fix the boring stuff before buying another security product.
First, update everything you actually use.
From WP-CLI, you can check outdated plugins with:
wp plugin update --all
Don't blindly run this on a production site with no backup or staging process, though. Updates can break poorly maintained plugins.
Second, delete plugins and themes you don't use.
Deactivated code is still code sitting on your server. If it contains a vulnerability, “inactive” doesn't magically make it safe.
Third, protect administrator accounts.
Use unique passwords and MFA. Don't use admin as the username. Don't reuse the WordPress password for hosting or email.
Credential attacks aren't theoretical either. Verizon found compromised credentials involved in 22% of breaches in its 2025 DBIR, and small businesses still saw credential-stuffing attempts making up a meaningful share of authentication traffic.
Fourth, disable dashboard file editing if you don't need it:
define( 'DISALLOW_FILE_EDIT', true );
WordPress recommends this as a hardening measure because it removes the built-in ability to edit plugin and theme files from the dashboard. It won't stop an attacker who already has server-level access, but it removes one useful avenue after an account compromise.
Fifth, make sure your backups are actually recoverable.
A backup you have never restored is a theory, not a recovery plan.
I'd restore one to a staging environment occasionally and check that the database, uploads, themes, plugins, and configuration all come back correctly.
A WAF helps, but it won't patch your WordPress site
This is another common misunderstanding.
A Web Application Firewall can block malicious requests before they reach your application. That's useful.
But a WAF doesn't turn vulnerable code into secure code.
Suppose a plugin has an upload vulnerability. Your WAF might block some obvious exploit attempts. Great.
But if an attacker gets around that rule, the vulnerable plugin is still vulnerable.
The same applies to security headers.
You might see something like:
Content-Security-Policy: default-src 'self'
That's useful for reducing certain browser-side attack paths, especially some forms of cross-site scripting.
It doesn't patch a vulnerable plugin.
Likewise, this:
Strict-Transport-Security: max-age=31536000; includeSubDomains
helps enforce HTTPS in browsers. It doesn't stop someone from exploiting an outdated PHP library on your server.
Think of the layers separately:
LayerWhat it protectsUpdates and patchingKnown software vulnerabilitiesMFAStolen or guessed credentialsWAFMalicious HTTP requestsSecurity headersBrowser-side attack surfaceMonitoringDetecting changes and failuresBackupsRecovery after compromise
You want all of them.
But don't let a shiny WAF dashboard convince you that patching is optional.
WordPress's own security guidance makes the same distinction. Website owners are responsible for the application they install, while hosts primarily protect the underlying infrastructure. WordPress also recommends keeping plugins updated, removing unused plugins, using backups, and considering a WAF.
Stop checking WordPress security only after something breaks
If you manage one site, you might remember to check it.
If you manage ten, you'll forget.
That's where security monitoring becomes more useful than another checklist sitting in a Notion page.
You want to know when a plugin becomes vulnerable, when an SSL certificate is about to expire, when the site goes down, when a page starts behaving differently, or when a real browser can't complete an important action.
That last part matters.
A basic uptime check can tell you that https://example.com returns HTTP 200.
It can't tell you whether the checkout button works.
It can't tell you whether JavaScript errors broke the login form.
It can't tell you whether your contact form silently stopped submitting.
For client sites, I'd monitor both infrastructure and actual user journeys. That's much closer to what the customer experiences.
You also want security checks before deployment, not only after code reaches production. A vulnerable dependency or dangerous code change is much cheaper to fix before it becomes a live incident.
Torlyx brings those checks into one website security lifecycle, including vulnerability scanning, uptime and SSL monitoring, real-browser checks, WAF protection, and pre-deployment code scanning. Torlyx features
What I'd do today if a client said their WordPress site was hacked
I'd keep it simple.
1. Take the site seriously, but don't start deleting random files.
Preserve logs and a copy of the current state if you can. You may need them to understand what happened.
2. Put the site behind a maintenance page if the compromise is active.
You don't want customers submitting forms or entering payment information while you're investigating.
3. Rotate credentials.
WordPress admins, hosting, SSH, FTP, database users, API keys, application passwords, and anything else that could have been exposed.
4. Identify the vulnerable component.
Check WordPress core, plugins, themes, PHP, server software, and known CVEs. Don't assume the most obvious plugin is responsible.
5. Remove persistence.
Look for unknown administrator accounts, malicious PHP files, modified plugins, injected JavaScript, cron jobs, and suspicious configuration changes.
6. Patch before restoring.
If the vulnerable plugin is still installed, restoring yesterday's backup doesn't solve the problem.
7. Restore from a known-clean backup if necessary.
Then compare the restored site against the compromised one.
8. Add monitoring.
You want to know quickly if the site goes down, its certificate changes, a vulnerability appears, or something important stops working.
And if you can't confidently determine whether the site is clean, get another engineer to inspect it. Guessing is expensive when the site handles customer accounts, payments, or personal data.
For a site you don't have time to babysit, you can run a free scan to get an initial view of exposed security problems before deciding what needs attention.
FAQ
Why does my WordPress site keep getting hacked?
Usually because the original entry point remains open. Common causes include vulnerable plugins, stolen administrator credentials, outdated software, insecure hosting, or malicious code that survived the first cleanup.
How do I know if my WordPress site has been hacked?
Look for unknown admin accounts, unexpected redirects, unfamiliar files, sudden traffic changes, malware warnings, modified plugins or themes, and strange server requests. A clean-looking homepage doesn't prove the site is clean.
Can a WordPress security plugin prevent hacking?
It can reduce risk, but no plugin can guarantee that your site won't be compromised. Patching, MFA, backups, monitoring, sensible configuration, and a WAF all solve different parts of the problem.
If your WordPress site has been hacked, don't start by redesigning the homepage.
Start by finding the door the attacker used, close it, then verify that they didn't leave another one behind.