Table of Contents

What is the PolyShell (Polyglot) Attack?
Attack Flow
Quick Detection
Immediate Protection
Why This Vulnerability is Critical
Key Risk Areas You Should Audit
Final Thoughts
Quick Recap Checklist

Understanding the Magento PolyShell (Polyglot) Attack – Stay Secure

A recent unauthenticated Remote Code Execution (RCE) vulnerability in Magento 2 / Adobe Commerce, commonly referred to as the magento PolyShell (Polyglot) attack, has been actively exploited in the wild. This vulnerability is particularly dangerous because it does not require authentication, making it easier for attackers to target stores at scale.

If left unaddressed, it can lead to full server compromise, persistent backdoors, and complete control over your Magento environment. Let’s break down how this attack works, how to detect it, and what immediate steps you should take to secure your store.

What is the PolyShell (Polyglot) Attack?

At its core, the magento PolyShell attack leverages a clever technique called a polyglot file a file that is valid in multiple formats simultaneously.

In this case, the attacker creates a file that:

Appears to be a legitimate image (e.g., starts with GIF magic bytes)
Contains embedded PHP code within it

Because Magento’s file validation mechanisms are not strict enough in this context, the system accepts the file as an image while still allowing the embedded PHP code to execute later.

This dual-nature file becomes the entry point for a full Remote Code Execution attack.

Attack Flow (Step-by-Step Breakdown)

1. Polyglot File Creation

The attacker begins by crafting a malicious file designed to bypass validation checks.

The file starts with valid image headers (like GIF89a)
Hidden inside is executable PHP code

This allows the file to pass as a harmless image during upload while retaining its ability to execute as a script.

2. Delivery via REST API

Once the file is ready, the attacker uses Magento's guest cart REST API endpoint to upload it.

Endpoint used:

/rest/V1/guest-carts//items

Key points:

The payload is sent as a base64-encoded string
It is injected inside a custom file option
No authentication is required, making it highly exploitable

This is the critical entry point where the attack bypasses standard upload restrictions.

3. File Storage

After submission, Magento processes and stores the uploaded file.

Due to weak validation:

The system accepts the file as a valid image
It gets stored with a .php extension

Typical storage location:

pub/media/custom_options/quote/...

At this stage, the malicious file is successfully placed on the server.

4. Remote Code Execution

This is where the real damage begins.

If the web server allows PHP execution in the pub/media directory:

The attacker simply accesses the uploaded file via a browser or HTTP request
The embedded PHP code executes immediately

Result:

Instant webshell access
Ability to run arbitrary commands on the server

From here, attackers typically:

Deploy persistent backdoors
Modify core files
Escalate privileges
Take full control of the Magento instance

Quick Detection: How to Check if You are Compromised

Early detection is critical. One of the simplest ways to identify suspicious activity is by scanning for unexpected PHP files in media directories.

Run this command:

find pub/media/custom_options/ 
-name "*.php" 
-o -name "accesson.php" 
2>/dev/null

What this does:

Searches for any .php files inside the custom_options directory
Flags known suspicious filenames like accesson.php

Additional Checks:

You should also review your server access logs for:

Requests targeting /pub/media/custom_options/
URLs ending in .php

Any such request is a strong indicator of attempted or successful exploitation.

Immediate Protection: Stop the Attack Vector

Even if a malicious file has already been uploaded, you can block execution instantly at the server level.

Add this Nginx rule:

location ^~ /pub/media/custom_options/ {
   deny all;
   return 403;
}

Why this works:

It completely blocks access to the vulnerable directory
Prevents execution of any malicious PHP files inside it
Acts as a strong defensive layer even if the upload vulnerability exists

Important Note:

Place this rule early in your server block to ensure it takes precedence over other configurations.

Why This Vulnerability is Critical

This PolyShell attack is particularly severe because it combines multiple weaknesses:

Unauthenticated access → No login required
Weak file validation → Malicious files pass as images
Executable media directory → Allows direct PHP execution

Together, these create a perfect path from:

Upload → Storage → Execution → Full Compromise

Key Risk Areas You Should Audit

To stay secure, you should evaluate your Magento setup across these areas:

1. File Upload Handling

Are file types strictly validated?
Are extensions enforced correctly?

2. Media Directory Execution

Is PHP execution allowed in /pub/media/?
Are sensitive directories protected via server rules?

3. API Exposure

Are guest endpoints monitored?
Are unusual payload patterns being logged?

Final Thoughts

The Magento PolyShell (Polyglot) attack is a strong reminder that file upload mechanisms are one of the most critical attack surfaces in any application.

What makes this vulnerability dangerous is not just the exploit itself, but how easily it chains together: