DEV Community

Cover image for PolyShell (CVE-2026-48356): The Actively Exploited Magento Flaw Every Store Owner Must Act On
Senthil Kumar MS
Senthil Kumar MS

Posted on Originally published at phpscientist.com

PolyShell (CVE-2026-48356): The Actively Exploited Magento Flaw Every Store Owner Must Act On

#magento #adobecommerce #ecommercesecurity #php

Decision needed this week

CVE-2026-48356, nicknamed PolyShell, lets anyone on the internet upload a file to a Magento or Adobe Commerce store through its public shopping-cart API, with no login. On many servers that file becomes a backdoor that criminals use to plant card skimmers. Attacks have been running since March 2026, and on 27 October CISA added it to its list of actively exploited flaws, with a 10 November deadline for US federal agencies. If your store has not installed Adobe’s July 2026 security update (APSB26-73), treat it as urgent, and check for signs of compromise even if you have.

  • 9.3 - CVSS 3.1 score, rated critical by Adobe and NIST
  • 0 - accounts or passwords the attacker needs
  • 471 - stores infected in one hour on 30 March 2026 (Sansec)
  • 10 Nov - CISA deadline to patch or stop using the product

Most security bulletins can wait for the next maintenance window. This one should not. It affects every supported line of Magento Open Source and Adobe Commerce, it was being exploited for four months before an official patch existed, and the people using it are organised groups who steal payment data from shoppers. This guide is for owners, directors and heads of e-commerce: what the flaw is in plain terms, what it can cost you, how to tell whether you are exposed, and what to ask your team or agency to do this week.

What PolyShell is, in plain terms

Magento lets a product carry a “custom option”, such as a file a shopper attaches to an order: a logo for printing or a photo for engraving. Those files are saved on your server. Researchers at Sansec found that the public API behind the cart, the one your storefront and apps use for guest checkouts, would accept such a file for any product, even one with no file option, and from anyone, with no login.

Magento only checked that the upload looked like an image. Attackers send a “polyglot”: a file that is a valid GIF or PNG and at the same time contains PHP code. It lands in pub/media/custom\_options/quote/ on your server. What happens next depends on how your web server is set up:

  • If the server runs PHP files in that folder (common with older or customised nginx and Apache set-ups), the attacker can run any code on the store. This is full control: the database, customer records, admin accounts and the checkout.
  • If it does not, the file is still stored and can be used to attack people who view it, for example an administrator, which is why the official description mentions user interaction.

The flaw has existed since the first release of Magento 2, so the age of your store does not protect you. Sansec named it PolyShell when it published its advisory on 17 March 2026.

Why the official description sounds milder

The NVD entry describes code execution that needs a victim to visit a crafted link, the worst case Adobe could promise for every configuration. In practice, Sansec and CISA report attackers running code directly on servers that execute PHP in the upload folder, without anyone clicking anything. CISA rates the technical impact as “total”. Plan for the worse outcome.

What it can cost the business

The groups exploiting PolyShell are not after your server; they are after your customers. Sansec traced the attacks to a long-running campaign that, once inside, does three things:

For a decision maker, that translates into concrete exposure:

  • Payment card theft and PCI DSS consequences. A skimmer on the checkout is a reportable cardholder-data breach, with forensic investigation costs, possible fines from your acquirer and, in some cases, loss of the ability to take cards.
  • Personal data breach notification. Customer names, addresses and order histories are in reach, which can trigger GDPR, UK GDPR or US state notification duties.
  • Revenue and reputation. Browsers and search engines flag infected sites; clean-up often means taking the store offline or into maintenance at short notice.
  • Hidden, lasting access. Because the injected script lives in the database and the backdoors are spread across folders, patching alone does not remove an existing infection.

How widely it is being exploited

This is not a theoretical risk. According to Sansec’s research:

