On July 17, 2026, the WordPress security team released version 7.0.2 to fix a critical flaw in core. According to Patchstack, the first exploitation attempts reached its sensors about ninety minutes later.
That window is shorter than the time most site owners need to read an alert, open the admin and click “Update”.
The story sums up WordPress security in 2026. Attacks almost never target one site in particular: they sweep the web for known flaws, and they do it faster than any human can react.
The ten measures below are about practices and settings rather than plugins. They are ranked according to our reading of the attacks actually observed, each with how to put it in place and how to check that it works.
How we ranked them
No report ranks these measures. The order here is our reading of the data published by two of the companies that see the most attacks on WordPress: Patchstack’s 2026 annual report and Wordfence’s reports (its 2024 annual review and its second-quarter 2026 report).
That data says three things. First, the vast majority of flaws live in extensions: Patchstack attributes 91% of the vulnerabilities found in 2025 to plugins, the rest to themes, and only six to core, all rated low priority by Patchstack. Second, attackers move fast: roughly half of high-impact flaws are exploited within 24 hours.
Third, a fix does not always exist: in 2025, 46% of flaws had received no patch from their developer when they were made public. Our article on what the WordPress vulnerability numbers really show goes through these reports in detail.
Hence our order. Measures 1 to 3 act on the dominant way in, the exploitation of known flaws. Measures 4 to 6 protect access. Measures 7 and 8 limit the damage of an intrusion. Measures 9 and 10 prevent nothing: they shorten detection and make recovery possible.
One caveat: Patchstack and Wordfence both sell protection, and their reports recommend what they sell. Their figures remain the best observations available, but keep that bias in mind.
1. Update automatically: close the door attackers use most
Why it comes first
The most attacked flaws are rarely new. In the second quarter of 2026, the most targeted vulnerability according to Wordfence was still a privilege escalation in LiteSpeed Cache that was fixed in August 2024. Two years later, nearly 50 million requests still targeted it in the second quarter of 2026, a sign that attackers still find sites to exploit.
Against attacks that start within hours, a weekly manual update always arrives too late. Automatic updates are what comes closest to the attackers’ pace.
How to do it
Keep minor core updates on, which is WordPress’s default (the WP_AUTO_UPDATE_CORE constant set to 'minor'). Turn on automatic updates for plugins from the Plugins screen, one by one or in bulk, and for themes one at a time, from Appearance, then Themes. The feature has existed since WordPress 5.5.
Since WordPress 6.6, released in July 2024, a plugin auto-update that triggers a fatal error is rolled back automatically, and the administrator receives an email. That was the main argument against automation, and it has lost most of its weight.
For premium plugins and themes, keep licenses active: an expired license usually blocks updates. Patchstack notes that premium components had three times more actively exploited vulnerabilities than free components in 2025.
How to check it works
WordPress runs its automatic updates twice a day through its scheduled tasks system. If they do not fire, the Site Health tool (Tools, then Site Health) reports it. After every major security release, check the installed version number instead of assuming the update happened. The wp core version command and the other essential WP-CLI commands make that check instant across several sites.
Limits
An update is useless when no fix exists yet. And the update channel itself can be hijacked, as the June 2024 attack described in measure 4 showed. Updating remains essential, but it is a trust relationship that needs other protections alongside it.
The wp2shell case: ninety minutes from patch to attack
For years, the reassuring line was always the same: WordPress core is safe, plugins are the problem. Summer 2026 added nuance to that line, and the affair known as “wp2shell” illustrates half the measures on this list on its own.
The flaw
Researcher Adam Kues, of Searchlight Cyber, found a route confusion in the REST API “batch” endpoint, which lets a client send several requests in one. Combined with a SQL injection in the WP_Query class, reported by another team, it led to remote code execution.
According to Searchlight Cyber, the attack required no account and worked on a stock install with no plugins at all. Cloudflare added one condition: the path to code execution assumed no persistent object cache was in use. The full chain affected versions 6.9.0 to 7.0.1; the 6.8 branch was only exposed to the SQL injection.
The first hours
On July 17, 2026, WordPress released versions 7.0.2, 6.9.5 and 6.8.6. Given the severity, WordPress.org enabled forced updates, through the automatic update system, for every affected site. The same day, Cloudflare deployed firewall rules for all its customers, free plan included.
Patchstack, for its part, saw the first exploitation attempts arrive about ninety minutes after the release. Three days later, the company Wiz published its measurements: among the organizations using WordPress that it observes, the share exposing a vulnerable server to the internet had dropped from 25% to 10% within twenty-four hours, as patches were installed.
On July 21, the US agency CISA added both flaws to its catalog of actively exploited vulnerabilities. Wiz described what attackers did once inside: harvest administrators’ usernames and email addresses through the API, access the admin, attempt to read wp-config.php, then install backdoors disguised as plugins through the plugin upload form. Patchstack, for its part, saw three IP addresses try to create administrator accounts directly.
The firewall bypass
That same July 21, Patchstack observed a change of tactics. Most of the rules published in a hurry looked for the batch API path in the URL. Attackers simply moved it into the request body. Rules that only inspected the address no longer saw anything.
Patchstack published its analysis the next day: more than 65,000 blocked attempts from more than 1,500 IP addresses, most of them aimed at finding vulnerable sites. The company was candid that these were blocked attempts, not successful compromises. No primary source has published a total count of hacked sites.
What the affair teaches
Sites whose automatic updates worked received the fix with no intervention. Sites whose updates were disabled, blocked by file permissions or handled by a custom deployment had to act by hand. In every case, Patchstack advised checking for unknown administrators or plugins, since exploitation had started before every site was patched.
The firewall bought time, but the rules published in a hurry, almost all limited to the URL, were bypassed within four days. Cloudflare put it plainly: these protections do not replace the patch. As for the traces left by intruders (new administrators, unknown plugins, PHP files in the media folder), only active monitoring could spot them quickly.
2. Remove abandoned, closed or unused plugins
Why it matters
A deactivated plugin stays on the server, with all its PHP files. An abandoned plugin will never receive a fix. And a plugin removed from the official directory for an unpatched flaw shows up in your dashboard exactly like an up-to-date one.
Patchstack counted 1,614 plugins and themes removed from the directory in 2024 for unpatched flaws. The ticket asking WordPress to alert administrators in that case has been open for years, with no delivery date.
How to do it
Once a quarter, delete every deactivated plugin and every unused theme, keeping one default theme as a fallback. For each remaining plugin, open its page on WordPress.org: a banner flags those not tested with the last three major releases, and a closed listing says so clearly.
Wordfence considers software abandoned when it has received no update for two years. Replace it with a maintained alternative, even if it still works.
How to check it works
Vulnerability scanners (Wordfence, Patchstack, WPScan) flag closed or unpatched components. Install count is not a safety criterion in itself: a small plugin updated regularly beats a popular plugin left to rot.
3. A WordPress-aware firewall, at the edge and in the application
Why it matters
A web application firewall (WAF) blocks attack requests before they reach vulnerable code. It is often the only protection that does not require removing the vulnerable component during the window when the fix does not exist yet, or has not been installed.
Not all firewalls are equal. In penetration tests run in 2025 on hosting setups, Patchstack reports that traditional defenses blocked only 12% of WordPress-specific attacks. The figure comes from a protection vendor, but Wordfence reaches the same conclusion: a generic firewall protects a WordPress site poorly.
At the edge or inside WordPress
An edge firewall, such as Cloudflare’s or Sucuri’s, filters traffic before it reaches the server. It absorbs brute force attacks and large volumes without using the site’s resources. But it knows nothing about WordPress: which plugins are installed, in which version, which user is logged in.
An application firewall, such as Wordfence or Patchstack, runs inside WordPress. It knows that context and can apply a rule to a specific plugin version. In return, it uses server resources under heavy attack, and it can be tampered with by an intruder who already has a foothold. Combining both remains the most robust answer.
Pricing
At the time of writing, in October 2026, Wordfence is free with a thirty-day delay on new rules and signatures, and costs $149 per year for Premium, with no delay. Patchstack offers a Developer plan at $69 per month billed annually ($828 per year), or $79 billed monthly. Cloudflare’s free plan includes a free managed ruleset, with paid plans getting fuller rulesets. Our comparison of WordPress security plugins covers these tools in detail.
How to check it works
Read the firewall logs: they show blocked requests rule by rule. After a major flaw is disclosed, check that a rule exists and that it inspects the request body, not just the address: that is how the wp2shell attackers got around the first rules.
4. Two-factor authentication and passkeys for every privileged account
Why it matters
Password attacks remain massive: Wordfence blocked more than 55 billion of them in 2024, and another 18.2 billion in the second quarter of 2026 alone. A password reused on another service, then leaked in a breach, is enough to open an administrator account.
The June 2024 attack
In June 2024, an attacker took over five plugin developer accounts on WordPress.org. Nothing sophisticated was hacked: the attacker tried credential combinations already leaked in data breaches, and some of them worked.
With that access, the attacker pushed booby-trapped updates of several plugins, including Social Warfare. The malicious code read the configuration file to grab database credentials, created an administrator account and injected spam into pages. According to Wordfence, roughly 35,000 sites could have been affected.
WordPress.org responded directly: a forced password reset for plugin authors, then mandatory two-factor authentication for plugin and theme authors and accounts with commit access, from October 1, 2024. The principle applies to your own accounts too: a password leaked elsewhere should never be enough to get in.
How to do it
Require two-factor authentication at least for the Administrator, Editor and Shop Manager roles. Prefer an authenticator app, a security key or a passkey over email or SMS; the official documentation states that SMS is not a secure channel. Keep backup codes offline.
WordPress core still does not offer two-factor authentication. The Two Factor plugin, maintained by WordPress contributors, provides it for free. Wordfence has offered passkeys for free since version 9.0, in August 2026; its former standalone plugin, Wordfence Login Security, was closed at its author’s request on August 17, 2026, with its features now in the main plugin.
Limits
Two-factor authentication protects neither against a flaw exploitable without an account, such as wp2shell, nor against the theft of an already open session cookie. Application Passwords, designed for integrations, bypass it by design: issue one per service and revoke it as soon as it is no longer needed.
A two-factor plugin can itself contain a flaw: in late September 2026, version 0.17.0 of Two Factor fixed a flaw that let a plain password through the REST API or XML-RPC without a second factor.
5. Least privilege: the right role for each account
Why it matters
According to Wordfence, the access level most often required to exploit the flaws disclosed in 2024 was Contributor. In other words, every unnecessary Contributor account is a foothold for part of the attacks.
Default roles are not trivial. On a single-site install (not multisite), an Editor has the unfiltered_html capability, which allows publishing arbitrary code. Only Administrators can install plugins or create users.
How to do it
One named account per person, never a shared administrator account. The lowest role that does the job: a writer who does not publish on their own can stay a Contributor. Contractors get temporary accounts, deleted at the end of the engagement. Our guide to WordPress user roles and capabilities details every level.
If nobody needs to publish raw HTML, the DISALLOW_UNFILTERED_HTML constant removes that capability from every user, administrators included.
How to check it works
The wp user list --role=administrator command lists administrators. Compare it each quarter with the list of people who should be one. Some malware filters these lists: Wordfence recommends also checking the users table directly in the database. An activity log also tells you when each of them last logged in.
6. XML-RPC and the REST API: reduce what is exposed
Why it matters
The official documentation is blunt: xmlrpc.php is a frequent target of brute force attacks, notably through the system.multicall method, which tests many passwords in a single request. If you do not use XML-RPC, disable it.
The REST API is another way in. wp2shell went through its batch endpoint, and several of the most attacked plugin flaws of 2026 go through poorly protected REST routes.
How to do it
Block xmlrpc.php at the server or edge firewall rather than with a plugin. Watch for exceptions: Jetpack requires an accessible XML-RPC file, as do some mobile apps. The xmlrpc_enabled filter only disables authenticated methods, not the whole service.
Never disable the REST API: the documentation states that doing so breaks the admin itself. You can, however, require authentication for anonymous requests with the rest_authentication_errors filter, then test the site features that depend on it.
How to check it works
Request /xmlrpc.php from outside: a block should return a 403 or 404 error. Request /wp-json/wp/v2/users while logged out and see what comes back.
7. Harden wp-config.php: DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS and the rest
Why it matters
The wp-config.php file holds the database credentials. The June 2024 malware read it to extract the database credentials. A few constants there also limit what an intruder can do with a stolen administrator account.
How to do it
The essential settings, checked against the official documentation:
define( 'DISALLOW_FILE_EDIT', true ); // removes the theme and plugin file editors
define( 'FORCE_SSL_ADMIN', true ); // login and admin always over HTTPS
define( 'WP_DEBUG', false ); // no debug mode in productionIf possible, move wp-config.php one level above the web root, with permissions of 440 or 400. For the database, the everyday user only needs to read, insert, update and delete rows. Also make sure error display is off at the PHP level (display_errors). If you turn on the debug log, know that wp-content/debug.log is one of the files bots look for.
The DISALLOW_FILE_MODS trade-off
The DISALLOW_FILE_MODS constant goes further: it forbids installing or updating plugins and themes from the admin. It would have closed the path wp2shell attackers used to install their backdoors.
But it also turns off automatic updates, including security fixes forced by WordPress.org. Only use it if your updates go through another channel, such as a Git deployment, or explicitly re-allow the automatic updater through the file_mod_allowed filter.
How to check it works
The Theme File Editor menu should be gone. From outside, wp-config.php and wp-content/debug.log should return no content.
8. File permissions and no PHP in the uploads folder
Why it matters
The wp-content/uploads folder is writable by design. Malicious scripts dropped through a vulnerable upload form land there naturally. Among the wp2shell indicators of compromise, Patchstack lists unexpected PHP files in exactly that folder.
How to do it
The official documentation sets permissions: 755 or 750 for directories, 644 or 640 for files, 440 or 400 for wp-config.php, and never 777, not even for the uploads folder. Then forbid PHP execution in uploads. On Nginx, the documentation suggests:
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}On Apache, an .htaccess file in the uploads folder does the job. Be careful: Nginx ignores it entirely, and OpenLiteSpeed only reads rewrite rules from an .htaccess file. On those servers, the rule belongs in the site configuration.
How to check it works
Drop a small test PHP file into the uploads folder and request it: it must not execute. Delete it afterwards.
9. Monitoring and logging: see the intruder before your customers do
Why it matters
Most attacks described here leave traces: an oddly named administrator account, an unknown plugin, a PHP file in the media folder. Some hide them. In September 2026, Wordfence documented malware installed as a must-use plugin, loaded on every request, absent from the usual Plugins screen, and hiding its administrator account from both the Users screen and the REST API.
Some infections show a clean page to the owner and to scanners, and spam to search engines. Without monitoring, you find out when a customer complains.
How to do it
Install an activity log, such as WP Activity Log or Simple History, both free and maintained. Set alerts for the creation of an administrator, a role change, a plugin or theme install, and any change to the mu-plugins folder. Schedule malware scans and keep server logs long enough to investigate.
How to check it works
Create a test user and make sure the alert arrives. A log stored on the compromised server can be wiped: shipping logs off the server is more robust.
10. Backups that are tested and stored elsewhere
Why it matters
A backup prevents no intrusion. It decides whether an intrusion costs an afternoon or turns into a disaster. Some malware families, running in the server’s memory, rewrite files as soon as they are restored. You need a restore point older than the infection, but you also need to stop the malicious process and fix the entry point before restoring.
How to do it
The WordPress documentation recommends keeping several recent backups, three to five, in different locations, and taking one before every major update. The US agency CISA adds an essential requirement: at least one offline, encrypted copy, because attackers look for accessible backups to delete them.
A backup stored on the same server, or deletable with the site’s credentials, protects you from nothing. Our comparison of WordPress backup solutions covers the tools and their restore methods.
How to check it works
Once a quarter, restore a backup onto a test copy and time the operation. Until a backup has been restored, nothing proves that it works.
Where to start
These measures do not take the same effort. For a blog or a brochure site, measures 1, 2, 4 and 10 cover the essentials in an hour of work: automatic updates, plugin cleanup, two-factor authentication, an off-site backup.
For a WooCommerce store, add a firewall (measure 3) and monitoring (measure 9) right away: the financial stakes justify fast detection. For an agency managing many sites, the priority is tooling: remotely verified updates, a plugin inventory, centralized alerts. A WordPress maintenance checklist helps keep that pace over time.
Summary table
| Measure | What it stops | Effort | How to check |
|---|---|---|---|
| 1. Automatic updates | Exploitation of known flaws | Low | Installed version, Site Health |
| 2. Plugin cleanup | Flaws that will never be fixed | Low | WordPress.org listings, scanner |
| 3. WordPress-aware firewall | Attacks before the patch | Medium | Block logs |
| 4. Two-factor authentication | Stolen or guessed passwords | Low | Login without second factor refused |
| 5. Least privilege | Flaws that need an account | Low | Quarterly account review |
| 6. XML-RPC and REST API | Brute force, exposed routes | Medium | External test requests |
| 7. wp-config.php | Abuse of a stolen account | Low | Editor gone, file unreadable |
| 8. Permissions, uploads | Execution of a dropped script | Medium | Test PHP file does not run |
| 9. Monitoring | Nothing, it detects | Medium | Alert received on a test account |
| 10. Backups | Nothing, they repair | Medium | Timed quarterly restore |
Frequently asked questions
Is WordPress core secure in 2026?
It remains by far the best defended part of the whole: only six minor flaws in 2025 according to Patchstack. But 2026 showed it is not invulnerable, with two cases added to CISA’s catalog of exploited flaws, in July and then in September. Automatic core updates must stay on.
Do I need a security plugin if my host has a firewall?
Often, yes. A generic hosting firewall blocks WordPress-specific attacks poorly. Ask your host whether it applies plugin-specific rules (virtual patches). If not, an application firewall is a useful complement.
Should I disable XML-RPC?
Yes, if nothing uses it. Check Jetpack, mobile apps and remote publishing tools first. Block it at the server level rather than with the xmlrpc_enabled filter, which leaves part of the service active.
Are passkeys better than two-factor authentication?
They resist phishing better, because they are bound to the site and cannot be copied. They can even replace the password. For an administrator account, a passkey or a security key is the best choice today, with an authenticator app remaining a very good option.
How often should I test a restore?
At least once a quarter, and after any significant change of hosting or backup tool. The test must go all the way: site restored, browsable, login working.
Conclusion
WordPress security depends less on a miracle tool than on hygiene: updates that run on their own, a maintained plugin inventory, reduced and protected access, and the ability to see and then repair.
The wp2shell affair proved it under real conditions: sites that updated automatically received the fix with no intervention, the others had to act by hand while the flaw was already being exploited. Either way, checking accounts and plugins remained necessary.
Sources
- Patchstack (February 2026). State of WordPress Security in 2026
- Wordfence (April 2025). 2024 Annual WordPress Vulnerability and Threat Report
- Wordfence (September 29, 2026). Quarterly WordPress Threat Intelligence Report, Q2 2026
- WordPress.org (July 17, 2026). WordPress 7.0.2 Release
- Patchstack, Dave Jong (July 22, 2026). Ninety minutes: watching attackers weaponize the WordPress core RCE
- Cloudflare (July 17, 2026). Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities
- Wiz (July 20, 2026). Exploitation in the Wild of wp2shell
- Searchlight Cyber, Adam Kues (July 2026). wp2shell: Pre Authentication RCE in WordPress Core
- CISA. Known Exploited Vulnerabilities Catalog
- Wordfence (June 26, 2024). Developer Accounts Compromised Due to Credential Reuse in WordPress.org Supply Chain Attack
- Make WordPress Plugins (October 1, 2024). Plugin Check and 2FA Now Mandatory For New Plugin Submissions
- WordPress.org (July 16, 2024). WordPress 6.6 “Dorsey”
- WordPress Developer Resources (2026). Hardening WordPress
- WordPress Developer Resources (2026). Editing wp-config.php
- WordPress Developer Resources (2026). Brute Force Attacks
- WordPress Developer Resources (2025). Changing File Permissions
- WordPress REST API Handbook. Frequently Asked Questions
- Wordfence (September 22, 2026). Inside a Malicious, Stealthy WordPress Must Use Plugin
- CISA (September 2023). #StopRansomware Guide
- Patchstack (March 2025). State of WordPress Security in 2025
- Patchstack (October 2024). Security implications of WordPress repository access restrictions and plugin closures
- Wordfence (June 27, 2024). An Inside Look at The Malware and Techniques Used in the WordPress.org Supply Chain Attack
- Make WordPress Plugins (June 29, 2024). Password Reset Required for Plugin Authors
- Make WordPress Plugins (September 4, 2024). Upcoming Security Changes for Plugin and Theme Authors on WordPress.org
- Wordfence (September 15, 2026). Free Passkeys by Wordfence
- Wordfence (October 2026). Pricing
- Patchstack (October 2026). Pricing
- WordPress Developer Resources (2026). Two Step Authentication
- WordPress Developer Resources (2025). Nginx
- WordPress Developer Resources (2026). Backups
LaFactory designs, builds and maintains WordPress and WooCommerce sites, updates and security included, and develops its own plugins. Talk to us about your WordPress project.