WordPress powers roughly 43% of all websites on the internet. That market dominance makes it the single largest target for automated attacks, botnet campaigns, and opportunistic hackers. If you are running a WordPress site, you are not invisible — you are on a list. Attackers do not need to know your domain name. They scan IP ranges, fingerprint CMS versions, and exploit known vulnerabilities at scale. The good news is that WordPress itself is not inherently insecure. The problem is how most people configure, extend, and maintain it.

1. Why WordPress Gets Targeted

Sheer volume is the primary reason. With nearly half the web running WordPress, a single vulnerability in a popular plugin can expose millions of sites simultaneously. Attackers write exploit scripts once and run them against every WordPress installation they can find. The ecosystem compounds the problem — there are over 60,000 plugins in the official repository, and thousands more sold through third-party marketplaces. Many are written by solo developers with no security review process, no ongoing maintenance budget, and no incident response plan. When a researcher discloses a vulnerability, the window between public disclosure and mass exploitation is often measured in hours, not days.

2. Plugin and Theme Vulnerabilities

The vast majority of WordPress compromises do not exploit WordPress core — they exploit plugins and themes. Outdated plugins are the number one attack vector. A plugin that was secure when you installed it two years ago may now have three known CVEs against it. Themes are equally dangerous, especially nulled or pirated premium themes that often ship with backdoors baked in. Audit your plugin list ruthlessly. Remove anything you are not actively using. For what remains, verify that each plugin has been updated within the last six months and has a responsive maintainer. If a plugin has not seen an update in over a year, treat it as a liability and find an alternative.

3. Default Admin Paths and Enumeration

Every attacker knows that /wp-admin and /wp-login.php are the default login endpoints. Automated tools like WPScan enumerate usernames by iterating through /?author=1, /?author=2, and so on, or by hitting the REST API at /wp-json/wp/v2/users. Once they have a valid username, they launch brute force attacks against the login page. While changing the login URL is not true security — it is security through obscurity — it does eliminate a massive amount of automated noise. Use a plugin or server-level rewrite to move wp-login.php to a non-standard path. More importantly, disable user enumeration entirely by blocking author archives and restricting the REST API users endpoint to authenticated requests only.

4. Disabling XML-RPC

The xmlrpc.php file is a legacy interface that allows external applications to communicate with WordPress. It supports the system.multicall method, which lets attackers attempt hundreds of password guesses in a single HTTP request, bypassing most rate-limiting protections. It is also used to launch amplification DDoS attacks via the pingback functionality. Unless you specifically need XML-RPC for a mobile app or external publishing tool, disable it completely. The cleanest approach is to block it at the web server level before PHP even processes the request:

5. Hardening wp-config.php

Your wp-config.php file contains database credentials, authentication salts, and the table prefix. It is the single most sensitive file in your WordPress installation. Move it one directory above your web root — WordPress will automatically look for it there. Set file permissions to 400 or 440 so only the web server user can read it. Add the following constants to disable the file editor, enforce SSL for admin sessions, and limit auto-updates to security releases:

Disabling the file editor is critical. If an attacker gains admin access to the WordPress dashboard, the built-in editor lets them inject PHP code directly into plugin or theme files. Removing it forces them to need filesystem access, which is a significantly higher barrier.

6. File Permissions and Database Prefix

Incorrect file permissions are an open invitation. Directories should be set to 755 and files to 644. The wp-config.php file should be 400 or 440. Never set anything to 777 — not even temporarily for debugging. On the database side, change the default table prefix from wp_ to something unique during installation. This is a one-time configuration that prevents automated SQL injection attacks that assume the default prefix. If you already have a running site, you can still change it, but you will need to update the prefix in both wp-config.php and every table name in the database, along with any references in the options and usermeta tables. It is tedious but worthwhile.

7. Login Hardening: 2FA and Rate Limiting

Passwords alone are not enough. Enable two-factor authentication for every account with administrative or editorial privileges. TOTP-based 2FA (using an authenticator app) is the minimum standard. Hardware keys via WebAuthn are even better. Alongside 2FA, implement login attempt limiting. After five failed attempts, lock the account or IP for a meaningful duration — at least 15 minutes. Many security plugins handle this, but you can also enforce it at the server level with tools like fail2ban watching your WordPress access logs. Consider renaming or removing the default "admin" username entirely. Attackers always try it first. Create a new administrator account with a non-obvious username, transfer ownership, and delete the original admin user.

8. Update Hygiene and Ongoing Monitoring

Security is not a one-time task. Enable automatic updates for WordPress core minor releases. For plugins and themes, set up a weekly review process where you check for available updates, read the changelogs, and apply them in a staging environment before pushing to production. Subscribe to vulnerability databases like WPScan and Patchstack to receive alerts when plugins you use are compromised. Run regular malware scans on your file system and database. Monitor your access logs for suspicious patterns — repeated requests to wp-login.php, requests to non-existent plugin paths, or POST requests to xmlrpc.php are all indicators of active probing. Use a tool like Blacksight's scanner to get an external perspective on your WordPress site's security posture. Automated scans catch the things you forget to check manually — exposed debug logs, outdated server headers, missing security headers, and vulnerable plugin versions. The sites that get compromised are almost never the ones that were carefully maintained. They are the ones that were set up, launched, and forgotten.