PHP2Shell: Are You at Risk and What to Do

In short

On 21 October 2026, PHP shipped an emergency fix for two critical flaws in its core: CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2).
An attacker can run code on your server without logging in, or read passwords and API keys from memory.
If you run PHP 8.2 to 8.5, update to the latest version: 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
If you run older PHP 8.1, 8.0 or 7.4, there will be no new release for you. Only the patch itself is available, and your server administrator or hosting provider must apply it manually. For PHP 7.3 and older, even this patch is unavailable. The only solution is to move to a newer PHP version. These older systems are the most exposed.

What PHP2Shell is

PHP2Shell is the name for two vulnerabilities in PHP itself, not in a CMS or plugin. The first is in how PHP handles running out of memory during a request. The second leaves request state behind in memory PHP has already freed, where a later request can abuse it.

Both lead to remote code execution as the web server user. According to Huntress, a single unauthenticated request is enough, before your application code even runs.

Why it's serious

Details leaked before the official fix, so PHP released patches a day earlier than planned. Amazon recorded an exploitation attempt on 17 October, four days before disclosure (AWS Security). Wiz demonstrated a working attack on WordPress, Drupal and Joomla, and a public proof of concept is on GitHub.

Any standard PHP setup serving web requests is affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php carries the highest risk (PHP).

Are you exposed?

If your website, store or internal system runs on PHP and is reachable from the internet, assume yes. What matters is your PHP version and who manages it.

Your situation	What it means
PHP 8.2 to 8.5, managed hosting	Confirm with your host that the fixed version is live.
PHP 8.2 to 8.5, own server or cloud	Upgrading to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is on you.
PHP 8.1 and older	Upstream support has ended. Only minimal source-level backports or distro fixes exist.
Linux distro (Ubuntu, Red Hat…)	The package may be fixed while keeping an older version number. Check your distro's security notice.

Get a PHP security check →

What to do now

Find out which PHP version runs on every server you own. Not just the main site, but the old admin panel, the intranet and the forgotten microsite too.
Upgrade to a fixed version wherever you can. Upgrading is the only complete fix.
Where you can't upgrade right away, apply stopgaps. Disable session.upload_progress.enabled in php.ini or the FPM pool config, set memory_limit to -1 via php_admin_value, cap post_max_size and request size at the proxy. A memory_limit of -1 removes PHP's memory cap, so watch server memory by other means. Don't rely on ini_set() or .user.ini (PHP).
Take systems you can't fix off the internet, or put them behind a VPN or WAF. Cloudflare has deployed rules for known attack vectors on free and paid plans.
If you suspect a breach, rotate passwords, tokens and API keys that PHP can access.

Why upgrading legacy systems isn't one click

Moving from PHP 7.4 or 8.0 to 8.2+ is more than a version bump. Old frameworks, libraries and custom code often use functions newer PHP removed or changed. Switch the version and the app can break in places nobody has tested.

So we see two mistakes. Teams either postpone the upgrade for fear of breaking something, or do it blind and find out in production that checkout or invoicing stopped working. With PHP2Shell, you can afford neither.

The sensible path has three steps: contain the immediate risk with stopgaps, map what in the code blocks the upgrade, then upgrade in a controlled way, with tests. The second step is what a legacy codebase audit is for. And moving off old code costs less than it used to.

How we can help

At BRACKETS we run legacy codebase audits. A senior architect reviews your code together with specialised AI agents, not a junior developer.

We find where PHP runs and how exposed you are.
We apply stopgaps where you can't upgrade right away.
We map dependencies and the code that blocks a move to supported PHP.
We give you an upgrade plan with effort per step, and we can do the work too.

Get a PHP security check →

FAQ

PHP2Shell is the name for two critical vulnerabilities in the PHP core, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. They allow unauthenticated remote code execution and reading sensitive data from server memory.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. For PHP 8.1, 8.0 and 7.4 the PHP team published a backported fix as a source patch you build yourself. PHP 7.3 and older got no fix. Linux distributions may ship a fixed package under an older version number.

Yes. The flaw is in PHP itself, not the CMS, so any application on unpatched PHP is exposed. Wiz demonstrated a working attack on WordPress, Drupal and Joomla.

Amazon recorded an exploitation attempt on 17 October 2026, before public disclosure. A public proof of concept is on GitHub, so act now.

These versions get no new release, but the PHP team published a backported fix that your server admin or host has to apply by hand. Until then, config stopgaps and isolating the server help. PHP 7.3 and older is no longer maintained and gets no fix. For all of them, the lasting fix is upgrading to supported PHP.

No. It blocks the known abuse path for CVE-2026-109619, but not CVE-2026-109618. Upgrading PHP is the only complete fix.

That is what a legacy codebase audit does. It maps dependencies, risks and the code that will break on newer PHP, and gives you a plan with effort per step. Most audits take two to four weeks.

Sources

Tell us what you're thinking about.
We'll tell you what we think.

Critical PHP security flaw: is your website at risk?