How do I check WordPress security myself?

Start with current backups, then verify core and plugin files, review users, inspect key wp-config.php settings, check permissions and exposed files, and test public headers and login controls. Record findings before changing settings so you can test each correction.

Does wp core verify-checksums find all WordPress malware?

No. It compares standard WordPress core files with official checksums, so it is excellent for unexpected core changes. It does not inspect every custom file, plugin, database record, server setting, or attacker-created file outside core.

Should I disable XML-RPC on WordPress?

Disable or restrict it when no required app, integration, or publishing workflow needs it. If it is needed, use login protections and monitor its use rather than disabling a function your site relies on without testing.

Verify WordPress Installation Security

You can verify WordPress installation security with a practical audit of files, accounts, configuration, public exposure, and login controls. Start by recording what you find, make sure you have a usable backup, and change one control at a time so you can test the site after each correction.

This is a self-audit, not a promise that a site is free of every weakness. It is designed to find common gaps and give you a clear list for a developer, host, or security reviewer to resolve.

Verify WordPress core and plugin files first

File integrity checks tell you whether known WordPress files match their official release. From the directory containing wp-config.php, run this WP-CLI command:

wp core verify-checksums

The command reports core files that differ from expected checksums and unexpected files in core locations. Investigate each result. A mismatch can be malware, a failed update, or a manual modification that should be moved out of WordPress core. The safe repair is normally to replace core files from a matching trusted WordPress release, preserving wp-content and wp-config.php.

Also try:

wp plugin verify-checksums --all

This compares supported plugin files to their published checksums. Some plugins do not provide checksums, and custom, premium, or privately distributed plugins need a comparison with a fresh trusted package instead. Do not assume a passing checksum check covers theme files, mu-plugins, database content, or files an attacker added outside the checked paths.

Record unfamiliar PHP files, especially under wp-content/uploads, which is normally for media. Review wp-content/mu-plugins, active theme files, custom snippets, .htaccess, and wp-config.php as part of the same check. If you find suspicious code or unexplained administrator access, stop editing files at random and move to a structured incident-response process instead.

Review users and roles as an access-control audit

Every WordPress user should have a known purpose and the least permission needed. In Users, list all accounts and verify the name, email address, role, and owner. Filter for Administrators and confirm each one with the person or team responsible for the site.

Remove or deactivate former staff, old agency accounts, test users, and accounts you cannot identify after preserving the relevant details. Avoid sharing an Administrator login among several people. Individual accounts make it possible to remove access cleanly and to understand who changed a setting.

Review service accounts created for integrations too. An integration that needs to publish posts may not need full Administrator capability. Check user-registration settings and new-user notifications so a public registration feature cannot quietly create privileged accounts through a vulnerable add-on.

For a deeper review of unexpected accounts, see how to find hidden WordPress admin users. The visible user screen is important, but attackers may also attempt to create access through code or database changes.

Check the security constants in wp-config.php

wp-config.php contains settings that should be reviewed carefully. Make a copy before editing it, keep it out of public version-control repositories, and do not paste its contents into support tickets because it can contain database credentials and secret values.

First, make sure debugging is disabled on production. A production setting should use define('WP_DEBUG', false);. If you need logging during troubleshooting, ensure logs are not publicly accessible and turn debugging back off when finished. An exposed debug.log can reveal file paths, plugin names, and sensitive application errors.

Consider define('DISALLOW_FILE_EDIT', true); to disable the built-in theme and plugin file editor for dashboard users. This does not stop someone with SFTP, SSH, hosting, or database access from changing files, and it can affect a workflow that relies on the editor. Test it and keep deployment access properly controlled.

Check that WordPress authentication salts and keys are present, unique, and secret. Regenerating them invalidates existing WordPress login cookies, so plan for all users to sign in again. Rotate them after an incident or suspected credential exposure, along with the related passwords and access tokens.

Confirm file permissions limit unnecessary writing

File permissions should allow WordPress and the web server to do their job without allowing broad changes. Exact ownership and permission needs vary by host, PHP handler, and deployment method, so avoid copying a permission setting blindly from another server.

A common starting point is directories at 755 and files at 644, with wp-config.php more restrictive where the host supports it. The goal is that files are not world-writable, the account owner and web process have only necessary access, and an attacker who compromises one application cannot freely write across unrelated sites.

Review ownership as well as numeric permissions. A site that cannot update may have an ownership problem, and changing everything to 777 is not an appropriate fix. Keep writable locations limited, monitor unexpected changes, and work with the host if the PHP process ownership is unclear. The WordPress file permissions guide covers the checks to make before changing them.

Look for files and data exposed to the public

Public exposure often comes from a leftover troubleshooting file or backup archive rather than WordPress itself. Test your domain for readme.html, license.txt, and wp-content/debug.log. Removing or restricting readme.html does not secure WordPress by itself, but it reduces unnecessary detail about the installation.

Search hosting folders for backup archives, old site copies, SQL dumps, and temporary files such as .zip, .tar, .gz, .sql, .bak, and editor backup files. Move needed backups out of the web root, restrict access, or remove obsolete copies after confirming retention needs. Also review directory listing behavior, because a browsable backup or uploads directory can disclose more than intended.

Use a private browser to check that errors do not display stack traces or full server paths. Review public forms and cached pages for keys, credentials, internal URLs, and personal data. A security check includes the content your site actually sends, not just the dashboard settings.

Test headers and public-facing WordPress features

HTTP response headers can add browser protections when configured correctly at the web server, CDN, or application layer. Review at least Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and clickjacking protection through frame-ancestors in Content Security Policy or X-Frame-Options where applicable.

Do not add a strict Content Security Policy to a live site without testing. Themes, analytics, payment processors, embedded video, and form tools may need permitted sources. Start with a report-only policy if your hosting stack supports it, review the reports, then apply an enforced policy that matches the site.

Check whether xmlrpc.php is needed. WordPress apps, remote publishing tools, and some integrations use XML-RPC. If none of yours do, disable or restrict it through a tested server or security-plugin setting. If it must remain available, protect login access, monitor authentication activity, and understand the abuse patterns described in XML-RPC WordPress attacks.

Protect the login path and administrative access

The WordPress login page is a frequent target for password guessing and stolen credential use. Use unique passwords, enable multi-factor authentication for administrators when available, and add rate limiting or a tested login-protection control. Keep an account-recovery process that does not depend on one shared email inbox.

Review who can access the hosting panel, SFTP, SSH, database manager, DNS, and the email accounts used for password recovery. WordPress hardening cannot compensate for a compromised hosting account. Disable accounts you no longer need, remove old SSH keys and application passwords, and use separate accounts for each person where possible.

The WordPress hardening checklist includes a read-only audit script that can help collect configuration and file findings without making changes. Run it from an appropriate server account, review its output, and use it as a starting point rather than an automatic remediation tool.

When to get help

Get help if checksums show unexplained changes, an administrator cannot be identified, or you find suspicious code, redirects, or exposed data. A security audit can provide a documented review, while WordPress hardening can help implement and test the corrections.

How to Verify WordPress Installation Security