Magento “PolyShell” Exploit: What It Is, How It Works, and What You Need to Do Now

By Clayton DillardBlog, Cyber Threat Spotlight

A newly disclosed vulnerability known as PolyShell is rapidly becoming one of the most serious threats to Magento and Adobe Commerce environments in recent years.

Security researchers are now observing mass exploitation across thousands of eCommerce sites, with attackers using automated scanning and exploitation tools to identify and compromise vulnerable stores at scale. (BleepingComputer)

If your organization runs Magento, this is not theoretical risk—this is active, widespread exploitation happening right now.

What is the Magento PolyShell Vulnerability?

PolyShell is a critical, unauthenticated remote code execution (RCE) vulnerability affecting Magento Open Source and Adobe Commerce platforms. (BleepingComputer)

At its core:

  • It allows any external attacker (no login required) to upload malicious files
  • Those files can then be executed on the server
  • Resulting in full system compromise, data theft, or persistence

👉 Learn more:

How the PolyShell Exploit Works

This vulnerability exists in Magento’s REST API, specifically in how it handles file uploads tied to product customization features.

Step-by-step attack chain:

1. Exploiting the REST API

Magento allows file uploads when customers customize products (e.g., uploading an image for printing).

  • The API accepts a file_info object containing:
    • Base64 file data
    • MIME type
    • Filename
  • The file is saved to:/pub/media/custom_options/quote/

2. Bypassing File Validation (Polyglot Technique)

Attackers craft a polyglot file:

  • Appears to be a valid image (e.g., GIF or JPEG)
  • Also contains embedded PHP code

This works because Magento:

  • Trusts MIME type and extension
  • Does not properly validate executable content

👉 Result: the file is accepted as an image, but functions as executable code

3. Writing to a Web-Accessible Directory

The malicious file is stored in:

/pub/media/custom_options/

This directory is:

  • Writable by the application
  • Often web-accessible
  • Frequently misconfigured to allow execution

4. Remote Code Execution

If the web server allows PHP execution in that directory:

  • The attacker simply requests the file via browser
  • The server executes the embedded PHP code
  • A web shell is established

👉 At this point, the attacker has:

  • Command execution
  • File upload capability
  • Persistent backdoor access

Why This Is So Dangerous

PolyShell stands out for several reasons:

🚫 No authentication required

Anyone on the internet can attempt exploitation (Plumrocket)

⚡ Mass automation

Attackers are actively scanning and exploiting sites at scale

  • Over 56% of vulnerable stores have already been targeted

🧬 Stealth techniques

  • Malicious files disguised as images
  • Small, obfuscated web shells
  • Hard to detect without inspection

Real-world impact

Observed attacks include:

  • Credit card skimmers
  • Data exfiltration using WebRTC (bypassing traditional controls)

Mitigation: What Actually Works (Right Now)

At the time of writing:

  • Adobe has issued a fix only in pre-release versions
  • No widely available production patch exists yet
  • If you have access to Magento developer resources in-house or through a DevOps partner, you may be able to write a custom patch to help mitigate this until Adobe releases an official patch

That means organizations must rely on compensating controls

1. Web Application Firewall (WAF)

A properly configured WAF can partially mitigate exploitation by:

  • Blocking access to:/pub/media/custom_options/
  • Blocking requests to:
    • .php or .phtml files in /media/
  • Detecting suspicious upload patterns

⚠️ Important:
A WAF helps prevent execution and access, but does not stop uploads entirely in all cases (The Hacker News)

2. Disable PHP Execution in Media Directories

This is one of the most effective controls:

  • Prevents uploaded files from executing
  • Breaks the attack chain even if upload succeeds

3. Scan for Existing Compromise

Do not assume you are safe.

Look for:

  • PHP files in /pub/media/
  • Files masquerading as images containing PHP code
  • Unexpected recently modified files

4. Restrict Access to Upload Directories

Explicitly block access to:

/pub/media/custom_options/

Verify:

  • Nginx / Apache rules are enforced
  • Files cannot be accessed directly via browser

Important: WAF Alone Is Not Enough

In our real-world incident response work over the past several days, we’ve observed:

  • WAF rules can successfully block or hinder post-exploit attacker access
  • But malicious files may still be written to disk

This means:

👉 A WAF reduces risk
👉 It does NOT guarantee your system is clean

If exploitation has already occurred:

  • The server must be treated as compromised
  • A rebuild from a clean image is the only reliable remediation

Recommended Response Strategy

Immediate (Today)

  • Implement WAF protections
  • Disable PHP execution in media directories
  • Scan for web shells and suspicious files

Short-term (24–48 hours)

  • Validate logs for exploitation attempts
  • Identify indicators of compromise
  • Rotate credentials if needed

Required Remediation

  • Rebuild affected systems from a clean image
  • Apply patches once available
  • Harden web server configuration

Final Thoughts

PolyShell is a perfect storm vulnerability:

  • Easy to exploit
  • No authentication required
  • Highly automatable
  • Massive attack surface

This is why we’re seeing such rapid and widespread exploitation.

If you operate a Magento environment, the question is no longer:

“Are we vulnerable?”

It’s:

“Have we already been targeted—and do we know it?”

If you need help with incident response for this exploit, contact us today.

Contact US