PHP Warns of a Third Flaw the PHP2Shell Patches Miss

PHP warned on Oct. 23 of a third code execution risk that the Oct. 21 PHP2Shell patch releases do not fix.

At Ecommerce Paradise the question is always what a store owner changes today, and for this flaw the answer is one server setting. If you run your own PHP (a WooCommerce store, the WordPress blog that feeds your Google traffic, a quote funnel on a VPS), that setting is yours or your host’s to change. A store that lives entirely on Shopify‘s hosted storefront has no PHP server of its own to touch, though the blog, helpdesk and landing-page tools around it may.

I covered the emergency patch schedule on Oct. 21. The exploit probing followed a day later. This post covers what PHP said about the new flaw, why the earlier fixes miss it, and a checklist to run with your host this week.

When a server scare turns into a bad week, your LLC is the structure meant to keep business trouble separate from your personal assets, and Northwest Registered Agent is the best LLC formation service I know of for ecommerce owners. It has a 25-year record behind it, which is why I trust it over cheap formation sites that upsell you after checkout. Form your LLC with Northwest →

PHP Flags CVE-2026-115560, a Flaw the Oct. 21 Patches Miss

PHP published an informational advisory on Oct. 23 for CVE-2026-115560, according to The Hacker News. The issue is separate from the two PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619. The Oct. 21 releases (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35) do not fix it.

PHP has not assigned a severity score or published a list of affected versions. Exposure needs three things to line up, per Security Affairs. An application sets session.serialize_handler to php_binary or php_serialize in its configuration, switches it to php at runtime with ini_set() before calling session_start(), and keeps session upload progress enabled.

PHP called that “an unusual combination of configuration and application code,” per Security Affairs. A security vendor’s write-up at Safeguard quotes PHP calling it “an unlikely RCE vector.”

There is no emergency fix. PHP said it will handle the issue in its next routine release, has not given a date, and promised a full advisory with that release, according to The Hacker News.

The interim guidance is to set session.upload_progress.enabled=0. That is the same workaround PHP listed for CVE-2026-109619 on Oct. 21, so anyone who already applied it needs no further action for this issue. Safeguard adds that the directive has to be set in server configuration, not with ini_set(), and that workers need a restart before the change takes effect.

No attacks against CVE-2026-115560 have been reported. The attacks that have been reported target the two earlier PHP2Shell flaws.

One caution from the Safeguard write-up: it found no NVD, CVE.org or OSV record when it checked, so a vulnerability scanner that comes back clean does not prove a server is unaffected. It is a single vendor’s blog post, and PHP’s own advisory is the authoritative source.

PHP2Shell Timeline: Exploit Attempts Began Oct. 17, Four Days Early

The third flaw landed in the middle of a messy week, and the sequence explains why owners should treat the whole cluster as one job.

Amazon’s threat intelligence team said the first exploitation attempts came on Oct. 17, four days before the patches, according to BleepingComputer. The attempts came from an IP address tied to a commercial anonymization network and hit a honeypot while the flaws were still under embargo. AWS CISO CJ Moses said the vulnerabilities are “now being broadly exploited in the wild,” and that it is unclear whether any attempts would have worked against real systems.

PHP warned administrators to prepare for emergency updates on Oct. 20, after details including the CVE IDs leaked online and the disclosure date moved up. The patches shipped Oct. 21. Per BleepingComputer, attackers launched multiple proof-of-concept exploits within hours, though PHP said none of the proofs of concept published before the patches were functional.

The size of the exposed pool is the part that matters for store owners. Qualys, drawing on more than 10,000 customer organizations, counted 167 million PHP installations, 156 million with a known version, per its advisory post updated Oct. 23. About 44 million of those (28%) run supported branches with the fix not yet applied, and 110 million (71%) run end-of-life branches. Only 199,000 were patched within 12 hours of disclosure. VirusTotal separately tracks more than 5.1 million exposed PHP hosts, per BleepingComputer.

