한국어
WordPress

WordPress Security Center

A practical guide to WordPress security: PHP engine versus core and plugin vulnerabilities, PHP upgrades, backups, updates and common misconfigurations.

Updated Oct 24, 2026

Check a version Scan a site

How to use this page

WordPress security depends on several layers that are maintained by different people and updated in different ways: the PHP runtime, WordPress core, and the plugins and themes you install. A problem in any layer can expose a site, and fixing one layer does nothing for the others.

This page walks through each layer, explains who is responsible for it, and lists practical steps. Where a PatchScope tool can help, it is linked:

  • PHP Version Checker: check the support status and known engine advisories for your PHP version.
  • Website Security Checker: run passive checks for HTTPS, security headers, version disclosure and commonly exposed files such as debug.log and wp-config.php backups.

Neither tool can tell you that a WordPress site is secure. They show what can be observed, and the rest of this page covers what they cannot see.

PHP engine vulnerabilities are different

A vulnerability in PHP itself is not a WordPress vulnerability, and updating WordPress will not fix it. The reverse is also true: upgrading PHP does not patch a vulnerable plugin.

Layer Who fixes it Where advisories are published How you update
PHP engine (php-src) The PHP project, then your hosting provider or OS distribution php-src GitHub security advisories, the PHP ChangeLog, CVE/NVD, distribution security trackers Through your hosting control panel or OS packages; often managed by your host
WordPress core The WordPress project WordPress.org news and release notes Automatic background updates, or Dashboard → Updates
Plugins and themes Each plugin or theme author Vendor changelogs and announcements, WordPress.org plugin directory, third-party vulnerability databases Plugin and theme updates via the Dashboard, or the vendor’s own update mechanism for commercial products

Why this matters

  • Different update channels. WordPress can update itself; it cannot update PHP. PHP updates come from your host or your server’s package manager.
  • Backports. On many servers, PHP is provided by a Linux distribution such as Debian, Ubuntu or RHEL. These distributions often backport security fixes without changing the upstream version number. A version number alone cannot prove whether a fix has been applied. See how to check whether a PHP security patch is installed.
  • End-of-life branches. Once a PHP branch reaches end of life, the PHP project stops releasing fixes for it. Unless your host provides extended support, new engine vulnerabilities will not be patched.

PHP compatibility with WordPress

WordPress publishes its recommended server environment on the requirements page. The WordPress core handbook maintains a PHP compatibility table showing which PHP versions each WordPress release supports, including which are considered beta support.

Before changing PHP versions:

  • Check the compatibility table for your WordPress version rather than relying on assumptions or older articles.
  • Remember that core compatibility does not guarantee plugin and theme compatibility. Older or abandoned plugins are the most common source of breakage after a PHP upgrade.
  • Check each important plugin’s listing or changelog for the PHP versions it has been tested with.

For a structured approach, see PHP upgrade planning.

WordPress core updates

Automatic updates

By default, WordPress installs minor releases, which include security and maintenance fixes, automatically in the background. Leave this enabled unless you have a managed process that applies updates promptly another way. Check Dashboard → Updates to confirm the current setting and version.

Automatic updates can fail silently, for example because of file permissions or a host restriction. Review the Dashboard and Site Health periodically rather than assuming updates happened.

Major updates

Major releases add features and can change behavior. Depending on your configuration, they may require manual action. Before a major update:

  • Take a full backup (see below).
  • Read the release notes for changes that affect your theme or key plugins.
  • Test the update on a staging copy if the site is business-critical.

Staging

A staging site is a private copy of your production site used to test updates. Many managed hosts provide one-click staging. If yours does not, a copy on a subdomain protected by authentication, or a local development environment, serves the same purpose. Prevent staging sites from being indexed and do not leave them publicly accessible.

Theme and plugin vulnerability management

Most reported WordPress vulnerabilities are in plugins and themes rather than core. Managing them is an ongoing process.

Keep an inventory

Maintain a list of every installed plugin and theme, including inactive ones, with its version, source (WordPress.org, a commercial vendor or custom) and owner. You cannot monitor what you do not know is installed.

Remove what you do not use

Deactivated plugins and unused themes can still contain exploitable code, because their files remain on the server. Delete them rather than only deactivating them. Keep one default theme as a fallback if your setup requires it.

Update on a regular cadence

  • Apply security updates as soon as practical after release.
  • Apply routine updates on a fixed schedule, such as weekly.
  • Consider enabling automatic updates for well-maintained plugins where the risk of breakage is low.
  • For commercial plugins, make sure licenses are active so updates are delivered.

Watch for advisories and closures

  • Follow the changelogs and security announcements of plugins you depend on.
  • Watch for plugins closed in the WordPress.org plugin directory. A closure can indicate an unresolved security issue or an abandoned project. Closed plugins stop receiving updates through the directory.
  • Third-party vulnerability databases such as WPScan, Wordfence Intelligence and Patchstack publish information about plugin and theme vulnerabilities. They can be useful for monitoring, but coverage and timing vary, so treat them as one input alongside vendor advisories.

Prefer maintained code

Before installing a plugin, check when it was last updated, whether the author responds to support requests, and whether it has been tested with recent WordPress versions. Replace abandoned plugins with maintained alternatives.

Backups and restoration

A backup is only useful if you can restore it. Plan backups around recovery.

The 3-2-1 approach

  • 3 copies of your data.
  • 2 different storage types or locations.
  • 1 copy offsite, separate from your hosting account.

A backup stored only on the same server as the site can be lost along with the site.

