PHP2Shell: What Online Stores Must Do About the Critical PHP Flaws

Posted on the 22 October 2026 by Techcanada

PHP2Shell is the name Wiz Research gave to two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. PHP’s own advisory says they “can allow unauthenticated remote code execution,” and both are rated 9.2 on CVSS v4.0. If your store runs on WooCommerce, Magento or Adobe Commerce, PrestaShop, Shopware or any other PHP software you host yourself, update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today, or confirm that your host already has. Updating is the only complete fix.

This guide explains what the flaws are in plain terms, which stores are exposed, how to check and patch, what to do if you cannot patch immediately, and how to look for signs of compromise. It is based on PHP’s security advisories, Wiz Research’s disclosure and security vendor analyses, all checked on October 21, 2026. Details are still emerging, so check the sources at the end for updates. We do not publish exploit details.

What PHP2Shell is, in plain terms

PHP is the language that runs most self-hosted online stores. Wiz says it powers about 70% of websites, which is where its headline “70% of the Internet” comes from.

Both flaws are memory-safety bugs in how PHP handles errors while it processes a web request. Neither is a bug in WordPress, WooCommerce or Magento code. That is what makes this serious: the vulnerable code runs before your application does, so a fully updated store can still be exposed if the PHP underneath it is not.

Detail CVE-2026-109618 CVE-2026-109619

PHP advisory title RCE via OOM corruption RCE via stale global state

What goes wrong When PHP runs out of memory mid-request, internal request data can be left half set up, and cleanup then treats the invalid data as valid Internal state owned by one request can survive after its memory is freed, and a later request on the same worker can use it

Bug type Use after free (CWE-416) and related memory errors Use after free; memory disclosure is a confirmed impact

Severity Critical, CVSS v4.0 9.2 Critical, CVSS v4.0 9.2

Login needed by attacker No No

Confirmed exploitation setup in advisory Apache mod_php with default limits; FPM, FrankenPHP and LSAPI susceptible to varying degrees Apache mod_php confirmed; PHP-FPM conditionally affected; LSAPI a conditional candidate

GitHub advisory GHSA-w8hw-w9fx-j79w GHSA-6wmf-4rv5-p3rp

From PHP’s security announcement and the two php-src GitHub security advisories, checked October 21, 2026.

Wiz says the flaws can lead to two kinds of damage. The first is remote code execution: an attacker runs their own commands on your server as the web server’s user. The second is memory disclosure, which Wiz says may expose passwords, tokens, API keys and certificates belonging to other requests or the server. For a store, that could mean database passwords, payment gateway API keys, admin session cookies or customer data passing through the server.

Datadog Security Labs, which reproduced both flaws, says a single unauthenticated HTTP POST request reaches the vulnerable code, that any PHP script exposes it, and that application-level login does not block it because PHP handles the request before your code runs. Wiz reports that it demonstrated remote code execution against the latest WordPress, Drupal and Joomla container images at the time of testing.

Is your online store affected?

PHP’s advisory says the risk covers “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed,” and that PHP considers the risk “highest for mod_php.”

PHP branch Status What to do

8.5 Fixed in 8.5.12 Update to 8.5.12 or later

8.4 Fixed in 8.4.27 Update to 8.4.27 or later

8.3 Fixed in 8.3.36 Update to 8.3.36 or later

8.2 Fixed in 8.2.35 Update to 8.2.35, then plan a move: PHP says 8.2 gets no security fixes after December 31, 2026

8.1, 8.0, 7.4 No official PHP release; PHP no longer supports these branches Use a distribution or LTS vendor backport if one exists, or upgrade to a supported branch

5.4 to 7.3 Affected and end of life, no fix Upgrade, or take the site offline or behind strict access controls

From PHP’s October 21, 2026 announcements and release notes; Tenable lists minimal source backports from the PHP security team for 7.4 to 8.1, and Calif traced the earliest affected code to PHP 5.4.0.

