PHP2Shell: two critical PHP flaws let attackers take over servers without logging in. Update now

Two critical security flaws have been found in PHP, the language that powers roughly three in four websites. Known together as PHP2Shell, they can let an attacker run malicious code on a server remotely without logging in. The PHP project released emergency security updates on 21 October.

What the flaws are

Both stem from the same underlying problem: when a request ends abnormally, PHP can leave its memory in a corrupted state. Each carries a CVSS score of 9.2, rated critical.

• CVE-2026-109618 (out-of-memory corruption): if a request hits PHP’s memory_limit at exactly the wrong moment, for example while a file upload is being parsed, internal data can be left half-initialised. PHP later treats that invalid data as valid, corrupting memory.
• CVE-2026-109619 (stale global state): after a fatal error, internal state can keep pointing to memory that belonged to a previous request. The same worker may then use that freed memory when handling the next request (a use-after-free).

The PHP security team says the risk is highest for Apache with mod_php, where full remote code execution was demonstrated with default settings using a single request, before any application code runs. Remote code execution was also confirmed on PHP-FPM through application code paths.

Who is at risk

Almost every PHP installation that serves web requests is affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP 5.4 and later are vulnerable in default configurations, so sites built on WordPress, Drupal, Joomla, Laravel or Magento are exposed if they run on an unpatched PHP. Updating themes, plugins or application code will not fix this; the flaws are in the PHP engine itself.

VirusTotal estimates that more than 5.1 million PHP hosts are exposed online. In Bangladesh, a large share of news, e-commerce and business websites run PHP on cPanel shared hosting, so local exposure is significant.

Attacks have already started

Technical analysis became public after the patches were released, and proof-of-concept exploit code is circulating. Cloudflare reported seeing early exploitation attempts even before the fixes shipped. CERT-EU has urged organisations to patch immediately, and the UK’s National Cyber Security Centre (NCSC) has advised taking systems offline if they cannot be updated.

PHP core developer Gina Peter Banyard warned that there are no complete mitigations. Web application firewall (WAF) rules or configuration changes may help temporarily, but updating is the only permanent fix.

Fixed versions

• PHP 8.5 → 8.5.12
• PHP 8.4 → 8.4.27
• PHP 8.3 → 8.3.36
• PHP 8.2 → 8.2.35

PHP 8.1 and older are end-of-life and will not get official releases. Given the severity, however, the PHP security team has published minimal source patches for 7.4, 8.0 and 8.1. Linux distributions and LTS vendors received the fixes in advance.

What to do now

1. Check your version: run php -v on the server or look in your hosting panel’s PHP settings.
2. Update: move to a fixed version from the list above. On cPanel servers, update the EasyApache ea-php packages and LiteSpeed’s lsphp packages.
3. Restart services: restart PHP-FPM, Apache or LiteSpeed after updating; if you use container images, rebuild and redeploy them.
4. Leave old versions behind: if you are on PHP 8.1 or earlier, move to a supported version or get a backported patch from your vendor.
5. On shared hosting: if you cannot update the server yourself, ask your hosting provider today whether they have applied the patch.
6. Watch for signs of compromise: investigate unexpected new files, unknown admin accounts or sudden worker crashes in your logs.

The PHP Foundation notes that the flaws sit in parts of PHP that almost every request touches, memory management and error handling, which is why they are so serious and were so hard to fix. Updating without delay is now the most important step.