PHP2Shell Exploitation Confirmed: Patch Your Store Hosts

A researcher’s honeypot recorded working remote code execution through the PHP2Shell flaws, BleepingComputer reported on Oct. 26.

If your store, your blog, your quote-request form or any tool you host yourself runs on PHP, your host’s PHP version just became a revenue question. WordPress and WooCommerce both run on PHP, and so does most of the budget hosting where store owners park their content sites. I track this stuff at Ecommerce Paradise because a dead checkout page during a traffic spike costs more than any patch ever will.

I covered the emergency patch and the unpatched third flaw earlier this week. Until Saturday the story was scanning and probing. Now there is documented, working exploitation on a test server, and the fix has been available since Oct. 21. Below: what the data shows, where the sources disagree about scale, what it does to a store doing real revenue, and the checks I’d run before Black Friday traffic arrives. Storefronts hosted by Shopify sit outside this reporting. Everything else you run yourself does not.

A store breach is a customer-trust and legal problem as much as a technical one, and the LLC that owns the store is where that exposure should sit, so form yours with Northwest Registered Agent, the best LLC formation service for ecommerce owners. Northwest forwards physical mail to operators who live outside the formation state or country, which is where cheap formation sites that upsell tend to fall down. Form your LLC with Northwest →

Perplexity Researcher’s Honeypot Shows PHP2Shell Remote Code Execution

According to BleepingComputer’s Sergiu Gatlan, Adel Karimi, detection and response lead at Perplexity, reported that his honeypots recorded confirmed remote code execution against an Apache mod_php installation running PHP 8.4.26. The server’s response contained an 800 KiB decoded cookie dump. A function address derived from that dump, using the public exploit’s offsets, showed up in a later execution payload.

Karimi attached a limit to his own finding. He said the evidence reflects “the intentionally favorable single-worker mod_php profile” and does not measure how reliable the attack is across other worker counts, PHP builds or applications.

Marcus Hutchins of Expel confirmed the findings, calling them “by far the highest quality confirmation” of in-the-wild exploitation he had seen, per BleepingComputer. Security magazine reported the evidence sits in a GitHub honeypot-data report dated Oct. 24. Steve Povolny of Exabeam told the magazine the flaws moved from scanning to confirmed code execution on a honeypot within days of the patches. His line: “Patching closes the door. It doesn’t tell you who is already inside.”

The two flaws are CVE-2026-109618 and CVE-2026-109619. watchTowr’s write-up scores each 9.2 on CVSS v4.0 and says an attacker needs only network access to the server, with no account and no login. The fixes shipped Oct. 21 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Every way of serving PHP web requests is in scope, according to watchTowr: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache mod_php carries the highest demonstrated risk because an attack can succeed before any application code runs. PHP 8.1 and older get only minimal source backports from PHP, and PHP 7.3 and older get nothing.

One more piece of status. SOCRadar’s tracker noted that as of Oct. 23 neither CVE was in CISA’s Known Exploited Vulnerabilities catalog. BleepingComputer says CISA shared a detection rule on Oct. 23 but had not yet flagged the flaws as exploited. That may change once agencies digest the honeypot report.

PHP2Shell Timeline: Leak, Patch and Attacks Since Oct. 17

Amazon Threat Intelligence says the first exploitation attempts came on Saturday, Oct. 17, four days before the patches, according to BleepingComputer’s earlier report. Details leaked on Oct. 20 and PHP pulled its release forward a day. AWS CISO CJ Moses said defenders “should not assume the public disclosure date is the earliest date of exploitation.”

Hosting companies saw trouble early. Recorded Future’s Insikt Group cites Patchstack saying hosting partners had flagged multiple active exploitation incidents by 07:34 UTC on Oct. 21, hours before PHP’s fix landed. Cloudflare’s CTO, Dane Knecht, reported early attacks and Cloudflare added WAF protections.

Exposure is large and old. Recorded Future cites a Modat scan of 4,384,302 PHP services on 1,886,612 hosts, with about 79% of version-reporting services on unsupported branches. A VirusTotal scan found about 5.1 million IPs running PHP, but only about 1.1 million disclose a version. Of those, roughly 758,000 run end-of-life branches and roughly 272,000 run supported ones.

