Information Technology

The Biggest WordPress SecurityRisk Nobody Talks About

Ankit Subedi · · 5 min read

Everyone hardens the walls. Nobody checks who already has the keys.

Six-plus years of doing WordPress site takeovers, I have stopped being surprised by what I
find in the user list. Shocked, occasionally. Surprised, never.
Before touching a single plugin, before running a vulnerability scan, before even looking at the theme
I go straight to Users. Every time, without exception, I find some version of the same four things:

What I findWhy it exists
2–4 admin accounts, former staffNobody offboarded them. The accounts just stayed.
A dev@ account with a 2019 passwordSet up during the original build. Never revisited.
A plugin author’s support accountCreated to fix one bug in 2022. Still active.
A subscriber with Administrator roleSomeone needed quick access once. Never reversed.
Temporary admin accountsTemporary and admin do not belong together. Ever.
Accounts from old web agencies or Fiverr hiresYears-old contractor access, long forgotten.

Real Risk: Any one of these accounts is a fully valid login. An attacker does not need a zero-day. They just need that dev@ account on a credential dump from 2019 and they are in as an administrator.

The user list is only the beginning. Here is what else turns up on almost every site inherited:

The File Manager Plugin

No-go. Full stop. The File Manager plugin gives anyone with admin access a full file browser inside WordPress. If that admin account is compromised, an attacker can upload a web shell or inject malware without ever touching FTP or cPanel. Remove it immediately. Use cPanel File Manager or SFTP for file access instead.

Abandoned and Outdated Plugins

Plugins that are installed, not used, and not updated are not just dead weight they are open attack surface. Every unpatched plugin is a potential entry point:

  • Plugins last updated four or more years ago, still active
  • Plugins installed for a one-off task and never deactivated
  • Duplicate functionality spread across three plugins where one would do
  • Plugins that can be replaced with a few lines of code in functions.php

Plugin Audit Approach:

First: disable anything not actively used.

Second: identify plugins that are used but not really needed convince the client the convenience is not worth the risk.

Third: identify plugins replaceable with a small amount of code. Most sites have a manageable plugin count. The ones with pages of plugins are harder, but the principle is the same.

Passwords That Should Not Exist

Users setting passwords that include their own username. Passwords like password1 or welcome123 or the domain name. No complexity enforcement, no expiry, no reset policy. This is not a technical failure it is a policy failure, and it is entirely fixable.

WordPress Core Left Unupdated

A WordPress version that has not been updated in four-plus years is not a legacy system it is an unlocked door with a sign on it. Core updates exist for a reason. Running a version from 2020 on a live production site in 2026 is not defensible.

The Full Security Audit, Everything I Check

This is the full sequence run on every takeover. Not every item applies to every hosting environment, but this covers everything worth checking when there is full access.

Users and Access

  • Export the full user list, sort by role, get client to name every admin and editor
  • Demote unrecognised accounts to Subscriber, do not delete, preserve the audit trail
  • Change any default or generic admin usernames: admin, administrator, webmaster
  • Force a password reset on all remaining accounts
  • Enforce stronger password requirements via plugin
  • Set a 60 or 90-day password expiry policy
  • Enable two-factor authentication, mandatory for Administrator and Editor roles
  • Kill all active sessions after completing user cleanup

Plugins and Themes

  • Remove the File Manager plugin, immediately, no exceptions
  • Update all plugins to their latest versions
  • Audit all active plugins: disable unused ones, delete deactivated ones
  • Check CVEs (Common Vulnerabilities and Exposures) for every installed plugin
  • Replace plugins with code where feasible, especially simple utility plugins
  • Audit all installed themes, delete inactive themes, update the active one
  • Confirm the active theme is updatable and on a current version

WordPress Core

  • Update WordPress core to the latest stable release
  • Verify core file integrity: WP-CLI wp core verify-checksums
  • Reduce version information exposed publicly, remove generator meta tag, hide version from feeds

Login and Authentication

  • Change the login URL away from the default wp-login.php
  • Limit login attempts with rate limiting and IP banning
  • Block xmlrpc.php, disable XML-RPC entirely unless specifically required
  • Ask the client which countries they serve, block all others at firewall or plugin level

WordPress Configuration

  • Disable file editing in wp-config.php: define DISALLOW_FILE_EDIT true
  • Rotate WordPress security salts in wp-config.php, assume them compromised on inherited sites
  • Change the database table prefix away from the default wp_ where possible
  • Restrict PHP execution in the uploads directory via .htaccess

Server-Level Hardening

  • Route traffic through Cloudflare — DDoS protection, CDN, and easy country blocking
  • Install fail2ban to block repeated failed authentication attempts
  • Lock down PHP settings: disable dangerous functions, restrict open_basedir
  • Enable Imunify360 and a CSF firewall at the server level, catches a large portion of threats before they reach WordPress
  • A good server environment is not optional. Server-level hardening makes everything else easier to manage.

Malware and Security Scanning

  • Scan for malware using Wordfence or Sucuri
  • Verify WP core checksum to confirm no core files have been tampered with
  • Set up Wordfence for ongoing logging, alerting, and firewall rules

Backup and Recovery

  • Set up automated off-site backups, not just on the same server
  • Verify backups are actually restorable, an untested backup is not a backup

Performance

  • Add a caching layer via plugin: LiteSpeed Cache, W3 Total Cache, or WP Super Cache

I have added a Check List for WordPress Audit that you can use whenever you come up with a new wordpress website you want to check.

Written by
Ankit Subedi
← Previous Claude Can Use Your Computer Autonomously: But Should It Use Yours?

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top