Status as of October 21, 2026. This situation is moving quickly. Verify current guidance before acting.
On October 21, the PHP project shipped emergency patches for two vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on the CVSS severity scale, which runs to 10. Researchers nicknamed the pair PHP2Shell.
Both are memory-safety flaws in how PHP cleans up after a request fails, particularly when a server runs out of memory. In practice they allow two things: running code on the server without any login, and reading fragments of server memory that can contain session tokens, API keys, and credentials.
The flaws affect PHP installations that serve web requests, across every common configuration. The risk is highest on mod_php, the older Apache setup, where a single unauthenticated request can trigger the problem before any application code runs at all.
The timeline moved fast. Details leaked publicly on October 20, roughly two days ahead of the planned disclosure, which forced the PHP team to pull the release forward. Exploit write-ups and tooling are now public.
Patched versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35. There are source-only backports for 7.4, 8.0, and 8.1, and nothing at all for 7.3 and earlier.
PHP runs a large share of the web. By W3Techs data, it is used by roughly 69% of sites where the server-side language is known. On the commerce side, WooCommerce, PrestaShop, and Adobe Commerce together account for more than half of all detectable online stores.
If your store runs on any of these, your server's PHP needs patching:
- Magento
- Adobe Commerce on-premise or PaaS
- WooCommerce and WordPress
- PrestaShop
- Shopware, Sylius, OpenCart, Drupal Commerce, CS-Cart, and other PHP carts
- Custom commerce builds on Laravel or Symfony
That last point is the one worth sitting with. This is not a bug any of those vendors wrote. It is a bug in the language underneath all of them, which means a store with perfect code and current extensions is still exposed until someone patches the runtime.
WordPress was direct about this. Its security lead confirmed that no WordPress update is required or planned for these issues, and pointed site owners at their PHP version instead.
Some merchants cannot simply upgrade PHP, because their platform version does not support a patched release.
PrestaShop 8 officially supports PHP 8.1 and does not support 8.2 or above, so no PrestaShop 8 store can run an officially patched PHP on a supported configuration. Older Magento 2.4 lines pinned to PHP 8.1 or below are in the same position.
For those merchants, the choice is a platform upgrade, a distribution backport, or accepting exposure.
None of those is a same-day fix.
Your storefront is not affected. Shopify runs on Ruby on Rails and Salesforce Commerce Cloud runs on a Java stack. Neither is a PHP runtime, and neither asks the merchant to patch it.
That is the honest short answer, and it is where most commentary stops. It is incomplete.
Almost every enterprise retailer we work with runs PHP somewhere, just not in the checkout:
- The marketing site or blog on WordPress, often on a subdomain
- Headless CMS or PIM layers
- Middleware and ERP or OMS connectors
- Campaign microsites and landing pages, frequently built by a different agency and forgotten
Any of those can hold customer records, API tokens, or a path into systems that do touch payment data. A clean storefront does not clear the estate.
The useful exercise this week is an inventory, not a patch. Find every PHP asset attached to your brand, including the ones nobody owns anymore. That list is usually longer than the team expects.
Inventory every PHP Runtime. Production, staging, containers, subdomains, middleware, admin tools, vendor appliances.
A note on WAFs. Cloudflare shipped rules to all plans including free, and other providers followed. Cloudflare's own CTO called them a stopgap. They cover known attack patterns and only traffic that actually routes through the proxy. Treat them as cover while you patch, not as a substitute for patching.
For merchants in scope for PCI DSS, Requirement 6.3.3 gives you up to one month to install critical patches. That is the outer limit, not the target. With exploit tooling already public, a merchant can be fully compliant with the one-month window and still be compromised in the first week. The standard sets a floor. The threat sets the pace.
A few things are being said this week that the evidence does not yet support.
It does not mean stores are being breached right now. Cloudflare and Patchstack reported early attack traffic, and watchTowr logged honeypot hits. Other firms monitoring the same window saw nothing. As of today there is no publicly confirmed compromise, no named victim, no retailer breach, and no card-skimming campaign tied to these CVEs. The flaws are also not listed in the US government's catalog of known exploited vulnerabilities.
That could change this week. Breach disclosures usually lag the actual compromise by weeks or months, so quiet today means very little. But "likely to be exploited" and "actively breaching stores" are different claims, and only one of them is currently true.
It does not mean Adobe or Magento did something wrong. This is a PHP bug. Adobe did not write it, and no application patch would fix it. Anyone using this week to argue that Magento is uniquely unsafe is selling something.
It does not mean you should replatform. A vulnerability is a terrible reason to move platforms. Replatforming is an eighteen-month decision about total cost of ownership, team capacity, and roadmap. It should never be made in a week that started with a security advisory. If you were already evaluating a move, this is one more data point. If you were not, patch your server and go back to work.
Set the specific CVEs aside for a moment.
The more interesting detail in this story is how the flaws were found. The researchers who discovered them used frontier AI models to do work that would previously have taken a specialist team months. The PHP Foundation has published fifteen CVEs since July as AI-assisted research floods its queue.
If that holds, emergency patch cycles get more frequent for every self-hosted stack, not less. The question for a retailer is not whether PHP is safe. It is: who is responsible for patching the runtime our revenue sits on, and can they do it in hours?
For some teams the honest answer is a named platform engineer with a tested process, and self-hosting is the right call. For others the answer is a hosting partner who has not been asked that question in two years. That gap is worth knowing about before the next advisory, not during it.
We would rather help a retailer answer that question than use it as a reason to sell a migration.
If you are not sure what is running PHP across your brand, or whether anyone owns patching it, we will map it with you and tell you honestly whether it is a problem.
About Red Van: Red Van Workshop is a commerce technology consultancy and systems integrator for retailers. We work across Shopify, Shopify Plus, Shopify POS, and Salesforce Commerce Cloud, with onshore senior teams who scope the work, deliver it, and stay on afterward.