This is a summary of public advisories as of October 22, 2026. Follow the linked sources for the latest guidance.
What happened
On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These releases fix two critical vulnerabilities, now called PHP2Shell:
- CVE-2026-109618: remote code execution through out-of-memory corruption. If a request hits memory_limit at the wrong moment, PHP can treat partially initialized data as valid.
- CVE-2026-109619: remote code execution through stale global state. This is a use-after-free: one request can reuse memory freed by an earlier request on the same worker.
The PHP security team rates both CVSS v4.0 9.2. Both can be exploited by an attacker who is not logged in. Details leaked on October 20, before the planned disclosure. Cloudflare reported early attacks on the morning of October 21, before the release went out.
Why this matters for Magento 2
This is not a Magento bug, so no Adobe patch fixes it. The flaw is in the PHP runtime under every Magento Open Source and Adobe Commerce store, and in some setups the attack runs before any store code. Sansec reports that researchers showed unauthenticated code execution on Magento 2.4.9.
Your setup changes the risk:
- Apache with mod_php: the highest risk. The demonstrated exploit fires before application code runs.
- PHP-FPM, php-cgi, FrankenPHP, LiteSpeed: still affected.
Who is affected
- PHP 8.2.x before 8.2.35, 8.3.x before 8.3.36, 8.4.x before 8.4.27 and 8.5.x before 8.5.12.
- PHP 7.4 to 8.1: no official release. The PHP security team published minimal source backports, and some distributions and LTS vendors ship their own fixes.
- PHP 5.4 to 7.3: end of life, with no fix from the PHP project.
Your Magento version decides which PHP versions you can run. Stores on 2.4.7 or newer, and 2.4.6 stores on PHP 8.2, can move to an official fixed release. Stores on 2.4.4, 2.4.5 or 2.4.6 running PHP 8.1 depend on a vendor backport, or they need to upgrade.
What to do today
1. Find out who runs your PHP. On managed hosting, open a ticket and ask for the exact patched version and the time it was installed.
2. Check your version. Run php -v on the CLI, and also check the version your web workers use, because the two can differ.
3. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package. Then restart every PHP worker: PHP-FPM, Apache, queue consumers. Rebuild your Docker images too.
4. On PHP 8.1 or older, get a backport from your vendor. Otherwise, plan the Magento and PHP upgrade now.
5. Treat stopgaps as stopgaps. PHP says there are no complete mitigations. Blocking multipart/form-data at the web server or WAF also breaks admin image uploads and some checkout forms. Magento maintenance mode does not protect you, because PHP parses the request before Magento checks the flag.
6. Look for signs of compromise, especially if you patched late. Check for unknown admin users, modified files and injected scripts in checkout pages. If you suspect a breach, collect evidence before you restart workers.
Sources
- PHP Foundation: Today's PHP Security Release
- MagentoInfo: what it means for Magento and Adobe Commerce
At Claspwell we build an AI shopping assistant for Magento 2 and Hyvä stores, so we follow the Magento ecosystem closely. If you're keeping your store up to date this week, we hope this checklist saves you some time.