WordPress Security and Hardening

WordPress security in CorePanel works on two levels that complement each other:

• Hardening — changes applied inside WordPress: constants in wp-config.php and a companion must-use plugin.
• The WAF — rules applied in front of WordPress, blocking the request before PHP ever runs. See Web Application Firewall.

Hardening removes attack surface; the WAF stops attackers from reaching what is left.

The hardening switches

Each is independent and reversible. On always means “protection enabled”, so xmlrpc = on means XML-RPC is blocked.

Switch	What it does	Default on new installs
File editor	Disables the plugin/theme editor in wp-admin (DISALLOW_FILE_EDIT)	On
XML-RPC	Blocks XML-RPC requests	On
Version hiding	Removes the WordPress version from the page source and feeds	On
User enumeration	Blocks ?author=N and REST endpoints that list usernames	On
Application passwords	Disables WordPress application passwords	Off

Set them per instance from the Security view, or:

corepanel wp hardening 12 3 --set xmlrpc=on --set user-enumeration=on

Why these defaults

• File editor off. A stolen administrator session should not be a shell. This is the single highest-value switch and it costs a site nothing: plugin and theme files should come from an update or a deploy, not from a textarea in a browser.
• XML-RPC blocked. Modern WordPress uses the REST API. XML-RPC remains a favourite for password-guessing amplification (system.multicall) and pingback abuse. Turn it back on only if something you actually use needs it — some older mobile apps and the Jetpack connection do.
• Version hidden. Not a defence in itself, but it removes the free targeting hint.
• User enumeration blocked. Usernames are half of a credential-stuffing attempt. There is no reason for a public endpoint to hand out the login names of your administrators.
• Application passwords left alone. They are a legitimate integration mechanism, so disabling them is offered but not imposed.

Adopted sites start with everything off

A site CorePanel adopted by scanning reports every switch off until you enable them — adoption does not silently change how an existing site behaves. Reviewing the hardening of an imported site is a good first move after a migration.

The WordPress WAF rules

In front of all this, the WAF ships a WordPress-specific rule family that stops attacks before PHP runs:

Rule	What it catches
WPE-001	wp-login brute force from non-browser clients
WPE-002	XML-RPC amplification (multicall / pingback)
WPE-010 / WPE-011	User enumeration via ?author=N and via the REST API
WPE-020 / WPE-022	Access to sensitive config, backup and debug.log files
WPE-030–WPE-032	Path traversal in the URI, query and POST arguments
WPE-040 / WPE-041	Executable uploads via double extensions and server control files
WPE-050 / WPE-051	Comment spam and XSS in comment bodies

The extended WordPress package (WPE) is a Pro and above feature; the core WordPress rules are part of the baseline protection every edition gets.

Hardening and WAF rules overlap on purpose — user enumeration, for example, is blocked both inside WordPress and at the edge. Whichever layer sees the request first wins, and neither depends on the other being enabled.

After a compromise

If a site has been hacked, do these in order:

1. Maintenance mode on — stop serving the compromised site (toggles).
2. Integrity check — find modified core files.
3. Reinstall core — replace core files, keeping wp-content and wp-config.php.
4. Review plugins and themes — remove anything unused, update everything, and look hard at anything not from the official directory.
5. Look through uploads for PHP files. Nothing in wp-content/uploads should execute.
6. Rotate credentials — WordPress administrators, the database user, and the account’s FTP password.
7. Enable the hardening switches, and check the WAF’s event log for how they got in.
8. Maintenance mode off.

A restore point or an account backup from before the compromise is faster than any of this — if one exists, and if you are sure of the date.