Security advisorywp2shell: WordPress core vulnerability. Updated August 7, 2026.

Read the advisory

How to protect your WordPress site against attacks

Practical preventative measures for WordPress: device hygiene, updates, passwords, access limits, separate databases, and security plugins that reduce attack risk.

Topics Hardening & checklists

Lars Koudal

Updated Published

WordPress powers a huge share of the web, so automated attacks never stop probing it. You cannot remove every risk. You can make your site a poor return on an attacker’s time.

This post is about prevention. Deep dive: WordPress security hardening guide and the security checklist.

Why WordPress sites get attacked

Why sites get targeted

Most “attacks” are bots, not a human staring at your brand. Common goals:

  • Steal customer or admin data
  • Send spam from your domain
  • Redirect visitors to scams or malware
  • Use your server in larger botnet or phishing campaigns

Small sites get hit because they are easy, not because they are famous. Context: why insignificant sites get attacked.

Start with the computer you use to log in

A keylogger or stolen browser session bypasses a hardened WordPress install. Keep your OS and browser updated. Use reputable endpoint protection. Prefer a password manager and 2FA for admin work. Avoid logging into production from untrusted machines.

Keep WordPress core, themes, and plugins current

Unpatched software is still the boring, reliable entry path. Apply updates on a schedule. Remove unused themes and plugins so old code is not sitting on disk waiting for a known exploit. Check advisories in the WordPress vulnerabilities database. Plugin judgment calls: plugins as security risks.

Use strong, unique passwords and limit who is admin

Passwords fail because people reuse them and make them short. Aim for long unique secrets per account, stored in a manager. Enable 2FA on every administrator. Full login playbook: WordPress login security guide and brute-force.

Password strength matters for WordPress

Give editors and authors the roles they need, not Administrator. Revoke access when freelancers finish. Details: user roles and least privilege.

Separate sites and databases when you run more than one

Do not point several production sites at one shared database user with wide privileges if you can avoid it. Isolation limits how far a SQL injection or stolen credential can travel. Hosting accounts should be separated the same way when budgets allow.

Add monitoring and a security layer that fits your stack

Use tools that match real jobs: malware scanning, integrity checks, login protection, and a WAF or host firewall where available. Pick maintained plugins from trusted sources. Avoid stacking five overlapping “security suites” that fight each other.

Useful follow-ups:

Expect failure and plan recovery

Prevention reduces odds. It does not make you untouchable. Keep backups you have restored at least once. If you are already compromised, skip straight to malware removal instead of bolting on plugins over an infected install.

Defense in depth is the mindset: device, hosting, WordPress, accounts, and backups each cover gaps the others miss.

Found this useful? Share it.