Skip to content
Guide

October 21, 2026

PHP2Shell: Critical PHP Vulnerability, What WordPress Site Owners Must Do Now

PHP2Shell: two critical PHP flaws allow attacks without login, WordPress included. Which PHP versions are safe and what you need to do today.

PHP2Shell: Critical PHP Vulnerability, What WordPress Site Owners Must Do Now
Contents

As of 21 October 2026, 4:30 pm CEST. I will update this article as soon as there is news.

PHP contains two critical security vulnerabilities, called PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They let attackers run their own code on the server without logging in and take over the entire website, WordPress included. On 21 October at 14:00 UTC the PHP team released the fixed versions PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your WordPress website runs on an older version, PHP has to be updated today. Updating WordPress or the plugins is not enough.

What happened

Researchers, among them the company Calif, found the bugs in August and reported them to the PHP team. Before the updates were ready, details leaked to the public. The PHP team therefore issued an advance warning on 20 October and scheduled the updates for 21 October, 14:00 UTC. Both vulnerabilities are rated 9.2 out of 10 (CVSS 4.0).

Germany's Federal Office for Information Security (BSI, in German) warns that all known PHP versions back to at least PHP 5 are vulnerable and considers large-scale exploitation within a few hours of the updates likely. According to the security firm Sansec, Cloudflare reported first attacks on the morning before the release. The Calif researchers state that they exploited the bug against WordPress 7.1.2, Drupal, Joomla, Magento and Nextcloud, among others, without logging in.

Is my WordPress website affected?

Very likely yes, until PHP on your server is updated. WordPress is written in PHP, so every WordPress website runs on PHP. In its security advisory the PHP team lists all PHP installations that serve web requests as at risk, whether through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. The risk is highest with Apache and mod_php: there, the attack can be triggered before WordPress even starts.

How to see which PHP version your website uses: log in to WordPress and open Tools, Site Health, Info. The PHP version is listed in the “Server” section.

PHP version on your serverWhat it means
8.5.12, 8.4.27, 8.3.36, 8.2.35 or higherFixed. Still check whether anything suspicious happened before the update (see below).
8.2 to 8.5, but an older patch releaseVulnerable. The update must be installed today, by the host for hosting packages.
8.1, 8.0, 7.x or olderVulnerable and no longer maintained by the PHP project. Move to PHP 8.2 or newer, unless your host explicitly provides a security fix for this version.

What you need to do now

  1. Check the PHP version as described above and note it down.
  2. Ask your host if your website is on a hosting package. Most hosts update PHP themselves and often report the status on their status page. A short email is enough: “Has PHP for my website already been updated to a version that fixes CVE-2026-109618 and CVE-2026-109619?”
  3. Move to a supported version if your website still uses PHP 8.1 or older. According to php.net, only PHP 8.2 and newer are still maintained. You usually switch the version in your host's customer menu. Make a backup first: old plugins and themes do not always run on newer PHP.
  4. Your own server: update your distribution's PHP packages and restart all PHP processes (PHP-FPM, Apache). The PHP team points out that the widely used rpms.remirepo.net repository had no updates on 21 October. If you use it, switch to your distribution's packages.
  5. Check for traces after the update (next section).

For server administrators, the PHP team lists settings that make individual attack paths harder if an update is not possible right away. It states explicitly, however, that they do not make an installation safe. I would not rely on them. If no update happens today, taking the website offline temporarily is the safe choice. According to German news channel n-tv, the city of Mainz and the University of Mannheim, among others, took their websites offline for this reason.

Why a WordPress update does not help this time

Most WordPress security warnings concern a plugin or WordPress itself, and one click on “Update” in the dashboard fixes the problem. This time the bug sits one level deeper, in PHP, the software on the server that runs WordPress. Sansec puts it plainly: the hole cannot be closed from within the website's code. Security plugins also come too late on Apache with mod_php, because the attack can take effect before WordPress starts.

That is why good WordPress maintenance covers more than plugin updates: someone also needs to know which PHP version the website runs on and to test a move to a new version on a test copy first.

How to recognise a successful attack

A PHP update closes the hole, but it does not remove anything an attacker left behind beforehand. So after the update, check for:

  • new administrator accounts under Users that nobody created
  • unknown PHP files, especially in the wp-content/uploads folder, which normally only holds images and documents
  • modified files in WordPress, the theme or plugins (a comparison with fresh original files shows this)
  • redirects to unknown sites, spam pages in Google under your domain or browser warnings

Sansec also describes that one of the bugs can leak memory contents of other requests, including passwords, sessions and API keys. If your website was online unpatched, after the update I would change the administrators' passwords, renew the security keys in wp-config.php (this logs all users out) and replace access keys for connected services such as payment providers or newsletter tools.

If you find any of these signs, the website has probably been compromised. Then an update alone no longer helps, a clean-up does. If you need that, my WordPress support covers emergencies as well.

Frequently asked questions

Which PHP version is safe?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later, released on 21 October 2026. PHP 8.1 and older no longer receive updates from the PHP project. There, the only options are moving to a supported version or a security package from your host, if it offers one.

Is it enough to update WordPress and the plugins?

No. The vulnerability is in PHP itself, the software WordPress runs on. It is only closed by a PHP update on the server. WordPress and plugin updates remain important, but they do not close this hole.

Does a security plugin such as Wordfence help?

Not reliably. According to the PHP team, on Apache with mod_php the attack can be triggered before any application code runs. A plugin inside WordPress comes too late. Only the PHP update closes the hole.

I use a hosting provider. Do I still need to do anything?

Yes: check whether your host has already updated, and switch to PHP 8.2 or newer if your website still runs on 8.1 or older. The host installs the PHP update itself, but you usually choose the PHP version in the customer menu.

Should I take my website offline?

If your server cannot be updated today, taking it offline temporarily is the safe choice. Several German cities and universities took their websites offline on 21 October for exactly this reason. Once PHP is updated, the website can go back online.

Help if you get stuck

You do not know which PHP version your website runs on, your host does not answer, or something stopped working after the PHP switch? I will check it for you, install the update and test the website afterwards. Call +49 89 3288 6771 or write to me via the contact form.

Sources: PHP team security advisory with the technical details in GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, BSI press release (German) and CERT-EU.