PolyShell: The Unpatched Magento Zero-Day Threatening 130,000 Online Stores

A critical vulnerability in Magento's REST API — present in every version of Magento 2 ever released — allows unauthenticated attackers to upload arbitrary files to web-accessible directories, potentially achieving remote code execution and full admin account takeover. Discovered by e-commerce security firm Sansec and published on 17 March 2026, the flaw dubbed "PolyShell" affects an estimated 112,000–130,000 active storefronts processing a combined $173 billion in annual gross merchandise value.

Adobe has addressed the issue in security bulletin APSB25-94, but only in pre-release branch 2.4.9. For the thousands of stores running current production versions — 2.4.8 and below — no isolated patch exists yet. With Sansec warning that "the exploit method is circulating already" and automated attacks expected imminently, this is a vulnerability that demands immediate attention.

What Makes PolyShell Different

The e-commerce threat landscape is no stranger to critical Magento flaws. CosmicSting (CVE-2024-34102) compromised 4,000+ stores in 2024, with one threat group breaching 2,000 stores in hours. SessionReaper (CVE-2025-54236) hit 250+ stores within 24 hours of exploit code publication, eventually probing 81% of all Magento stores within two weeks. PolyShell has the potential to be worse than both.

The reason is the attack surface. Unlike previous flaws that required some degree of authenticated access or specific preconditions, PolyShell requires no authentication whatsoever. Any anonymous visitor to a Magento storefront can exploit it through the publicly accessible REST API.

How the Vulnerability Works

The Upload Mechanism

The flaw resides in how Magento's REST API handles cart item custom options with a type of file. When a guest shopper adds a product to their cart via the API, and that product has a custom option accepting file uploads, Magento processes an embedded file_info JSON object containing:

• Base64-encoded file data
• A MIME type
• A filename

The uploaded file is written to pub/media/custom_options/quote/ — a web-accessible directory on the server. The critical problem: Magento performs no meaningful validation on the uploaded file's content, type, or extension. An unauthenticated attacker can upload any file they choose, including executable PHP scripts.

The Polyglot Technique

The name "PolyShell" derives from polyglot files — files engineered to be valid in multiple formats simultaneously. In this context, an attacker crafts a file that is both:

1. A valid image file — containing legitimate image headers that pass superficial content-type checks
2. A valid PHP script — containing embedded PHP code that executes when the web server processes it

This dual-format approach defeats any naive content validation that simply checks whether uploaded data "looks like" an image. The file genuinely is an image — it just also happens to be a webshell.

Exploitation Paths

The severity of exploitation depends on the server configuration, but no configuration is entirely safe:

The stored XSS path is particularly concerning because it affects every single configuration. Even stores with properly hardened web servers that block PHP execution in the upload directory remain vulnerable to cross-site scripting attacks that can compromise administrator sessions and lead to full account takeover.

Why This Is an Emergency

The Patching Gap

Adobe's fix is available only in the 2.4.9 pre-release branch as part of APSB25-94. Stores running production versions — 2.4.8 and below — have no official isolated patch to apply. Given that the Magento ecosystem's patching track record is poor at the best of times (only 38% of stores had applied the SessionReaper patch six weeks after release), the window of vulnerability is likely to remain open for months.

E-Commerce Is Already Under Siege

The timing could not be worse. Magecart web-skimming attacks surged 103% during 2024–2025, with 269 million payment card records exposed via dark and clear web sources in 2024 alone, according to Recorded Future. An estimated 11,000+ unique e-commerce domains were infected in 2024 — a nearly 300% year-over-year increase. A Magecart attack is attempted approximately once every 16 minutes globally.

The average financial impact of a Magento breach now exceeds $120,000, accounting for incident response, forensic investigation, regulatory penalties, and customer notification costs. For stores processing significant transaction volumes, the reputational damage can dwarf the direct financial loss.

A Pattern of Escalation

Sansec's own research timeline illustrates how quickly Magento vulnerabilities are weaponised at scale:

• CosmicSting (2024): Impacted 75% of Adobe Commerce and Magento platforms; Group Peschanki breached 2,000 stores in hours, Group Laski infected 3,000 in a single campaign wave
• Backdoored extensions (April 2025): A supply-chain compromise in widely used Magento extensions affected 500–1,000 stores, including a $40 billion multinational
• SessionReaper (October 2025): Mass attacks reached 49% of all stores within nine days of exploit code publication, with 16–18% having backdoors injected

