What happened
Two vulnerabilities in the PHP core, discovered by Wiz Research, were patched on 21 October. Both are rated 9.2/10 (critical) under CVSS 4.0.
# CVE-2026-109618
Memory corruption when handling an ‘out of memory’ condition: PHP cleans up a request whose internal data is only half-initialised // score 9.2
# CVE-2026-109619
‘Use-after-free’: an internal state survives the freeing of its memory and is reused by the next request processed by the same process // score 9.2
The release was brought forward due to a leak. On 20 October, a post on Hacker News revealed the CVE identifiers ahead of schedule, according to Infosecurity Magazine. The PHP security team then released its patches on 21 October at 14:00 GMT instead of on 22 October. CERT-EU and the UK’s NCSC immediately urged users to apply the patches without delay.
# Who is affected
Virtually every PHP installation that serves web pages is vulnerable: all versions from 5.4 to 8.5.11, according to Google Cloud.
PHP branch > Fixed version
• 8.5 > 8.5.12
• 8.4 > 8.4.27
• 8.3 > 8.3.36
• 8.2 > 8.2.35
• 8.1 and earlier > No official patch: upgrade to 8.2 or later, or apply a patch provided by your distribution
All execution modes are affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the most vulnerable, as the attack can succeed even before the application code is executed (Rapid7). PHP-FPM, which is the most widely used today, is also exploitable, albeit via more complex pathways.
Important note: session upload progress tracking (session.upload_progress), which is enabled by default, opens up a vulnerability even if your application never uses sessions.
# Specific risks
An attacker can take control of the server using the web process’s privileges, without requiring any credentials or user action. In practical terms, this opens the door to:
• the installation of a backdoor or a web shell;
• data theft: customer databases, database credentials, API keys stored in the configuration;
• website tampering (malicious code injection, redirects, card skimming on an e-commerce site);
• a jump to the rest of your infrastructure.
As of 21 October, no active exploitation had yet been confirmed. However, researchers have already developed a working exploit, several teams are replicating the research, and Rapid7 expects a public exploit to be released shortly. Given PHP’s prevalence on the web, large-scale attacks are likely to follow soon.
# What to do now
The only proper fix is to update to a version that includes both patches. Here are the steps to follow.
1. Take stock. Identify all your servers, containers and PHP hosting environments, including any old, forgotten websites. On each machine, running `php -v` will show the version.
2. Update immediately. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply the security package for your Linux distribution (Debian, Ubuntu, Red Hat, etc.), which has already received the patches.
3. Restart all PHP processes. PHP-FPM or Apache that has not been restarted will continue to run the old code.
4. Rebuild Docker images. An image based on a vulnerable version of PHP remains vulnerable until it is rebuilt and redeployed.
5. Contact your hosting provider. Whether you’re on a shared hosting plan or a managed hosting service, check that they have applied the patch; they are often the ones who manage the PHP version.
6. Plan to phase out obsolete versions. PHP 8.1 and earlier will not receive an official patch: migrating to at least 8.2 is now a priority.
If you cannot apply the patch straight away
These settings, which should be placed in php.ini or in the FPM pool configuration (not within the application), reduce the vulnerability without eliminating it:
• session.upload_progress.enabled = 0, followed by a restart of all workers;
• on PHP 8.5, set `fatal_error_backtraces = 0`;
• limit `post_max_size` (8M if you do not have file uploads, 32M otherwise);
• block multipart requests at the reverse proxy or WAF level if your application does not require them;
• failing that, isolate applications exposed to the internet, as recommended by CERT-EU.
Beware of false leads: hiding errors (display_errors, @) offers no protection, and the absence of traces in the logs does not prove that a server is secure.
# In summary
PHP2Shell is one of the most serious vulnerabilities PHP has ever faced: remote code execution, without authentication, affecting almost all versions. There are only a few days left before the first large-scale attacks begin. Update, restart, check, and take this opportunity to clear out any end-of-life PHP versions.
