– Article written by Radu Ailenei, CTO Fort.
On September 22, WordPress published a security update for a critical vulnerability in Core, meaning the platform’s underlying code. The issue affects almost all versions released over the past nine years, and the first exploitation attempts appeared just a few hours after publication.
The good news is that a fix exists for every affected version and can be applied quickly. So, if your organisation uses WordPress, today’s question is no longer whether the update needs to be applied, but whether the patch has actually reached every site, including those that nobody remembers anymore.
What happened
Whenever someone opens a page, WordPress has to choose the file from the theme that will serve as the display template. This selection is made by the get_page_template() function: it builds a list of candidate filenames, one of which is derived directly from the address requested by the visitor.
This is where the problem appears. As the GHSA-7hp8-65ch-5whp advisory shows, this value was not properly validated: a ../ sequence that had been encoded twice passed through the initial filters undetected and was only decoded when WordPress searched for the file. The result is path traversal. The attacker escapes the theme directory and can make WordPress include a local .php file of their choosing, located anywhere on the server, provided that the file can be read.
And in PHP, including a file means executing it. If there is a file on the server that can be used for this purpose, the attacker gains remote code execution (RCE), meaning they can run their own code on the server with the application’s privileges.
Translated into practical terms: control over the site. And for all of this, they do not need an account, nor do they need anyone in the organisation to click on anything.
How serious is it, really?
On paper, the vulnerability is as serious as it gets: it has a CVSS 4.0 score of 9.2 (Critical) and is classified as CWE-98. Versions 4.7 through 7.1.1 are affected. The fix was released in 7.1.2 and backported to all branches, down to 4.7 (7.0.6, 6.9.9, 6.8.10 … 4.7.37).
Concretely, you do not need a major upgrade, which carries the risk of breaking compatibility with the theme or plugins. The patch for the version you are already using is sufficient.
However, a high score does not mean that every vulnerable site can be taken over. Exploitation depends on two conditions.
The first concerns the theme: the active theme or parent theme must have, directly in its root, a directory whose name starts with page-, for example page-templates, a fairly common name.
The second concerns the server, where there must be a PHP file that the attacker can use to write and execute their own code. In the public demonstration, this role was played by pearcmd.php, a component of the PEAR package manager, on a server with the PHP register_argc_argv setting enabled. Such a configuration appears, for example, in the official PHP Docker image and in some cPanel installations using older PHP versions.
Neither of these conditions depends on authentication, so where they are met, the attack can come from anywhere on the internet. Moreover, determining whether a particular site meets them requires an analysis of each individual instance, and that analysis takes longer than the patch itself.
For this reason, we recommend treating the patch as the highest priority, without waiting for a detailed exposure assessment.
What has changed since publication
In the first few hours, Patchstack observed only reconnaissance requests, through which attackers were testing whether they could include harmless Core files. However, attempts to write PHP files to the server through pearcmd.php appeared that same day, and the following day malicious traffic increased more than tenfold.
The payloads used correspond exactly to the changes in the patch, indicating that attackers started directly from the corrected code. In the meantime, a public PoC and automated scanning templates for this CVE are already available.
This does not automatically mean large-scale compromises. Automatic updates are enabled by default in WordPress, and some analysts estimate that we will see many attempts and relatively few actual compromises.
The risk accumulates where the update does not arrive automatically: in organisations with strict change management processes, where a patch is waiting for approval, and on forgotten sites, such as old campaign microsites, websites acquired along with other companies, or pages built by agencies.
What we recommend
Patch and verify. Apply the update to the branch you are using, then verify the version actually installed on every instance. The fact that automatic updates are enabled does not guarantee that the update was actually applied: it may be disabled by the hosting provider, a plugin or an internal policy, and it may fail without anyone noticing.
Complete inventory. The list should include everything running WordPress that is accessible from the internet, including publicly exposed staging environments (test copies of websites), campaign sites and instances managed by third parties. In our experience, these are precisely the ones most often left unpatched.
Monitoring until patching is complete. As long as unpatched instances remain, an additional layer of detection is worthwhile. First, check whether the WAF (Web Application Firewall, the filter that analyses requests before they reach the site) provider has published dedicated rules.
In addition to these, configure rules in the WAF and SIEM, the system that centralises security alerts, for requests to WordPress that contain traversal sequences, including encoded variants, especially in the pagename parameter, as well as for any request containing pearcmd.
Because the exploitation details are now public, these rules can be quite precise, but they remain a temporary measure.
On the server, add alerts for system processes started by PHP-FPM or the web server (shell, curl, wget) and for new or modified PHP files within the installation.
Hardening. Restrict the locations where the web server user can write files and verify that no plugin allows .php file uploads. Configure open_basedir so that PHP can access only the application directory.
If register_argc_argv is not required, disable it, and if PEAR is not used on web servers, remove it. These measures do not replace the patch, but they reduce the chances of a file inclusion turning into RCE.
Compromise assessment. For instances that were not updated immediately, applying the patch now is no longer sufficient: you must also check whether the site has already been compromised.
We recommend checking file integrity (for example, using wp core verify-checksums, plus plugins and themes) and analysing access logs, meaning the records of all requests received by the server, for the period of exposure.
Exploitation can include an existing file without writing anything to disk, so logs may be the only source of evidence. If you find unexpected .php files in /tmp or /var/tmp, treat the server as compromised, not merely scanned.
If you are not technical: what can you do?
You do not need to apply the patch yourself, but you can quickly find out whether the issue concerns you.
The simplest option is to ask the IT team, marketing team or agency that built the site. You can also check yourself in two ways: open the site in a browser, select “View page source” from the right-click menu and search for wp-content, or add /wp-admin to the end of the address.
If a WordPress login page appears, you have your answer. The information can usually also be found in the contract with the agency or hosting provider.
If the answer is yes, a few questions asked today to your colleagues or provider cover almost everything that matters:
• How many WordPress instances do we have, including staging environments, campaign sites and sites belonging to acquired companies?
• Which version is each one currently running? The correct answer is 7.1.2 or the fixed version on the respective branch.
• Who is responsible for patch management: us, the agency or the hosting provider?
• When was the patch applied, and can we receive written confirmation?
• If the patch was not applied immediately, has anyone performed a compromise assessment?
Keep the confirmation you receive. An email with the version and application date is sufficient and, as explained below, may matter during an audit.
From the NIS2 and DORA perspective
NIS2 includes vulnerability management among the mandatory risk-management measures for systems used in operations and in the provision of services. In practice, a compromised public website, even one considered non-critical, can become an entry point into the organisation or affect its reputation.
For financial entities, the requirements go into greater detail. DORA, applicable since January 2025, requires an inventory of ICT assets, documented patch-management policies and mechanisms for detecting abnormal activity, while the RTS on the ICT risk management framework details these requirements for vulnerability and patch management.
The recommendations above directly overlap with these obligations. An often-overlooked aspect is the ICT risk posed by third-party providers: many WordPress sites are hosted or managed by agencies and external providers, but under DORA the responsibility remains with the financial entity, which must be able to demonstrate that the provider applied the patch.
Under both frameworks, the speed with which you identify affected systems and the quality of remediation documentation matter just as much as the patch itself. During an audit, it is not enough to say that the issue has been resolved. You must be able to show when and how.
Thanks to Robert Ressl for discovering and responsibly reporting the vulnerability, and to the WordPress team for the fix and for backporting it to all branches, down to 4.7.
