xPHP2Shell: what the October 2026 PHP vulnerabilities mean for your company
On 21 October 2026 the PHP project shipped emergency releases for two critical bugs, together called PHP2Shell. An attacker who can reach an unpatched server may be able to run their own code on it. If your company runs PHP anywhere, patch first, then ask for help with whatever is left.
- Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Those are the fixed releases.
- CVE-2026-109618 and CVE-2026-109619 are both rated 9.2 and can lead to remote code execution.
- PHP 8.1 and older have no official fix. Take those sites off the internet until they move to a supported release.
- A firewall rule is a stopgap. The PHP project says updating is the only complete fix.
- If you cannot find every copy of PHP this week, we can do that with you.
What was disclosed
On 21 October 2026 PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP Foundation says the two bugs, under the right conditions, let an unauthenticated attacker execute code on a server that is still running an older build. Both are scored 9.2. A leaked score of 10.0 was wrong.
CVE-2026-109618 is a memory-handling bug. If a request hits PHP's memory limit at the wrong moment, PHP can treat half-initialised internal data as valid. On Apache with mod_php, the PHP Foundation says this can happen before your application code runs, and remote code execution was demonstrated with default settings. It was also confirmed on PHP-FPM through application code paths.
CVE-2026-109619 is a stale-state bug. A fatal error can leave internal state pointing at memory from a previous request. A later request on the same worker can then use that freed memory. A crash was confirmed, and the reporter demonstrated remote code execution against a real application on Apache with mod_php.
Both sit in memory management and error handling, which nearly every PHP request touches. CERT-EU says every PHP install that serves web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is the highest-risk setup. CISA's alert on the same day told organisations to patch immediately. CISA said it had not observed exploitation at the time it published. The PHP Foundation said that, at the moment of the release, it had not identified a functional public exploit, though proof-of-concept material was already circulating. Do not wait for a confirmed breach report.
Which version to install
Stay on the branch you are already on, and move to the security release for that branch. Jumping a whole major version in a panic is how a checkout or a WordPress admin breaks on a Friday. Read the version with php -v on each server, container and hosting panel, not from memory.
| Branch you run | Install at least | What to do |
|---|---|---|
| 8.5 | 8.5.12 | Update, then retest the site |
| 8.4 | 8.4.27 | Update, then retest the site |
| 8.3 | 8.3.36 | Update, then retest the site |
| 8.2 | 8.2.35 | Update, then retest the site |
| 8.1 or older | No official fix | Take it off the internet, then upgrade or replace it |
PHP is often hidden inside other software: WordPress and its plugins, Laravel, Magento, custom admin tools, Docker images, and the PHP that a host enables for one old microsite. CISA's point is that an inventory which only lists servers named "the PHP app" will miss most of it.
What a firewall will not do
AWS and the PHP project are aligned on this: a web application firewall can reduce exposure to some request patterns while you patch, and it is not a fix. One of the two bugs is largely outside what a firewall can see, because it depends on what a previous request left behind inside a PHP worker. Blocking uploads, if your site never accepts them, is a reasonable temporary control. Leaving the old PHP binary in place is not.
If a vendor tells you a firewall rule means you can schedule the PHP upgrade for next quarter, ask them to put that in writing against CVE-2026-109618 and CVE-2026-109619. Then upgrade anyway.
A sensible order of work
This is the sequence we use when a company asks us to look. It is deliberately boring.
1. List every PHP runtime
Servers, containers, serverless layers, CI images, and anything a marketing site still has on shared hosting. Note the version, whether it faces the internet, and who can change it. Shared hosts and old agency retainers are where this list usually stalls.
2. Patch what is internet-facing and supported
8.2 and newer get the matching release from the table above. Deploy it the same way you deploy everything else, through the image or the package, not by copying a binary onto one box. Then click through login, checkout, file upload and any queued jobs. Many applications need only the new PHP. PECL extensions and very old frameworks may not survive the jump, so retest before calling it done.
3. Take unsupported PHP offline
CISA's advice for 8.1 and earlier, or for anything you cannot update today, is to take the PHP system offline until it is patched or upgraded. That is uncomfortable when the thing offline is the shop. It is still cheaper than hosting an unauthenticated code-execution bug.
4. Watch the workers after you patch
CISA asks organisations to look for suspicious activity, including PHP worker processes launching shells or downloading tools. If you already had a vulnerable version exposed, patching stops the next attempt. It does not tell you whether an earlier one worked. That question is a log and host review, not a version number.
If you want us to do it with you
Webbyfox is a small Python studio in England. We are not a PHP distributor, and we will not pretend a firewall is a patch. What we will do is the work a lot of companies are stuck on this week: finding the runtimes, getting the supported ones upgraded, and giving you a written plan for anything that cannot be patched safely.
That plan is usually one of three things.
- You are on 8.2 or newer and the app is healthy. We help you upgrade, retest, and confirm nothing internet-facing is still on the old build. This is days, not a rewrite.
- You have several sites, an old host, and nobody is sure what is live. Start with a fixed-price discovery. You get an inventory, a patch order, and a recommendation you can hand to your board or your current host.
- The application is on PHP 8.1 or older, and every upgrade attempt breaks it. Patching the runtime is not a strategy. We can rebuild the product in Django, keep the data, and put the old site behind a redirect map. That is a project, and we will say so before anyone signs anything. The shape of that work is on Django development and upgrades and rescue.
If the honest answer is "your host can apply this update this afternoon", we will tell you that and stop. If the honest answer is that a checkout, a members area or an internal tool is one unpatched PHP process away from someone else operating it, we should talk this week.
Email hello@webbyfox.co.uk or send a brief with the PHP version from php -v and whether the site is on the public internet. If you do not know the version, say that. We reply within one working day.
Questions
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Older builds in those branches are vulnerable. PHP 8.1 and earlier are unsupported and have no official fix.
Does this affect WordPress, Laravel and Magento?
Yes, if they are running on an unpatched PHP. The bugs are in the PHP runtime, not in one application. A fully updated WordPress on PHP 8.2 before 8.2.35 is still exposed. A neglected plugin does not have to be the way in.
Is a web application firewall enough?
No. It can block some request patterns while you upgrade. The PHP project and AWS both say updating PHP is the only complete fix, because one of the bugs depends on state left inside a worker, which a firewall cannot see.
Has this been exploited?
CISA said on 21 October 2026 that it had not observed exploitation at the time of its alert. The PHP Foundation said it had not identified a functional public exploit at the moment of the release. Proof-of-concept material was already circulating. Patch as if exploitation is coming, not as if you have weeks.
Can Webbyfox help if we do not have a PHP developer?
Yes. We will find the PHP versions you are actually running, upgrade the supported ones, and write a plan for anything that is too old to patch. Where the right outcome is a new application, we build that in Django. Email hello@webbyfox.co.uk or use the contact form.