Security Advisory: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) – Please check your hosting

On 21 October 2026, the PHP security team released emergency security patches for two critical remote code execution vulnerabilities, tracked collectively as PHP2Shell. Both are rated CVSS 9.2 by the vendor.

Is my Zen Cart store affected?

This is not a Zen Cart bug, and it can’t be fixed by updating Zen Cart or your plugins. The vulnerability is in PHP itself, the software your site runs on. It affects all PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, and the risk is highest for mod_php, where an unauthenticated request can trigger exploitation before any application code runs. In short, if your store runs on unpatched PHP, it is at risk.

What we’ve done

The Zen Cart support site and our ping/servermanager infrastructure have already been patched.

What you need to do

Find out which PHP version your store runs on (Admin → Tools → Server/Version Info).
Make sure your host has applied the fix. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or your host’s vendor backported packages.
If you’re on shared hosting, contact your host today and ask them to confirm in writing that the PHP2Shell patch has been applied.
If you’re on PHP 8.1 or older, treat this as the push to upgrade. PHP 8.1 and older are no longer supported by the PHP project; distributions and LTS vendors may provide backported packages, but that is a stopgap, not a long-term solution.

Running your own Debian or Ubuntu server on older PHP?

Ondřej Surý’s repository (packages.sury.org) has published PHP2Shell backports for end-of-life branches all the way back to PHP 5.6, so a normal apt update && apt upgrade should get you protected without changing PHP versions. Two things to know:

The patched packages keep the old version number, so php -v will still show e.g. 7.4.33. Check the package changelog for CVE-2026-109618 / CVE-2026-109619 to confirm you have the fix.
Restart PHP-FPM/Apache afterwards. Running workers keep using the old code until they’re restarted.

This buys you time, but it is not a substitute for moving to a supported PHP version. If you’re on shared hosting, you can’t apply this yourself; ask your host instead.

A big thank you to Ondřej, who maintains these packages as a volunteer and isn’t employed by the PHP project. A huge number of servers are safer this week because of his work.

Don’t wait on any of this. Cloudflare reported observing early attacks targeting these flaws even before the patches were released.

The growing threat from bots

PHP2Shell is part of a wider pattern. The time between a vulnerability being disclosed and attackers using it has collapsed; this incident illustrates the extremely shortened window between disclosure and active exploitation. Much of that speed comes from automated, increasingly AI-driven bots. They:

scan the whole web around the clock, so no store is too small to be found;
pick up newly published vulnerabilities within hours, not weeks;
probe for outdated add-ons, weak or reused admin passwords, exposed admin folders and leftover install or backup files;
generate heavy junk traffic (fake accounts, card testing, scraping) that can slow your store down even when they don’t get in.

The practical upshot: assume your store will be probed, and keep PHP, Zen Cart and your plugins up to date as a matter of routine, not just when there’s a headline.

Protecting your store with a WAF

A Web Application Firewall (WAF) in front of your store is now a sensible baseline. Cloudflare is one popular option; even its free tier offers bot filtering and rate limiting, and Cloudflare had already deployed WAF rules designed to block known PHP2Shell exploitation methods. Other providers and host-level WAFs offer similar protection.

One important caveat: a WAF is an extra layer, not a replacement for patching. PHP core developers have warned that no PHP2Shell mitigation will fully block potential attacks, and that applying the official security patches is the only permanent defence.

What Zen Cart is doing

We know the threat landscape has changed, and we’re changing with it. The Zen Cart team is treating security issues as a top priority and will respond to new threats as quickly as we can, whether that’s patching our own infrastructure, releasing fixes for Zen Cart itself, or getting clear guidance out to you here on the forum when an issue (like this one) sits outside Zen Cart. Please keep an eye on the announcements forum, and make sure you’re subscribed so you hear from us promptly.

If you have questions about your setup, please post in the appropriate support forum rather than replying here.