Magento PolyShell Patch: What Every Store Owner Must Know Right Now

⚠️ URGENT: Active exploitation of PolyShell has been confirmed since March 19, 2026, with mass automated attacks targeting stores globally. If you’re running any production version of Magento 2 or Adobe Commerce, read this immediately. 

What Is the Magento PolyShell Vulnerability? 

A critical security flaw named PolyShell was publicly disclosed by Dutch eCommerce security firm Sansec on March 17, 2026. It affects every stable production version of Magento Open Source and Adobe Commerce — from Magento 2.0.0 all the way through 2.4.8. 

PolyShell is classified as an unrestricted file upload vulnerability in Magento’s REST API. In plain language: an attacker who has never logged into your store — not a customer, not an admin, completely unauthenticated — can upload a malicious file disguised as a harmless image directly to your server. 

The vulnerability is tracked under Adobe’s security bulletin APSB25-94.

Why Is It Called “PolyShell”?

The name is a combination of two words: 

• Poly — short for polyglot, a file that is simultaneously valid in two formats (in this case, a file that looks like an image but contains executable PHP code)
• Shell — because the end goal is gaining a shell (remote command access) on your server

Attackers craft a file that passes Magento’s file type validation as an image, but is actually a PHP script. Once uploaded, depending on your server configuration, it can execute commands directly on your server. 

How Does the Attack Work?

The vulnerability lives in Magento’s REST API cart item custom options handler. Here’s the attack chain in straightforward terms: 

Step 1 — Upload the polyglot file When a product option has the type set to “file,” Magento’s REST API processes an embedded file_info object containing base64-encoded file data, a MIME type, and a filename. Magento writes this file directly to pub/media/custom_options/quote/ on your server — no authentication required. 

Step 2 — The file lands on disk The attacker’s polyglot file is now on your server. It looks like an image. It passes validation. But it contains executable PHP code hidden inside. 

Step 3 — Execution or persistence Depending on your web server configuration, one of two outcomes follows: 

• Remote Code Execution (RCE): If your server is configured to execute PHP in the upload directory (common on stock Nginx 2.0.0–2.2.x, or Apache without php_flag engine 0), the attacker can trigger their file and run arbitrary commands on your server — reading databases, stealing customer data, installing backdoors, or injecting payment skimmers. 
• Stored XSS / Account Takeover: On servers where PHP execution is blocked, the file can still be used as a stored cross-site scripting attack to hijack admin or customer accounts. 

Step 4 — Backdoor deployment After gaining access through PolyShell, attackers have been observed deploying a secondary backdoor called accesson.php, sprayed across multiple directories to maintain persistent access even if the original file is removed. 

Critical warning: Even if your server is currently configured correctly and PHP execution is blocked, the malicious file stays on disk. A future server migration, configuration change, or web server swap could expose it — giving attackers access months or years later. 

Who Is Affected?

GraphQL API users: GraphQL uses a different code path and is not vulnerable. Only REST API is affected. 

Scale of the threat: PolyShell affects an estimated 112,000–130,000 active storefronts globally, processing a combined $173 billion in annual gross merchandise value. 

Is There an Official Patch?

This is the most alarming part of the PolyShell story. 

Adobe has fixed the vulnerability in the 2.4.9 pre-release branch (alpha3 and later) as part of APSB25-94. However, no isolated security patch exists for production versions — meaning every store running Magento 2.4.8 and below is left without an official fix while attackers are actively exploiting the vulnerability. 

The fix in 2.4.9-alpha3 introduced a new class — Magento\Catalog\Model\Product\Option\Type\File\ImageContentProcessor — which adds a strict file extension validation check during upload. This check was not backported to production versions. 

Adobe’s timeline of response has drawn criticism from the security community, given that the vulnerable code has existed since Magento 2’s very first release and active exploitation is now confirmed and accelerating. 

Active Exploitation: What’s Happening Right Now 

PolyShell is not theoretical. It is being actively weaponized at scale: 

• March 16, 2026: First probing activity detected by Sansec at 12:00 UTC 
• March 19, 2026: Automated mass scanning began across all Magento stores 
• March 23, 2026: 50+ IP addresses actively scanning; attacks confirmed on stores belonging to globally recognized brands 
• March 24, 2026: PolyShell used as the entry vector for a novel WebRTC-based payment skimmer found on a $100+ billion car manufacturer’s store 
• March 30, 2026: Mass attack wave hit hundreds of stores in a single hour, injecting JavaScript loaders from a malicious domain. Attackers have fully automated the PolyShell exploitation chain. 

Sansec reports that PolyShell attacks have been attempted against 79.5% of all protected Magento stores they monitor — a staggering rate that reflects the severity and automation level of this threat. 

What Can Happen If Your Store Is Compromised? 

A successful PolyShell exploitation can result in: 

• Payment skimming (Magecart attack): Malicious JavaScript injected into your checkout page silently captures every credit card number, CVV, and billing detail entered by your customers 
• Customer data theft: Full access to your Magento database — names, emails, addresses, order history, hashed passwords 
• Admin account takeover: Attackers can create new admin users or reset existing credentials 
• Persistent backdoors: Hidden PHP shells planted in multiple directories, surviving cache clears and module reinstalls 
• SEO poisoning: Malicious content injected into your store to damage your search rankings or redirect customers to competitor or phishing sites 
• Server-level compromise: Full shell access means attackers can pivot to other services running on your server 

The average financial impact of a Magento breach now exceeds $120,000, accounting for incident response, forensic investigation, regulatory penalties, and customer notification costs. 

Immediate Mitigation Steps (Act Now) 

Since no official production patch exists yet, store operators must implement defensive measures immediately. Here is what Aims Infosoft recommends: 

1. Apply the Community Patch (Highest Priority) 

A community-developed patch is available on GitHub: 

👉 https://github.com/markshust/magento-polyshell-patch 

This patch backports Adobe’s 2.4.9 fix to production Magento 2 versions. It is the fastest way to close the file upload vulnerability while waiting for an official patch from Adobe. 

2. Audit Your Upload Directories 

Immediately scan for suspicious files that may already be present: 

find pub/media/custom_options/ -type f ! -name '.htaccess'

Delete any files that are not legitimate PNG or JPEG images. Be especially cautious with .svg files (which can enable XSS) and any file with a .php extension or unusual naming patterns. 

Also check for the known backdoor file: 

find . -name "accesson.php"

3. Verify Your Web Server Configuration 

For Nginx: Ensure your configuration explicitly denies PHP execution in the media directory. Confirm that pub/media/custom_options/.htaccess exists and has not been tampered with. 

For Apache: Verify that pub/media/.htaccess contains php_flag engine 0, and that pub/media/custom_options/.htaccess denies all file access. Check that AccessFileName is set to .htaccess (not a custom value). 

Adobe provides a recommended server configuration — if your hosting provider has customized it, review those changes carefully. 

4. Deploy a Web Application Firewall (WAF) 

A WAF with Magento-specific rules can block PolyShell exploitation attempts in real time. Sansec Shield, Cloudflare WAF with Magento rulesets, and similar solutions have been blocking PolyShell attempts since the vulnerability was disclosed. 

5. Monitor for Compromise Indicators 

Watch for the following signs of active compromise: 

• New or unknown PHP files in pub/media/, pub/static/, or root directories 
• Unknown admin user accounts created recently 
• Unexpected JavaScript inclusions in your theme or layout XML files 
• Outbound requests from your server to unknown external domains 
• Customer complaints about unusual behavior during checkout 

6. Enable REST API Restriction (If Applicable) 

If your store does not require unauthenticated REST API access for cart operations, consider restricting REST API access at the WAF or server level as an additional protective measure. Note that this may impact legitimate guest checkout functionality and should be tested carefully. 

Context: Magento’s Recent Security Track Record 

PolyShell does not exist in isolation. It is the latest in a pattern of critical Magento 2 vulnerabilities that have been rapidly weaponized at scale: 

The pattern is consistent: a critical vulnerability is disclosed, automated exploitation begins within days, and tens of thousands of stores are compromised. The window between disclosure and mass exploitation has shrunk to as little as 72 hours. 

How Aims Infosoft Can Help 

At Aims Infosoft, security is not an afterthought — it is part of every Magento 2 engagement we deliver. In response to PolyShell, our team is offering: 

Emergency Security Audit We will audit your Magento 2 store for PolyShell exposure, scan upload directories for existing compromise indicators, review your server configuration, and assess your WAF coverage. 

Patch Application & Server Hardening Our certified Magento developers will apply the community PolyShell patch, harden your Nginx/Apache configuration to Adobe’s recommended standards, and verify that all .htaccess protections are intact. 

Ongoing Security Monitoring With 10+ years of Magento expertise and a track record of protecting 50,000+ stores, we offer proactive security monitoring to catch threats before they become breaches. 

Stay Protected 

PolyShell is one of the most serious Magento 2 vulnerabilities ever disclosed — made more dangerous by the absence of an official production patch and the speed at which attackers have automated exploitation. 

Do not wait. Every day without mitigation is a day your store, your customers’ data, and your business are at risk. 

👉 Contact Aims Infosoft for an Emergency PolyShell Security Review 

Aims Infosoft — #1 Magento Solutions Provider | 10+ Years | 90% Client Satisfaction | 52+ Products | 12+ Extensions 

References: 

• Sansec Research: https://sansec.io/research/magento-polyshell 
• Adobe Security Bulletin APSB25-94 
• Community Patch: https://github.com/markshust/magento-polyshell-patch 
• Searchlight Cyber Analysis: https://slcyber.io/research-center/magento-polyshell-unauthenticated-file-upload-to-rce-in-magento-apsb25-94/