PHP2Shell and OpenCart: What Store Owners Need to Do

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog. We found no PHP2Shell statement from the OpenCart project as of 23 October 2026.

The direct answer: an OpenCart store is exposed if the PHP running it is unpatched. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of bugs in PHP itself, and OpenCart is a PHP application. No OpenCart release or extension can fix that. Get a patched PHP build onto the server and restart it.

Because OpenCart has said nothing official, this guide sticks to what can be checked: what OpenCart has published, what PHP its current releases accept, who patches, and which OpenCart habits need care. For the wider online-store picture, see PHP2Shell for online stores.

What OpenCart Has Said

As of 23 October 2026 we found no PHP2Shell statement from OpenCart. Here is where we looked:

• The OpenCart releases page on GitHub. The latest releases, 4.1.0.4 and 3.0.5.1, are both dated 11 August 2026. Neither mentions PHP2Shell, which was fixed by PHP on 21 October.
• The OpenCart issue tracker on GitHub, searched for "CVE-2026-109618" and "php2shell." No results.
• The opencart.com blog and the OpenCart forum, which returned access errors when we checked, so their status is unknown rather than "none."

No statement is not a sign of a problem with OpenCart. Vendors that did publish, such as WooCommerce and PrestaShop, all said the same thing: updating the store software does not fix it. Check the OpenCart site and forum in case something has been posted since.

Was OpenCart Tested by the Researchers?

No. Calif confirmed unauthenticated remote code execution against 11 PHP applications, including Magento, WordPress and WHMCS. Wiz demonstrated its attacks against WordPress, Drupal and Joomla. OpenCart appears on neither list.

The Dutch National Cyber Security Centre's PHP2Shell software list marks OpenCart as "Vulnerable," but with a generic note that applies to most PHP applications: affected when deployed on an affected PHP runtime. It is an inference from "it runs on PHP," not a confirmed OpenCart bug. The list itself says its entries "should still be treated as investigation leads until they are backed by an upstream or vendor source."

What PHP Does OpenCart Run On?

We could not find an official OpenCart requirements page to cite. What OpenCart's own code shows:

The PHP minimums come from the composer.json file in each release (see the 4.1.0.4 package file), which declares "php": ">=8.1.0" for 4.1.0.4 and "php": ">=8.1" for 3.0.5.1. That is a package constraint, not a published support policy.

The practical point is PHP 8.1. It is the floor for current OpenCart, so many stores will be running on it. PHP says "PHP 8.1 and older no longer receive updates from the PHP project," although it published source-only backports and some distributions and long-term support vendors ship patched builds. Stores on 8.1, or on older OpenCart versions that need PHP 7.x, should ask their host whether their build includes the fix. Our guide to PHP2Shell on PHP 8.1 explains where those builds come from.

If you can move to a newer PHP, test your theme, payment extensions and checkout on a staging copy first. PHP 8.2 reaches end of life on 31 December 2026, so 8.3 or newer is the better target.

Who Patches PHP for Your Store

If your store is on shared hosting, you can't patch PHP yourself. Our guide to PHP2Shell on shared hosting covers what to ask and how to switch PHP versions safely in a control panel.

If you manage the server, a generic example for Debian or Ubuntu with PHP-FPM (replace 8.3 with your version):

sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm

On Apache with mod_php, restart Apache instead. Old PHP workers keep running the old code until they are replaced.

How to Check Your PHP Version

We did not find OpenCart documentation that names an admin screen showing the PHP version, so use these:

1. Your hosting control panel, which usually shows the PHP version per site or folder.
2. Your host's support team, by ticket so you have the answer in writing.
3. Over SSH, php -v. The command-line PHP can be a different version from the one the web server runs, so confirm which PHP serves your store.

Treat the number with care. Linux distributions often backport fixes without changing the version, so a patched server may still show an older release. Our guide on how to check your PHP version explains how to confirm a fix through the package changelog.

Per-Directory PHP Settings Are Not Protection

OpenCart's install notes deal with PHP settings in several ways: they ask you to enable extensions in php.ini, and they note that on some hosts you may need to rename php.ini to user.ini. On shared hosting, PHP settings can end up spread across several per-directory files.

That matters for PHP2Shell in two ways:

• Mitigations in the wrong place don't work. PHP's advisory says to set them in "php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini." A setting in .user.ini is applied too late.
• Bad settings can be part of the problem. One confirmed path for CVE-2026-109619 involves per-request settings that produce a warning or deprecation early in the request. PHP's mitigation is to "Remove invalid or deprecated settings applied per request that emit diagnostics before initialization." On Apache with mod_php, that includes php_value lines in .htaccess.

Ask your developer or host to review per-directory PHP settings and remove any that are invalid or deprecated for your PHP version. For the official stopgap settings and what they can break, see our guide to PHP2Shell interim mitigations. If you lower upload limits, test product image uploads and a full checkout afterward.

Why Extensions Can't Fix It

OpenCart extensions, including security extensions, run as part of OpenCart. On Apache with mod_php, PHP's advisory says the first flaw is reached "entirely before any application-specific code begins execution." Nothing installed in OpenCart can stop it. Extensions still matter for general security, since each one is code you must trust and update. Our guide to plugin, app and package security covers how to keep that list short and current.

A WAF run by your host or a CDN can filter attack traffic while you patch. It is an extra layer, not a fix.

Payment Keys, Backups and Going Offline

Wiz warns that memory leaked through PHP2Shell "may contain passwords, authentication tokens, API keys and certificates." For a store, that can include payment extension credentials. After PHP is patched and restarted, review your logs from 17 October 2026 onward. If you find signs of compromise, or can't rule it out, rotate payment API keys and admin passwords. Our guide on whether your site was hacked lists what to look for. A clean backup taken before any changes makes recovery easier; see our guide to website backups and recovery.

If your store runs on PHP 8.1 or older and your host can't confirm a patched build, CISA says organizations in that position "should take PHP-based systems offline until they can be patched or updated." Use a maintenance page or network restriction rather than disabling the PHP handler, which Beazley warns "can expose application source code and credentials."

OpenCart PHP2Shell Checklist

Conclusion

As of 23 October 2026, OpenCart has published nothing on PHP2Shell, and it doesn't need to for you to act: the fix is a patched PHP build on your server, restarted, whatever OpenCart version you run. Confirm it with your host in writing, pay special attention if you are on PHP 8.1, keep stopgap settings out of .user.ini, and protect your payment keys if anything looks wrong. If you run your own server and need help patching quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions