WordPress powers a substantial share of the web, which is exactly why automated attack bots scan it more than almost any other platform. This checklist ranks the concrete steps you need to protect your site from malware, unauthorized access, and plugin vulnerabilities, by priority. Each section explains why it matters and gives you a specific action to check today; we've also added current numbers, a table comparing risks, and the sources behind them.
Why are WordPress sites targeted?
Most attacks don't target a specific site. They target known vulnerabilities in outdated plugins and themes, found by bots that scan the web automatically. These bots typically reference open databases like WPScan, fingerprint which plugin version a site is running from its readme.txt file or page source, and flag any version with a known vulnerability. That means a small blog and a high-traffic store fall under the same scan; attackers care about which software version you're running, not how big your site is.
A compromised site is rarely the final target. It's a tool: attackers take it over to spread spam links, inject hidden pages that poison search results, mine cryptocurrency, or use it as a relay for attacks against other targets. That makes "there's nothing valuable on my site, why would anyone bother" a misleading assumption. Bots pick a site based on whether it's vulnerable, not on what it's worth.
WordPress security, by the numbers
A few current numbers explain why this isn't optional:
- According to W3Techs, roughly 41% of all websites run WordPress as of September 2026, which makes it the single most efficient target for automated scanning.
- Patchstack's 2025 security report found that the overwhelming majority of newly registered vulnerabilities that year were in plugins and themes, while WordPress core accounted for only a single-digit number of reported issues.
- Wordfence reported blocking 19.2 billion brute-force attempts against the more than 5 million sites it protects, in the third quarter of 2025 alone.
- Security researchers have repeatedly documented that once a WordPress vulnerability is publicly disclosed, the first exploitation attempts often begin within hours, which makes delaying an update far more expensive than it used to be.
How do you keep core, plugins, and themes updated?
Nearly every known vulnerability is closed by an update the developer already shipped but the site hasn't applied yet. WordPress core applies minor security patches automatically, but plugins and themes are on you. Checking dozens of plugins by hand doesn't scale, so updates need to be automated. Automation itself carries risk, since an incompatible version can break a site instantly, and there have been repeated cases in the plugin marketplace where ownership changed hands and a subsequent "update" quietly added ad injection or backdoor code.
What makes updating something you don't have to hesitate over is backing up automatically before the update runs and being able to roll back with one click if something breaks. Patchstack's research also found that developers failed to ship a patch before public disclosure for more than half of the vulnerabilities reported to them. That means "I'll update the moment it's disclosed" isn't a complete strategy on its own; updating needs to be paired with a firewall.
How do you strengthen WordPress login security?
The login page is the door automated bots try most often. Attackers rarely guess passwords one at a time; they run brute-force and credential-stuffing attacks using lists compiled from major data breaches, containing billions of username and password pairs, trying dozens of combinations per second. The billions of attempts Wordfence blocks are a direct measure of how automated and constant this traffic is. Reusing the same password across sites turns a breach on some unrelated platform into a direct risk for your WordPress login.
Three things address this: temporarily blocking an IP after a set number of failed attempts, avoiding the default "admin" username, and requiring two-factor authentication (2FA) on admin accounts. SMS-based verification is relatively weak against SIM-swap attacks, so an authenticator app (TOTP) or passkeys are the better choice. With 2FA on, even a stolen password isn't enough, the attacker still needs to pass a second verification step. On its own, it's one of the highest-impact measures you can take.
How dangerous is each security risk, really?
All of these risks matter, but they don't carry equal weight. The table below compares five common risk types by how often they occur and how much damage they can do:
| Risk type | How often it occurs | Potential impact |
|---|---|---|
| Outdated plugin or theme | Very high | High (full site takeover) |
| Weak or reused password | High | High (direct admin access) |
| Two-factor authentication turned off | Medium (not a hole by itself, amplifies other risks) | High |
| Overly permissive file or folder permissions | Medium | High (speeds up how a vulnerability spreads) |
| Unpatched WordPress core | Low | Critical (huge blast radius when it hits) |
The takeaway: the risk you'll encounter most often isn't always the one that does the most damage. An unpatched core is rare, but when it hits, the blast radius is huge; an outdated plugin, on the other hand, shows up on nearly every site and is usually the first thing attackers try. Weighing likelihood against impact when you set priorities beats trying to fix everything at once and finishing none of it.
How do you automate WordPress backups?
No matter how tight your security is, zero risk doesn't exist. That's why the last layer of any strategy is always backups: the ability to quickly restore a site after an attack, a bad update, or human error. The widely used 3-2-1 rule is a good reference point here: keep at least three copies of your data, across two different types of storage, with one copy kept physically offsite. If the server itself is compromised, backups sitting on that same server go down with it.
Ideally, backups run on a daily automatic schedule rather than a manual reminder, keep several recent versions (a week to a month is a reasonable range), and get tested by an actual restore on a regular basis. Plenty of site owners assume their backups work and have never once tried restoring one; a broken backup isn't meaningfully safer than having no backup at all.
What do a firewall and malware scanning protect against?
A web application firewall (WAF) filters malicious requests at the server level before they ever reach WordPress. By blocking known attack patterns, it can neutralize even a vulnerability that hasn't been officially patched yet, a technique the industry calls virtual patching. Since exploitation can start within hours of disclosure, as covered above, this layer buys real time on a site that's still waiting for the actual fix.
Regular malware scanning does a different job: catching malicious code that's already made it onto the site, usually injected into files without being noticed. A good scan combines signature-based checks (looking for known malicious code patterns) with integrity checks that compare core files against the originals on wordpress.org; the uploads folder in particular is a frequent target, since it's writable and often isn't restricted from running executable files. The two layers work together: the WAF blocks the entry, scanning catches anything that slipped through.
Why review user permissions and file access?
Every WordPress role, Administrator, Editor, Author, Contributor, Subscriber, carries a different level of access, and admin accounts that piled up over time and are no longer used are a quiet risk; a forgotten account from a former employee or an old agency counts too, and every account is a potential entry point. Applying least privilege, giving each person only the role they actually need, reviewing the user list periodically, and removing admin access no one uses directly shrinks your attack surface.
The same logic applies to file permissions. The generally accepted baseline is 644 for files, 755 for directories, and something even more restrictive where possible for a file like wp-config.php; leaving that file writable by more than it needs to be makes it easier for a small plugin vulnerability to spread across the entire site. Disabling the file editor from the WordPress admin (DISALLOW_FILE_EDIT) is another useful layer, since it stops an attacker who gets into the dashboard from directly editing theme or plugin files.
Checklist summary
- Keep core, plugins, and themes updated, with rollback available
- Require two-factor authentication (2FA) on admin accounts
- Limit login attempts and stop using the default "admin" username
- Automate backups, keep several versions, and store them offsite
- Use a web application firewall (WAF)
- Run malware scans on a regular schedule
- Remove unused admin accounts
- Review critical file permissions
- Prioritize risks by likelihood and impact (see the table above)
Sources
- W3Techs, "Usage Statistics and Market Share of WordPress": market share figure.
- Patchstack, "State of WordPress Security in 2025" report: vulnerability distribution and patch-timing data.
- Wordfence, Q3 2025 threat statistics: brute-force attack volume.
- SecurityWeek and The Hacker News, 2026 vulnerability-exploitation coverage: examples of how fast attacks begin after disclosure.
Following each of these manually takes time, and it gets easier to miss one as you add more sites. Watch Your WP automates updates, backups, firewall, and malware scanning from a single panel, keeping this checklist running for you.
Erdinç
Building Watch Your WP. Writes from hands-on WordPress maintenance, security, and site management experience.
LinkedIn