On Oct. 23, PHP published an advisory for a separate issue, CVE-2026-115560, that the Oct. 21 releases do not fix. I broke that down in my post on the third flaw. Exploiting it needs an unusual combination of configuration and application code, and no attacks against it have been reported.

The sources disagree on scale, and you should know that before you plan around any one headline. Amazon says PHP2Shell is “now being broadly exploited in the wild.” Dataminr’s TRACE team said activity was limited to scanning, fingerprinting and non-working exploits, with no known compromises, until Karimi’s findings. PHP’s security team said none of the proof-of-concept exploits published before the patches were functional. Recorded Future notes one researcher’s proofs of concept rested on a theory later invalidated.

A related claim also got walked back. SOCRadar reports that Unit 42 retracted its Oct. 23 report tying a European government agency intrusion to PHP2Shell, saying it could not confirm initial access came from either CVE.

The counterpoint deserves its space. TechRadar argued the internet is not dying: fixes exist, major sites were likely patched fast, visitors need to do nothing, and the risk concentrates in sites on PHP 8.1 or older. It also says there is “no cast-iron guarantee” every site is patched. Press accounts relayed by Hackernoon add that AI-assisted analysis found the flaws, which the outlet did not independently verify. If that holds, the gap between disclosure and working exploit will keep shrinking.

What PHP2Shell Means for WordPress and WooCommerce Store Owners

My read is that this is a hosting-ownership problem wearing a security costume. The patch is free. The failure mode is nobody knowing who is responsible for the PHP version on the machine serving the site.

Start with who is exposed. A Shopify-hosted storefront runs on Shopify’s infrastructure, and none of the reporting I read ties PHP2Shell to it. Your exposure is everything else: the WordPress blog that drives your organic traffic, a WooCommerce store, the landing page on a cPanel account, the quote-request site, the self-hosted helpdesk, the supplier-feed tool someone built years ago. In high-ticket dropshipping those side properties often feed the leads, and a single sale carries real margin, so a dead lead form costs more than a dead page on a cheap-product store. If you are new to the model, start with my guide to high-ticket dropshipping.

Here is rough math, and it is hypothetical. Say a store does $60,000 a month, or $2,000 a day. Three days offline for cleanup is $6,000 in lost sales. If you keep paying for ads that send people to a dead page at $150 a day, add another $450. Cleanup help and a possible card-processor review sit on top of that. Now imagine the same outage in Black Friday week, when a normal day can run several times higher. The patch takes an afternoon.

The deeper risk is what an attacker finds on the machine. Remote code execution means commands run as your web server. Assume any secret that server can read is readable: payment gateway keys, SMTP credentials, supplier API tokens, admin cookies. The recent Railway breach is the model for what comes next if you suspect a compromise, because the cleanup is mostly rotating keys.

Three scenarios, with thresholds. If your host confirms in writing that the PHP serving web requests is 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer and workers were restarted, your PHP2Shell risk is low and your job is watching logs. If your host is on PHP 8.1 or older, treat the site as exposed no matter what the dashboard says, because PHP itself ships only minimal backports there. If you run your own VPS, nobody else is coming, and today is the day.

Fixing PHP does not fix the plugins. The last two weeks produced the Rank Math PRO backdoor. They also produced the stolen UpdraftCentral keys. Both hit WordPress stores through the app layer.

WordPress and plugin updates will not touch the PHP runtime either, per SOCRadar, so you watch two layers at once. My longer piece on protecting a high-ticket store covers the full stack.

I would not panic-migrate. If your host answers the written question fast and the answer is good, stay put. If it dithers, that tells you what you need to know.

If you do shop around, get a quote from Cloudways. Then get one from ScalaHosting.

My ScalaHosting vs Cloudways comparison shows how they differ. Already on SiteGround? The SiteGround alternatives post lays out the options before you decide to stay or go.

There is a bigger decision under this one. Every self-hosted PHP property you keep is a server you are responsible for. Some store owners should shrink that surface by moving the store onto Shopify and keeping only the blog on WordPress. Others should keep WooCommerce and pay for a host that treats patching as its job. What I would not do is leave it as a vague someday task.