How this maps to the way you run your store:

  • Self-hosted WooCommerce, Magento, PrestaShop, Shopware or OpenCart on a VPS or dedicated server. You are responsible for PHP. Treat this as urgent.
  • Managed WordPress or Magento hosting. Your host usually manages PHP, but confirm it. Ask your host directly whether its PHP builds include the October 21 fixes, and check any PHP version selector in your hosting panel.
  • Shared hosting with cPanel or Plesk. The host updates the PHP packages, but you may have chosen an old PHP version for your site. If your site is set to 8.1 or older, move it to a supported version once your extensions and theme support it.
  • Hosted platforms such as Shopify or BigCommerce. The platform runs its own servers, so this is its job, not yours. Check the platform’s status page. Any PHP site you run alongside the store, such as a WordPress blog on a subdomain, still needs patching.

Huntress also warns that software bundling its own PHP, control panels and Windows applications can carry vulnerable copies. Include them in your inventory.

How the disclosure unfolded

Dates from Wiz Research’s disclosure timeline, with the October 20 leak as reported by Tenable and Huntress. Day counts are our own arithmetic.
  • August 19, 2026. Wiz finds the first vulnerability. Its post says the team confirmed unauthenticated remote code execution on Drupal on August 20 and on WordPress on August 21.
  • August 24. Wiz reports to the PHP security team. PHP’s advisories credit several reporters, and Wiz links to companion write-ups from OpenAI and Calif.
  • September 21. According to Wiz, PHP acknowledges the reports and begins a coordinated fix.
  • October 20. Huntress says a Hacker News post claimed two critical PHP flaws were about to be disclosed; the post was removed but screenshots spread. Tenable says the CVE identifiers circulated that day, and that PHP moved its planned release forward from October 22 to October 21. PHP’s own notice that day scheduled the release for October 21 at 14:00 UTC.
  • October 21. PHP ships 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and publishes its advisories. Wiz and other researchers publish their write-ups.

From Wiz’s first discovery to fixed releases took 63 days, and 58 days from the report to PHP. Wiz says its own exploit work took hours with AI assistance, which is part of why researchers expect attackers to move fast now the fixes are public: a patch shows exactly what changed.

Is it being exploited?

As of October 21, reports differ, so treat exploitation as likely soon even if it has not reached your server yet.

  • Wiz’s post does not report in-the-wild exploitation.
  • Tenable reports that Cloudflare described “early attacks emerging” and that watchTowr reported exploitation attempts against both CVEs. These are Tenable’s summaries of other companies’ reports.
  • Huntress said that as of 4:30 PM ET on October 21 it had not seen in-the-wild exploitation on its partners’ systems.
  • Datadog reported no in-the-wild exploitation in its first post.
  • Tenable says exploit code is circulating but unverified, and that the PHP Foundation said at disclosure it had not identified a functional public exploit. Tenable warns that unverified exploit code may itself contain malware. Do not download “proof of concept” code to test your store.

How to check your PHP version

Check the PHP version your website actually uses, not just the one on the command line. A server can have several PHP versions installed, and the web server may use a different one from the terminal.

  1. WordPress and WooCommerce. In WordPress admin, go to Tools > Site Health > Info and open Server to see the PHP version. WooCommerce also lists it under WooCommerce > Status in the server environment section.
  2. Hosting control panel. cPanel, Plesk and most managed hosts show the PHP version per site, often with a selector to change it.
  3. Server access. Running php -v shows the command-line version. For the web version, ask your developer to check the PHP-FPM or Apache module in use; a temporary phpinfo page works but delete it straight away, since it exposes server details.
  4. Linux distribution packages. Distributions often backport security fixes into their own package versions rather than moving to PHP’s version numbers. Check your package changelog or your distribution’s security notice for the two CVE IDs instead of relying on the version string alone. AlmaLinux, for example, said on October 21 that it was backporting fixes into its supported PHP streams.

How to patch: a plan for store owners

