# PHP2Shell: store owners must update PHP now

> PHP released emergency fixes on 21 October 2026 for two flaws that can allow unauthenticated remote code execution. Sources disagree on how widely they are being exploited, and the sources used here do not report a compromised store.

- Publication: The Sourcing Herald
- URL: https://sourcingherald.com/articles/php2shell-store-owners-must-update-php-now
- Format: News
- Section: Business Guides
- Published: 2026-10-26
- Sources last checked: 2026-10-24

## Key points

- PHP released fixes for CVE-2026-109618 and CVE-2026-109619 on 21 October 2026 in PHP 8.5.12, with the same fixes in 8.4.27, 8.3.36 and 8.2.35 [2][3].
- Magento, Shopware and WooCommerce stores are affected even when their own code is clean, because the flaws sit in the PHP runtime [7].
- PHP says there are no complete mitigations and updating is the only safe choice, so store owners must update PHP or ask their host to do so [3][7].
- Exploitation reports conflict: Amazon describes broad exploitation, Sansec calls mass exploitation less likely than expected, and CISA's 21 October alert did not report observed exploitation [6][7][8].

PHP, the scripting language behind many online stores, released emergency fixes on 21 October 2026 for two flaws, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell [4], that can allow unauthenticated remote code execution [3]. The flaws are in the PHP runtime, not in store software, so stores on Magento, Shopware and WooCommerce are affected even when their own code is clean [7]. Store owners who run PHP on their own servers must update it or ask their host to, and sources disagree on how widely the flaws are being exploited.

The PHP advisory and mailing-list announcement are written for server administrators. The store-owner steps below draw on the PHP advisory and Sansec's guidance. Sources were checked on 24 October 2026; the official PHP advisory is at https://www.php.net/archive/2026.php#2026-10-21-5 [3].

## What happened: PHP ships emergency fixes for two critical flaws

On 21 October 2026 the PHP development team announced PHP 8.5.12 as a security release fixing both CVEs. The announcement is dated 14:10:11 UTC [3]. The same fixes are in PHP 8.4.27, 8.3.36 and 8.2.35 [2]. The announcement states: "There are no complete mitigations, updating is the only safe choice." [3]

Details became public on 20 October, before the planned release [1]. PHP had scheduled the release for 22 October, but moved it up by a day after the CVE identifiers leaked [5].

The two flaws work differently. CVE-2026-109618 involves out-of-memory handling, where PHP can be interrupted while request data is only partly set up. CVE-2026-109619 involves request-owned internal state that survives after its memory has been freed [2]. Both are rated 9.2 on the Common Vulnerability Scoring System (CVSS) v4.0 [4].

## Which stores are exposed

PHP's advisory says every PHP installation that serves web requests is in scope. It lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed [2]. PHP considers the risk highest for mod_php [2].

Sansec reports that the flaws sit in the PHP engine, so Magento, Shopware and WooCommerce stores are affected even when their own code is clean [7]. Calif, the researcher that reported the flaws, showed that an attacker without a login can run code on Magento 2.4.9, WordPress 7.1.2 and several other platforms [7].

Versions matter. The fixed branches are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 [4]. PHP 7.4, 8.0 and 8.1 have no official release, and PHP 7.3 and older, including PHP 5, have no fix available [4].

Scale is large. Censys counted about 1.57 million unpatched PHP hosts out of roughly 1.58 million hosts reporting identifiable PHP versions on 21 October [6]. These are internet-wide counts, not store counts. A hosted store's exposure depends on the PHP build its provider runs, so treat every hosted store as unverified until the provider confirms otherwise.

## Who must act

- Store owners who run their own servers must update PHP. Sansec says: "Update PHP on every server: you cannot fix PHP2Shell from within your store code." [7]
- Store owners on hosted platforms should ask the provider to apply the update. Sansec says: "If you do not manage your own server, ask your hosting provider to apply the update." [7]
- Linux distributions and LTS vendors received the patches in advance, so PHP says site operators should check their vendor for updated packages [2].
- Agencies and developers who manage client stores should check every server they run. BlueVoyant CISO John Harbaugh said: "Events like this expose forgotten applications, shadow systems and PHP installations that network owners may not even know exist." [6]

## What store owners should do now

The steps below follow the six-step diagram.

