Two critical PHP vulnerabilities — nicknamed php2shell — allow an unauthenticated attacker to execute arbitrary code on the server. The PHP project released the patched versions on 21 October 2026, and every relevant security authority agrees on one point: update immediately.
What Happened and Why It Is Urgent
On 21 October 2026 the PHP project published versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two vulnerabilities with a CVSS v4.0 score of 9.2 (a score of 10.0 had circulated online by mistake, but either way the severity is critical).
Both vulnerabilities enable unauthenticated Remote Code Execution (RCE): an external attacker can take control of the server without providing credentials or interacting with the application layer.
The release was originally planned for 22 October but was brought forward by one day after the CVE identifiers had already leaked online on 20 October. This also accelerated the publication of proof-of-concept (PoC) exploit code, as noted by CERT-EU in Advisory 2026-018: the window between public disclosure and active exploitation has therefore shrunk dramatically.
At the time of publication CISA had not observed confirmed real-world attacks, but the availability of public PoCs significantly increases the likelihood that threat actors are already probing targets.
The Two Vulnerabilities — Technical Deep Dive
CVE-2026-109618 — RCE via OOM Corruption (GHSA-w8hw-w9fx-j79w)
When an HTTP request hits the `memory_limit` boundary at a critical moment — for example while processing a multipart file upload — PHP can be interrupted with its internal request data only partially initialised. The subsequent cleanup routine treats those incomplete structures as valid, corrupting memory in a way the attacker can influence.
The most dangerous vector is mod_php on Apache: exploitation with a single unauthenticated request has been demonstrated, before any application code even runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected.
Temporary mitigations (reduce some attack paths — they do not replace the patch):
Set `memory_limit=-1` at pool or virtual-host level (`php_admin_value` in FPM pool or Apache config) so applications cannot override it
Set `post_max_size` to 8 M (or 32 M if file uploads are needed), with `upload_max_filesize` lower than `post_max_size`
Apply upstream web server or proxy limits on request size, field count, multipart parts, headers and nesting depth
Do not use `RLIMIT_AS` or `RLIMIT_DATA` as a substitute
CVE-2026-109619 — RCE via Stale Global State (GHSA-6wmf-4rv5-p3rp)
After a fatal error, an internal request state can persist even after its memory has been freed. A subsequent request handled by the same PHP process can access that freed memory (use-after-free), leading to attacker-controlled code execution. On PHP-FPM, code execution has been confirmed through application code paths.
Temporary mitigations:
Set `session.upload_progress.enabled=0` in `php.ini`, in the FPM pool or in the server config (not via `ini_set()` or `.user.ini`)
On PHP 8.5: also add `fatal_error_backtraces=0`
Restart all PHP processes after applying the change
Suppressing messages with `error_reporting`, `display_errors` or `@` provides no protection
Practical Guide for Businesses and Non-Technical Teams
PHP is often an invisible component: it powers CMS platforms, e-commerce stores, web-based management tools and many commercial products that do not advertise themselves as "PHP applications". CISA recommends performing a full inventory of all systems running PHP, prioritising those exposed to the internet.
The Dutch National Cyber Security Centre (NCSC-NL) has published a list of commercial and open-source products that bundle PHP — the link is at the bottom of this article.
Checklist for organisations that do not manage servers directly:
Contact your hosting provider or managed service provider and request written confirmation that PHP has been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35
Ask explicitly for coverage of CVE-2026-109618 and CVE-2026-109619 by name
Check with your CMS, e-commerce or ERP vendor whether a compatible update is available
If the provider cannot patch within an acceptable timeframe, discuss with your IT team whether to take those applications offline temporarily, as recommended by CISA for systems that cannot be patched quickly
Watch for PHP processes spawning shells or downloading external tools — this is a sign of a possible compromise already under way
PHP 8.1 and earlier no longer receive updates from the PHP project. The PHP security team did publish minimal source-level fixes for PHP 7.4, 8.0 and 8.1, and some Linux distributions and long-term-support (LTS) vendors supply backported packages — verify with your vendor. PHP 8.2 reaches end of life on 31 December 2026: plan your migration now.
Operational Guide for Server Administrators
Verify the active version:
```bash
php -v
php-fpm8.x -v
```
If you are using distribution packages, check your package manager (`apt`, `dnf`, `yum`) for available updates. Major Linux distributions and LTS vendors received the fixes under embargo before the public release: use your vendor's official channel as the primary source. Note that the volunteer repository rpms.remirepo.net had not published updates on release day (21 October 2026) — do not rely on unofficial channels as a primary source.
Recommended update sequence:
Take a full backup of the environment (config files, data, application code)
Update PHP to the latest patch of your current branch (8.5.12, 8.4.27, 8.3.36 or 8.2.35)
Restart PHP-FPM or the web server (`apache2`, `nginx` with proxy pass, `litespeed`)
Verify the version actually loaded by the web server — not just CLI — for example by creating a temporary `phpinfo()` test file and removing it immediately afterwards
Apply the temporary mitigations in parallel, not as an alternative to patching
If you operate a Web Application Firewall (WAF), CISA notes it can provide partial protection: it is not sufficient on its own
From 11 September 2026, manufacturers of hardware and software products within scope of the Cyber Resilience Act (EU Regulation 2024/2847) are required to report actively exploited vulnerabilities through the European Commission's single reporting platform. Check whether your organisation has notification obligations.
The joint statement of 21 October 2026 from the European Commission (DG CNECT), ENISA, CERT-EU, Europol EC3 and the network of national CSIRTs explicitly calls on organisations to coordinate with hosting and service providers, and to prioritise internet-facing systems.
Key Takeaways and Next Steps
Patch now: updating to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is the only complete fix — temporary mitigations reduce the attack surface but do not eliminate the risk
Inventory all PHP-based systems, including commercial products that bundle PHP silently, and obtain written confirmation from your hosting or managed-service provider that the patch has been applied
Plan your migration away from PHP 8.1 and earlier (already end of life) and PHP 8.2 (end of life 31 December 2026) to a supported branch
Do you need help assessing your exposure or coordinating the update with your hosting provider? **Contact us for a free consultation** — the TelcaVoIP team is available to support you in reviewing your infrastructure.