Current situation: PHP2Shell. Two critical PHP vulnerabilities (CVSS 9.2) allow malicious code without login. Patches since 21 October 2026.What to do now →

Magento Vulnerability PHP2Shell: Securing Magento and Adobe Commerce

PHP2Shell hits Magento through PHP. Besides the patch and restart, what matters most with Magento is env.php, skimmers in the database and hidden admin accounts.

Last updated 4 min readPlatforms

In short: The current Magento vulnerability is called PHP2Shell and is not in Magento but in PHP. A Magento patch does not close it. After the PHP update with a restart, you should check app/etc/env.php, the database for skimmers and the list of admin accounts.

What PHP2Shell means for Magento shops

Magento Open Source and Adobe Commerce are large PHP applications that usually run with PHP-FPM. According to the PHP team, the flaws CVE-2026-109618 and CVE-2026-109619 allow code execution without authentication. Whether the shop itself is up to date plays no role here.

For years, Magento shops have been a preferred target for credit card skimming, in which entries in the checkout are read. PHP2Shell opens another path for this. Palo Alto Networks counted more than 22.6 million exposed, potentially vulnerable PHP instances; which shops are among them is not known.

Magento vulnerability: determining the PHP status correctly

Magento does not show the PHP version prominently in the admin. Check the status in the hosting panel for the domain, or have your host confirm it. php -v on the command line shows only the CLI PHP, which bin/magento and cron jobs run on. The web PHP via FPM can be a different version, and both must be patched.

Fixed upstream versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; distribution backports can carry older numbers. Which PHP versions your Magento version supports can be found in the system requirements in Adobe's documentation (experienceleague.adobe.com). For Adobe Commerce on Adobe infrastructure, ask Adobe or your operator for the status. A step-by-step guide is provided by Checking the PHP version and patch level correctly.

Where malicious code sits in Magento

Location Content What to check
app/etc/env.php Database, encryption key, admin path Modification date, renew values if you suspect an incident
pub/ Document root, pub/media, pub/static PHP files in media and static folders
app/code/ Custom modules Unknown modules, modified files
vendor/ Composer packages, including extensions Deviations from the lockfile
generated/, var/ Generated code, cache, logs Secure the logs, regenerate the code
Database Configuration, CMS blocks, admin users Foreign scripts, new admins

In Magento, skimmers are often in the database, for example in the settings for additional scripts in the page header or footer and in CMS blocks. A pure file scan misses them. Harmless read-only queries help with a first look (table prefix depends on the installation):

bin/magento info:adminuri
bin/magento module:status
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
Important

A cleaned checkout does not mean that no data was exfiltrated. Secure logs from 20 October 2026 onward and database dumps before you remove scripts. Only then can it be established later from when and which orders were affected.

Admin area and extensions

In Magento, the admin path can be chosen freely and is stored in env.php. A path that is hard to guess is sensible, but it does not replace two-factor authentication or a restriction to known networks. Check the admin users and their roles regularly, as well as integrations and API tokens.

Third-party extensions are numerous in Magento: payment methods, ERP connections, search and marketing modules. Each brings code that has to be checked during PHP upgrades. Use composer audit regularly and remove disabled modules completely.

Also think of the background processes. Magento works with cron jobs and often with queue consumers that run as their own PHP processes on the command line. After the PHP update, these must restart just like PHP-FPM. After a switch of the PHP major version, you should also have the generated code in generated/ and the static files rebuilt and click through the shop in a test environment before live operation resumes. How to do the restart cleanly is described in Restarting PHP-FPM and all workers.

What a Magento update can and cannot do

A Magento release or security patch from Adobe closes flaws in the shop code. It does not patch PHP, does not restart FPM processes, does not remove scripts from the database and does not delete foreign admin accounts. If code has already been executed, an investigation is needed. How to recognise backdoors is explained in Detecting and removing webshells.

For merchants accepting card payments, the following also applies: check your payment provider's requirements for security incidents and coordinate with it before renewing keys. Whether a report to the data protection authority is necessary should be clarified with your data protection officer or lawyer.

How does PHP SOS help?

  • We clarify the web and CLI PHP of your Magento server and have the patch and restart confirmed.
  • We secure logs, files and database in a traceable way, where needed through our IT forensics.
  • We check env.php, pub/, modules, configuration tables, CMS blocks and admin accounts.
  • We clean up, renew keys and access credentials, and document the period of possible impact for data protection and the payment provider.

Frequently asked questions

Does a Magento security patch also close PHP2Shell?

No. Magento patches fix flaws in the shop code. PHP2Shell sits in the server's PHP interpreter and is closed only by a PHP update or a confirmed backport, with a restart of all processes.

Where do attackers hide credit card skimmers in Magento?

Often not in files but in the database, for example in the settings for additional scripts in the page header or in CMS blocks. That is why a check of the database is always part of the process after a suspicion.

Who patches PHP for Adobe Commerce in the cloud?

That depends on your contract and your environment. Ask Adobe or your operator in writing about the PHP status and the restart. Custom extensions and database content remain your responsibility.

Why is app/etc/env.php so important?

The file contains the database credentials, the encryption key and the path to the admin area. Anyone who could read it can decrypt encrypted values and find the admin. If you suspect an incident, these values should be renewed.

Sources

Immediate contact

Every hour counts. Write to us now.

Briefly describe your system, PHP version and observation. We will get back to you, clarify the situation and work remotely until the incident is closed and documented.

Immediate help