1. Check the PHP version each store runs against the fixed branches: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 [2].
2. Check your Linux distribution or LTS vendor for updated PHP packages, as PHP advises [2].
3. Update to a fixed version. If you run PHP 8.1 or older, PHP says to contact your vendor for backported fixes or upgrade to a supported version [2]. Sansec notes that a fixed package keeps its PHP version number, such as 8.1.34, and gets a new package release [7].
4. Confirm the new version is running after the update. Sansec advises looking for the CVE in the package changelog, and restarting PHP-FPM or Apache [7].
5. Review logs for requests probing for affected servers. Amazon reports probing from 17 October 2026 [6], so logs from that date onward are the place to start. Watch for web server processes that start shells or download tools [8].
6. Ask your host or platform provider to confirm in writing that its servers are patched.

If you cannot patch at once, PHP lists partial settings but says they do not make an installation safe [2]. Sansec says you do not need to take your store offline [7]. Its temporary step is to reject multipart/form-data requests at the web server, which breaks file uploads such as product images in the Magento admin, so remove that rule after updating [7].

## Exploitation: the reports disagree

Amazon says threat actors started probing for affected servers on 17 October, four days before the fixes, and that "PHP2Shell is now being broadly exploited in the wild" [6]. Cloudflare reported thousands of exploit attempts in the 10 hours before the announcement [6].

watchTowr says it observed exploitation in the wild from 21 October 2026 through its Attacker Eye honeypot network [4]. Its head of threat intelligence said many of the circulating exploits either do not work, test for timing differences, or crash the target [6].

Sansec's 22 October update says mass exploitation is "less likely than we expected on release day," and that public exploits do not work against a default PHP installation [7]. Sansec is also clear that updating is still required [7].

CISA urged organisations to update immediately [6]. Its 21 October alert did not report observed exploitation [8]. As of 22 October, neither CVE was listed in CISA's Known Exploited Vulnerabilities catalogue [4].

InternetRetailing says there is no public evidence that attackers exploited the flaws before the fix was deployed [1]. Multiple organisations saw the activity but said the exploitation attempts were unsuccessful [6].

## What is not yet known

- **How widespread exploitation is.** Amazon, watchTowr, Sansec and CISA describe it differently, as shown above.
- **Whether any store has been compromised.** The sources used for this article do not report a compromised store.
- **When CISA will catalogue the flaws.** No date is given.
- **How quickly shared and managed hosts will roll out patched PHP builds.** The sources do not say.
- **The next PHP release.** PHP published an advisory on 23 October about session upload progress, a related setting. It says it will publish a full advisory for CVE-2026-115560 with the next release [2].

## Frequently asked questions

### Which PHP versions contain the fix?

The fixed branches are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 [2][4]. PHP 7.4, 8.0 and 8.1 have no official release, and PHP 7.3 and older have no fix available [4].

### Do I need to take my store offline to fix this?

No. Sansec says you do not need to take your store offline, but you must update PHP on your server or ask your hosting provider to apply the update [7].

### Am I affected if I use a hosted store?

Your exposure depends on the PHP build your provider runs, so treat your store as unverified until the provider confirms it is patched [7]. Sansec advises asking your hosting provider to apply the update if you do not manage your own server [7].

## Sources

1. The vulnerability beneath the checkout: why the PHP scare was a wake-up call for retail — InternetRetailing, published 2026-10-23. https://internetretailing.net/the-vulnerability-beneath-the-checkout-why-the-php-scare-was-a-wake-up-call-for-retail/
2. PHP (official homepage security advisory) — PHP Project (php.net), published 2026-10-23. https://www.php.net/
3. [ANNOUNCE] PHP 8.5.12 Released — PHP Project (php.announce mailing list), published 2026-10-21. https://news-web.php.net/php.announce/513
4. PHP2Shell FAQ: CVE-2026-109618 & CVE-2026-109619 Fixes — watchTowr, published 2026-10-20. https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
5. php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ — Tenable, published 2026-10-21. https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
6. PHP2Shell Exploitation Started Days Before Patches — SecurityWeek, published 2026-10-22. https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/
7. PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619) — Sansec, published 2026-10-21. https://sansec.io/research/php2shell
8. PHP2Shell: Fixed PHP Versions and Free Check — Brandefense, published 2026-10-21. https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/