PolyShell Alert: Critical Magento REST API Vulnerability Faces Massive Global Exploitation in the Wild
Ddos 
A critical security flaw in the Magento REST API is currently being weaponized by cybercriminals to hijack e-commerce stores globally. Researchers at Sansec have identified a vulnerability they’ve dubbed “PolyShell,” so named because the attack utilizes a “polyglot”—malicious code disguised as a harmless image file.
The threat is immediate and escalating. As of March 23rd, 2026, Sansec has “observed active exploitation since March 19th, with automated mass scanning accelerating rapidly”.
PolyShell leverages an unrestricted file upload vulnerability that has quietly existed since the very first release of Magento 2. By sending a specially crafted request to the REST API, an unauthenticated attacker can upload executable PHP code to a target store.
To bypass security filters that might block .php files, attackers disguise their scripts as images. One common variant prepends the standard GIF header GIF89a to a PHP shell script. This “polyglot” allows the file to be treated as an image by some systems while remaining fully executable by the web server.
Once the file is on the server, the attacker’s goal is Remote Code Execution (RCE). “Unauthenticated attackers can upload executable files to any store,” which can then be used to drop persistent webshells.
These shells often serve as a permanent backdoor, allowing attackers to:
- Steal Customer Data: Intercepting payment information and personal details at the point of checkout.
- Inject Malicious Scripts: Deploying credit card skimmers (Magecart) directly into the storefront.
- Full System Compromise: Executing OS commands to pivot further into the hosting environment.
Attackers are currently using a wide variety of filenames to hide these shells, ranging from index.php to obfuscated Unicode strings like \u0062\u0079\u0070\u0061\u0073\u0073.\u0070\u0068\u0070.
The most alarming aspect of PolyShell is the lack of a formal fix for most users. While Adobe addressed the flaw in a pre-release version (2.4.9-alpha3+), “no isolated patch exists for current production versions”.
Furthermore, even if a server is configured to block the execution of files in upload directories, the risk remains. “The uploaded file stays on disk. A future configuration change, server migration, or web server swap could expose it,” Sansec warned.
Until an official patch is released by Adobe, store owners must take proactive steps to harden their environments:
- Audit Upload Directories: Scan your media and upload folders for suspicious PHP files or “images” containing PHP code.
- Verify Web Server Config: Ensure your web server (Nginx or Apache) is explicitly configured to not execute PHP in any directory where user uploads are stored.
- Monitor REST API Traffic: Look for unusual POST requests to file upload endpoints, especially from unknown IP addresses.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
