php2shell: What the Critical PHP Vulnerability Means for Your Business Website

On 21 October 2026 the PHP project released emergency updates for two vulnerabilities it rates critical, CVSS 9.2 each, that can let an attacker run their own code on a web server without logging in. Five days later the US Cybersecurity and Infrastructure Security Agency added both to its Known Exploited Vulnerabilities catalog, a list it reserves for flaws with evidence of exploitation. Security researchers are calling the pair php2shell.

If your website runs on WordPress, WooCommerce, Laravel, Magento or almost any shared hosting plan, it runs on PHP. This is what happened, which versions are safe, and what to do this week, depending on who looks after your server.

What happened, in plain terms

PHP's security advisory describes two separate bugs in how PHP cleans up after a web request:

• CVE-2026-109618. When PHP runs out of memory part-way through a request, cleanup can treat half-prepared internal data as valid.
• CVE-2026-109619. Internal state belonging to one request can survive after its memory is freed, and a later request on the same worker can use it.

Both can lead to remote code execution: someone on the internet making your server run commands of their choosing. In PHP's words, all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers mod_php the highest risk, because a demonstrated exploit fires before any of your application's code runs. That also means your website's own security plugins and login protection never get a chance to see it.

The UK National Cyber Security Centre, CERT-EU and the Dutch NCSC have issued their own guidance. They all reach the same conclusion: update.

The versions that fix it

Anything below those numbers on a supported branch is vulnerable. PHP's own guidance is blunt: there are no complete mitigations, updating is the only safe choice.

One thing that does not help: updating WordPress, your theme or your plugins. This is a flaw in PHP itself, the engine underneath. A fully up-to-date WordPress site on an old PHP build is still exposed.

What to do, by who runs your server

Shared or managed hosting

Most small and mid-sized business sites in the UAE sit here, and here you cannot update PHP yourself. Your host does. Your job is to confirm they have.

1. Open your hosting panel and find the PHP version, usually under PHP configuration or PHP info. Check the full number, not just "8.3".
2. If it is below the fixed release for its branch, open a ticket. Ask for the date the patched build will be live on your server, not a general statement that the host is "monitoring".
3. If your site is on PHP 8.1 or older, ask whether the host has applied a backport. If they cannot answer clearly, plan the move to a supported version now. That is a compatibility project for older themes and plugins, not a button press. Our guide to PHP 8.2's end of life and upgrading safely walks through it.

Not every host has patched at the same speed. Some apply updates automatically on their own schedule, and a ticket is the fastest way to find out where yours stands.

Your own VPS or dedicated server

Update PHP from your distribution's packages, or from source, then restart every PHP worker: PHP-FPM pools, Apache, LiteSpeed. A patched binary does nothing while old workers are still running. Then check software that bundles its own PHP, such as control panels, appliances and vendor images. The Dutch NCSC keeps a list of affected third-party products.

If you cannot update today

PHP lists temporary measures that reduce exposure to specific attack paths. In its words, they do not make an installation safe. They buy time; they are not the fix.

• Turn off session upload progress (session.upload_progress.enabled=0) and restart every worker. It must be set in php.ini, an FPM pool or the server configuration. PHP specifically says not to rely on ini_set() or an FPM .user.ini file.
• Lower the request size limit. PHP suggests post_max_size = 8M for sites that take no file uploads and 32M for sites that do, with upload_max_filesize kept below it.
• On PHP 8.5, set fatal_error_backtraces=0.
• Hiding errors does nothing. Changing error_reporting or display_errors does not reduce the risk.

On shared hosting, several of these settings are out of your reach, which is another reason the ticket to your host matters more than anything you can change yourself. The UK NCSC goes further: if a system cannot be updated or mitigated quickly, consider taking it offline. If it stays online unpatched, check it for signs of compromise.

After you patch

On 23 October PHP published a follow-up about a third, less likely path through session upload progress, CVE-2026-115560. It only arises with an unusual combination of settings and code. It will be fixed in the next regular release, not an emergency one. Until then PHP suggests keeping session.upload_progress.enabled=0. Very few business websites use that feature, so for most sites leaving it off costs nothing.

A message you can send your host

Copy, paste, fill in your domain:

Regarding the PHP security releases of 21 October 2026 (CVE-2026-109618 and CVE-2026-109619, listed by CISA as known exploited): which exact PHP version is serving [your domain] right now, and on what date will 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a patched backport) be live on our server? Is session.upload_progress disabled server-wide in the meantime?

A good host answers with a version number and a date. If you get neither, that tells you something about where your website lives. We cover the rest of the checklist (accounts, backups, updates, monitoring) in our website security guide for UAE businesses.

If your site is on WordPress and nobody owns its updates, hosting or PHP version, that gap is worth closing before the next advisory, not during it. Our WordPress service includes that ownership, and if you are weighing whether WordPress is still the right base at all, read WordPress or a custom website. Tell us what you are running and we will tell you where you stand.

Versions, dates and guidance are as published by the PHP project, CISA, the UK NCSC, CERT-EU and NCSC-NL on or before 5 November 2026. Check php.net for later releases.