Keeping WordPress secure

Each WordPress site on a domain's WordPress tab has a Security section. It lists known vulnerabilities in what's installed, then a checklist. A green tick means the item is fine; a warning means it needs a look. Most items have a Fix button, and Undo where the change can be reversed.

The quickest win: press Fix on every item with a warning. XML-RPC is blocked is optional and has no warning: see below.

What each checklist item does

Blocked by the web server. These take effect as soon as you press Fix:

Item	What it stops
PHP can't run from uploads	PHP files in wp-content/uploads from running. Uploaded backdoors are one of the most common ways sites get taken over.
readme, license, wp-config and debug.log aren't served	Visitors reading readme.html and license.txt (which give away your WordPress version), wp-config.php, wp-config-sample.php and wp-content/debug.log.
Hidden files (.env, .git) aren't served	Any file or folder whose name starts with a dot, which often hold passwords or your site's code history. /.well-known/ stays open for certificates.
Sign-in attempts are rate-limited	Password guessing. Each address can try to sign in about 10 times a minute; after that it gets "429 Too Many Requests". On most servers, an address with 10 failed sign-ins in 10 minutes is also blocked from every website on the server, and the panel, for an hour.
XML-RPC is blocked	All requests to xmlrpc.php. Optional: see below.

Sites installed or imported through Hostctl start with the first four on. On a site that was already on the server, check them and press Fix.

Changed in wp-config.php. These run as a short job on the site:

• Code can't be edited from wp-admin: turns off WordPress's built-in theme and plugin editor, so a stolen admin password can't be used to plant code.
• Debug output isn't shown to visitors: turns WordPress's debug mode off. Error messages can reveal file paths and other details an attacker can use.
• wp-config.php isn't readable by others: tightens the permissions on the file that holds your database password, so other users on the server can't read it. If wp-config.php sits in the folder above WordPress, Hostctl leaves it alone.

Checked against WordPress.org:

• Core files match WordPress.org: if any of WordPress's own files were changed or added, they're listed, and Reinstall core files replaces them with clean copies of the same version.
• Plugin files match WordPress.org: changed plugins are listed with a Reinstall button for each. Plugins that aren't on WordPress.org can't be checked and are named as such.

Both reinstalls save a restore point first and roll back if the site breaks.

Advice only. Hostctl can't fix these for you:

• Easy-to-guess admin username: an administrator called admin, administrator or root is the first name attackers try. Create a new administrator in wp-admin, sign in as them, then delete the old one.
• The site address uses http://: once the site has a certificate, change both addresses under Settings → General in wp-admin to https://. See setting up SSL.

Why XML-RPC stays open

XML-RPC is an older way for apps to talk to WordPress. Jetpack and the WordPress mobile apps still use it, so blocking it would break them. That's why it's off unless you turn it on. If you don't use either, press Fix to block it. While it's open and sign-in attempts are rate-limited, xmlrpc.php is rate-limited too.

Known vulnerabilities

Hostctl checks the WordPress version, plugins and themes on every site against a list of known security flaws. Each one found is shown at the top of the Security section with its severity, the version that fixes it, and a Details link. The domain's owner also gets an email titled "Security alert".

• Update now installs the fix straight away, safely: a restore point first, and a rollback if the site breaks.
• When no fix has been released yet, the notice says so. Dismiss hides it until a fix comes out, and Show lists what you've dismissed, with Restore to bring a notice back. Until a fix exists, consider deactivating the plugin or theme.

To fix several sites at once, tick them on Hosting → WordPress and press Apply security fixes.

Automatic security fixes

Under Automatic updates on each site, Security fixes, even when the above are off is ticked by default. Each night, any update that fixes a known vulnerability is installed, even if automatic plugin or theme updates are off. It goes through the same safe steps: a restore point, a check afterwards, and a rollback if the site breaks.

The domain's owner gets an email either way: "Security fix applied", or "Security fix rolled back" if the update broke the site. A rolled-back update isn't tried again automatically, so fix the conflict and press Update now.

WordPress core security fixes are only installed automatically while WordPress core isn't set to Off.

Where the vulnerability list comes from

By default, Hostctl asks WPVulnerability.net, a free public database, about each plugin, theme and WordPress version in use.

Server admins can switch to Wordfence's more complete feed with a free Wordfence Intelligence key. The key is entered under Server → Security → Vulnerabilities, which only admins see. Create one at wordfence.com under Account → Integrations → Wordfence Intelligence API, paste it into Wordfence Intelligence API key, press Save, then Refresh now. The feed is downloaded once a day after that.

Wordfence's terms don't allow sharing a key, so each server needs its own, even if you run several. If you're a customer and want this, ask your host.