WordPress PHP Vulnerability: How to Check and Fix Your Site

Understanding What a WordPress PHP Vulnerability Is

The term covers three different realities, each requiring a different fix.

Three Types of Vulnerabilities, Three Culprits

The first type involves the PHP version installed on the server. Each PHP branch receives security patches for a limited time; beyond that, newly discovered vulnerabilities are no longer fixed. A site still running on PHP 7.4 or 8.0 is running on an engine that hasn’t received a patch in years, and changing versions depends on the host or a simple setting in the hosting panel. The second type, by far the most common, involves the PHP code of plugins and themes: SQL injection in a form, unverified file uploads, or functions accessible without authentication. These vulnerabilities are published weekly in vulnerability databases, along with the fixed version number, and are exploited by bots within hours. The fix is to update the affected plugin or delete it if it’s no longer maintained. The third type includes configuration errors: file editing allowed in the admin area, PHP execution possible in the media folder, error display enabled in production, or overly permissive file permissions. These aren’t bugs, but they turn a small flaw into a full site takeover. The WordPress core itself, which is regularly audited, automatically updated, and rarely the source of an exploited WordPress PHP vulnerability, represents a marginal share of actual incidents.

WordPress PHP Vulnerability: What Bots Really Exploit

Server access logs tell the same story everywhere: hundreds of daily requests from addresses all over the world, testing for the existence of specific files. /wp-content/plugins/nom-extension/readme.txt to read the version number, followed by a POST request to the vulnerable file if the version matches. The bot knows nothing about your site; it scans a list of millions of domains with a list of known vulnerabilities, and it only stops where it gets a response. The primary targets are plugins installed on millions of sites: page builders, contact forms, galleries, backup tools, and e-commerce extensions. A single vulnerability in one of them opens up hundreds of thousands of sites at once, and mass exploits often begin the same day the patch is published, because comparing the fixed version to the previous one reveals exactly where to strike. The delay between the publication of a vulnerability and its first automated exploit is now measured in hours. A site updated once a month is therefore exposed for an average of two weeks per vulnerability, which is more than enough time. It’s this delay, rather than a particularly clever WordPress PHP vulnerability, that explains the majority of compromised sites.

Knowing if a WordPress PHP Vulnerability Exposes Your Site

Three checks, ten minutes, no development skills required.

Check the PHP version and its support status

In the WordPress admin, the Tools menu then Site Health displays the PHP version in use and flags it if it’s obsolete. The same information can be found in the hosting panel, usually under a “PHP Configuration” or “Version Selector” section. The table below summarizes the status of current branches. An end-of-life branch isn’t necessarily exploitable immediately, but every new vulnerability discovered in PHP will remain open there forever. Switching to a supported branch is done in the hosting panel with one click, and in the vast majority of cases, an up-to-date WordPress site works without modification on PHP 8.2 or 8.3. The exceptions are old themes and plugins that use deprecated functions; these can be identified by testing the version change on a staging copy of the site or by checking the compatibility listed on their official page. If a plugin blocks the move to a supported PHP version, the plugin has to go, not the update.

Spotting Vulnerable or Abandoned Plugins

The list of installed plugins, along with their versions, is the second check. For each one, ask three questions. Is the installed version the latest? Being several versions behind on a popular plugin almost always means a known vulnerability is open. Is the plugin still maintained? On its official page, a note saying “has not been tested with the last three major versions of WordPress” or a last update over two years ago signals abandonment; discovered vulnerabilities will never be fixed. Is the plugin still in use? A deactivated plugin remains on the disk and its code remains directly accessible by URL, making it exploitable. Public vulnerability databases, like those from Patchstack or Wordfence, allow you to search for a plugin’s name and see known vulnerabilities along with the fixed version. For a single site, this check takes fifteen minutes a month. For an agency managing thirty sites, it’s half a day, which explains why it’s never done by hand and why site management tools automatically compare each installed version to the list of published vulnerabilities and report affected sites every morning.

Checking Settings That Make Everything Worse

The third check focuses on configuration. These settings aren’t vulnerabilities per se, but they determine what an attacker can do once they’ve found a small breach. Here are the points to review, in order of importance.

