All posts

PHP critical RCE: where is PHP running in your fleet?

5 min readDrafted with AI, edited and approved by Mat Caniglia

Two critical PHP RCE flaws were fixed on October 21, 2026. The hard part is finding PHP in images, appliances and unsupported versions.

On October 21, 2026, PHP shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution on any PHP install serving web requests. The fix itself is a version bump. The hard part is finding PHP inside vendor images, appliances and third-party apps, and replacing anything on 8.1 or older.

What happened on October 21?

The PHP project released four patch versions on October 21, 2026, fixing two critical flaws that let an unauthenticated attacker run code on the server. CISA published an alert the same day urging immediate patching. The Canadian Centre for Cyber Security issued its own alert and updated it on October 23.

The two bugs are use after free flaws and carry the nickname php2shell. The Cyber Centre lists every 8.5, 8.4, 8.3 and 8.2 release before the fixed versions as affected.

At the time of the alerts, no active exploitation had been reported. The Cyber Centre does point to open-source reporting of a public proof of concept, and it warns that this can change quickly. A team should treat the current quiet as temporary.

On October 23 the PHP project disclosed a third issue, CVE-2026-115560, which the October 21 releases do not fix. It needs an unusual setup. The application has to switch its session serializer to the php handler at runtime before starting the session, with upload progress still enabled. The interim mitigation is session.upload_progress.enabled=0, which the project had already listed for CVE-2026-109619.

Which PHP setups are exposed?

Every PHP installation that serves web requests is exposed. The Cyber Centre names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project rates mod_php as the highest risk, because a demonstrated exploit fires on an unauthenticated request before any application code runs.

That detail matters for triage. On a mod_php host, framework middleware, input validation and app authentication never get a chance to act. Internet-facing mod_php servers go first, then any other internet-facing PHP, then internal web apps.

Versions 8.1 and older get no fix from the PHP project. For anything on 8.1 or below, the options are a confirmed vendor backport or a move to a supported branch.

Where does PHP hide in a fleet?

PHP usually hides in software nobody on the team thinks of as PHP. CISA says PHP is often a component of other software and may not be directly visible. The Cyber Centre asks organizations to find third-party products, appliances and containers that bundle it.

A practical way to split the search is by who controls the upgrade.

Where PHP runs How to find it How it gets patched
Hosts you manage Run php -v for each version and list versions under /etc/php Upgrade every installed version, then restart PHP-FPM and long-running workers
Container images Search image layers or SBOMs for a php binary, including old pinned base tags Rebuild on a fixed base and redeploy, since running containers keep the old binary
Vendor appliances and bundled apps Ask each vendor whether the product embeds PHP and which version Vendor update, or network isolation until one exists
Managed hosting and server tooling Check the provider’s notes on how it installs and updates PHP Depends on the provider, so confirm it rather than assume it
PHP 8.1 and older Any host or image reporting 8.1 or lower Vendor backport or upgrade to 8.2 or newer

Automatic security updates only help if they actually cover the package PHP came from. When PHP comes from a third-party repo, a custom build or a vendor bundle, a host can look up to date and still run a vulnerable build. The only way to know is to check the running version.

How hard is the patch, and what can go wrong?

On a host the team controls, the patch is a package upgrade and a service restart. Plan for a brief restart of PHP-FPM or Apache on each host. Long-running PHP processes, such as queue workers, most likely keep running whatever they loaded at start, so restart those as well. Treat any process older than the upgrade as unpatched until it has restarted.

Packages can lag behind the upstream release, depending on who builds them. Check the candidate version before upgrading and the running version after. A green deploy proves nothing if the package manager pulled the old build.

Where patching cannot happen right away, the Cyber Centre suggests isolating internet-facing applications from public networks until a fix is applied. The cost of skipping all of this is an outside attacker running code on the web server, with whatever credentials, data access and network reach that host holds.

What to check this week

Time box this to five working days, starting today.

Day one: build the inventory. Query hosts, container registries and SBOMs for any PHP binary or package, and list every vendor product that serves a web interface. Mark which ones face the internet and which still run mod_php.

Day two: move internet-facing PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, mod_php hosts first. Restart PHP-FPM, Apache and every long-running PHP worker. Confirm the running version on each host.

Day three: rebuild container images on fixed bases and redeploy them. Set session.upload_progress.enabled=0 everywhere, unless an app needs upload progress and never changes its session serializer at runtime.

Day four: ask each vendor whose product embeds PHP for the bundled version and a fix date. Isolate any internet-facing appliance without a credible answer.

Day five: close the 8.1 and older gap. Confirm a vendor backport covers both CVEs or put a dated upgrade on the plan. Then review web server and endpoint logs since October 21 for unexpected processes, files, accounts or outbound connections tied to PHP or web-server services.

Sources