What to back up

  • The database, which holds posts, pages, settings and users.
  • The wp-content directory, which holds themes, plugins and uploads.
  • wp-config.php and any custom server configuration such as .htaccess or nginx rules. Store these securely, since wp-config.php contains database credentials and keys.

When to back up

  • On a regular schedule that matches how often the site changes.
  • Before every PHP upgrade, major WordPress update or significant plugin change.

Test restores

Periodically restore a backup to a staging environment and confirm the site works. Record how long the restore takes and the steps involved. An untested backup is an assumption, not a plan.

Upgrading PHP through your hosting control panel

Most shared and managed hosts let you change the PHP version yourself. The exact steps vary by host. For a step-by-step walkthrough, see how to update PHP in WordPress.

Common control panels

  • cPanel: look for MultiPHP Manager, which sets the PHP version per domain, or Select PHP Version on hosts that use CloudLinux.
  • Plesk: open the domain’s PHP Settings (under Hosting & DNS or the domain’s dashboard) and select a PHP version and handler.
  • Managed WordPress hosts: most provide a PHP version selector in their own site dashboard. Check your host’s documentation.
  • VPS or dedicated servers: PHP is managed through the operating system’s packages. Coordinate with whoever administers the server.

A safe upgrade sequence

  1. Check your current PHP version with the PHP Version Checker and the WordPress compatibility table.
  2. Update WordPress core, plugins and themes first. Newer releases are more likely to support newer PHP.
  3. Take a full backup of the database and files.
  4. Test the new PHP version on staging if possible.
  5. Switch the PHP version in the control panel.
  6. Confirm the change in Tools → Site Health → Info → Server, which shows the PHP version WordPress is actually running.
  7. Browse the site and the admin area, and test key functions such as forms, checkout and login.
  8. Check the PHP error log and, if enabled, wp-content/debug.log for new warnings or fatal errors.

Have a rollback plan

Know how to switch back to the previous PHP version before you start, and keep the backup from step 3. If something breaks, roll back first, then investigate on staging. Treat rollback as temporary: if the previous branch is end of life, schedule the fix for the incompatible plugin or theme.

Common misconfigurations

The following issues appear often on WordPress sites. Some can be detected externally by the Website Security Checker; others can only be checked from inside the site or server.

Debug output on production

WP_DEBUG should be off on production sites. If you need logging, keep errors out of the page output and make sure the log file is not publicly reachable.

// wp-config.php (production)
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );

If you must enable logging temporarily, WP_DEBUG_LOG can be set to a path outside the web root instead of true. By default, the log is written to wp-content/debug.log, which is publicly accessible unless blocked. Block it at the web server:

# nginx
location ~* /wp-content/debug\.log$ {
    deny all;
}
# Apache 2.4 (.htaccess in wp-content or server config)
<Files "debug.log">
    Require all denied
</Files>

Delete old log files once you no longer need them; they can contain file paths and other details useful to an attacker.

Directory listing

If directory indexing is enabled, visitors can browse the contents of folders such as wp-content/uploads. Disable it with Options -Indexes in Apache, or ensure autoindex is off in nginx (the default).

Exposed wp-config.php backups

Editor and manual backups such as wp-config.php.bak, wp-config.php~ or wp-config.php.old may be served as plain text and reveal database credentials. Never leave copies of wp-config.php in the web root. If one was exposed, remove it and rotate the database password and the authentication keys and salts.

xmlrpc.php when not needed

xmlrpc.php enables remote publishing and some integrations, and is a common target for credential-guessing attempts. If nothing on your site uses it, disable it through your host, a security plugin or a web server rule. Confirm first that integrations you rely on do not need it.

Weak administrator accounts

  • Avoid predictable usernames such as admin.
  • Use long, unique passwords stored in a password manager.
  • Enable two-factor authentication for all administrator and editor accounts.
  • Review user accounts regularly and remove those that are no longer needed.

Outdated PHP

Running an end-of-life PHP branch means new engine vulnerabilities will not be fixed upstream. Check your version with the PHP Version Checker and plan an upgrade if needed.

File editing from the dashboard

The built-in theme and plugin editors allow anyone with administrator access to modify PHP code from the browser. Disable them:

// wp-config.php
define( 'DISALLOW_FILE_EDIT', true );

Incorrect file permissions

Overly permissive permissions let other processes or users modify your files. A common baseline is 755 for directories and 644 for files, with wp-config.php more restrictive, such as 640 or 600, where your hosting setup allows. Never use 777. Confirm the recommended values with your host, since the correct settings depend on how the server runs PHP.

Exposing the PHP version

The X-Powered-By header can reveal the exact PHP version. Hiding it does not fix an outdated version, but it removes an easy signal for automated scanners. In php.ini:

expose_php = Off

On shared hosting, this setting may be available in the control panel’s PHP options rather than through direct php.ini access.

A short checklist

  • PHP branch is supported, and updated by your host or package manager.
  • WordPress core automatic minor updates are enabled and working.
  • Unused plugins and themes are deleted; remaining ones are updated regularly.
  • Backups follow 3-2-1, include database and wp-content, and have been test-restored.
  • WP_DEBUG is off, and debug.log is not publicly accessible.
  • No wp-config.php backups are in the web root.
  • Administrators use strong passwords and two-factor authentication.
  • DISALLOW_FILE_EDIT is set, and file permissions are appropriate.
  • expose_php = Off is set.

Run the Website Security Checker after changes to confirm what is visible from outside, and remember that it cannot see inside your server, plugins or code.