PolyShell's unauthenticated nature and the absence of a production patch make it a prime candidate for rapid, automated exploitation at similar or greater scale.

Immediate Mitigation Steps

With no official patch available for production Magento installations, store operators must implement defensive measures immediately.

1. Verify Web Server Configuration

The most critical step is ensuring the web server does not execute PHP files in the upload directory.

For nginx: Verify that a location block with deny all exists for pub/media/custom_options/ and that it is not overridden by a broader \.php$ regex match. Cross-reference your configuration against Magento's official nginx.conf.sample.

For Apache: Confirm that the .htaccess file is present and functioning in pub/media/custom_options/. Ensure AllowOverride directives permit the .htaccess rules to take effect.

2. Test for Exploitability

Sansec recommends creating a test PHP file at pub/media/custom_options/polyshell.php containing a simple phpinfo()call, then attempting to access it via a web browser. If the PHP executes and returns output, the store is vulnerable to RCE.

3. Deploy a Web Application Firewall

Critically, blocking access to the upload directory does not block the uploads themselves. Attackers can still deposit malicious files through the REST API — the web server configuration only prevents execution. A WAF capable of inspecting API payloads and blocking malicious file uploads at the application layer is essential to fully mitigate the risk.

4. Monitor for Indicators of Compromise

Security teams should immediately audit the pub/media/custom_options/quote/ directory for unexpected files, particularly those with .php, .phtml, or polyglot image extensions. Any files present that were not uploaded through legitimate customer activity should be treated as potential webshells and investigated accordingly.

5. Scan for Existing Compromise

Given that the vulnerable code has existed since the very first Magento 2 release, there is a possibility that sophisticated attackers have been exploiting this flaw quietly. A comprehensive malware scan of the entire Magento installation — not just the upload directory — is warranted.

The Broader E-Commerce Security Challenge

PolyShell exposes a structural problem in e-commerce security. Magento powers approximately 8% of global e-commerce— the third-largest platform by market share — yet its ecosystem consistently struggles with both vulnerability discovery and patch adoption. Sansec recently used Claude AI to audit the top 5,000 Magento Packagist extensions, uncovering 353 confirmed vulnerabilities across packages with 5.9 million total downloads. The attack surface is vast, the supply chain is fragmented, and the operators of individual stores often lack the security expertise to respond to threats of this complexity.

The declining store count trend (down 10% year-over-year in Q4 2025) suggests that some operators are migrating away from Magento, but those who remain are processing increasingly concentrated transaction volumes. A successful compromise of even a fraction of the remaining stores could expose millions of payment card records and customer accounts.

For organisations running Magento storefronts, the lesson is clear: perimeter defences and timely patching are necessary but insufficient. Continuous monitoring of the attack surface — including the web-accessible directories, API endpoints, and third-party extensions that comprise a modern Magento deployment — is the only way to detect exploitation before customer data is exfiltrated.

Key Takeaways

• Every version of Magento 2 ever released is vulnerable to the PolyShell flaw, which allows unauthenticated attackers to upload arbitrary files via the REST API's cart custom options handler — no credentials required.
• The polyglot technique bypasses content validation by crafting files that are simultaneously valid images and executable PHP scripts, enabling RCE on misconfigured servers and stored XSS on all configurations.
• No production patch exists yet — Adobe's fix is only in the 2.4.9 pre-release branch, leaving an estimated 112,000–130,000 active stores without an official remediation path.
• Magento's exploitation history suggests rapid weaponisation — previous critical flaws like CosmicSting and SessionReaper were exploited at scale within hours to days of disclosure, and only 38% of stores patched SessionReaper within six weeks.
• Immediate mitigation requires verifying web server configuration, deploying a WAF to block malicious API uploads, and scanning for existing compromise in the pub/media/custom_options/ directory.

Vulnerabilities like PolyShell are discovered and weaponised faster than most organisations can patch. Discover your attack surface with RavenEye — continuous, AI-powered monitoring that identifies exposed assets, misconfigurations, and indicators of compromise across your organisation's digital footprint before attackers exploit them.