In short: A WordPress update does not help against the PHP vulnerability PHP2Shell, because the flaw is not in WordPress but in PHP, the software on the server that runs WordPress. According to Dr. Web, WordPress.org is therefore not planning an update of its own either. Only a PHP update on the server, with a restart of all PHP processes, can protect you. Your hosting provider or server operator generally installs it.
The trigger: "But we updated everything"
After the first headlines about PHP2Shell, many operators did the obvious: open the WordPress dashboard, click "Update now", and update plugins and themes at the same time. Afterwards everything is green, and the feeling says: done.
With this vulnerability, the feeling is misleading. That is not down to WordPress but to where the flaw sits. Cloudflare, too, points out in its announcement that updating application code or plugins does not fix the vulnerabilities.
WordPress update and PHP vulnerability: the layer model
A WordPress website consists of several layers that build on each other. Each layer has its own updates and often its own people responsible:
| Layer | Example | Who typically updates it | Affected by PHP2Shell? |
|---|---|---|---|
| Operating system | Debian, Ubuntu, AlmaLinux | hosting provider or server admin | no, but often supplies the PHP package |
| Web server | Apache, Nginx, LiteSpeed | hosting provider or server admin | operating mode influences the risk |
| PHP runtime | PHP-FPM, mod_php | hosting provider or server admin | yes, this is where the vulnerability is |
| WordPress core | WordPress | operator or agency | no |
| Plugins and themes | WooCommerce, page builders | operator or agency | no |
The update button in the dashboard reaches only the bottom two rows. The PHP runtime lies underneath them and is invisible to WordPress. How other systems build on PHP is described in the article CMS and shops on PHP.
Why WordPress cannot close the vulnerability
One might think WordPress could simply "program around it". With PHP2Shell, that does not work, for two reasons.
First, both flaws lie in the way PHP processes requests and cleans up afterwards. That happens regardless of which program is running in PHP. Second, the PHP team has shown an exploit for Apache with mod_php that takes effect before any application code is executed. WordPress, its plugins and every security plugin then never get a chance to act.
For the same reason, no "hardening plugin" that changes settings via ini_set() helps either. php.net expressly advises against setting interim measures this way.
And with managed WordPress?
With managed WordPress offerings, the provider often takes care of not only WordPress updates but also the server underneath. For PHP2Shell this is an advantage, but not automatic. Ask specifically whether the PHP update has been installed and all PHP processes restarted. The statement "We keep your WordPress up to date" does not answer this question.
Many websites, one PHP installation
Agencies and companies with several websites should know a peculiarity: on one server, many WordPress installations often share the same PHP version. If it is unpatched, all of them are affected, regardless of how well each individual website is maintained. Conversely, a PHP update protects all installations at once, provided all associated PHP processes are restarted afterwards. Anyone running several PHP versions in parallel has to update each one individually.
A green WordPress dashboard says nothing about PHP2Shell. What matters is the patch level of PHP on the server and the restart of all PHP processes.
Reading the PHP version in WordPress correctly
WordPress displays the PHP version: in the dashboard under Tools, Site Health, in the Info section under Server. This is a good first indication but not proof.
If a branch such as 8.1 or older is shown there, that is a clear warning sign, because there are no official updates for it any more. If 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is shown, the fixed version is installed. If an older number of a supported branch is shown, a backport may nevertheless have been installed. Distributions and hosting providers often do not change the number in the process. Only the hosting provider's confirmation or a look at the package changelog gives clarity. How to do that is described under Checking the PHP version and patch level.
What WordPress operators should do instead
- Ask the hosting provider or server operator: Is PHP patched, when, and were all PHP processes restarted? Answer in writing.
- Check the PHP branch: If the website runs on 8.1 or older, plan the move to a supported branch. Which version your WordPress version supports is listed in the system requirements on wordpress.org. Changing it in the customer menu is described in Changing the PHP version in the hosting customer area.
- Check for traces: new PHP files in
wp-content/uploads, unknown administrator accounts, foreign entries inmu-plugins. The typical hiding places are described on the page WordPress and PHP2Shell. - Keep WordPress up to date anyway: Core, plugins and themes close other vulnerabilities. That remains a duty, just a different one.
- Clarify responsibility: If an agency looks after the website, record whether it is also responsible for PHP or only for WordPress.
The last point in particular often creates gaps. The agency maintains WordPress, the hosting provider the server, and each believes the other has PHP2Shell in view.
How does PHP SOS help?
- Clarifying the layers: We establish who is responsible for which layer of your WordPress website.
- Updating PHP: On your own or managed servers, we install the PHP update and restart all processes.
- Checking WordPress: We look for traces of an attack in files, database and accounts.
- Proof: You receive the patch level in writing, also to pass on to your agency or customers.
The process is described in the PHP patch service.
Conclusion
The WordPress update is good maintenance, but against PHP2Shell it is the wrong layer. The vulnerability sits one floor lower, in PHP on the server. Anyone who understands this asks the right question to the right party: Is PHP patched, restarted and documented?
Frequently asked questions
Is WordPress releasing a security update against PHP2Shell?
According to Dr. Web, WordPress.org is not planning an update against PHP2Shell, because the vulnerability is in the PHP interpreter on the server. The only remedy is a PHP update by the hosting provider or server operator.
Where do I see the PHP version in WordPress?
In the dashboard under Tools, Site Health, in the Info section under Server. However, the displayed number does not reliably tell you whether the patch is installed, because hosting providers often build fixes in as a backport without a new version number.
Does a security plugin protect against PHP2Shell?
Only to a very limited extent. A plugin itself runs in PHP and only becomes active once WordPress is loaded. With Apache and mod_php, according to the PHP team, an exploit was shown before any application code even runs. A plugin cannot intervene there.
Should I still update WordPress?
Yes. Current versions of WordPress, themes and plugins close other vulnerabilities and are part of good maintenance. They just do not solve the PHP2Shell problem.