• PHP execution in wp-content/uploads: if enabled, any vulnerable upload form becomes a full site takeover. A three-line .htaccess file in this folder prevents it.
• File editor in the admin area: a stolen admin account then allows writing PHP directly. The DISALLOW_FILE_EDIT constant disables it.
• Error display: in production, WP_DEBUG should be set to false, otherwise messages reveal paths and queries.
• File permissions: 644 for files, 755 for folders, and never 777; wp-config.php can be set to 600.
• XML-RPC: disable it if not in use; it’s a channel for brute force and amplification attacks.
• Table prefix and account name: an “admin” account and the default wp_ prefix make automated attacks easier.

Each of these settings takes a minute to check and five to fix. Together, they turn a minor vulnerability that might have allowed reading a table into a non-event.

Reading Logs to See Who’s Knocking at the Door

Server access logs, available in the hosting panel or in the logs folder, show in minutes what the previous checks don’t: if someone has already tried, and where. Filter POST requests from the last seven days, then look for those targeting plugin files rather than normal pages: admin-ajax.php with an unknown action, a file in wp-content/plugins called directly, or xmlrpc.php by the hundreds, wp-login.php from dozens of different addresses. Response codes complete the picture: a series of 404s signals a bot looking for a plugin you don’t have, while a 200 on a directly called plugin file signals it found it. Note the addresses and dates; if a suspicious request coincides with a modified file or a created account, the WordPress PHP vulnerability has been exploited and cleanup takes priority over everything else. This reading doesn’t need to be daily for an isolated site—a monthly check is enough—but it becomes invaluable the day a symptom appears, because it dates the incident and points to the entry door. For a site portfolio, it must be automated: a tool that counts attempts per site and per day flags anomalies before they become incidents.

Closing the Doors and Keeping Them Closed

Fixing things once is useless if the routine doesn’t follow: new vulnerabilities are published every week.

WordPress PHP Vulnerability: The Update Routine That Works

The most effective measure is also the simplest: update every week, and automatically whenever possible. WordPress offers automatic updates for the core, plugins, and themes, which can be enabled on a per-plugin basis. The usual hurdle is the fear of breaking the site. This is addressed with three precautions: an automatic backup before every update, a quick test of the homepage and a form afterward, and an immediate rollback if anything has changed. Security updates for plugins are minor in the vast majority of cases and don’t change anything visible; it’s the major version changes, announced as such, that deserve testing on a copy. Beyond updates, keep an inventory: what’s installed, why, and since when. Anything that no longer serves a purpose should be deleted, not just deactivated. Finally, subscribe to alerts from a vulnerability database for the plugins you use, or use a tool that does it for you. A WordPress PHP vulnerability published on a Tuesday is exploited by Tuesday night; a Friday update arrives too late, while a Tuesday noon update arrives just in time.

WordPress PHP Vulnerability: What to Do When a Patch Doesn’t Exist

Sometimes a vulnerability is published for an abandoned plugin, or the patch is delayed for several days. You have three options, from the cleanest to the most temporary. The first is replacement: almost every plugin has a maintained equivalent, and migrating a form or a gallery takes an hour. The second is immediate deactivation and deletion, accepting the loss of the feature while finding a replacement; a missing gallery costs less than a compromised site. The third is a virtual patch, offered by some web application firewalls and services like Patchstack: a rule that blocks the malicious request before it reaches the vulnerable code, without modifying the plugin. It buys time, but it doesn’t replace a real fix. In all cases, after the fix, check that the WordPress PHP vulnerability hasn’t already been exploited: look for recent PHP files in uploads, unknown administrators, and changes to wp-config.php and .htaccess. Bots arrive before patches, and a site that is fixed but already compromised remains compromised. For a site portfolio, this daily check is the only way to sleep soundly: every morning it flags sites where a plugin has a published vulnerability, along with the version needed, and those where a file has moved for no reason.

Frequently Asked Questions

Can updating PHP break my site? Rarely, if WordPress, your theme, and your plugins are up to date. Test on a copy, and roll back from your hosting panel if an error page appears.

Is a deactivated plugin still dangerous? Yes. Its code remains on the disk and is directly accessible. Delete it.

How do I know if a vulnerability has already been exploited? Look for recent PHP files, unknown administrators, and changes to wp-config.php. An external scan complements, but does not replace, this check.

Is a firewall enough? No. It blocks known attacks, not those published yesterday. Updating remains your primary protection.