On the defense side, AWS added a WAF rule for CVE-2026-109619 on Oct. 22 and one for CVE-2026-109618 on Oct. 23, according to the AWS security blog. AWS also said a custom rule blocking POST requests that carry both PHPSESSID and PHP_SESSION_UPLOAD_PROGRESS helps with CVE-2026-115560. Its own framing: “AWS WAF is a defense-in-depth control in this situation, not a replacement for the PHP upgrade.”

Cloudflare CTO Dane Knecht said, “We are seeing early attacks emerging and are updating mitigations as new vectors show up,” per The Hacker News.

The counterpoint is that none of the reporting I pulled shows a confirmed compromise from any of the three flaws. Dataminr’s TRACE team described scanning, fingerprinting and non-working exploits with no known compromises, and neither PHP2Shell flaw was in CISA’s known-exploited catalog when The Hacker News checked. PHP, meanwhile, rates the new one unlikely. That is a reason to keep the response proportionate, not a reason to skip it.

What CVE-2026-115560 Means for WooCommerce and Self-Hosted Stores

My read: this third flaw is a low-probability item with a nearly free fix. I would treat it as a checkbox attached to the PHP2Shell work, not a new fire.

The bigger problem it exposes is that most store owners cannot answer a simple question. Which PHP version and which settings are my web workers running right now? If that answer lives only in your host’s head, a flaw like this one turns into a guessing game on a day you do not have time to guess.

Here is hypothetical math, labeled as such. A high-ticket store averaging $2,500 orders and two orders a day books about $5,000 a day. A compromised site pulled offline for three days puts roughly $15,000 of orders at risk, and $300 a day in ad spend still sending clicks to a dead page adds another $900. The fix for this particular flaw is a support ticket and a restart.

The chargeback side matters too. A site that takes payment details while compromised, or goes dark after customers paid, creates disputes you pay for later, which is why my guide to stopping disputes before they cost you belongs on the same to-do list. Payments need a plan too, and I wrote about building a backup plan for your processor.

Four scenarios, with thresholds, cover almost every owner reading this.

Scenario one: your host is managed and confirms in writing within 48 hours that the Oct. 21 fixes are in and session upload progress is off. You are done. Managed hosts take that work off your plate, and I send people to Cloudways for it. SiteGround is the other one I point to, and you still ask for the confirmation in writing.

Scenario two: your host cannot confirm in 48 hours, or the answer is vague. That is your signal to start planning a move, and my breakdown of cheaper WordPress and WooCommerce hosts is a decent starting list. If you want to compare how WooCommerce costs stack up against a hosted platform first, read my WooCommerce pricing breakdown.

Scenario three: you run your own server. Set the flag in server configuration, restart workers, and verify the value the web workers actually see. Liquid Web sells managed server plans where the host can own the runtime for you. Scala Hosting is another managed option. In either case, get the runtime ownership in writing.

Scenario four, and the one I would worry about most: you are on PHP 8.1 or older. The Hacker News reports that those branches get no upstream updates, with minimal source backports for 7.4, 8.0 and 8.1, and Qualys puts 71% of the installs it counted on end-of-life branches. This third flaw is a footnote next to running a runtime that PHP no longer supports. Plan the upgrade to 8.3 or newer on a staging copy and test checkout, shipping and payments there first.

Plugins are a likelier door than a runtime flag. In recent weeks I covered a Rank Math PRO backdoor. I also covered how stolen UpdraftCentral keys opened WordPress stores. Both reached stores through software the owners installed on purpose, and a Ninja Forms flaw that planted hidden admins followed the same pattern.

Shopify-only owners are not off the hook for the same reason. Apps, credentials and third-party tools are where the risk lives. The case of three hijacked Shopify apps showed it. The Railway breach showed it again for stores that run side tools on that platform.

If you would rather not own any of this, my team builds and runs high-ticket stores so the infrastructure decisions are not sitting on your desk. That is the turnkey done-for-you service, and it fits owners who want the store without the server homework. If you are still picking what to sell, start with my high-ticket niches list.

Patches and host emails should not be what eats your week. Want my team to scale the store you already have while you stay out of the server room? See the scaling service →

