PolyShell CVE-2026-48356: check and fix your Magento stores

PolyShell: what is established, where sources differ

What the sources say, and what you take from them

Scroll the table

Why the patch does not close the case

What this procedure leaves in your hands

• An inventory per store — edition (Commerce or Open Source), exact version, whether the 2026-jul fix is present.
• A target version per branch — read from bulletin APSB26-73, with no guessing at the numbering.
• A frozen state before any work — snapshot and database export kept as evidence, before any cleanup.
• Four repeatable checks — files under pub/media, accesson.php backdoors, JavaScript in cms_block and in cms_page.
• A complete credential rotation — admin accounts, API and integration keys, database, encryption key, SSH and SFTP.
• A dated status report for each client — what was checked, found and fixed, and what was not.

Affected and fixed versions according to APSB26-73

Scroll the table

Inventory the version of every store

1. 01

   Read the declared version

   cd /var/www/client-store
bin/magento --version
   The command prints the edition and the number. The path is an example: adapt it to each hosting setup. Run it as the system user that owns the files, not as root, so you do not change the cache permissions.

2. 02

   Cross-check with Composer

   composer show magento/product-community-edition
   for Magento Open Source, or
   composer show magento/product-enterprise-edition
   for Adobe Commerce. Composer reads what is actually installed. If the two readings differ, Composer is authoritative, and the gap gets recorded.

3. 03

   Sweep an entire server

   find /var/www /home -name composer.lock -not -path '*/vendor/*' -exec grep -H -A1 '"name": "magento/product-' {} +
   Each file listed belongs to a Magento installation, and the version line follows the package name. A public staging site or an old unpacked copy counts as a store: it is exposed in the same way if it is served.

4. 04

   Classify with the version table

   Compare the number you found with the table above. Reading rule: any version without the 2026-jul suffix for its branch needs action. For Magento Open Source 2.4.5 and 2.4.4, which are not in the NVD list, do not write "not affected": refer to the Adobe bulletin and treat the store as exposed until you have read otherwise.

5. 05

   Record one row per store

   Client, server, path, edition, version found, date and time of the check. Add right away the columns you will need later: fix applied, result of the four checks, credentials rotated. This table becomes the central document of the file handed to the client.

Freeze the state before touching anything: it is also evidence

Apply the fix without a long outage

1. 06

   Rehearse on a staging copy

   Restore the frozen state to a staging environment, or clone the store, and run the update there first. Time each command: that duration sets the maintenance window you announce to the client.

2. 07

   Pin the fixed version

   composer require magento/product-community-edition=<fixed-version> --no-update
   Replace the package with magento/product-enterprise-edition for Adobe Commerce, and <fixed-version> with the 2026-jul version of your branch, exactly as the bulletin writes it.

3. 08

   Resolve and validate the lock file

   composer update magento/product-community-edition --with-all-dependencies
   Review the list of changed packages. The composer.lock you obtain and test is the one you will deploy: production no longer resolves anything, it installs.

4. 09

   Open the maintenance window in production

   bin/magento maintenance:enable
bin/magento maintenance:allow-ips <your-ip>
   Everything before this point happened without stopping sales. The second command lets you test the store before it reopens.

5. 10

   Install and apply

   composer install --no-dev
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
   With a lock file already validated, the outage is limited to these four commands.

6. 11

   Reopen and verify

   bin/magento maintenance:disable
composer show magento/product-community-edition
   The installed version must be the fixed version of your branch. Place an order with the payment gateway in test mode, then record the version and time in the table.

Look for traces of compromise

1. 12

   List files dropped under pub/media

   find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
   A command published by Sansec, to run from the store root. Every file listed needs review, especially a PHP script. Copy it outside the public tree with its modification date before deleting it.

2. 13

   Search for accesson.php backdoors

   find . -name 'accesson.php' -type f
   Sansec reports this file "in multiple directories": run the search from the root, not only under pub/. An empty result proves that this particular file is absent, not that no backdoor exists.

3. 14

   Query the cms_block table

   SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
   A query published by Sansec. Add the installation's table prefix if there is one. The update_time column helps date the injection.

4. 15

   Query the cms_page table

   SELECT page_id, identifier, update_time FROM cms_page WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
   The same check on CMS pages. A result is not necessarily malicious: localStorage.getItem can appear in a legitimate script. Read the content before concluding.

5. 16

   Match against published indicators

   For the March 2026 wave, Sansec published a loader domain, lanhd6549tdhse.top, a localStorage key, 136c1e07507f4a97, and a backdoor marker, 8194460. Look for them in the previous results and in the files you found, for example with grep -rl 'lanhd6549tdhse' pub/ app/. This list is not exhaustive: their absence does not clear a store.

6. 17

   Check administrator accounts

   SELECT user_id, username, email, created, logdate, is_active FROM admin_user ORDER BY created DESC;
   An account nobody recognizes, or one created close to the date of a suspicious file, gets disabled and then documented. The monthly check of these points on each client VPS is described in our audit checklist.

Troubleshooting: common blockers during the procedure

After the cleanup: what must be rotated

• Administrator passwords — every account in admin_user, including the ones you consider sound.
• API keys and integrations — tokens of the integrations declared in the admin, keys for third-party services (payment, shipping, ERP) stored in the configuration.
• Database credentials — a new password, updated in the store configuration.
• Encryption key — to be changed following the Adobe documentation, after assessing the effect on data that is already encrypted.
• SSH and SFTP access — passwords, authorized SSH keys, unknown system accounts.
• Hosting access — control panel and backups, which also give access to the files.

The dated status report to hand to each client

Scroll the table

What you keep, and the sources to cite