PHP2Shell: what the critical PHP vulnerabilities mean for anyone running PHP

Last updated 26 October 2026. This is a fast-moving security issue, so check the PHP project's advisory and your hosting or software vendor for the latest guidance.

On 21 October 2026 the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed "PHP2Shell". Both can let an attacker run code on a web server without logging in. The flaws are in PHP itself, so they matter to anyone who runs PHP to serve web requests, whatever is built on top: a content management system, an online shop, a framework-based application, an API, an internal tool or a site written from scratch. Here is what happened, how to tell whether you are affected and what to do.

What happened

• CVE-2026-109618 is memory corruption that can occur when PHP runs out of memory part-way through handling a request.
• CVE-2026-109619 is a "use-after-free" flaw: state left over from one request can be reused by a later request on the same PHP worker.

The PHP security team rates both 9.2 out of 10 (CVSS v4.0). They affect PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php considered the highest risk. The affected code goes back as far as PHP 5.4, so very old servers are exposed too.

Security researchers have reported attempts to exploit the flaws. Amazon's threat intelligence team says it saw attempts from 17 October, four days before the fixes were published, and firms including watchTowr and Cloudflare have reported attacks since. The US Cybersecurity and Infrastructure Security Agency (CISA) has issued an alert urging immediate patching, and CERT-EU has published its own advisory.

Which PHP versions are fixed

Linux distributions and long-term support vendors may ship the fix under their own package version numbers, so check your vendor's advisory rather than relying on the version number alone.

Are you affected?

If you run PHP that serves web requests, assume you are until you have checked. That includes:

• Content management systems and shops built on PHP, such as WordPress, Drupal, Joomla, WooCommerce, Magento (Adobe Commerce) and PrestaShop.
• Applications built with PHP frameworks such as Laravel, Symfony, CodeIgniter or CakePHP, and custom PHP code.
• APIs, admin panels, customer portals and internal tools written in PHP, including ones that aren't public-facing but are reachable on a network.
• Docker containers built on PHP images, which keep running whatever version they were built with until the image is rebuilt.

Frameworks and applications don't bundle PHP itself, so updating WordPress, Laravel or Magento does not fix this; the PHP runtime on the server has to be updated. Fully managed (SaaS) services run and patch their own servers, so if you don't operate any servers yourself, check your provider's status page rather than doing anything on your side.

How to check your PHP version

• On the server: php -v shows the command-line version, which can differ from the version your website uses. To be sure, check the PHP-FPM or web server version, or ask your host.
• Hosting control panels: in cPanel, MultiPHP Manager (or "Select PHP Version") shows the version each domain uses. Plesk and other panels have a similar setting.
• Inside your application: many systems report it, for example WordPress under Tools, then Site Health, then Info and Server.
• Containers: check the base image tag in your Dockerfile and rebuild from an updated image.

Don't overlook the systems nobody thinks about: an old microsite, a staging copy, a forgotten subdomain or a test server is just as exposed as your main site, and often less closely watched.

What to do now

1. 1Make an inventory. List every server, container and hosting account that runs PHP. CISA notes that PHP can be embedded in other software, so it isn't always obvious.
2. 2Update PHP. Move to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or install your vendor's patched package, starting with anything that faces the internet. The PHP team says updating is the only complete fix.
3. 3Restart PHP. Restart PHP-FPM, the web server or the containers afterwards, so every worker runs the new version.
4. 4If you can't update today, apply the PHP team's interim settings (below) and consider putting a web application firewall in front of the site. CISA recommends taking PHP systems offline if they can't be patched, especially those on PHP 8.1 or older.
5. 5Plan the move off old PHP. PHP 8.1 and earlier get no official fix. Upgrading may mean updating your application, plugins or code first, so test on a staging copy.
6. 6Check for signs of compromise. Look for unfamiliar admin users, unknown or recently changed PHP files, and PHP processes starting shells or downloading tools. CISA has published a detection rule to help with log review. If you find anything, treat it as a security incident: restore from a clean backup and rotate passwords and API keys.

Interim settings if you can't update yet

For servers that can't be updated straight away, the PHP security team has published configuration changes that reduce exposure. They don't make a server safe:

• For CVE-2026-109618: set memory_limit=-1 in a way applications can't override, with a memory limit enforced at the container or server level instead.
• For CVE-2026-109619: set session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0.
• Restart all PHP workers after making the changes.

A separate, lower-risk issue, CVE-2026-115560, was disclosed on 23 October. It only affects applications with an unusual session configuration and is due to be fixed in PHP's next routine release. The session.upload_progress.enabled=0 setting above also covers it.

Make PHP updates routine

PHP2Shell is a reminder that the language your application runs on needs the same care as the application itself. Keep a current list of where PHP runs, stay on a supported PHP branch, apply operating system and PHP security updates promptly, rebuild container images regularly, and follow the PHP project's announcements so the next security release doesn't come as a surprise.

This article is general information, not a security assessment of any particular system. Sources: CISA, CERT-EU and Tenable's PHP2Shell FAQ, which summarises the PHP security team's advisory.