PolyShell Magento Zero-Day: 57% of Vulnerable Stores Hit in Days

A Polyglot File Walks Into a REST API

On March 17, 2026, eCommerce security firm Sansec publicly disclosed a vulnerability they named PolyShell — an unauthenticated unrestricted file upload flaw affecting every production version of Magento Open Source and Adobe Commerce. Within two days, automated mass exploitation began. Within two weeks, more than half of all vulnerable stores had been hit.

The vulnerability is elegant in its simplicity. Magento’s REST API accepts file uploads as part of cart item custom options. When a product option is set to type “file,” the API processes an embedded file_info object containing base64-encoded file data, a MIME type, and a filename. The uploaded file is written to the pub/media/custom_options/quote/ directory on the server.

The critical failure: no file extension restriction. Extensions like .php, .phtml, and .phar are not blocked. The only validation is an image header check via getimagesizefromstring(), which is trivially bypassed using a polyglot file — a file that is simultaneously valid as both an image and a PHP script.

The simplest exploit prepends GIF89a (a valid GIF header) to a PHP payload. As long as the file starts with GIF89a and contains some data, getimagesizefromstring() considers it a valid image. The PHP interpreter ignores the image header and executes the code.

The result: unauthenticated remote code execution on any Magento store with default configuration.

The Exploitation Timeline

The speed of mass exploitation sets PolyShell apart from typical web application zero-days.

March 16, 12:00 UTC — First probing activity detected by Sansec. Attackers begin reconnaissance against Magento REST API endpoints.

March 17 — Sansec publishes its research disclosure naming the vulnerability “PolyShell.”

March 19 — Automated mass scanning kicks off with no fewer than 50 IP addresses participating in the initial scan wave.

March 19-29 — Sustained exploitation campaign. Attackers deploy backdoors, inject malicious JavaScript, and establish persistent access across thousands of stores.

March 30 — A mass attack wave hits hundreds of stores in a single hour, injecting JavaScript loaders from the malicious domain lanhd6549tdhse.top.

By the time Sansec measured the impact, PolyShell attacks had hit 56.7% of all vulnerable stores — an exploitation rate that dwarfs typical web vulnerability campaigns.

The Scale of Exposure

PolyShell affects an estimated 112,000 to 130,000 active Magento storefronts processing a combined $173 billion in annual gross merchandise value. This includes both Magento Open Source (community) and Adobe Commerce (enterprise) installations.

Adobe addressed the flaw in the 2.4.9 pre-release branch and subsequently released security patches for production versions (2.4.4-p16 through 2.4.8-p3) as part of security bulletin APSB25-94. However, the overwhelming majority of stores had not applied these patches by the time mass exploitation began — and the initial disclosure period left all production stores exposed.

This patching gap is the defining characteristic of the PolyShell crisis. The 56.7% exploitation rate reflects that most stores had not patched even after patches became available, underscoring the persistent gap between patch availability and patch adoption across the Magento ecosystem.

Post-Exploitation: Backdoors and JavaScript Injection

Gaining initial code execution through PolyShell is only the first step. Sansec documented a consistent post-exploitation playbook:

Step 1: Deploy the accesson.php backdoor. After achieving RCE, attackers spray a secondary backdoor named accesson.php across multiple directories to maximize persistence. Even if the original polyglot file is discovered and removed, the accesson backdoor provides continued access.

Step 2: Inject obfuscated JavaScript. Malicious JavaScript loaders are injected into the store’s frontend, loading external malware from attacker-controlled domains. This JavaScript captures payment card data entered by customers during checkout — the classic Magecart skimming pattern, now delivered through a zero-day entry point. In some cases, attackers deployed a novel WebRTC-based skimmer capable of bypassing Content Security Policy (CSP) protections, representing an evolution in the skimming toolkit.

Step 3: Establish customer account takeover. Beyond skimming, the vulnerability enables stored cross-site scripting (XSS) that can be weaponized for customer account takeover, accessing order histories, saved payment methods, and personal data.

The multi-stage post-exploitation means that cleaning up a PolyShell compromise requires more than patching the upload flaw. Every directory must be scanned for accesson.php variants, all JavaScript files must be audited for injected loaders, and customer sessions should be invalidated.

Immediate Mitigations

While Adobe has released production patches, the low adoption rate means most stores remain unpatched. Magento administrators who have not yet applied the APSB25-94 updates must implement manual defenses immediately:

Block dangerous extensions at the web server level. Configure Nginx or Apache to reject requests that upload files with .php, .phtml, .phar, or .shtml extensions to the custom options directory. This is the most effective immediate mitigation.

Restrict REST API access. If guest checkout via API is not required, disable unauthenticated access to the cart item custom options endpoint. This breaks the attack chain at the entry point.

Deploy a Web Application Firewall (WAF) rule. Major WAF providers including Cloudflare, Akamai, and Sucuri have released rules to detect PolyShell payloads. WAF protection is not a substitute for patching but reduces exposure against automated scanning.

Monitor the custom_options directory. Set up file integrity monitoring on pub/media/custom_options/quote/ to alert on any new PHP files. Legitimate uploads to this directory should only contain image files.

Scan for accesson.php. Search the entire Magento installation for accesson.php or any recently created PHP files outside expected directories. The presence of this file confirms active compromise.

Audit JavaScript for injected loaders. Check all CMS blocks, static files, and template files for obfuscated JavaScript referencing external domains.

Why PolyShell Matters Beyond Magento

PolyShell is a case study in the systemic risk of monolithic eCommerce platforms. The vulnerability exists because Magento’s file upload validation trusts content type over file extension — a design choice that treats convenience over security.

For the broader eCommerce ecosystem, PolyShell raises three uncomfortable questions:

How many other platforms have similar validation gaps? If Magento’s REST API missed extension blocking on file uploads, competing platforms should audit their own upload pipelines immediately.

What happens when the patch gap exceeds the exploitation window? Adobe knew about the fix in pre-release but did not ship a production patch in time. The Magento ecosystem absorbs the cost of that timing gap.

Can eCommerce stores remain secure without dedicated security resources? The 56.7% exploitation rate suggests that most Magento stores lack the monitoring and response capability to detect and mitigate zero-day attacks. The small-merchant security gap is a structural problem that platform vendors have not solved.

Frequently Asked Questions

Sources & Further Reading

• PolyShell: Unrestricted File Upload in Magento and Adobe Commerce — Sansec
• Magento PolyShell Flaw Enables Unauthenticated Uploads, RCE and Account Takeover — The Hacker News
• PolyShell Attacks Target 56% of All Vulnerable Magento Stores — Bleeping Computer
• PolyShell Flaw Exposes Magento and Adobe Commerce to File Upload Attacks — Security Affairs
• PolyShell Alert: Critical Magento REST API Vulnerability Faces Massive Global Exploitation — Security Online
• Magento PolyShell — Unauthenticated File Upload to RCE (APSB25-94) — Searchlight Cyber