PHP2Shell (CVE-2026-109618 and CVE-2026-109619): What the NCSC’s Critical PHP Warning Means for You

What the NCSC said

On 21 October 2026 the National Cyber Security Centre posted a warning to UK organisations:

The NCSC is encouraging UK organisations to prepare for immediate updating of systems using PHP. Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated.

The NCSC doesn’t usually tell organisations to take systems offline. Its full alert asks organisations to find every PHP installation, internet-facing ones first, and update them, and to check for signs of compromise on any system that can’t be updated straight away.

The two vulnerabilities

Both flaws are in the PHP interpreter, not in any framework or plugin. If a server runs PHP for a website, it’s potentially exposed, whatever the site is built with.

The PHP security team confirmed working exploits against Apache with mod_php, and confirmed the session upload progress path against PHP-FPM too. Neither attack needs a password or any user interaction. Exploits aren’t trivially reliable, as they depend on the build and server layout, but an attacker can simply keep trying. Details leaked before the planned release date, and on release day watchTowr and Cloudflare both reported attack attempts. Assume your server will be targeted.

Am I affected?

Almost certainly, if you run PHP on a server and haven’t updated since 21 October 2026. According to the researchers who reported them, every PHP version back to 5.4 has at least one of the two flaws. What changes from site to site is how you get the fix:

Don’t forget PHP you didn’t install yourself: hosting control panels, NAS boxes, routers, monitoring tools and other appliances often bundle PHP. The Dutch NCSC keeps a list of products with affected PHP.

What to do today

1. Find out which PHP you’re really running

# The PHP version the web server is actually using (CLI and FPM can differ)
php -v
php-fpm8.3 -v        # adjust to your FPM binary

# On Debian/Ubuntu: is the distro security update installed?
apt list --upgradable 2>/dev/null | grep -i php

The command-line php and the PHP that serves your website are often different builds. A phpinfo() page (deleted straight afterwards) shows what the web server actually uses. On Ubuntu and Debian, the distribution backports the fix into its own version numbers, so “8.3.6” from Ubuntu can be patched: check that the security update is installed instead of looking for 8.3.36.

2. Update and restart

# Debian/Ubuntu with distro or ondrej/php packages
sudo apt update && sudo apt install --only-upgrade 'php*'

# Then restart every PHP process: old workers keep running old code
sudo systemctl restart php8.3-fpm     # or: sudo systemctl restart apache2

The restart matters. PHP-FPM and Apache keep long-running workers, and a worker started before the update is still running the vulnerable code. On shared or managed hosting, ask your host to confirm their PHP is patched.

3. If you can’t update today, apply the interim mitigations

The PHP security team’s advice for systems that can’t be updated straight away is to block the known attack paths in configuration:

; php.ini, or the FPM pool / Apache config (not .user.ini or ini_set())
memory_limit = -1
post_max_size = 8M                    ; 32M if you need uploads
upload_max_filesize = 8M              ; keep below post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0            ; PHP 8.5 only

Set these where the application can’t override them. For PHP-FPM, use php_admin_value in the pool configuration:

; /etc/php/8.3/fpm/pool.d/www.conf: php_admin_value can't be overridden by the app
php_admin_value[memory_limit] = -1
php_admin_value[session.upload_progress.enabled] = 0

Then restart every worker. Settings in .user.ini or ini_set() are applied too late to help. Also limit request and upload sizes at nginx or Apache, and block file-upload requests entirely on sites that don’t use them. Don’t limit memory with RLIMIT_AS or RLIMIT_DATA, as that can trigger the flaw.

These settings reduce the risk. They don’t remove it. The PHP team is clear that updating is the only complete fix, and if you use session upload progress or file uploads, some of these settings will affect your site.

4. If you can’t do either, take it offline

That’s the NCSC’s advice, not ours, and it applies to anything that can’t be patched or mitigated quickly. Whatever you do, check systems that were exposed for signs of compromise: unfamiliar PHP files in upload and cache folders, new admin users, unexpected scheduled tasks and outbound connections from the web server. If you find something, an NCSC-assured incident response provider can help.

Why this is really about PHP versions

Patching takes minutes on a supported PHP version. It took the PHP project one day to ship fixes for 8.2, 8.3, 8.4 and 8.5. Sites on PHP 8.1 and older didn’t get a release at all, and their owners are now choosing between unofficial patches, paid backports, configuration workarounds and switching the site off.

This is what running an end-of-life PHP version means in practice. For years it looks like it costs nothing: the site works, nothing is broken, and the upgrade keeps moving down the list. Then a flaw like this arrives and it costs you all at once, on someone else’s schedule.

PHP 8.2 sites are only one step behind. 8.2 got this fix, but it reaches end of life on 31 December 2026. After that, the next critical flaw gets no fix. If you’re upgrading anyway, go straight to PHP 8.5: it gets security fixes until the end of 2029.

Upgrading isn’t usually the rewrite people fear. Most of the work is finding the deprecated code (dynamic properties, removed functions, outdated Composer packages), and tools like Rector and PHPStan do much of that automatically. What takes judgement is the order of work and the testing, and that’s easier to plan in a calm week than after an NCSC alert.

And there will be another alert. The flaws were found with AI, and OpenAI says they’re among several it has found, with more to announce. See More to come: AI and PHP vulnerabilities.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name given to two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, published on 21 October 2026. Both are rated CVSS 9.2 and can allow an unauthenticated attacker to run code on a web server running PHP. They are in the PHP engine, not in WordPress, Laravel or any plugin, so every PHP application on an unpatched server is exposed.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026. Linux distributions such as Ubuntu and Debian backport the fix into their own packages, so on those systems install the latest security update for your PHP package rather than looking for these exact version numbers.

Is PHP 7.4, 8.0 or 8.1 affected?

Yes. Every PHP version back to at least 5.4 is affected by one or both flaws, and the PHP project no longer releases updates for PHP 8.1 or older. Minimal source patches exist for 7.4, 8.0 and 8.1, and some vendors offer paid backports, but there is no official patched release. The lasting fix is to upgrade to a supported version.

Can I just change php.ini instead of updating?

Only as a stopgap. The PHP security team publishes interim settings, such as disabling session upload progress, that block the confirmed attack paths, but says updating is the only complete fix. Use the settings to buy hours or days, not as a permanent answer.

I’m on shared hosting. What should I do?

Check with your host that their PHP has been patched, and use their control panel to move to PHP 8.3 or newer if you’re on an older version. If your site only works on PHP 7.x or 8.0, that is now a security problem rather than just technical debt, because your host either can’t patch it or will be removing it.

This article reflects the PHP security advisories and NCSC guidance as of 22 October 2026. Check the PHP security advisories for the latest.