Disable Session Upload Progress and Confirm Your PHP Version

Run these six checks in order. Most take one message to your host.

Inventory every site and tool that runs PHP: the WooCommerce store, the WordPress blog, any quote funnel, helpdesk or landing page on your own hosting. Write down who controls the PHP runtime for each one.
Email each host and ask two questions in writing. Is the runtime at 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a distribution backport that names the CVE fixes? Is session.upload_progress.enabled set to 0 where the web workers can see it?
If you manage the server, set session.upload_progress.enabled to 0 in server configuration (a php.ini file or the FPM pool or virtual host setting, never in application code), then restart the workers. Check the value from a request through the real web server, because the command line can show a different configuration.
If you are on PHP 8.1 or older, schedule the move to 8.3 or newer on a staging copy. Test checkout, shipping rates and payment capture before you flip it live.
Set up an outage plan before you need it. Put an uptime monitor on the checkout page, and my comparison of uptime monitoring tools covers the options. Draft the customer notice you would send through Klaviyo. Make sure your support inbox in Gorgias has a saved reply ready.
Put PHP’s next routine release on your calendar. PHP has given no date, so check its release announcements weekly and ask your host to confirm when the permanent fix lands.

If you want help deciding which of these your store needs, book a call through my discovery page. For the bigger picture on layers worth adding as you scale, read my guide to protecting a high-ticket store.

Frequently Asked Questions

Is my WooCommerce store exploitable through CVE-2026-115560?
Only if an application switches session.serialize_handler at runtime and keeps session upload progress on, per PHP. PHP calls that combination unusual and has seen no attacks against it, but setting session.upload_progress.enabled to 0 removes the question for about the cost of a restart.

Did the Oct. 21 PHP updates fix this flaw?
No. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix the two PHP2Shell flaws only. PHP plans a fix in its next routine release and has not given a date.

Will turning off session upload progress break my site?
Nothing I read reports breakage. The setting controls a progress readout for file uploads, so in my read the only visible effect would be on a custom upload form that relies on it, and I would test any such form after the change.

Does a store on Shopify need to do anything?
A store running entirely on Shopify’s hosted storefront has no PHP server for you to patch. Check the pieces around it: a WordPress blog, a self-hosted helpdesk or any funnel tool on your own server, and use my high-ticket Black Friday checklist to stress-test the rest before ad spend climbs.

Will a web application firewall protect me instead?
AWS calls its WAF rules defense in depth, not a replacement for the PHP upgrade, and notes the rules cannot see worker memory or server configuration. A rule can reduce exposure while you patch, and the upgrade is still the fix.

Where do I start if I am still choosing what kind of store to build?
Start with the basics in my guide to high-ticket dropshipping. Then grab my free niches list before you pick one.

Want 1-on-1 coaching to fix the weak spots in your high-ticket store before the next scare? Get the coaching details →

Subscribe to the YouTube channel for daily breakdowns. More breaking news coming through the day.

If this was useful, these go deeper:

Trevor Fenner

Trevor Fenner is an ecommerce entrepreneur and world traveler from Seattle, Washington, and the founder of Ecommerce Paradise, a platform focused on helping entrepreneurs build and scale profitable high-ticket ecommerce and dropshipping businesses. With over a decade of hands-on experience, Trevor specializes in high-ticket dropshipping strategy, niche and product selection, supplier recruiting and onboarding, Google & Bing Shopping ads, ecommerce SEO, and systems-driven automation and scaling. Through Ecommerce Paradise, he provides free education via in-depth guides like How to Start High-Ticket Dropshipping, advanced training through the High-Ticket Dropshipping Masterclass, and fully done-for-you turnkey ecommerce services for entrepreneurs who want a faster, more hands-off path to growth. Trevor is known for emphasizing sustainable, real-world ecommerce models over hype-driven tactics, helping store owners build scalable, sellable, and location-independent brands.

He maintains homes in Seattle and Bali, spends most of the year overseas, and usually returns to Seattle for about a month each summer.