Order matters. Start with what faces the internet and handles payments or logins.

  1. Make a list. Every PHP site you run: the store, any blog, staging sites, old landing pages, admin tools. Staging and forgotten sites are easy to miss and just as exposed if they are public.
  2. Back up. Take a full file and database backup, or confirm your host’s latest backup, before changing PHP.
  3. Update PHP. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution’s patched package. On managed hosting, get written confirmation from your host.
  4. Restart PHP. Restart PHP-FPM or Apache so every worker runs the new code. Huntress and PHP both stress restarting workers after changes.
  5. Test the store. Place a test order, log in to the admin, and run your payment gateway’s test mode.
  6. If you are on PHP 8.1 or older, treat the upgrade as a project with a deadline measured in days. Check that your theme, plugins or extensions support the target version on a staging copy first.

If you cannot patch today

PHP’s advisories list configuration changes that reduce exposure to specific attack paths. PHP is explicit that they “do not make an installation safe,” and Datadog goes further, saying community workarounds such as disabling session upload progress do not protect against these vulnerabilities. Use them only as a bridge while you patch.

Measure Which flaw it targets Caveats from the advisories

Set memory_limit=-1, enforced so applications cannot override it CVE-2026-109618 Not a complete mitigation. Keep post_max_size conservative and limit request size, input variables, multipart parts and uploads at the web server or proxy. PHP warns not to use RLIMIT_AS or RLIMIT_DATA instead.

Set session.upload_progress.enabled=0 CVE-2026-109619 Blocks the demonstrated session path only. PHP suggests leaving it off even after patching if you do not use the feature.

On PHP 8.5, set fatal_error_backtraces=0 CVE-2026-109619 Removes the producer for the confirmed case, not other state.

Move per-directory PHP settings (such as php_value in .htaccess) into startup configuration CVE-2026-109619 Reduces early code paths on mod_php.

Restart all PHP workers after any change Both Settings do not apply to running workers until restart.

Web application firewall rules Both Wiz lists Cloudflare, Fastly, Google, Akamai, AWS, Microsoft, Imperva and Vercel as publishing mitigations. Tenable notes Cloudflare called its rules a stopgap covering only traffic routed through Cloudflare.

Take the site offline, read-only, or behind a VPN Both Recommended for end-of-life PHP by Huntress; CERT-EU recommends isolating internet-facing applications until fixed, per Tenable. Sansec suggests read-only mode for stores that cannot patch within the hour.

From PHP’s GitHub security advisories and announcement, Wiz, Tenable, Huntress, Datadog and Sansec, checked October 21, 2026. Changing these settings can affect how your store works; test on staging where possible.

Two practical warnings for stores. Removing the PHP memory limit can let a single heavy request use far more server memory than before, so watch server resources. And blocking or restricting multipart form requests, as Sansec suggests, can break product image uploads, checkout file fields or admin imports. Have someone who knows your setup make these changes.

Signs your store may have been attacked

No confirmed indicators of compromise had been published by October 21; Huntress listed its table as to be determined. Researchers describe these signals to watch:

  • In web logs: unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, and unusually large or malformed PHPSESSID cookies in responses (Wiz). Datadog adds large form submissions and memory-exhaustion errors during request startup.
  • On the server: PHP worker processes starting shells, script interpreters or download tools (Huntress, Datadog), and unexplained PHP worker churn (Wiz). Datadog notes that successful exploitation may not crash the worker, so a quiet log is not proof of safety.
  • After a compromise: new or changed files in the web root, especially PHP files you did not add, new cron jobs, scheduled tasks or admin accounts (Huntress).

Wiz notes that application logs may say little, because the flaws sit below the application. For a store, add checks that matter for payment theft: unexpected changes to checkout templates or JavaScript files, new payment gateway settings, and admin users you do not recognize. Once an attacker can run code on a store server, card-skimming code on checkout pages is a known risk; our coverage of the critical Magento flaw in July covers what to check on Magento specifically.

If you find signs of compromise

  1. Isolate the server or put the store into maintenance mode.
  2. Preserve web server and PHP logs before changing anything else, as Huntress advises.
  3. Bring in your host’s security team or an incident response provider.
  4. Rotate secrets that lived on the server: database passwords, payment gateway and API keys, admin passwords and session secrets. Wiz says memory disclosure can expose exactly these.
  5. Contact your payment provider about possible card data exposure. Your legal and notification duties depend on your location and contracts, so get professional advice on those.

