Magento PolyShell Flaw Enables Unauthenticated Uploads, RCE and Account Takeover

A vulnerability in Magento REST API known as PolyShell represents one of the most serious threats to e-commerce platforms that have emerged in recent months. Sansec, specializing in e-commerce platform security, has revealed a critical vulnerability that allows attackers to upload arbitrary executable files without authentication, achieve remote code execution (RCE), and take over user accounts. This is not an ordinary vulnerability — it is a systematic bypass of security mechanisms that should protect millions of online stores worldwide. The fact that the attack is based on malicious code disguised as an image demonstrates the sophistication of modern security bypass techniques.

Magento, being one of the most popular e-commerce platforms, powering thousands of online stores from small startups to large retail chains, has become the target of an advanced attack. The PolyShell vulnerability affects the platform's REST API, which is the programming interface through which various system components and external applications communicate. The lack of authentication requirement means that anyone with access to the network can potentially launch an attack without needing any permissions or passwords.

Anatomy of the PolyShell attack — how the threat works

The genius of the PolyShell vulnerability lies in its simplicity and effectiveness at the same time. The attacker uses Magento's REST API to upload a file that the system interprets as an image, but actually contains executable code. The technique relies on polyglot files — documents that simultaneously comply with the image format specification and contain PHP code or another scripting language. The Magento server, checking only the file header or extension rather than conducting an in-depth analysis of the content, accepts the file as a safe image.

After uploading such a file, the attacker can then trigger its execution by accessing it through a web browser or direct HTTP request. The server, instead of rendering the image, executes the PHP instructions contained in it. From that point on, the attacker has full control over the server — they can read databases containing customer data, modify store content, install backdoors for future attacks, and most importantly, take over administrator and user accounts.

A particularly dangerous aspect of this vulnerability is its universality. It does not require specialized knowledge about a particular store or advanced social engineering. An attacker can automatically scan the Internet for Magento instances and conduct an attack on a massive scale. This methodology, known as "indiscriminate scanning," is particularly effective against vulnerabilities that affect public APIs without authentication requirements.

Magento REST API — a security bottleneck

REST API in Magento plays a key role in the system architecture, enabling integration with external applications, mobile clients, and resource management systems. However, in the case of PolyShell, it was precisely this flexibility and openness of the interface that became a source of threat. The endpoint responsible for file uploads, instead of being protected by multi-layered validation mechanisms, relied on basic checks.

A typical security stack for file uploads should include:

• MIME type validation at the server level
• Analysis of magic bytes to confirm the actual file format
• Storage of uploaded files outside the directory accessible to the web server
• Enforcement of non-execution of files in the uploads directory (via .htaccess or nginx settings)
• Antivirus scanning of uploaded files
• Authentication requirement for upload operations

In the case of PolyShell, at least several of these protection layers were omitted. The lack of authentication requirement is particularly alarming because it means that every public API endpoint is a potential entry point for an attacker. This type of design flaw often results from rushed development, lack of dedicated security review, or the assumption that "no one will attack this interface."

Account takeover — privilege escalation and lateral movement

After achieving remote code execution, the attacker has access to the Magento database. Administrator passwords are typically stored in hashed form, but Magento uses SHA-256 with salt, which is vulnerable to dictionary attacks with sufficient computing power. However, instead of attacking passwords, the attacker can directly modify the database, resetting administrator passwords or creating new accounts with full privileges.

Taking over an administrator account opens an entirely new dimension of attack. The attacker can:

• Modify product prices and redirect payments to their own accounts
• View personal and financial data of all customers
• Install payment skimmers to collect credit card data
• Modify email templates for phishing users
• Set up permanent backdoors to maintain access even after the vulnerability is patched

Lateral movement — the attacker's movement within the network — is a key step in advanced attacks. If Magento is integrated with other systems through REST API, the attacker can use the compromised server as an entry point to attack ERP systems, CRM, or databases. This is exactly the scenario that Zero Trust Network Access (ZTNA) solution providers warn against — the need for network segmentation and access restriction at the user and device level.

Polyglot files — the technique of masking code in images

Polyglot files are documents that simultaneously comply with the specification of multiple file formats. The simplest example is a file that is both a valid JPEG file and a valid ZIP file. This technique is used both in security (for example, for testing systems) and by attackers to bypass filters.

In the case of PolyShell, the attacker creates a file that is simultaneously a valid PNG or JPEG image and contains PHP code. This is possible by adding PHP code to the end of the image file — browsers and image viewing tools will ignore additional data at the end of the file, but a web server configured to execute PHP can interpret the entire file as PHP.

Alternatively, the attacker can exploit vulnerabilities in image processing libraries (such as ImageMagick), which can be forced to interpret the file as a script. This type of attack is particularly difficult to detect because antivirus signatures look for malicious code, but a polyglot file can pass through scanning as a safe image.

Scale of the threat — millions of e-commerce stores in danger

Magento powering e-commerce platforms for an estimated 240,000 online stores worldwide, the PolyShell vulnerability potentially affects a significant portion of e-commerce infrastructure. Many of these stores handle financial transactions, store customer personal data, and contain sensitive business information. It is estimated that the average time between vulnerability discovery and exploitation by cybercriminals is only a few days.

Additionally, many Magento stores run on older versions of software that no longer receive regular security updates. Administrators often delay updates due to concerns about extension compatibility or the time-consuming nature of the migration process. This creates ideal conditions for attackers — a vulnerable, outdated instance that no one actively monitors.

Industry response and security patches

Adobe, the owner of Magento, has released security patches for all supported versions of the platform. However, patch deployment is a process that requires time and planning. For e-commerce stores, every moment of unplanned downtime can mean financial losses, which is why many organizations deploy patches during scheduled maintenance windows.

Sansec, the vulnerability discoverer, recommends immediate actions for all Magento operators:

• Immediately apply available security patches
• Review REST API access logs for suspicious file uploads
• Scan upload directories for polyglot files or PHP files
• Change passwords for all administrator accounts
• Implement Web Application Firewall (WAF) with rules for REST API
• Enable two-factor authentication (2FA) for all administrative accounts

Zero Trust Architecture — the future of e-commerce security

The PolyShell vulnerability reveals a fundamental weakness in the traditional approach to security, where it is assumed that everything within the network is trusted. Zero Trust Network Access (ZTNA) architecture eliminates this assumption by enforcing authentication and authorization for every operation, regardless of user location or device.

In the context of e-commerce, ZTNA means that every access to REST API must be preceded by strong authentication, and each user or application has access only to specific endpoints necessary to perform their function. This approach significantly complicates the attacker's ability to conduct an attack — even if they manage to upload a file, they will not be able to execute it without appropriate permissions.

Implementing ZTNA in e-commerce platforms, however, requires a change in mindset — from open, convenient APIs to strictly controlled, segmented systems. This means additional complexity for developers, but significantly increases security. For organizations that handle millions of transactions and store sensitive customer data, this trade-off is unavoidable.

The PolyShell vulnerability is a reminder that e-commerce security cannot be an afterthought — it must be built into the architecture from the very beginning. Every API endpoint should be treated as a potential attack vector, and every file upload should be treated with caution. For the e-commerce industry, which generates trillions of dollars in revenue annually, the cost of neglecting security is simply too high.