If you want the whole operation, hosting included, run by people who live in it daily, that is what my team’s turnkey done-for-you service exists for. Already have a store that works? The scaling service is the route where my team grows it for you.

Want to work through your hosting and security checklist with other store owners and me inside the community? Join the Skool community →

PHP2Shell Checklist for Store Owners Before Black Friday

Six moves, in this order. None needs a developer, and the first two take about an hour.

List every PHP property you own. Include the WordPress blog, the WooCommerce store, old landing pages, the quote form, any helpdesk or feed tool you host, and any subdomain nobody remembers. Write down who controls the server for each one.
Email each host and ask three things in writing. What PHP version serves web requests, not the command line? Does it include the Oct. 21 fixes (8.5.12, 8.4.27, 8.3.36 or 8.2.35)? Were PHP workers restarted after the update? Keep the answers. In WordPress, Tools, Site Health, Info, Server shows the PHP version your site sees, but it will not tell you whether a vendor backport is in place.
If you control the server, update PHP and restart every worker today. Then review web logs from Oct. 20 onward for requests you do not recognize, and check for admin users or files you did not create. Per Recorded Future, exploitation may have begun before the patch, so Oct. 20 is the right starting date.
If you run PHP 8.1 or older, schedule the move. Test checkout, shipping rates and payment capture on a staging copy of the site first, and read my hosting at scale guide before you commit. A managed plan from Liquid Web is a fair third quote. Take a full backup before you touch anything.
Rotate secrets if anything looks off. Payment gateway keys, SMTP passwords, supplier API tokens and every admin login. Then confirm your processor can still pay you if a review starts, using my payment processor backup plan.
Build the outage plan before you need it. Set uptime alerts using my uptime monitoring roundup. Then draft a customer notice you can send from Klaviyo.

If you want a second set of eyes on how your sites, payments and ads fit together before the holiday rush, book a discovery call. Pair this with the Black Friday stress test checklist and the worst week of the year gets a lot less scary.

A messy outage also tends to produce angry buyers and disputes, so my write-up on stopping chargebacks is worth a read this week.

Frequently Asked Questions

Is my Shopify store affected by PHP2Shell?
None of the reporting ties PHP2Shell to Shopify-hosted storefronts, which run on Shopify’s infrastructure. Your exposure is any PHP site you host yourself, plus the apps you connect. Shopify has also asked app developers to tighten security, which I covered in the app security guidance post.

Does updating WordPress or my plugins fix it?
No. SOCRadar says updating WordPress or plugins does not fix PHP, and the host or administrator has to update the runtime. Do both, because plugin backdoors are a separate threat.

Does disabling session upload progress protect me?
Not fully. watchTowr says PHP states no configuration change fully closes the vulnerability. The setting is a useful interim step for the unpatched third flaw, CVE-2026-115560, but it is not a substitute for the Oct. 21 update. The release and the first probing are in my PHP2Shell patches post.

Is PHP2Shell on the CISA exploited list?
As of Oct. 23, SOCRadar reported neither CVE was in CISA’s Known Exploited Vulnerabilities catalog, and BleepingComputer said CISA had not yet flagged them as exploited. Check CISA’s catalog directly, since the honeypot report may change that.

Should I switch hosts because of this?
Only if your host cannot confirm the PHP version in writing or is stuck on 8.1 or older. A host that patched within days is doing its job. If you do shop around, SiteGround is one name on a short list worth comparing against what you pay now.

Do I have to tell customers if my site was hit?
If you confirm a compromise that exposed customer data, breach-notification laws can apply depending on where your customers live. I’m not a lawyer, so talk to counsel and your payment processor before you send anything. A help desk such as Gorgias helps you handle the reply volume once the notice goes out.

Can I just wait for the next scheduled maintenance?
I wouldn’t. Amazon reports attempts started four days before the patch existed, and Patchstack’s hosting partners flagged incidents hours before it landed. Waiting a month is a long time on that clock.

Would you rather never think about PHP versions at all? Let my team build and run your high-ticket store. See the turnkey done-for-you service →

That is the read for today. I’ll keep watching whether CISA adds these flaws to its exploited list and whether PHP ships the fix for the third one. 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.