PHP or WordPress website: what should you check after PHP2Shell?

First, check which PHP version actually serves your live website and update it to a fixed release: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or to a patched package from your distribution or hosting provider. Then go through the basics that PHP2Shell has put back in the spotlight: WordPress and plugin updates, admin accounts, backups and who is responsible for each site.

Below are only verified facts with dates, a practical checklist and an ownership table worth filling in this week.

In short

• On 21 October 2026 the PHP project released fixes for two critical vulnerabilities known together as PHP2Shell. ^[1]
• PHP installations that serve web requests are affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. ^[1]
• Attack attempts were seen before the fixes came out. ^{[5] [6]}
• There is no complete workaround. A web request filter (WAF) buys time but does not replace the update. ^{[1] [4]}
• The version in your documentation guarantees nothing. Look at what runs on the server and who owns each site.

What happened: facts with dates

On 20 October 2026 the PHP project announced a critical security release, and on 21 October it published the fixed versions and an advisory. Both vulnerabilities allow someone else's code to run on the server (RCE, remote code execution), and the PHP team rated each at 9.2 out of 10 on CVSS v4. ^[1]

What else is known as of 23 October 2026:

• Who found it. Wiz Research and Calif, with OpenAI taking part. Wiz writes that affected versions go back to PHP 5.4, and that in their own tests they ran code without logging in on WordPress, Drupal and Joomla. ^[4]
• Old branches. There are no official releases for PHP 8.1 and older; the PHP team published only source patches for 7.4, 8.0 and 8.1. ^[1] Distributions such as Ubuntu and Debian ship patches under the old version numbers. ^[5]
• Attacks. According to Sansec, Cloudflare reported the first attacks on 21 October at 07:43 UTC, before the fixes were out. On 22 October Sansec added that mass exploitation looks less likely than it first seemed, and that public exploits do not work against a default installation. ^[5] Tenable writes that Amazon saw attack attempts as early as 17 October, and that as of 22 October the vulnerabilities were not in the CISA KEV catalogue (the list of vulnerabilities known to be exploited). ^[6]
• Temporary measures. The PHP team recommends disabling session.upload_progress.enabled and limiting post_max_size, but states plainly that there is no full protection without the update. On 23 October an additional advisory repeated the advice on session.upload_progress.enabled. ^[1]

Which PHP version really runs on the site

Documentation, the contract with your contractor and the administrator's memory will not help here. Check the server:

• WordPress. In the dashboard: Tools, Site Health, Info, the Server section. It shows the PHP version serving this particular site.
• Hosting. The control panel shows the version for each site separately. Different sites on one account often run different versions.
• Your own server. The php -v command shows the command line version, while the site may run through PHP-FPM of another version. Look at the package that actually serves the web server.
• Version number and patch. On Ubuntu, Debian or a similar system, the number may stay old even though the patch is installed. Check the package changelog or ask your hosting provider to confirm the fix in writing.

Note PHP 8.2 separately: security support for this branch ends on 31 December 2026. ^[7] WordPress recommends PHP 8.3 or newer. ^[8]

Why a WAF does not replace the update

A WAF (a filter that drops suspicious web requests) can block known variants of the attack. Sansec describes a temporary rule that blocks a certain type of request and warns that it breaks file uploads. ^[5] Wiz states plainly that updating PHP remains the only complete fix. ^[4] So the filter gives you a few days to update, but does not let you skip it.

WordPress: what to check besides PHP

PHP2Shell is about PHP itself, but sites usually get broken into through the weakest spot, which is exactly what a pentest looks for. Go through the basics:

• Core, plugins, themes. Update everything that has an update. Take a backup first. ^[9]
• Unused plugins and themes. A deactivated plugin is still files on the server. If you do not need it, delete it.
• Administrators. Review the list of users with administrator rights. Former employees, contractors from an old project, shared accounts like «admin»: remove everything you do not need.
• Two step login. In WordPress it is added with a plugin, and the WordPress documentation lists options. ^[10] Turn it on at least for every administrator.
• Backups. Check not that a backup exists but that the site can be restored from it. Try it on a separate server.

Who is responsible for each site

Old PHP most often lives not on the main site but on a three year old campaign landing page, a test copy or a blog built by a former contractor. Make a table of all company sites and fill it in with facts, not guesses:

The rows with «nobody» and «unknown» are your risk. Such a site either gets an owner or gets switched off.

Checklist for owners and IT

• All company sites and subdomains are listed.
• Each site has a named owner.
• The PHP version is checked on the server, not in the documentation.
• PHP is updated to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or the hosting provider confirmed the patch in writing.
• Sites on PHP 8.1 and older have a migration plan.
• WordPress core, plugins and themes are updated.
• Unused plugins and themes are deleted.
• The administrator list is reviewed and extra accounts removed.
• Two step login is on for all administrators.
• Restoring from a backup has been tested.
• Temporary measures (WAF, PHP settings) are recorded as temporary, with an update date.

Download the preparation checklist (PDF)PDF · A4

When you need an outside check

If you have many sites and nobody is sure what is exposed to the internet, start with an external security review: it shows which of your sites and services are visible from outside. To systematically find outdated versions and known vulnerabilities on an agreed perimeter, a Vulnerability Assessment fits. If the site has a customer account area, payments or personal data, a pentest goes deeper. We run any active checks only after the scope is agreed and written permission is signed.

FAQ

My site runs on WordPress. Is updating WordPress enough?

No. PHP2Shell sits in PHP itself, not in WordPress. The WordPress update is needed, but PHP is updated separately by your hosting provider or administrator.

The host says everything is updated, but the panel shows an old version. Is that a problem?

Not necessarily. Distributions often apply the patch without changing the version number. Ask your host to confirm in writing that the fixes for both PHP2Shell vulnerabilities from the 21 October advisory are installed.

We run PHP 7.4. What should we do?

There are no official releases for that branch. A patched package from your distribution helps for now, but the real fix is moving to a supported version. Plan it now.

Will Cloudflare or another WAF protect us?

It can drop known attack variants and buy time. But there is no full protection without updating PHP; both the PHP team and the researchers say so.

How can we tell if the site has already been attacked?

Wiz suggests watching for unusual file upload requests followed by memory limit errors, repeated 500 errors and unexplained restarts of PHP processes. If you see this, bring in a specialist to investigate rather than only updating.

References

1. PHP News Archive 2026: Security advisory, critical remote code execution vulnerabilities php.net
2. PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) github.com
3. PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) github.com
4. Wiz Research: PHP2Shell wiz.io
5. Sansec: PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619) sansec.io
6. Tenable: php2shell FAQ tenable.com
7. PHP: Supported Versions php.net
8. WordPress: Requirements wordpress.org
9. WordPress: Updating WordPress wordpress.org
10. WordPress: Two Step Authentication developer.wordpress.org