Critical PHP Vulnerabilities (php2shell): What WordPress Site Owners Should Do Now

On 21 October 2026 the PHP team released fixes for two critical vulnerabilities that can let an attacker with no password run their own code on the server. Practically every PHP version since 5.4 is affected, and PHP runs most websites on the internet, including every WordPress site. Updating WordPress or plugins does not fix this. PHP itself has to be updated on the server.

The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, scored 9.2 out of 10 (CVSS v4.0). Researchers have named them php2shell. The UK National Cyber Security Centre (NCSC) calls for immediate action and says systems that cannot be patched should be considered for taking offline. Reuters reported a warning from an EU agency that some websites may need to be taken offline temporarily.

Below is what exactly happened, how to check in two minutes whether your site is patched, and what to do if it is not.

In short: The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older no longer receive official fixes, so move off them to a newer version. On shared hosting, check the version in WordPress (Tools, Site Health, Info, Server) and ask your host whether the fix has been applied. If your site runs through Cloudflare, it already blocks known attacks, but that is not a substitute for updating.

What exactly happened

Both bugs are in PHP itself, not in your site’s code:

• CVE-2026-109618 (RCE via out-of-memory corruption). When PHP runs out of memory while handling a request, it can stop while the request data is only partly set up. Cleanup then works with invalid data. An attacker triggers this with a specially crafted file-upload (multipart) request.
• CVE-2026-109619 (RCE via stale global state). After a fatal error, a PHP process can keep pointers to memory that has already been freed. The next request handled by the same process can use that state to read sensitive data from memory or run code.

The attack does not depend on your site’s code: the bugs are in the part of PHP that handles the request before your site even starts. Researchers at Wiz demonstrated unauthenticated code execution against the latest versions of WordPress, Drupal and Joomla. The PHP team says the risk is highest with mod_php, and that PHP-FPM, the most common setup on hosting, is also exposed based on source analysis.

The bugs were found and reported by researchers from Wiz, OpenAI, Calif.io and Quarkslab. The first was found on 19 August, the PHP team was notified on 24 August, and the fixes and public disclosure came on 21 October. Cloudflare says it has already seen attacks against its customers’ sites.

Which versions are fixed

For 7.4, 8.0 and 8.1 the PHP team published only minimal source backports, for people who build PHP themselves. Some Linux distributions and hosting companies include them in their packages, but you need to check with them. On shared hosting, do not count on it: if your site is still on 7.4 or 8.0, now is the time to move.

How to check your site in two minutes

1. In WordPress: Tools, Site Health, the Info tab, the Server section. The “PHP version” field shows the full version, for example 8.3.36.
2. Compare with the table above. If your version is the fixed one or newer, the fix is applied. If it is 8.3.35 or older in the same branch, the site is vulnerable.
3. In your hosting panel (hPanel, cPanel, Plesk) find the PHP version setting. There you choose the branch (8.3, 8.4), while the small patch versions are usually updated by the host.
4. If you have a VPS or your own server: php -v shows the version, but with distribution packages (Debian, Ubuntu, RHEL) the version number may stay old even when the fix is included. In that case check your distribution’s security notice.

What to do

On shared hosting (most small businesses):

• Send your host a short message: “Has the PHP fix for CVE-2026-109618 and CVE-2026-109619 (PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12) been applied to my account?” Most hosts apply fixes themselves, but asking speeds things up and gives you a written answer.
• If your site is on PHP 8.1 or older, switch to 8.3 or 8.4 in the panel. Take a backup first and check the site after the change, because old plugins and themes sometimes break on newer PHP.

On a VPS or your own server:

• Update the PHP packages and restart all PHP processes (PHP-FPM, Apache with mod_php). Without a restart, the old vulnerable code stays in memory.
• Check Docker images and containers too: every one that contains PHP must be rebuilt on a fixed version.

If the update has to wait a few hours:

The PHP team says there is no complete fix without updating, but the following measures reduce the risk. They are set in php.ini or the server configuration, not in your site’s code, and PHP processes must be restarted afterwards:

• session.upload_progress.enabled=0, unless you really need upload progress tracking;
• memory_limit=-1, set so the application cannot change it (for example php_admin_value in PHP-FPM);
• post_max_size=8M if the site does not accept files, or 32M if it does, with upload_max_filesize below that value;
• on PHP 8.5: fatal_error_backtraces=0;
• block multipart requests at the server or WAF if your site does not use them.

These are temporary measures and do not make the site safe. The NCSC advises that a system which can neither be updated nor protected by these measures should be considered for taking offline temporarily.

If your site runs through Cloudflare: on 21 October Cloudflare enabled rules that block these attacks, on the free plan too, with no action needed from you. That buys time, but Cloudflare explicitly says it does not replace updating PHP. Attackers are already changing their requests to get around the protection.

How to spot an attempt

The attacks happen below the level of the site, so WordPress and security plugin logs often show nothing. Wiz lists these signs:

• unusual multipart requests followed by out-of-memory errors or a string of 500 error responses;
• unexpectedly large or malformed PHPSESSID cookies in server responses;
• unexplained, frequent restarts of PHP processes.

If your site was unpatched and you see such signs, after updating check for unknown administrators, modified files and unknown PHP files in the uploads folder. Change your WordPress, database and hosting passwords.

What this means for WordPress site owners in Serbia

The biggest risk is not sites that are maintained regularly, but those built a few years ago where nobody has looked at the PHP version underneath since. There are many of them: the site works, so there is “no need” to touch it. This vulnerability hits exactly those sites, because fixes for old versions are usually unavailable, and moving to a new PHP version means checking plugins and the theme.

The good news is that for a maintained site on a maintained host, this is mostly a one-day job: the host applies the fix, you check the version, and that is it. If you are not sure which version your site runs on or who is responsible for it, we check and move sites to a supported PHP version as part of website maintenance. Get in touch through our contact page and we will look at your site.

Note: The information comes from the PHP team’s official security advisories (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp), the php.net announcement, the UK NCSC warning and publications by the researchers and Cloudflare. Status as of 21 October 2026. We will update this article as new information arrives.

FAQ: the php2shell PHP vulnerabilities

Is my WordPress site at risk?

If it runs on a PHP version older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12, it is vulnerable, no matter how up to date WordPress and the plugins are. Check the version under Tools, Site Health, Info, Server.

Does updating WordPress or plugins fix the problem?

No. The bug is in PHP itself on the server, so only updating PHP fixes it. On shared hosting the host does this, and you check the version.

Which PHP versions are safe?

PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 and newer in the same branches. PHP 8.1 and older receive no official fixes, and support for 8.2 ends on 31 December 2026, so 8.3 or 8.4 is the best choice for most sites.

What are CVE-2026-109618 and CVE-2026-109619?

Two critical vulnerabilities in PHP, known as php2shell, scored 9.2 out of 10. They can let an attacker without a login run code on the server or read sensitive data from memory. Fixes were released on 21 October 2026.

Does Cloudflare protect me?

If your site runs through Cloudflare, its rules from 21 October block known forms of the attack, on the free plan too. It is temporary protection until PHP is updated, not a substitute for updating.

What if my host has not updated PHP yet?

Ask your host for a deadline and a written answer. If your site does not accept files, ask them to temporarily limit uploads and turn off upload progress tracking. If the fix is delayed, consider moving to a host that maintains PHP regularly.

Sources: PHP: critical vulnerabilities announcement, GHSA-w8hw-w9fx-j79w (CVE-2026-109618), GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), NCSC: Critical security issue affecting PHP, Wiz: PHP2Shell, Cloudflare: PHP vulnerabilities WAF protection, Reuters.