WordPress security in 2027 comes down to a short list of habits: keep core, plugins and themes up to date, lock down logins with strong passwords and two-factor authentication, remove what you do not use, and keep tested backups away from the server. Almost every successful attack on a WordPress site walks through one of those open doors, not through some exotic flaw in WordPress itself.
Last updated: 20 October 2026.
This guide covers the main threats, a table of fixes and the effort each takes, a numbered hardening checklist, the EU rules that touch your site, and what to do in the first hours after a breach.
Is WordPress secure?
WordPress core is maintained by a large security team, receives automatic minor updates by default and is reviewed constantly. On its own it is a sound base. The risk comes from what is added to it and how it is run: plugins and themes from many authors, administrator accounts with weak passwords, old PHP versions, cheap hosting with no isolation between sites, and nobody watching.
In short: WordPress is as secure as the way it is built and maintained. A lean site with few, well-chosen plugins, current software and controlled access is a hard target. A site with forty plugins, five of them abandoned, and a shared admin password is an easy one. The difference is rarely the platform; it is the care around it.
At Odduel, a creative and technology agency in Barcelona and São Paulo, we build WordPress sites with our own block themes and as few plugins as possible, partly for speed and partly because every plugin is code you must trust. If you are planning a new site, our website development work starts with that question: what does this site really need to run?
What are the main WordPress security threats?
Attacks on WordPress are mostly automated. Bots scan the web for known weaknesses and try them on every site they find, so a small business site is as likely to be probed as a large one. These are the five threats that matter most.
Outdated plugins and themes
This is the most common way in. A flaw is found in a plugin, a fix is released, the details become public, and bots start trying the flaw on every site that has not updated. The window between the fix and the first attacks can be short. Abandoned plugins are worse: they will never be fixed at all.
Weak logins and stolen passwords
The sign-in page at `/wp-login.php` is public on every site. Bots try common passwords and passwords leaked from other services (credential stuffing). An administrator account with a reused password, or the default user name “admin”, gives an attacker the whole site with no flaw needed.
XML-RPC and other legacy entry points
XML-RPC is an old interface for remote publishing. Most sites no longer need it, but it stays switched on by default and lets an attacker try many passwords in one request. The same goes for the public list of user names in the REST API, which hands bots the first half of every sign-in.
File uploads
Any form or plugin that accepts files can become a way to put a script on the server. If the server then runs PHP from the uploads folder, the attacker has a back door. Contact forms with attachments, user profiles and media plugins are the usual suspects.
Supply chain
A plugin you trust can change hands. A new owner, or an attacker who has taken over the author’s account, can push an update with hidden code to every site that installs it automatically. Nulled (pirated) premium plugins and themes are a supply-chain attack by design: they often arrive with malware already inside.
Threats, fixes and effort at a glance
The table pairs each threat with the fix that closes it and a rough sense of the effort involved for a typical site.
| Threat | Fix | Effort |
|---|---|---|
| Outdated plugins and themes | Weekly updates, staging test, remove abandoned plugins | Low, ongoing |
| Weak logins | Unique passwords, two-factor authentication, rate limits on sign-in | Low, once |
| XML-RPC and user lists | Switch off XML-RPC and the public user list | Low, once |
| File uploads | Block PHP in uploads, limit file types, scan uploads | Medium, once |
| Supply chain | Few plugins from known authors, no nulled code, review updates | Medium, ongoing |
| Server compromise | Isolated hosting, current PHP, firewall, least-privilege file rights | Medium, once |
| Data loss after an attack | Off-site, versioned, tested backups | Low, ongoing |
Note that most of the work is low effort. The expensive part of WordPress security is not the fixes; it is the cleanup when they were skipped.
A WordPress security checklist in ten steps
Use this hardening checklist on a new site before launch and on an existing site as an audit. Work through it in order: the first steps close the doors attackers try most.
- Update everything. Core, plugins, themes and PHP. Turn on automatic minor core updates, test plugin updates on a staging copy first, and set a weekly rhythm for the rest.
- Remove what you do not use. Delete inactive plugins and themes, not just deactivate them. Replace any plugin that has had no update in a year.
- Review user roles. Give each person their own account with the lowest role that does the job. Editors do not need to be administrators. Remove former staff and agency accounts the day they leave.
- Turn on two-factor authentication. Make it mandatory for administrators at least. Add strong, unique passwords kept in a password manager.
- Limit sign-in attempts. Rate-limit `/wp-login.php` at the server or firewall, and hide user names from public archives and the REST API.
- Switch off XML-RPC unless a service you rely on needs it, and disable file editing in the admin (`DISALLOW_FILE_EDIT`).
- Keep backups off the server. Daily, versioned, stored elsewhere, and restored once in a test so you know they work.
- Add a firewall. A web application firewall at the host or in front of the site filters known attacks before they reach WordPress.
- Send security headers. HTTPS everywhere with HSTS, plus `X-Content-Type-Options`, frame protection, a referrer policy and, when you are ready, a content security policy.
- Choose hosting that isolates sites. Each site with its own system user, current PHP, PHP blocked in uploads and access to the server by key only.
Security also belongs in the launch checks. Our website QA checklist covers the tests to run before a site goes live, and security sits alongside speed, accessibility and forms in that pass.
How do you secure a WordPress site on the right hosting?
Hosting decides how much of the checklist you can actually do. On basic shared hosting you often cannot set server headers, block PHP in a folder or see logs. On a managed WordPress host or a well-run server you can.
Ask a host four questions. Is each site isolated from the others on the same machine? Which PHP versions are offered, and how quickly do they move to new ones? Are backups stored off the server, and can you restore one yourself? Is there a firewall and a limit on sign-in attempts at the server level?
If the answers are vague, the host is part of your risk. The choice of platform matters too: our guide to choosing a CMS compares WordPress with other options when security and maintenance weigh heavily.
Which EU rules apply to WordPress security?
Two recent EU laws are often quoted in security articles, and both are often overstated. Here is what they really say for a typical WordPress site.
The Cyber Resilience Act
The Cyber Resilience Act, Regulation (EU) 2024/2847, sets security rules for products with digital elements placed on the EU market. Its reporting duties for actively exploited flaws apply from 11 September 2026 and most other obligations from 11 December 2027. It targets manufacturers of software and connected products, so it matters most to companies that sell plugins or themes commercially. A business that simply runs its own website is not made a manufacturer by doing so, but it will benefit as the plugins it buys come under the rules.
NIS2
The NIS2 Directive applies to medium and large organisations in listed sectors, such as energy, transport, health, digital infrastructure and some manufacturing, through each member state’s national law. If your organisation is covered, your website is part of the systems you must protect and your incident reporting duties go beyond the website. If it is not covered, NIS2 does not apply to your site.
GDPR
The rule that applies to almost everyone is the GDPR. A WordPress site that holds form entries, customer accounts or orders holds personal data, and a breach of it is a personal data breach. That brings a clear deadline, set out below.
What should you do after a WordPress breach?
Speed and order matter more than tools. Follow these steps when you suspect the site has been compromised.
- Contain. Put the site in maintenance mode or take it offline, and change the passwords of every administrator, the hosting account, the database and any connected service.
- Preserve evidence. Copy the files, the database and the server logs before you clean anything, so you can find out how the attacker got in.
- Assess personal data. Work out whether form entries, accounts or orders were exposed. This decides your legal duties.
- Notify if required. Under Article 33 of the GDPR, a personal data breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people. Where the risk to people is high, they must be told as well.
- Clean or restore. Restore from a backup taken before the attack, or reinstall core, plugins and themes from official sources and clean the database. Do not trust files that were on the server during the attack.
- Close the door. Find and fix the way in, usually an outdated plugin or a stolen password, or the attacker will be back within days.
- Monitor. Watch logs, file changes and search results for spam pages in the weeks after, and request a review in Google Search Console if the site was flagged.
Keep a written record of each step and decision. The GDPR asks you to document every breach, even one you did not have to report.
Questions people ask
Is WordPress safe for a business website?
Yes, when it is built lean and maintained. WordPress core has a dedicated security team and regular updates. Most breaches come from outdated or abandoned plugins, weak administrator passwords and poor hosting. A site with few well-chosen plugins, two-factor authentication, current PHP and off-site backups is a hard target for the automated attacks that make up most threats.
How often should I update WordPress plugins?
Check for updates at least once a week and apply security fixes as soon as they are released, because attacks often begin shortly after a flaw is made public. Test larger updates on a staging copy first. Any plugin that has gone a year without an update should be replaced, since an abandoned plugin will never receive a fix.
Do I need a security plugin?
Not always. Many protections, such as rate limits on sign-in, blocking PHP in uploads, security headers and a firewall, work better at the server or host level, where they stop attacks before WordPress loads. A security plugin can help on hosting that offers none of these, but it is no substitute for updates, strong logins and tested backups.
Should I disable XML-RPC in WordPress?
In most cases, yes. XML-RPC is an old remote publishing interface that few sites still need, and it lets attackers try many passwords in a single request. Switch it off at the server or with a small setting, unless a service you rely on, such as an older mobile publishing app, still needs it. Check before you disable it.
Does the Cyber Resilience Act apply to my WordPress site?
Usually not directly. The Cyber Resilience Act places duties on manufacturers of software and connected products placed on the EU market, so it mainly concerns companies selling plugins, themes or software commercially. A business running its own website is not a manufacturer for that reason, but it gains as commercial plugins must meet the new security requirements.
How fast must I report a WordPress data breach?
If personal data was exposed, the GDPR requires you to report the breach to your supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to put people at risk. If the risk to people is high, you must tell them too. Document every breach, reported or not.
If your site has grown plugin by plugin, or you are not sure who last updated it, a short audit against the checklist above is the place to start; our website development guide explains how a lean build is planned from the first brief. When you want a WordPress site built secure from the start, see our website development service or talk to us about your project.
Further reading: Next.js vs React for a company website, Webflow vs WordPress in 2027: which suits your company, Website maintenance cost: what plans include.
