Critical Adobe Commerce (Magento) Bug Lets Attackers Execute Remote Code
Key Takeaways A critical “PolyShell” vulnerability in Adobe Commerce (Magento) allows unauthenticated remote code execution. Attackers are actively exploiting this flaw through mass...
Key Takeaways
- A critical “PolyShell” vulnerability in Adobe Commerce (Magento) allows unauthenticated remote code execution.
- Attackers are actively exploiting this flaw through mass automated attacks, leading to full system compromise.
- The vulnerability stems from insufficient validation and file type restrictions in the Magento REST API’s file upload mechanism.
- All versions of Magento Open Source and Adobe Commerce up to 2.4.9-alpha2 are affected, with no official production patch currently available.
- Immediate mitigation steps include deploying WAFs, restricting server access to specific directories, and scanning for webshells.
A severe unrestricted file upload vulnerability, dubbed “PolyShell,” is currently being actively exploited, posing a critical threat to Magento and Adobe Commerce online stores. This flaw enables attackers to execute arbitrary code remotely, leading to complete account takeover.
Table Of Content
Discovered by the Sansec Forensics Team, the vulnerability allows unauthenticated threat actors to bypass security measures and gain full control over affected e-commerce platforms. Since mid-March 2026, malicious actors have launched widespread automated attacks against vulnerable systems, capitalizing on the absence of an official production patch.
The PolyShell Vulnerability Explained
The PolyShell exploit specifically targets the Magento REST API, leveraging anonymous guest cart routes to circumvent authentication requirements. When a product option is configured to accept file uploads, Magento processes base64-encoded file data and writes it directly to the server’s pub/media/custom_options/quote/ directory.
The core of the vulnerability lies in the system’s failure to implement three crucial security checks:
- Lack of Option ID Validation: The submitted option ID is not verified against the product’s actual available options.
- Absence of Option Type Gating: The file upload logic is triggered irrespective of whether the product genuinely includes a file-type option.
- Insufficient File Extension Restriction: The system fails to block executable extensions like
.phpand.phar, relying instead on easily bypassed image header validation.
Sansec reported observing automated mass scanning for this vulnerability commencing on March 19, 2026. Over 50 distinct IP addresses were identified targeting approximately 23% of protected stores.
Attackers are deploying sophisticated polyglot files—files that appear to be legitimate GIF or PNG images but secretly contain executable PHP code. These malicious payloads primarily fall into two categories:
- A cookie-authenticated webshell, typically named
index.php,bypass.php, orc.php, which verifies access via an MD5 hash in a cookie named ‘d’. - A password-protected RCE shell, often dropped as
rce.phpormikhail.html, that uses double-MD5 hash verification to execute system commands directly.
To evade detection by basic security scanners, threat actors have occasionally employed Unicode obfuscation in these malicious filenames.
Affected Versions and Mitigation Strategies
The vulnerable code has been present in Magento since its initial release of version 2. While Adobe addressed the issue in the pre-release 2.4.9-alpha3 branch as part of APSB25-94, current production environments remain highly exposed. The severity of the flaw is contingent on the specific software version and server configuration.
All versions of Magento Open Source and Adobe Commerce up to 2.4.9-alpha2 are susceptible to the unrestricted file upload vulnerability. Additionally, stored cross-site scripting (XSS) affects all versions prior to 2.3.5 and environments with custom server configurations. Remote Code Execution risks are particularly pronounced for default Nginx configurations (e.g., versions 2.0.0 through 2.2.x) and Apache servers that lack specific PHP restrictions.
What You Should Do
The Sansec Forensics Team strongly advises administrators to implement immediate defensive measures until an official production patch becomes available. Defenders should:
- Deploy a Web Application Firewall (WAF): Utilize a WAF to actively block exploitation attempts in real-time.
- Restrict Web Server Access: Immediately restrict web server access to the
pub/media/custom_options/directory. For Nginx, this requires alocationblock with adeny alldirective that is not overridden by PHP regex matches. Apache servers necessitate strict.htaccessrules. - Scan for Webshells: Proactively scan your environments for hidden webshells to detect any existing compromises.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.