Date (2026)What happened17 MarchSansec publishes the PolyShell advisory; no production patch exists yet19 MarchMass scanning begins from more than 50 IP addresses30 MarchAutomated wave: 471 stores infected with a skimmer loader in one hour14 JulyAdobe releases APSB26-73 with fixes for supported versions; CVE-2026-48356 is published7–23 OctoberThe same group moves to a new domain; Sansec counts 953 stores affected since July 202527 OctoberCISA adds CVE-2026-48356 to the Known Exploited Vulnerabilities catalog, due 10 November

Sansec also found that 60% of infected Magento 2 stores it examined had files uploaded through PolyShell or the earlier SessionReaper flaw (CVE-2025-54236), and found the loader on one store that had every core patch. That is the key message for leadership: patched does not mean clean.

Are you affected? A quick check

ProductAffected versionsFixed in (July 2026 security release)Adobe Commerce2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, 2.4.4-p18 and earlier2.4.9 / 2.4.8 / 2.4.7 / 2.4.6 / 2.4.5 / 2.4.4 “-2026-jul” releasesMagento Open Source2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15 and earlier2.4.9 / 2.4.8 / 2.4.7 / 2.4.6 “-2026-jul” releasesAdobe Commerce B2B1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18 and earlierMatching “-2026-jul” releasesAdobe Commerce Events1.20.0 and earlier1.21.0

If your store is on Magento 2.3 or an older 2.4 line that no longer receives patches, there is no official fix: you need an upgrade plan, and the server-level block below in the meantime. Adobe Commerce Cloud customers should confirm with Adobe or their partner that the patch is applied to every environment, including staging.

Your developer can confirm the version and look for the most common traces in a few minutes:

# 1. Which version is installed?
bin/magento --version

# 2. Any files uploaded through custom options? (expect very few, and no PHP)
find pub/media/custom_options pub/media/customer_address -type f -newermt 2026-03-01 | head -50
grep -rlE "<\?php|eval\(|base64_decode" pub/media/custom_options pub/media/customer_address 2>/dev/null

# 3. Known backdoor name from the attack wave
find . -name "accesson.php" -not -path "./vendor/*"

# 4. Injected loader in CMS content (MySQL)
mysql -e "SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%fpCode%' OR content LIKE '%localStorage.getItem%' OR content LIKE '%se_referrer%';" your_db
Enter fullscreen mode Exit fullscreen mode

Any hit on steps 2 to 4 means you should treat the store as compromised and bring in incident response, not just apply the patch.

What to do this week

For nginx, Sansec’s advice is to deny the folder before any rule that passes .php files to PHP, otherwise the PHP rule wins:

# Place ABOVE any "location ~ \.php$" block
location ^~ /media/custom_options/ {
    deny all;
    return 403;
}
Enter fullscreen mode Exit fullscreen mode

On Apache, confirm that pub/media/custom\_options/.htaccess exists and contains both php\_flag engine 0 (inside an IfModule mod\_php block) and Deny from all. These are stopgaps: files can still be written to disk, so the patch remains essential.

Questions to ask your developer or agency

Send this list today

  • Which Magento or Adobe Commerce version runs on production and staging, and is APSB26-73 installed on both? When was it deployed?
  • Is PHP execution and direct access blocked for pub/media/custom_options/ in our web server configuration?
  • Have we scanned for web shells, accesson.php files and injected scripts in CMS blocks, and what did we find?
  • Are there admin users, integrations or CMS changes since March 2026 that nobody can explain?
  • Does our WAF or CDN block file uploads to the guest-cart API, and are we on a supported version line?
  • If anything was found, who leads incident response, and do we need to notify our payment provider or customers?

If you also run other PHP applications on the same servers, check this month’s other critical fixes too: our PHP2Shell guide covers the October PHP runtime release.

Magento security

Need your store checked and patched?

We can confirm whether your Magento or Adobe Commerce store is exposed, apply APSB26-73 and the server-level block, check for web shells and skimmers, and plan an upgrade off unsupported versions.

Book a free 30-minute call

Sources

Originally published at phpscientist.com.

Top comments (0)