PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619)

CVE-2026-109618 and CVE-2026-109619 are both rated CVSS v4.0 9.2. The flaws are in the PHP engine, so Magento, Shopware and WooCommerce stores are affected even when their own code is clean. Calif reported that an attacker without a login can run code on Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 and WHMCS. The exploit tool PHP2Shell, credited to Calif, combines both bugs into one attack that needs no login.

Exploitation

Cloudflare reported early attacks at 07:43 UTC on October 21, before the 14:00 UTC release. On release day, we expected mass exploitation to follow once the patch and the writeups were public.

That is now less likely. A PHP2Shell attack needs specific knowledge of the target server and specific conditions on it. The attack waves after Log4Shell and Shellshock used a single request that worked against any vulnerable server. Nobody has shown such a request for PHP2Shell.

A researcher who tested the public proof-of-concept exploits found that they do not work against a default PHP installation. Most need the target application to have a local file inclusion bug, a severe flaw on its own. Some only work because they add such a bug to the test server first.

Several Dutch sites went offline as a precaution on October 21, including Tweakers, the House of Representatives, the NCSC and Security.NL. You do not need to take your store offline.

Update PHP

The bugs are present in every unpatched PHP since 5.4. Update PHP on every server: you cannot fix PHP2Shell from within your store code. If you do not manage your own server, ask your hosting provider to apply the update.

PHP only supports version 8.2 and later. The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For PHP 8.1 or older, see I am using an EOL PHP, what to do?

I am using an EOL PHP, what to do?

PHP.net publishes no fixed release for PHP 8.1 or older. The PHP security team published source patches for 7.4, 8.0 and 8.1. Several package maintainers backported the fix into older PHP versions. A fixed package keeps its PHP version number (such as 8.1.34) and gets a new package release.

Install the fixed package for your server from the table below, then restart PHP-FPM or Apache. If your hosting provider manages PHP, ask them which of these builds they use.

On Plesk, DirectAdmin or cPanel without CloudLinux, update PHP through the panel and check its changelog for the CVE. The official Docker php image gets no fix for 8.1 or older.

To confirm the fix, look for the CVE in the package changelog:

# Debian, Ubuntu (use your PHP version in place of 8.1)
zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz
# RHEL, AlmaLinux, Rocky Linux (Remi's parallel packages: php81-php-common)
rpm -q --changelog php-common | grep CVE-2026-109618

Temporary mitigations

These steps are temporary and partial. They buy time until you update PHP.

1. Block multipart/form-data in your web server

Every known trigger is a multipart/form-data request, the format browsers use for file uploads. PHP parses that body before your store code runs. Reject these requests in your web server.

For nginx, add this to every server block that passes requests to PHP, then run nginx -t && systemctl reload nginx:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

For Apache, add this to every <VirtualHost> that serves PHP, then reload Apache:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

The rule breaks file uploads, such as product images in the Magento admin. Some stores submit cart or checkout forms as multipart, so place a test order after you add it. Remove the rule once you have updated PHP.

2. PHP settings

Calif published two partial mitigations: turn off session upload progress and remove the memory cap. PHP core developer Gina Peter Banyard warned that turning off session upload progress alone is not enough. Combine these settings with the multipart block above. With memory_limit = -1, a single request can use all server memory. Watch memory use and restore the limit once you have updated PHP.

With mod_php, set the values in php.ini (or a drop-in .ini file under conf.d) and restart Apache:

session.upload_progress.enabled = 0
memory_limit = -1

PHP-FPM reads its own pool configuration, not the command-line php.ini. Add these to every pool, for example /etc/php/8.3/fpm/pool.d/www.conf:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1

Reload the workers (systemctl reload php8.3-fpm, with your version in place of 8.3). Then confirm the values in a request served by PHP-FPM, not on the command line.

The vulnerabilities

Both CVEs are use-after-free bugs. A fatal error during a request, typically out-of-memory when a request crosses the memory_limit, interrupts native PHP code before it cleans up. A later request, or a reused worker, then treats the freed memory as live data.

CVE-2026-109618 also discloses server memory on its own. PHP's upload-progress handler can return freed worker memory to the client inside a PHPSESSID response cookie. That memory can contain passwords, session tokens, API keys and TLS private keys from other requests. The handler runs before application code, so the leak works even when the application never calls session_start().

Apache mod_php and PHP-FPM are both affected. The vulnerable code dates to PHP 5.4.0, released in 2012. Default configurations contain the bugs, but an attack also needs specific conditions on the target server.

Sansec Shield

The RCE and memory-disclosure paths run inside PHP, before your store code and before Sansec Shield. Do not wait for a Shield rule to protect you. Update PHP.

Timeline

Credits

The bugs were found by Ryan Austin of Calif, by Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz) and by OpenAI. The PHP security team coordinated the fix. See the writeups by Calif and Wiz for the full history and technical detail.

We will update this article as we learn more.

Read more

• BlockStrap: Magento and Adobe Commerce RCE (CVE-2026-103849)
• StyleSmuggler: Magento and Adobe Commerce 0-day RCE (CVE-2026-75650) under active attack
• PolyShell: unrestricted file upload in Magento and Adobe Commerce
• Critical backdoor found in MGT Varnish extension
• SessionReaper attacks have started, 3 in 5 stores still vulnerable