Key takeaways
WordPress's popularity, not a weakness in the software, is the main reason it gets targeted so heavily.
Researchers logged 11,334 new WordPress vulnerabilities in 2025, a 42 percent increase on 2024, and the median time from disclosure to mass exploitation is now around five hours.
Around 91 percent of these vulnerabilities sit in plugins, not WordPress core itself.
Most successful attacks exploit issues that already have a patch available. The gap is in applying it, not in the fix existing.
A layered setup- updates plus access control plus a firewall plus backups- stops the overwhelming majority of real-world attacks. No single plugin or setting does the job alone.
A secure WordPress site in 2026 depends on three consistent habits: keeping every layer- core, plugins, themes, and hosting- updated; controlling who can log in and their permissions; and monitoring the site closely to catch problems within hours, not months. WordPress remains the world's most widely used content management system, running about 42 percent of all websites as of mid-2026. That scale is why it draws so much attacker attention: a single flaw in one popular plugin can expose thousands of sites at once.
Secure your WordPress site in five steps
Keep WordPress, plugins, and themes updated, ideally checked weekly.
Enable two-factor authentication (or a passkey, where supported) plus strong, unique passwords.
Put a web application firewall in front of the site.
Schedule automated, true off-site backups.
Monitor for malware and unusual account activity.
Why does website security matter?
Website security protects obvious things like usernames, passwords, and payment details, but the business cost of failure is what changes behaviour. System downtime and reduced productivity affect about 30 percent of small businesses after a cyberattack, making it the most common disruption. Half of small businesses take 24 hours or more to recover after an incident. For a business site, that's a day or more of lost sales, lost enquiries, and a Google Search Console warning that doesn't disappear immediately after the malware is removed.
Layered security works the way a building's defences do: a firewall filters traffic before it reaches the site, hosting-level protection covers the server itself, WordPress core and its plugins form the next layer, the database sits behind that, and backups exist as the fallback if everything else fails. No single layer is meant to catch everything on its own, which is why relying on just a security plugin, or just a strong password, leaves gaps the other layers are there to close.
How exposed is WordPress right now?
WordPress is more exposed than most site owners assume, not because the core software is weak. WordPress core accounted for only a few vulnerabilities disclosed in 2025, with plugins responsible for about 91 percent of the total. Cross-site scripting made up roughly 47.7 percent of all disclosed issues. This scale shows in attack traffic: Forbes reported, citing Wordfence's threat intelligence team, that 1.6 million attacks hit WordPress users within 48 hours in October 2025. The attacks targeted two plugins, GutenKit and Hunk Companion, both patched about a year earlier. The vulnerability was not new. The patch just hadn't been applied everywhere.
That pattern, a known fix sitting unused, is the throughline behind most WordPress compromises. It's also the most fixable part of the problem.
Threat | Main protection |
Brute-force login attempts | Login limits, two-factor authentication or passkeys |
Malware and injected code | Malware scanning, file integrity monitoring, backups |
SQL injection | Prompt updates, a web application firewall |
Cross-site scripting (XSS) | Plugin and theme updates, security headers |
Credential theft | Password manager, passkeys, two-factor authentication |
DDoS traffic | Cloudflare or another WAF, hosting-level protection |
Lock down who can log in
1. Use strong, unique passwords
Weak or reused credentials remain a common way attackers get in. Use at least 12 characters, mixing uppercase, lowercase, numbers, and symbols. Avoid predictable usernames like "admin." A password manager such as LastPass, Bitwarden, or 1Password generates and stores unique credentials for every account, so no one has to remember them manually.
2. Turn on two-factor authentication
Two-factor authentication (2FA) means a stolen password alone isn't enough to get in; the attacker also needs a second code, usually from an authenticator app. Authenticator apps are stronger than SMS or email codes, which can be intercepted.
Enforcing 2FA for every administrator and editor account is one of the most valuable changes a site owner can make in an afternoon.
3. Consider passkeys where they're supported
Passkeys are a newer alternative to passwords, built on the same technology behind fingerprint and face unlock on phones and laptops. Where supported, passkeys resist phishing because there is no password to trick someone into typing on a fake login page, and nothing to reuse across sites even if one service is breached. Support across WordPress login plugins is still growing, but it's worth enabling wherever available.
4. Limit login attempts
WordPress allows unlimited login attempts by default, leaving it open to brute-force attacks that guess passwords repeatedly until one works. Limiting failed attempts and automatically banning abusive IP addresses closes that door. Security plugins like Wordfence, iThemes Security, or All In One WP Security cover this for the standard login page as well as XML-RPC and WooCommerce login forms.
6. Move your login page off the default URL
By default, every WordPress login is at a predictable address: /wp-login.php or /wp-admin. Automated bots scan for that path, so relocating it to a custom slug (many security plugins offer this as a one-click setting) removes your site from many automated scans without changing how you log in.
7. Disable XML-RPC if you're not using it
XML-RPC is a legacy WordPress feature that allows remote publishing and communication with external apps like the Jetpack mobile app. Most sites don't need it, and it is a common target for brute-force and denial-of-service attacks. If you don't use a service that depends on it, disabling it (most security plugins offer a toggle) removes an entire attack surface.
8. Stop username enumeration
WordPress often exposes usernames through author archive pages, even when the login page is well protected. An attacker who discovers your admin username has done half the work needed for a brute-force attempt. Blocking author enumeration, a setting in most security plugins, closes that gap.
9. Restrict the REST API to what you actually need
The WordPress REST API powers much legitimate functionality, but unauthenticated endpoints are often abused to read site data, probe for installed plugins, or push spam through exposed submission routes. If a site doesn't rely on public front-end API integrations, restricting REST API access to logged-in users closes a route that username-enumeration fixes alone don't cover.
Keep the software itself clean
10. Update WordPress core, plugins, and themes on a schedule
The median time between a vulnerability's public disclosure and mass exploitation is now about five hours. That is the strongest argument for updating promptly rather than "when there's time." Turn on automatic updates for minor WordPress core releases, and check plugins and themes weekly instead of waiting for a monthly reminder. Before updating blindly, tools like Patchstack, Wordfence, or WPScan can tell you which installed plugins have known vulnerabilities, so you can prioritise the riskiest updates first rather than working alphabetically.
11. Remove plugins and themes you're not using
An inactive plugin still contains executable code on your server. Deactivating it isn't enough; delete anything you are not actively using. Be wary of abandoned extensions not updated in over a year, since unmaintained code accumulates unpatched risk over time.
12. Vet plugins and themes properly before installing
"Trusted source" means more than just the official WordPress.org repository, though that is the right starting point. Before installing, check the last update date, number of active installations, how responsive the support forum is, and whether the developer has a track record across other plugins.
Pirated or "nulled" versions of premium plugins are a particular risk: malicious code is often built directly into the pirated file's core architecture rather than added as an obvious extra script. This is why it frequently slips past standard malware scanners that look for known injected patterns rather than a compromised original file.
13. Change your database table prefix
WordPress installs with a default database prefix (wp_), which makes some SQL injection attacks easier to automate at scale because the attacker knows the table structure. Setting a custom prefix during installation or changing it later with a plugin like WP-DBManager adds a layer of friction that costs only a few minutes.
14. Disable the built-in file editor
The dashboard's file editor lets logged-in users directly modify theme and plugin code. It is a convenience feature attackers often abuse to inject malicious code once they gain admin access. Add this line to wp-config.php to remove the option entirely:
define( 'DISALLOW_FILE_EDIT', true );Control accounts and sessions
15. Log out idle users automatically
A session left open on a shared or public device can be hijacked without stealing a password. Enforcing session timeouts through a plugin like Inactive Logout closes that window automatically.
16. Audit user accounts and roles regularly
Review user accounts monthly or bi-monthly. Remove anyone who no longer needs access and ensure each remaining account has only the permissions their role requires, rather than defaulting everyone to administrator for convenience. Attackers who compromise a low-privilege account can do far less damage on a site that follows this principle.
17. Monitor user activity and login logs
For any site with more than one user, track logins and logouts, new account creation, plugin and theme changes, and edits to pages or posts. In many real incidents, attackers create a hidden administrator account once they gain access, and an activity log often reveals it first.
Harden the server and infrastructure
18. Harden file permissions and restrict access with .htaccess
Server-level protections work even if WordPress credentials are compromised. Using .htaccess, you can block direct access to sensitive files like wp-config.php, disable directory browsing, and restrict PHP execution inside upload folders. Pair this with correct file permissions (typically 644 for files and 755 for directories) so a compromised account cannot rewrite core files.
19. Add HTTP security headers
Security headers instruct the browser itself to enforce protections that server-side settings alone can't cover. A Content Security Policy (CSP) restricts which scripts are allowed to run on the page, X-Frame-Options prevents the site being embedded in a malicious iframe (a common clickjacking technique), X-Content-Type-Options stops browsers from misreading file types in a way attackers can exploit, and HTTP Strict Transport Security (HSTS) forces every visit to use HTTPS. Most of these can be added through .htaccess or a security plugin without touching a line of PHP.
20. Choose hosting that takes security seriously
Your host is effectively your first line of defence. Look for server-level firewalls, isolated account architecture (so a compromised neighbour on shared hosting can't spread to your site), automated backups, and active malware monitoring. Cheap, unmanaged shared hosting is where cross-site contamination and slow incident response tend to happen.
21. Keep PHP updated at the server level
WordPress updates get most of the attention, but the PHP version running underneath it matters as much. Older PHP versions lose security support and become a target in their own right. Most hosts let you update PHP from a control panel in a couple of clicks; it's worth checking annually even if nothing on the site itself has changed.
22. Install an SSL certificate
SSL encrypts data moving between your site and its visitors, which matters most on login pages, contact forms, and anything involving payment. It's also a confirmed Google ranking signal and a visible trust marker for visitors. Let's Encrypt provides free SSL/TLS certificates, and most hosts now include one by default.
23. Put a web application firewall in front of your site
A web application firewall (WAF) filters malicious traffic before it ever reaches WordPress, including SQL injection attempts, cross-site scripting, and denial-of-service traffic. Cloudflare, Sucuri, Wordfence, and Jetpack all offer WAF protection, and combining a WAF with your hosting provider's own server-level firewall covers both the network and application layers.
24. Add bot protection to public-facing forms
Comment sections, contact forms, and registration pages are common entry points for spam and automated exploitation attempts that have nothing to do with the login page. A CAPTCHA or equivalent bot-filtering tool on these forms closes a gap that login hardening alone doesn't touch.
Detect and recover
25. Scan for malware and monitor file integrity
Sucuri alone recorded more than 500,000 infected websites in 2024, and vulnerabilities in WordPress core, plugins, and themes were responsible for close to half of those infections. Regular scans catch injected scripts and backdoors early, often before a site gets blacklisted by Google or a hosting provider.
Sucuri SiteCheck is a straightforward free option for a first pass. File integrity monitoring, a feature in tools such as Wordfence and Sucuri, covers a slightly different problem: it alerts you the moment a core WordPress file changes unexpectedly, which catches tampering that a signature-based malware scan can sometimes miss.
26. Back up your site automatically and off-site
Backups are the last line of defence, and they determine how fast recovery actually happens. A backup plugin such as UpdraftPlus automates the process well, but where those backups are stored matters just as much as how often they run. Storing backups only on the same server as the live site means a serious compromise can wipe both at once. Genuine off-site storage, such as AWS S3, Google Drive, or a remote SFTP location, keeps a clean copy available no matter what happens to the server itself.
27. Use a comprehensive security plugin, but don't rely on it alone
Plugins such as Wordfence or Sucuri Security combine prevention, detection, and monitoring into one tool, which is genuinely useful. What 2025's incident data made clear, though, is that a plugin alone doesn't eliminate risk. It's one layer among several, not a substitute for updates, access control, and backups working together.
28. Test updates on staging before pushing them live
A staging copy of the site lets you confirm that a plugin or theme update doesn't break anything before it reaches visitors. It's still worth taking a fresh backup immediately before applying a significant update, even after a clean staging test, since staging environments don't always replicate every production condition exactly. That combination, staging plus a pre-update backup, covers both the security risk and the more mundane risk of an update simply breaking something.
Signs your WordPress site might already be hacked
Some compromises are obvious. Many aren't, and sit quietly for weeks. Worth checking for:
Unexpected redirects sending visitors to an unfamiliar site
A Google Safe Browsing or browser security warning appearing for your own domain
Admin accounts you don't recognise in the users list.
A sudden, unexplained drop in site speed
Spam pages showing up in Google's index for your domain that you never created
A suspension notice or warning email from your hosting provider
Any one of these on its own could have another explanation, but two or more together are worth investigating immediately rather than waiting to see if they resolve.
What to do if your WordPress site is compromised
No website is completely immune, so how quickly you respond matters as much as the prevention itself.
Isolate the site. Take it offline or into maintenance mode to stop further damage while you investigate.
Reset every credential. WordPress admin accounts, hosting control panel, FTP or SSH access, and database users all need new passwords, with 2FA enabled wherever it wasn't already.
Scan and identify the infection. Run a full malware scan and compare file integrity against a known clean backup to see exactly what changed.
Restore from a clean backup, but only after confirming the original vulnerability has been fixed. Restoring without patching the cause invites a repeat.
Review logs and close the attack vector. Access logs, activity logs, and firewall alerts usually show how the attacker got in; apply the relevant updates or remove the vulnerable plugin once you know.
Monitor closely for several weeks afterwards to confirm no persistence mechanism, such as a hidden admin account, was left behind.
A documented response process, even a simple one written down in advance, cuts down recovery time considerably compared with figuring it out for the first time mid-incident.
Frequently asked questions
Is WordPress safe to use in 2026?
Yes, when it's maintained properly. The core software itself accounts for a small fraction of disclosed vulnerabilities; the risk comes almost entirely from outdated or poorly vetted plugins and themes, both of which are within the site owner's control.
How often should I update WordPress plugins and themes?
Weekly checks are a reasonable baseline, since exploitation of newly disclosed vulnerabilities can begin within hours. Turning on automatic updates for minor releases reduces how often manual checking is needed.
What's the difference between a firewall and a malware scanner?
A firewall filters malicious traffic before it reaches your site. A malware scanner checks the files already on your server for signs of infection after the fact. They solve different problems and work best together.
Do I still need a security plugin if my host already offers security features?
Usually yes, in a lighter form. Hosting-level security typically covers server infrastructure, while a security plugin adds WordPress-specific protections such as login hardening and file-integrity monitoring. The two overlap less than they might appear to.
How long does it typically take to recover a hacked WordPress site?
It depends heavily on backup quality. With a recent, verified off-site backup, restoration can happen within hours. Without one, cleanup can stretch to several days, particularly if the infection has spread across multiple files.
What's the single most important WordPress security step?
If only one thing gets done, it should be automated off-site backups paired with prompt updates. Between them, they address both how incidents happen and how quickly a site recovers when one does.
WordPress security checklist
Enable automatic core updates and check plugins weekly.
Enable two-factor authentication or passkeys, with strong unique passwords.
Limit login attempts and move the login page off its default URL
Restrict the REST API and stop username enumeration.
Vet every plugin before installing, and remove anything unused.
Change the default database table prefix.
Add HTTP security headers and harden file permissions.
Install a web application firewall and an SSL certificate.
Schedule automated, genuinely off-site backups.
Scan for malware and monitor file integrity regularly.
Test updates on staging, with a fresh backup taken beforehand
Most of what's above can be checked in an afternoon. Start with backups and outstanding plugin updates today. With exploitation now starting within hours of a vulnerability going public, waiting until tomorrow is a real gamble, not just a formality. If anything on the checklist turns up a genuine gap, a proper security and SEO audit is worth the couple of hours it takes to catch it before it becomes an incident.
