PHP2Shell — What It Is and How to Fix It

Two remote code execution flaws in PHP, patched on 21 October 2026. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Enter your domain

Free. No sign-up, no email. Public response headers only.

The two vulnerabilities

CVE	Technical path	Severity
CVE-2026-109618	Memory corruption reachable through request body handling, triggered when the handler runs out of memory	CVSSv4 9.2 Critical
CVE-2026-109619	Stale global state that survives across requests instead of being reset	CVSSv4 9.2 Critical

Both allow remote code execution through ordinary web request handling. Both were patched by the PHP project on 21 October 2026. "PHP2Shell" is the community name for the pair, not an official product name.

Which PHP setups are affected

Apache mod_php — the highest-risk arrangement, because the flaw can be reached before application code runs.
PHP-FPM — including pools behind Nginx.
php-cgi
LiteSpeed
FrankenPHP

In short: any PHP installation that handles web requests. A CLI-only PHP build with no web SAPI is not exposed through this path.

Fixed releases

Branch	Fixed in	Notes
8.6	8.6.0 RC4	RC1 to RC3 are affected
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36	Recommended upgrade target from 8.1 and older
8.2	8.2.35	Branch reaches end of life on 31 December 2026
8.1 and older	none	No official fix; some distributions ship backported builds

PHP 8.6 releases before RC4 are affected. PHP 8.1 and earlier will not receive an official fix; the PHP project only published source-level backports for those branches, so your practical options are upgrading to 8.3 or later, or asking your host or an LTS vendor for a patched build.

How to tell whether a site is affected

From the outside you can only read what the server chooses to advertise, which is why the check above often ends in "hidden". From the server you can settle it in one command:

php -v
# and confirm the SAPI actually serving requests:
php-fpm -i | grep -i "server api"

Subject: Please confirm the PHP version and patch level for this domain

Hello,

Please confirm which PHP version and which SAPI (PHP-FPM, mod_php, php-cgi, LiteSpeed or FrankenPHP) this domain uses, and whether it has been updated to the fixed release for its branch (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) per the security release published on 21 October 2026 covering CVE-2026-109618 and CVE-2026-109619.

If the current branch receives no official fix, please let me know the upgrade path.

If you cannot upgrade yet

Disable session.upload_progress — set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration, then restart the PHP workers. This closes one of the two flaws, not both, and does not fix the other.
Do not use ini_set() at runtime — this directive has to be set at the configuration layer to take effect.
Reduce the attack surface while you plan the upgrade: put admin surfaces behind authentication, cut down endpoints that accept uploads or large request bodies, and keep a rollback point before you touch production.

Read this as partial mitigation, not as a fix. A site that only disables upload progress is still exposed to one of the two CVEs.

Timeline

21 October 2026 — PHP project publishes fixed releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
31 December 2026 — PHP 8.2 reaches end of life. After that date 8.2 no longer receives security fixes at all.

Frequently asked

Is PHP 8.1 affected?

Yes, and it receives no official fix. Upgrade to a supported branch.

Is 8.2.35 a long-term answer?

It closes these two flaws, but the branch is end-of-life on 31 December 2026. Treat it as a stopgap.

Do you publish exploit code?

No. This site detects and explains exposure only. We deliberately do not host or link working exploits.

Are the two CVEs the same flaw?

No. They are two separate paths — memory corruption and stale global state — that were patched in the same release.