Why this matters more for stores than for most websites

A hacked brochure site is an embarrassment. A hacked store can leak customer data, skim card numbers at checkout, and trigger chargebacks and payment processor reviews long after the server is cleaned. Stores also hold the keys attackers want: payment gateway credentials, email platform keys, shipping accounts. Our e-commerce security checklist for small stores covers the wider basics, and our piece on why online stores are now a top bot target explains why automated scanning reaches small stores quickly.

What you should do next

  1. Today: confirm the PHP version on every public PHP site you run, and patch or get your host’s confirmation.
  2. Today: restart PHP workers after patching, then place a test order.
  3. If you cannot patch today: apply the interim settings above, add WAF rules, or take the site offline.
  4. This week: review logs and the web root for the signs listed above.
  5. This month: plan an upgrade off PHP 8.1 and older, and off 8.2 before December 31, 2026.

Frequently asked questions

Does updating WordPress, WooCommerce or Magento fix PHP2Shell?

No. The flaws are in PHP, the language runtime, not in the application. You need a fixed PHP build: 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a patched distribution package.

My store is on Shopify. Do I need to do anything?

Shopify and similar hosted platforms run their own infrastructure, so patching is their responsibility. Check their status pages. If you also run a self-hosted WordPress site or landing pages, patch those.

Is PHP 8.1 safe if my host says it is “supported”?

The PHP project no longer releases fixes for 8.1 and older. Some distributions and LTS vendors backport fixes, so ask your host specifically whether its 8.1 build includes fixes for CVE-2026-109618 and CVE-2026-109619.

Will a web application firewall protect me?

It can reduce risk while you patch, but vendors describe WAF rules as a stopgap. They only protect traffic that passes through the WAF, and attackers can reach a server directly if its origin address is known.

Should I test my store with a public exploit?

No. Tenable warns that unverified exploit code may contain malware, and running attack code against a live store risks crashing it. Check your PHP version instead, or use a vendor scanner.

The takeaway

PHP2Shell sits under every self-hosted PHP store, regardless of how well the store software itself is maintained. Update PHP and restart it today, confirm your host has done the same, and use the interim settings only as a short bridge.

Sources

  • PHP, “Security advisory: Critical remote code execution vulnerabilities, update now” and release announcements for 8.5.12, 8.4.27, 8.3.36 and 8.2.35, October 21, 2026. php.net
  • PHP security team, GitHub advisory GHSA-w8hw-w9fx-j79w, “RCE via OOM corruption” (CVE-2026-109618), October 21, 2026. github.com
  • PHP security team, GitHub advisory GHSA-6wmf-4rv5-p3rp, “RCE via stale global state” (CVE-2026-109619), October 21, 2026. github.com
  • Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”, October 21, 2026. wiz.io
  • Tenable, “php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions”, October 21, 2026. tenable.com
  • Huntress, “Rapid Response: php2shell, leaked critical PHP vulnerabilities”, October 20, 2026, updated October 21, 2026. huntress.com
  • Datadog Security Labs, “PHP2Shell: Critical vulnerabilities in PHP: detection, analysis, and remediation”, October 21, 2026. securitylabs.datadoghq.com
  • Sansec, “PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)”, October 21, 2026. sansec.io
  • AlmaLinux, “php2shell (CVE-2026-109618, CVE-2026-109619): Patched PHP packages”, October 21, 2026. almalinux.org

Last reviewed: October 21, 2026. Fixed versions, severity, affected setups and exploitation reports reflect the sources above as of that date; this is a developing story.

How this article was made: researched and drafted with AI assistance, with every factual claim checked against the sources above. The timeline day counts are our own arithmetic. This article is general information, not security or legal advice for your specific setup.

Related guides

  • E-commerce security checklist for small stores
  • Your Magento store has a critical flaw. Patch it now
  • Chargeback ratio limits: Visa VAMP, Mastercard and Shopify thresholds