PHP2Shell (CVE-2026-109618, CVE-2026-109619): critical PHP flaws — what to update
Two critical remote code execution flaws in PHP itself, CVSS 9.2. Fixed versions, temporary protections and how to check your servers.
5 min read
On 21 October 2026 the PHP project released fixes for two critical vulnerabilities in the PHP core, widely called PHP2Shell. They are in the language runtime itself, not in a CMS or plugin, so almost every website and web application written in PHP is affected until it is updated. According to the PHP advisories, a single crafted request can trigger the attack before any application code runs.
The vulnerabilities
CVE
What it is
Severity
CVE-2026-109618
Memory corruption during out-of-memory handling (for example while parsing multipart uploads) — remote code execution
Critical, CVSS 4.0: 9.2
CVE-2026-109619
Stale request state reused by the next request on the same worker (use-after-free) — remote code execution
Critical, CVSS 4.0: 9.2
CVE-2026-115560
Third issue announced by CERT-EU on 23 October; details to be published with the next PHP release
Remote code execution
The PHP team considers mod_php (PHP running inside Apache) the highest-risk setup; PHP-FPM, LSAPI and FrankenPHP are also considered susceptible. CERT-EU reports that proof-of-concept code has started to circulate.
Fixed versions
PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 and later.
PHP 8.1 and older (including 7.4) are end-of-life: there are no official releases. Use your Linux vendor's patched packages — for example, older Ubuntu releases such as 20.04 receive fixes only through Ubuntu Pro (ESM) — or upgrade PHP.
Distribution packages often keep the old version number after patching, so check the package changelog, not only php -v.
If you cannot update today
These steps from the PHP advisories and CERT-EU reduce risk but do not make a server safe:
Set session.upload_progress.enabled=0 in php.ini or the FPM pool (not via ini_set() or .user.ini) and restart all PHP workers.
On PHP 8.5, set fatal_error_backtraces=0.
Keep post_max_size small (8M if you do not accept uploads) and limit request size and multipart parts on the web server or proxy.
Block multipart requests at the front end for applications that do not use file uploads.
Do not use RLIMIT_AS / RLIMIT_DATA limits — they can trigger the vulnerable path.
If patching is impossible, take internet-facing PHP applications offline or put them behind a VPN until fixed.
Do not forget hidden PHP
PHP is embedded in many products: control panels, NAS devices, monitoring systems, routers' web interfaces and appliances. Ask your vendors whether their products are affected and install their updates.
Update first, then harden. Temporary settings only buy time.
CySec can check your servers for vulnerable PHP versions, apply updates with minimal downtime and set up monitoring for new advisories.
We use necessary cookies to run the site and, with your permission, Google Analytics and Google Ads cookies to understand visits and measure advertising. You can change your choice at any time. Cookie policy