PHP2Shell: two critical PHP vulnerabilities. What to do now, including on unsupported versions
On 21 October 2026 the PHP team published an emergency security release for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both can allow unauthenticated remote code execution and are rated 9.2 on CVSS v4.0. Details leaked the day before the planned release and early attack attempts have already been reported.
What happened
Both vulnerabilities are in the core PHP interpreter, not in a framework or a specific application:
- CVE-2026-109618: an out-of-memory condition can interrupt PHP while internal request data is only partially initialised; request cleanup then treats that data as valid.
- CVE-2026-109619: request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may reuse it.
In practice, a crafted HTTP request can lead to code execution on the server. According to the official advisory, with mod_php the attack has been demonstrated before any application code runs: the website itself does not need to be vulnerable.
Who is at risk
Every PHP installation serving web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is considered highest with mod_php. This includes corporate websites, e-commerce, CMSs such as WordPress, web-based business software and clinical research platforms such as REDCap, which is written in PHP.
Fixed versions and versions that will stay vulnerable
Fixes are only available for PHP branches that are still supported. All older versions remain exposed.
| PHP branch | Status | Fixed version |
|---|---|---|
| 8.5 | Active support | 8.5.12 |
| 8.4 | Active support | 8.4.27 |
| 8.3 | Security fixes only | 8.3.36 |
| 8.2 | Security fixes only, until 31/12/2026 | 8.2.35 |
| 8.1, 8.0, 7.x, 5.x | End of life | No fix |
Two things to keep in mind. Linux distributions may ship the fix as a backport in their own packages without changing the version number: in that case, rely on your vendor's security advisory. And the 8.2 branch stops receiving security updates on 31 December 2026: upgrading to 8.2.35 today only buys a few weeks, and a move to 8.4 or 8.5 still needs to be planned.
What to do now
- Take inventory: find every machine running PHP, starting with internet-facing ones, and record version and execution mode (FPM,
mod_php, CGI). - Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's fixed package, and restart all PHP processes. According to the PHP team there are no complete mitigations: updating is the only safe choice.
- If you cannot update right away, apply the partial mitigations listed in the official advisory. They reduce some attack paths but do not make the installation safe:
session.upload_progress.enabled=0, set inphp.inior the FPM pool (not withini_set()or.user.ini), then restart the workers;memory_limit=-1that the application cannot override, together with tight limits forpost_max_sizeandupload_max_filesize;- on PHP 8.5, also
fatal_error_backtraces=0.
- Reduce exposure: WAF rules for known vectors, VPN or IP allowlisting for internal systems, and temporarily taking offline systems that cannot be protected.
- Check for compromise on servers that stayed exposed: unknown PHP files, unusual processes, added accounts or cron jobs.
The real problem: unsupported PHP versions
Many production servers still run PHP 7.4, 8.0 or 8.1, often because the application was never adapted to newer versions. Those systems have no official patch today. There are two ways forward:
- Short-term protection: isolate the application from the public network, apply the available mitigations and filter traffic, knowing this is temporary.
- Upgrade to a supported branch, ideally PHP 8.4 or 8.5. Installing the new version is often not enough: removed functions, stricter type checks and outdated libraries require code and dependency changes, tested in a separate environment before going to production.
The same applies to application platforms: upgrading PHP under a REDCap instance, a CMS or business software requires checking the compatibility of the installed version and, if needed, upgrading the application too.
How Depalop can help
We work on critical PHP applications and the infrastructure they run on. For PHP2Shell we offer a three-step approach:
- Quick assessment: inventory of servers, PHP versions, execution modes and internet exposure, with a priority list.
- Immediate hardening: updates where possible, configuration mitigations, filtering and isolation for systems that cannot be updated yet, and a compromise check.
- Planned upgrade to PHP 8.4 or 8.5 for applications on unsupported versions: code and dependency analysis, fixes, testing in a separate environment, release with a rollback plan.
Learn more about our IT infrastructure and cybersecurity and REDCap management and maintenance services, or contact us for a review of your servers.