PHP Critical Security Release: What Magento, WooCommerce and WordPress Store Owners Need To Do Today

Updated 21 October 2026, 08:55 UTC. We’ll update this post once the release is published.

The PHP security team is releasing an emergency security update today, Wednesday 21 October 2026, at 14:00 UTC (15:00 BST, 10:00 EDT). It fixes two vulnerabilities, and the PHP team rates both critical, CVSS v4.0 9.2. Security researchers report that they allow remote code execution: an attacker could run their own code on your web server.

Attacks have already started. Patchstack reports that several hosting partners have seen active exploitation since 07:34 UTC this morning, before the patch is even available.

If your website or online store runs on PHP, and that covers Magento, Adobe Commerce, WooCommerce, WordPress, Shopware and Laravel, this affects you.

What we know so far

• When: The patch release is scheduled for 14:00 UTC today. PHP says it may release earlier if details go public or attacks are seen in the wild.
• Severity: Two vulnerabilities, each rated CVSS v4.0 9.2. Leaked posts circulated a CVSS 10.0 score, but 9.2 is the official rating.
• Impact: Remote code execution in PHP itself. Security firm watchTowr has confirmed the vulnerabilities are real and reproduced one of them.
• Leak: The bugs were meant to stay under embargo, but details leaked on 20 October, together with an exploit tool now called “PHP2Shell”. The tool’s banner claims it works against every PHP release since 5.4.0.
• Exploitation: Hosting partners have reported active exploitation incidents to Patchstack since 07:34 UTC today.
• CVE IDs: Public reports link the bugs to CVE-2026-109618 and CVE-2026-109619. PHP has not confirmed these IDs yet.
• Not yet published: The exact affected versions, the fixed version numbers, and the official technical details. These come out with the release.

Is there a stopgap until the patch?

There’s one partial measure. It isn’t a fix, but it’s worth applying now.

Researchers working from the leaked details think one of the two bugs is in PHP’s session upload progress feature. That feature is switched on by default. Attackers can trigger it with an ordinary POST request, even if your site never shows an upload progress bar. Switching it off closes that path:

; php.ini (restart PHP-FPM / Apache afterwards)                                                                                                                                                                                                                                 
  session.upload_progress.enabled = 0

If you can’t edit php.ini:

• PHP-FPM / CGI: put the same line in a .user.ini file in your web root. It can take up to 5 minutes to take effect.
• Apache mod_php: add php_flag session.upload_progress.enabled off to .htaccess. If your site starts returning 500 errors, remove the line.
• Managed hosting: ask your host to change it in their PHP settings.

You can’t change it from application code with ini_set(). Upload progress bars will stop working, but file uploads won’t.

Check it worked. Load a temporary phpinfo() page through your web server and confirm the setting shows Off, then delete the page straight away. Don’t rely on php -i, which shows the command-line PHP configuration, not the one your website uses.

Why this isn’t enough: PHP hasn’t confirmed where either bug is. Researchers report that the second bug is in PHP’s multipart upload parser, and this setting doesn’t touch that. Patchstack describes the setting as “only a partial mitigation”, and a PHP core developer has said the only real fix is to update PHP. A WAF or reverse-proxy rule that blocks or inspects multipart POSTs to URLs that never take uploads can cut the risk further.

The flaw sits in PHP itself, and the attack happens before your application code runs. That means no Magento extension, WordPress plugin or app-level firewall rule can fully stop it. Sansec, whose Shield product does exactly that kind of app-level blocking, puts it plainly: do not wait for a Shield rule to protect you.

Don’t mark a server as safe just because this setting is off. Turn it off now, then patch PHP the moment the release is out.

What to do today

1. Find out which PHP version you’re running

• On WordPress / WooCommerce: go to Tools → Site Health → Info → Server.
• On a server you manage: run php -v. Also check PHP-FPM, which can be a different build from the command-line PHP.
• Check everywhere PHP runs, not just production: staging sites, Docker images, CI runners, cron servers.

2. Turn off session upload progress now

Use the steps in the stopgap section above, and check the change has taken effect.

3. Find out who updates PHP

• Managed or shared hosting: Contact your host this morning. Ask them to confirm they’ll deploy the update as soon as it’s released.
• Your own servers (EC2, VPS, dedicated): Book a maintenance window straight after 14:00 UTC. Make sure someone who can patch and restart PHP is available.
• Containers: Plan to rebuild on the patched base images. The Laravel team says it’s working with the PHP Foundation to publish them quickly.

4. Check whether your PHP version is still supported

PHP only supports 8.2 and later with security fixes. If you’re on PHP 8.1, 7.x or older, you won’t get an official fix. Your options are an emergency upgrade to a supported version, or relying on your host or Linux vendor to backport the patch. Ask them today whether they will. Many older Magento 2 and WooCommerce installs still run on old PHP versions, so this is the group most at risk.

5. Patch, restart, verify

Once the release is out, install it. Then restart PHP-FPM or your web server so the new binary is actually running; stale PHP processes keep serving the old code. Check the version again afterwards.

6. Check for signs of a breach, starting now

Attacks began before the patch, so any internet-facing PHP site could already be compromised. Look for unfamiliar PHP files in web directories, new admin users, and changes to checkout templates or payment scripts. Patching closes the hole, but it won’t remove a backdoor that’s already been planted.

Need a hand?

If you’re not sure what version you’re on, who’s responsible for patching it, or you’re stuck on an unsupported PHP version, get in touch. Our technical support team can apply the stopgap, check your stack, apply the update and verify it today. That goes for Magento Open Source, Adobe Commerce, WooCommerce and WordPress sites alike.

Sources: PHP.net announcement, Patchstack, Sansec, Qualys, Help Net Security, Laravel News.