PHP2Shell and Magento / Adobe Commerce: What 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 Adobe for Magento Open Source or Adobe Commerce as of 23 October 2026.

The direct answer: a Magento store is exposed if the PHP running it is unpatched, whatever Magento version or patch level you are on. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of bugs in PHP itself. Researchers used Magento to prove the attack works, so act quickly. The fix is a patched PHP build plus a restart, not a Magento patch.

This guide covers which PHP each Magento release line runs on, which lines are stuck on end-of-life PHP, who patches on self-hosted servers and on Cloud, and what to test if you use temporary mitigations. For the general Magento security picture, see our Magento and Adobe Commerce security guide.

Was Magento Named by the Researchers?

Yes. Calif, which reported the first bug to PHP, writes: "We confirmed pre-auth RCE on the following PHP apps." The list includes Magento 2.4.9, alongside WordPress, Drupal and eight others. "Pre-auth RCE" means an attacker with no login can run their own commands on the server.

Wiz, the other main research team, demonstrated its attacks only against WordPress, Drupal and Joomla. Being named is not the same as Magento having a bug: Magento's code is not at fault, and a newer Magento patch release does not fix PHP2Shell.

What Adobe Has Said (and Where We Looked)

As of 23 October 2026 we found no Adobe statement for PHP2Shell. Adobe's security bulletin index returned an access error when we checked, and neither the Commerce on Cloud patch release notes nor the system requirements page mention it.

Two general Adobe statements still apply:

• Adobe's lifecycle policy says: "Adobe does not provide security and quality fixes for third-party services and software dependencies (such as PHP and MySQL) that may reach end of life while customers are in the three-year or extended support period for Adobe Commerce." It adds: "You are responsible for monitoring the support status of PHP versions used in your environments."
• The same page warns that running PHP 8.1 past its end-of-life date "puts PCI compliance at risk," and that PCI compliance "is the merchant's responsibility to assess."

If Adobe publishes guidance, follow it over anything here.

PHP by Magento Release Line

Adobe's system requirements (last updated 13 October 2026) list one or two PHP branches for each release line. Support dates come from Adobe's released versions page.

The problem rows are 2.4.4 and 2.4.5, which have no PHP option the PHP project still updates. PHP says "PHP 8.1 and older no longer receive updates from the PHP project," though it published source-only backports and some distributions and long-term support vendors ship patched builds. If you run PHP 8.1, ask your host whether their build includes the fix. Our PHP2Shell fixed versions page lists distribution packages by branch.

Upgrading a 2.4.4 or 2.4.5 store is the long-term answer, but it is a project, not an emergency patch. Get a patched PHP build first.

Who Patches: Self-Hosted vs Adobe Commerce on Cloud

On Adobe Commerce on Cloud, you choose the PHP version in your project's .magento.app.yaml file, in the form type: php:<version>, according to Adobe's Cloud PHP settings documentation. Adobe's shared responsibility model says "merchants must stay on versions compatible with their deployed Adobe Commerce release" and "Merchant must maintain PHP on a supported version."

We could not verify whether Adobe applied the PHP2Shell fix to Cloud PHP builds in place or whether merchants need to redeploy. Don't assume either. Ask Adobe support, and keep their answer on file.

How to Check Which PHP Your Store Runs

We did not find an Adobe document that shows the PHP version in the Magento admin. Use one of these instead:

1. Ask your host or check your hosting control panel.
2. Over SSH, run php -v, which Adobe's install guide uses to verify PHP. On Cloud, Adobe documents checking settings over SSH with php -i.
3. Confirm the web server uses the same PHP. The command-line PHP can be a different version from the one PHP-FPM or Apache runs.

Distributions backport fixes without changing the upstream number, so a patched server may still report an older 8.x release. The reliable check is the package changelog or your host's written confirmation. Our guide on how to check your PHP version walks through each method.

Why Magento Patches and Extensions Can't Fix It

Adobe's security patches fix Magento code, not PHP. On Apache with mod_php the first flaw is reached "entirely before any application-specific code begins execution," according to PHP's advisory. Extensions, admin hardening and in-application security tools all run later.

Sansec, a security firm that specializes in Magento, says so about its own product: "The RCE and memory-disclosure paths run inside PHP, before your store code and before Sansec Shield. Do not wait for a Shield rule to protect you. Update PHP." It also notes that "you cannot fix PHP2Shell from within your store code."

Testing Temporary Mitigations on a Magento Store

If PHP can't be patched today, PHP's advisory lists settings that make the known attacks harder but "do not make an installation safe." Our guide to PHP2Shell interim mitigations covers them. On Magento, three need extra care:

• Blocking multipart requests. Sansec warns that "The rule breaks file uploads, such as product images in the Magento admin. Some stores submit cart or checkout forms as multipart, so place a test order after you add it."
• Lower post_max_size. PHP suggests 8M for sites without uploads and 32M with them. Product images and catalog imports may need more, so test admin uploads.
• memory_limit=-1. Adobe already recommends 1G for compiling code or deploying static assets. Removing the cap means one request can use all server memory, so PHP says to pair it with a container or cgroup limit, never RLIMIT_AS or RLIMIT_DATA.

Set mitigations in php.ini, the PHP-FPM pool or server configuration, not in .htaccess, .user.ini or application code. PHP says: "Do not rely on ini_set() or FPM .user.ini."

Restart Everything, Then Check for Compromise

A fixed package does nothing until the old PHP processes are gone. Restart PHP-FPM or Apache on every server that runs your store, and ask your developer which long-running PHP processes need restarting too. A generic example for Debian or Ubuntu (replace 8.3 with your version):

sudo systemctl restart php8.3-fpm

See our guide to restarting PHP workers.

Then look back. Wiz warns that leaked memory "may contain passwords, authentication tokens, API keys and certificates." If you see signs of compromise, or can't rule it out, rotate payment gateway credentials and integration tokens after patching, not before. Our guide on whether your site was hacked explains what to look for, starting no later than 17 October 2026.

Should You Take the Store Offline?

Advice differs. CISA says organizations that "cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." Sansec's view is "You do not need to take your store offline," and it reports that a researcher found the public proof-of-concept exploits don't work against a default PHP install. Calif, on the other hand, calls the bugs "always exploitable under default configurations." That disagreement is unresolved, so we follow the official advice: if your store runs on PHP 8.1 or older, or you can't patch soon, plan a maintenance window. Use a maintenance page or network restriction rather than disabling the PHP handler, which Beazley warns "can expose application source code and credentials."

Conclusion

As of 23 October 2026, Magento 2.4.9 is a confirmed PHP2Shell target, Adobe has published no PHP2Shell statement we could find, and the fix is a patched PHP build, not a Magento patch. Find out which PHP your store really runs, get a patched build in place and restarted, get written answers from your host or Adobe support, and treat stores on 2.4.4 or 2.4.5 as the most urgent. If you need help patching a self-hosted store quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions