PHP2Shell and Magento: is your Magento or Adobe Commerce store affected?

Is my Magento store affected by PHP2Shell?

Your Magento or Adobe Commerce store is affected if the PHP it runs on is below the fixed release for its branch, or is PHP 8.1 or older without a vendor patch. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of flaws in PHP itself, so the Magento edition, extensions and patch level don’t change whether you are in scope.

Magento has been tested specifically. Sansec reports that researchers confirmed unauthenticated remote code execution against Magento 2.4.9. That was a research result, not a confirmed attack on live stores. Sansec also warns that Magento stores are exposed even when their own code is clean, and Cloudflare saw attack attempts against PHP sites before the patch was out.

Does installing a Magento or Adobe Commerce patch fix PHP2Shell?

No. Adobe’s security patches and Magento upgrades change Magento code, not the PHP runtime underneath it. Keep applying them, but the PHP2Shell fix comes only from updating PHP to a fixed release or your vendor’s patched package.

We found no Adobe security bulletin, Experience League note or other public Adobe statement about PHP2Shell as of 22 Oct 2026. Adobe’s security bulletin index refused our automated access, so check it yourself for anything newer.

How do I find the PHP version Magento runs on?

Check on the server, because that is where the version that matters lives:

• Command line: over SSH, as the Magento file-system owner, run php -v. This is the PHP that runs bin/magento, cron and the queue consumers.
• Web server: the storefront is usually served by PHP-FPM, which can be a different build from the command-line PHP. Check the FPM version too, or ask your host which PHP version serves the store.
• Adobe Commerce on cloud infrastructure: .magento.app.yaml sets the PHP branch (for example 8.4), not the patch level. Check php -v over SSH in each environment.

Enter the version in the PHP2Shell checker to see whether it is fixed. More methods: check PHP version.

Which PHP version should my Magento store move to?

Stay on a PHP branch that Adobe supports for your Magento release, and move to the fixed release on that branch. Adobe’s system requirements list these combinations:

PHP 8.1 gets no new release from PHP. Some vendors patch it: for example, Ubuntu shipped a fixed php8.1 package for 22.04. Otherwise, upgrade Magento to a release that supports PHP 8.2 or newer. See PHP end of life.

Who updates PHP for my Magento store?

It depends on where the store runs.

After the update, restart PHP-FPM and anything long-running: cron and Magento queue consumers keep running on the old PHP until you restart them. Then check the version again.

How do I tell if my Magento store was already compromised?

Updating PHP stops new attacks but says nothing about the past. On a Magento store, check:

• Admin users: accounts you don’t recognise under System → Permissions → All Users.
• Unexpected PHP files: .php files in pub/media or pub/static, which should hold only assets.
• Injected scripts: unknown code in Content → Design → Configuration (HTML head and footer) or in CMS blocks, where payment skimmers are often hidden.
• Code changes: recently modified files in app/code, vendor or app/etc that no deployment explains.

If you find something, follow the full compromise checklist before cleaning up, then rotate admin, database and payment integration credentials.

Does a WAF or a PHP setting protect Magento until I patch?

Neither is a fix. A WAF can block known attack patterns, but attackers were seen changing their requests to get around them. Magento security extensions run on top of PHP, and PHP has confirmed at least one attack path that runs before any application code. PHP’s official stopgaps only block specific paths; see the CVE-2026-109618 workaround for what they do and their limits. Plan the PHP2Shell patch now.