PHP2Shell and WordPress/WooCommerce: Patch Today, Then Move Off PHP to Shopify

PHP2Shell is the name for two flaws in the PHP language runtime, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a web server without logging in. The PHP project rates both CVSS v4.0 9.2 (critical) and shipped emergency fixes on 21 October 2026 (BleepingComputer). The flaws are in PHP itself, independent of the application running on top of it, so any application on an affected PHP version can be vulnerable.

Wiz Research, which found the flaws, reported four separate bugs that PHP grouped under the two CVEs:

• a use-after-free in session upload-progress handling;
• an unauthenticated remote disclosure of PHP worker memory that works regardless of the application;
• a use-after-free in fatal-error backtraces;
• a type confusion in OPcache, PHP's shared code cache.

Wiz traces all four to how PHP handles fatal errors, especially running out of memory, part-way through a request: internal state can be left behind and reused by a later request on the same worker. Wiz says every PHP version released in the last decade is affected by at least one of them, back to PHP 5.4.

The PHP project's security advisorydescribes them like this:

• CVE-2026-109618, RCE via out-of-memory corruption (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partly initialised, and request cleanup may then treat that invalid data as valid.
• CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its memory has been freed, and a later request on the same worker may use it before normal initialisation resets it.

Wiz demonstrated pre-authentication code execution against the wordpress:latest, drupal:latest and joomla:latest container images. Two of the four bugs, the upload-progress use-after-free and the OPcache type confusion, each gave Wiz pre-authentication code execution on WordPress. The applications aren't at fault: Wiz notes that even a simple "Hello World" application running on an affected PHP version can be vulnerable. Separately, the memory-disclosure bug can leak passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself, without any code execution, and Wiz says it works even when the application never calls session_start(), which for a store can mean payment-gateway and email-service credentials.

Wiz's headline says PHP2Shell affects "70% of the Internet". Wiz bases it on PHP powering "70% of all websites in the world", which matches PHP's share of websites whose server-side language W3Techs can detect (70.8% on 15 July 2026; snapshots through 2026 range from roughly 69% to 72%). It is not a count of vulnerable or exploitable sites.

Don't confuse PHP2Shell with WP2Shell, a separate WordPress core flaw chain (CVE-2026-63030 and CVE-2026-60137) that was fixed in WordPress 6.9.5 and 7.0.2 in July 2026. If your WordPress core is current, WP2Shell is already dealt with. PHP2Shell is a different problem in a different layer.

Yes, if the PHP running your site is below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on its branch, or is 8.1 or older, and your host hasn't backported the fix. WordPress and WooCommerce code is not the problem; the PHP runtime underneath them is, so updating WordPress, your theme or plugins does nothing for PHP2Shell. The fix is a PHP update on the server, usually your host's job.

According to reporting on WordPress.org's 21 October post ("Critical PHP Security Release"), WordPress.org said the issues are not specific to WordPress and that no WordPress update is required or planned; owners should update PHP. The WooCommerce developer blog, as reported, said the same for WooCommerce, and that self-hosted stores must confirm with their host that PHP is patched. It also said stores on Automattic's own hosting (WordPress.com, WordPress VIP, Pressable, WP Cloud) are already protected. That is Automattic's own claim.

Which PHP setups are at risk? Published advisories list the ways PHP commonly serves web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php described as the highest-risk case. PHP-FPM, the most common setup behind WordPress hosting, is on the PHP project's list of at-risk setups; PHP rates mod_php as the highest-risk case because its demonstrated exploit triggers before any application code runs. Treat every web-facing PHP install as in scope.

Affected versions are every PHP branch before the fixed releases below. Your host may already have patched, but WordPress can't show you whether it has: a backported build can keep the old version number. Until your host confirms the build, assume you're exposed. Self-managed servers and sites on PHP older than 8.2 are the most at risk.

A host or Linux distribution can backport the fix without changing the version number, so an older-looking version may be patched. Ask your host to confirm the build includes the fixes for CVE-2026-109618 and CVE-2026-109619; a build dated 21 October 2026 or later is a useful sign, not proof. On Windows servers, PHP also published rebuilt packages on 26 October (8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1; same PHP source, bundling Brotli 1.2.1) that fix a separate Brotli flaw, CVE-2026-111497. It is only reachable through the cURL extension with automatic HTTP response decompression enabled, which is off by default; take the -1 build anyway (PHP project).

Check your PHP version in WordPress under Tools → Site Health → Info → Server. If it is below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on its branch, it needs patching. Either way, ask your host to confirm the PHP build includes the fixes. Who installs the update depends on who manages PHP: your host on managed or shared hosting, you on a self-managed server.

Step 1: find your PHP version

1. Log in to WordPress admin (5.2 or later) and open Tools → Site Health.
2. Open the Info tab and expand Server. The PHP version is listed there (WP Engine's guide has screenshots).
3. Compare it with the fixed versions in the table above. The patch number matters: 8.3.35 is vulnerable, 8.3.36 is fixed.

One catch: Site Health shows the version number, not the build date. Ignore the green 'recommended' label on the Site Health Status tab as well. It reflects WordPress's general PHP support policy, not PHP2Shell, so an unpatched 8.3 or 8.4 build can still show as recommended (PCrisk and eSEOspace both flag this). Some shared hosts (for example on CloudLinux) and Linux distributions backport fixes without changing the number, so an older-looking version may be patched, and you can't tell from WordPress alone. For example, Ubuntu's patched packages keep the original version number, so a patched Ubuntu 24.04 server can still report PHP 8.3.6. On Ubuntu and Debian servers, the package changelog lists the CVE IDs when the fix is installed (ComputingForGeeks and DevToolLab explain). Where you have server access, the built: line in php -v, or phpinfo(), shows the build date (ComputingForGeeks walks through it). Otherwise, ask your host.

Step 2: patch according to your hosting type

• Automattic hosting (WordPress.com, VIP, Pressable, WP Cloud): WooCommerce says these stores are already protected (Automattic's own statement); nothing for you to install.
• Managed WordPress hosting: the host patches the PHP binary. Kinsta, for example, says it applied the update at hosting level and customers need do nothing. Check your host's status page or announcement, and if there isn't one, ask.
• Shared hosting: the host patches PHP. Timelines vary between hosts, so ask directly, and if your control panel lets you pick a PHP version, choose 8.3 or newer (8.2 is still patched but reaches end of life on 31 December 2026).
• Self-managed VPS or cloud server, including panels like Forge, RunCloud, Ploi or ServerPilot where you own the operating system: you patch it. Update PHP from your package source, then restart PHP-FPM or Apache so every worker loads the new binary. Laravel Forge's knowledge base covers the Forge side.

An email you can send your host

Hi, my site [domain] runs WordPress/WooCommerce on PHP [version from Site Health]. Please confirm whether the PHP build serving my site includes the fixes for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), i.e. PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a backported build dated 21 October 2026 or later. If not, when will it be patched, and what mitigations are in place until then? Thanks.

Open this email in your mail app

If your Site Health version is below 8.3, also ask your host to move you to 8.3 or newer: 8.2 got the fix but reaches end of life on 31 December 2026. Test the upgrade on a staging copy first; older plugins sometimes break on newer PHP.

Step 3: after patching, rotate sensitive keys

Because the memory-disclosure bug can leak passwords, tokens and API keys from other requests, rotate the secrets your store holds once PHP is patched, not before (a key rotated on a vulnerable server can leak again). Start with payment-gateway API keys, email-service keys, admin and hosting passwords, and the WordPress security keys and salts in wp-config.php. Regenerating the salts logs everyone out. (Skycloak and Safeguard cover post-patch steps in more depth.)

Not a complete one. The PHP project says \"there are no complete mitigations, updating is the only safe choice\", but it lists interim measures that reduce exposure to specific attack paths: for CVE-2026-109619, set session.upload_progress.enabled=0 (and fatal_error_backtraces=0 on PHP 8.5); for CVE-2026-109618, set memory_limit=-1 administratively with a container or cgroup memory limit, keep post_max_size low and enforce request limits at the web server. PHP is explicit that these do not make an installation safe; only updating PHP does. They need server-level access, so on shared hosting this is a request to your host, not something you set in WordPress. Forward this section to your host or developer.

Based on the PHP project's advisories, which list separate interim measures for each CVE:

• For CVE-2026-109619: set session.upload_progress.enabled=0 (and on PHP 8.5, fatal_error_backtraces=0) in php.ini, the FPM pool (for example via php_admin_flag) or the web server config, so that it applies before PHP parses the request. PHP says not to rely on ini_set() or an FPM .user.ini for this. Then restart every PHP worker. PHP is explicit about the limits: disabling upload progress "blocks the confirmed session paths but not other variants", and the backtrace setting blocks "the confirmed fatal backtrace path only". It also advises removing invalid or deprecated per-request settings that emit diagnostics before initialisation (hiding those diagnostics with error_reporting, display_errors or @ does not help), and fixing attacker-reachable fatal errors and execution timeouts. Wiz's table groups the four underlying bugs under the two CVEs differently; the per-CVE grouping here follows PHP's own advisories, since PHP publishes the fixes.
• For CVE-2026-109618: the advisory lists setting memory_limit=-1 administratively (for example php_admin_value in the FPM pool or Apache config), making sure no pool, directory or application setting overrides it back to a finite value, keeping post_max_size low (8M if you don't accept uploads, 32M if you do) with upload_max_filesize below it, and enforcing limits on decoded request size, input field count, multipart part count, header count and nesting depth at the web server or proxy, including for requests without a usable Content-Length. An unlimited PHP memory limit lets a single request use as much memory as it can, so only apply it together with a container or cgroup memory limit, which acts as the availability boundary and kills only the affected worker. PHP says not to substitute RLIMIT_AS or RLIMIT_DATA for that container or cgroup limit.

If your site is behind Cloudflare, its WAF managed rules have included PHP2Shell protections by default since 21 October 2026, including on the free plan (PPC Land reported the same). Paid-plan customers should confirm the Managed Ruleset is deployed in Block mode. Cloudflare itself says this is defence in depth, not a substitute for updating PHP.

One more point that applies after you patch: on 23 October the PHP project published an informational advisory suggesting you keep session.upload_progress.enabled=0 until the next regular bugfix release (the advice came after the 21 October releases, so it applies to fixed versions too), "to fully protect from an unlikely RCE vector". PHP says it is unlikely in practice: it needs session.serialize_handler set to php_binary or php_serialize in config, then switched to php with ini_set() before session_start(), with upload progress enabled. PHP will publish the full advisory for CVE-2026-115560 with that release.

Yes, exploitation attempts are confirmed. HKCERT, Hong Kong's national computer emergency response team, says both CVE-2026-109618 and CVE-2026-109619 are being exploited in the wild, and Amazon Threat Intelligence saw an attempt on 17 October 2026, four days before the patches.

HKCERT's 22 October bulletin rates the issue "Extremely High Risk". Amazon Threat Intelligence reported that its honeypots saw an exploitation attempt on Saturday 17 October, four days before the patches, followed by more attempts around disclosure.

On confirmed break-ins the picture is less clear, and as of 28 October 2026 it was still disputed. Recorded Future says reporting doesn't establish successful compromise at scale. Sansec has said mass exploitation looks less likely than first feared, and Beazley said it was not aware of confirmed mass exploitation. None of that is a reason to wait: attempts are real, and a store taking payments is a worthwhile target.

Because these attacks happen below WordPress, your WordPress logs may show little. Wiz lists the signs to pass to your host or developer: unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained PHP worker churn. Ask your host or developer to check logs from 17 October 2026 onwards, the date of the earliest exploitation attempt Amazon reported, not just from the patch date. Wiz is clear that applying the PHP update is the only complete fix.

PHP2Shell timeline

1. 19–24 August 2026: Wiz finds the first bug, confirms code execution against Drupal and WordPress, and reports to the PHP security team (acknowledged 21 September) (Wiz).
2. 17 October 2026: Amazon Threat Intelligence honeypots see an exploitation attempt, four days before the patches.
3. 20 October 2026: PHP gives advance notice of a critical security release, both flaws rated CVSS v4.0 9.2.
4. 21 October 2026: PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (8.6.0 RC4, for testing only, also has the fixes); Wiz Research publishes PHP2Shell; WordPress.org posts "Critical PHP Security Release".
5. 22 October 2026: HKCERT's bulletin rates the issue "Extremely High Risk" and reports exploitation in the wild.
6. 23 October 2026: PHP's informational advisory suggests keeping session.upload_progress.enabled=0 until the next bugfix release; full advisory for CVE-2026-115560 to follow.
7. 26 October 2026: PHP publishes rebuilt Windows packages (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) bundling Brotli 1.2.1 for a separate Brotli flaw, CVE-2026-111497.
8. 28 October 2026: Facts in this article last checked.

On self-hosted WooCommerce, someone, either your host or you, has to keep WordPress, plugins and the server software underneath them patched. PHP2Shell shows that the layer under WordPress can need an emergency patch too, and that patch only lands if your host does it or you do.

And it won't be the last time. For a WooCommerce owner, this is a bill that comes back every time PHP, a plugin or WordPress core needs an urgent fix. WebToffee describes the split: managed hosts usually patch PHP for you, and owners of self-managed servers patch it themselves. Three things make that burden grow over time:

• PHP versions expire. PHP 8.1 reached end of life on 31 December 2025 , and the PHP project has made no official releases for it since; for PHP2Shell it published only minimal source backports. Sites on any PHP older than 8.2 got no official PHP2Shell release. Staying current means planned PHP upgrades, and testing your plugins against each one.
• Plugins are their own attack surface. Separate from PHP2Shell, CVE-2026-27540 in the third-party WooCommerce Wholesale Lead Capture plugin was exploited to upload PHP webshells; it is fixed in version 2.0.3.2.
• Core needs patching too. WP2Shell, a separate WordPress core flaw unrelated to PHP2Shell, was fixed in WordPress 6.9.5 and 7.0.2 in July 2026. WordPress is patchable, but someone has to apply the patches.

You can keep paying that cost every year: the emergency patches, the PHP upgrades that break plugins, the plugin flaws, the late-night emails to your host. Or you can stop owning that layer altogether. That is what a move from WordPress to Shopify does.

Yes, for your store. Shopify runs and patches its hosted platform and checkout, so a Shopify store has no PHP runtime of its own for you or your host to patch. When the next PHP flaw lands, there's no server of yours to patch; the short list that does stay with you is below.

Shopify's core platform is built on Ruby on Rails, not PHP; its GitHub organisation lists Ruby as its top language, and Shopify Engineering describes the Rails monolith. Shopify states it is PCI DSS Level 1 certified and that stores on its platform are covered by that certification for the infrastructure Shopify runs (hosting, cart, checkout). It also runs a public bug bounty with rewards of up to $200,000, paying outside researchers to find flaws before attackers do. Shopify had not published a PHP2Shell advisory as of 28 October 2026.

Headless Shopify: no PHP in your storefront

Every eCommerce store we build is headless Shopify: Shopify runs products, orders and checkout, and the storefront your customers see is a custom front end built in JavaScript (TypeScript on TanStack Start). There is no PHP runtime in the storefront we build or on any server you run, so PHP2Shell gives you nothing to patch, and the next PHP flaw won't be your emergency either. You also get a faster storefront, because it loads only what your store uses instead of a WordPress theme plus every script your plugins inject into it.

No platform is unhackable, Shopify included. What changes is who carries the risk. On WooCommerce, the whole stack is yours to keep patched. On Shopify, a short list stays with you, and we set it up properly at launch:

• Apps. Third-party apps run on their developers' servers, and some are built in PHP (Shopify publishes an official shopify/shopify-app-php library). We keep app lists short and vetted, and you can ask your app vendors whether they've patched.
• Staff accounts and access. Least-privilege permissions, no leftover staff or agency logins, and two-step authentication for everyone.
• Scripts you add. Anything added to the storefront or checkout is vetted before it goes live. Shopify's PCI certification doesn't cover third-party scripts or apps, and you still complete your own Self-Assessment Questionnaire.
• Your storefront code. The headless front end runs on JavaScript, not PHP, so PHP2Shell doesn't apply to it. Its code libraries and hosting still get security updates, like any software: on a Neelo maintenance plan we keep them current for you; without one, they're yours or your developer's to update.
• Any WordPress you keep. If you keep a WordPress blog alongside the store, it still runs PHP and still needs patching, or we move the content too.

That short list is part of every build we ship, not something you work out alone. See how we build headless Shopify stores, or get a plan to move your WordPress store to Shopify.

Yes, if you don't want to keep owning server, PHP and plugin patching. Patch PHP today, because your current site keeps trading while the new store is built, then plan the move to Shopify. PHP2Shell is the latest reminder, not the first, that running WooCommerce means owning a stack of server software, plugins and core updates that someone has to keep patched, on someone else's timeline.

It's time to move if any of these sound familiar:

• This week, you weren't sure who was responsible for patching PHP on your store.
• You're on a self-managed server, or a shared host that was slow to patch, with no developer on retainer.
• Your store is stuck on an end-of-life PHP version because a theme or plugin breaks on 8.2+.
• You've been hit by a plugin flaw, a WordPress core update that broke checkout, or a slow, plugin-heavy store that costs you sales.
• You'd rather spend time on products and marketing than on server maintenance.

What moving has done for stores like yours

These are WooCommerce stores we moved to Shopify, with results checked against their own analytics and Shopify data on 27 October 2026:

• MaxFit SA: online revenue up 145% in the seven months after launch versus the seven months before (April–October 2026 against September 2025–March 2026), with average order value up 50% (GA4 and Shopify).
• RCVR Electrolytes: monthly online sales up 6× on the new Shopify store, from its first full month (March 2026) to September 2026, with orders growing from 4 to 28 a month (Shopify).
• Binuns: organic search revenue up 165% since the new store launched (20 April–26 October 2026 against the same period in 2025), with total online revenue up 12% year on year (GA4).

How we move a WooCommerce store to Shopify

The real risk in a migration is losing search traffic or customer data. Our process is built around protecting both:

1. Patch PHP on your current site first. It stays live and earning until cutover.
2. Export every URL on the old site and map each one to its new Shopify URL.
3. Migrate products and variants, customers and order history.
4. Plan subscriptions and stored payment methods separately; they need their own process.
5. Replace each plugin with a Shopify feature, a vetted app or custom code in the storefront.
6. Build the headless storefront, then set up 301 redirects, least-privilege staff accounts and two-step authentication before launch.
7. Handle customer and order export files securely, and delete them once the import is checked.
8. Send customers account activation emails so they can sign in to the new store.
9. Decommission the old WordPress site, or keep it patched if it stays online, and remove old admin and agency accounts.

What to budget for, against what you pay now: today that's hosting, premium plugins and security tools, and developer time for PHP, WordPress and plugin updates. On Shopify, it's a monthly Shopify plan and any paid apps, hosting for the headless storefront, payment fees (with extra transaction fees if you use a gateway other than Shopify Payments; check Shopify's pricing for your country), and the one-off cost of the migration. Server patching drops off your list. Shopify's URLs follow their own pattern, which is why every old URL gets a 301 redirect.

Ready to stop patching PHP? Get a migration plan for your store: we'll map every URL, your products, customers and order history, and a Shopify replacement for each plugin. For larger catalogues, see our WooCommerce-to-Shopify migration service.

Every security fact and figure in this article comes from the sources below, last checked on 28 October 2026. The PHP facts (fixed versions, CVE descriptions, affected setups, mitigations) were checked against the PHP project's own advisories on 28 October 2026. The WordPress.org and WooCommerce statements are paraphrased from secondary reporting. This is a developing story: check the PHP project's advisories and your host's status page for the latest position.

• Wiz Research: PHP2Shell (Tzadik, Tamari, Ohfeld, Schwartz, 21 October 2026)
• PHP project news archive 2026 (releases and advisories)
• PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• HKCERT security bulletin
• BleepingComputer: PHP ships emergency patches
• BleepingComputer: Amazon on early exploitation
• Recorded Future: PHP2Shell exploitation
• Fortinet: reducing risk while you patch
• ComputingForGeeks: check and patch
• ComputingForGeeks: patching PHP2Shell on Ubuntu
• DevToolLab: how to check and patch PHP2Shell
• PCrisk: PHP2Shell, checking your PHP version
• Laravel Forge: PHP security release October 2026
• Cloudflare: WAF protection for the PHP vulnerabilities
• PPC Land: Cloudflare blocks PHP2Shell exploits
• Skycloak: patch PHP and rotate login secrets
• Safeguard: after patching, check for compromise
• W3Techs: server-side programming languages
• Pasquale Pillitteri: WordPress.org and hosting statements
• eSEOspace: PHP2Shell and WooCommerce
• eSEOspace: PHP2Shell and WordPress
• Kinsta: PHP2Shell statement
• WP Engine: how to check your PHP version
• WebToffee: critical PHP security update for WooCommerce
• BleepingComputer: WP2Shell
• Infosecurity Magazine: WooCommerce Wholesale Lead Capture flaw
• Shopify on GitHub
• Shopify Engineering: inside Shopify's tech stack
• Shopify: PCI compliance
• Shopify bug bounty
• Shopify developer changelog: official PHP and Python app packages

Keep reading