PolyShell Vulnerability Exposes Magento Stores to Silent Takeover and Remote Code Execution

Introduction: A Quiet Threat with Explosive Potential

A newly uncovered vulnerability known as “PolyShell” is raising serious concerns across the eCommerce landscape. Affecting all stable installations of Magento Open Source and Adobe Commerce version 2, this flaw opens the door to unauthenticated attackers, allowing them to execute malicious code or even take over user accounts. While no confirmed active exploitation has been reported yet, security experts warn that the situation could escalate quickly. The exploit method is already circulating, and once automation kicks in, thousands of online stores could be at risk within hours.

Summary: How PolyShell Works and Why It Matters

The PolyShell vulnerability stems from a flaw in Magento’s REST API, specifically in how it handles file uploads tied to custom product options in the shopping cart. When a product includes an option of type “file,” Magento processes a file_info object that contains base64-encoded data, along with a MIME type and filename. This data is then written directly to the server in the pub/media/custom_options/quote/ directory.

The real danger lies in how attackers can manipulate this functionality. By crafting a polyglot file, one that can behave both as an image and as executable code, attackers can bypass typical validation checks. Depending on the server configuration, this can lead to either remote code execution (RCE) or stored cross-site scripting (XSS), ultimately resulting in account takeovers.

Security researchers at Sansec analyzed a wide range of Magento and Adobe Commerce stores and discovered that many of them expose uploaded files in publicly accessible directories. This significantly increases the attack surface. If an attacker successfully uploads a malicious file and accesses it via the web, they could execute arbitrary code on the server.

Although Adobe has released a fix, it is currently limited to an alpha version (2.4.9-alpha2), meaning production environments remain vulnerable. Adobe has suggested a sample web server configuration to mitigate the issue, but many stores rely on default hosting setups that may not implement these protections effectively.

In the meantime, administrators are urged to take immediate defensive actions. These include restricting access to the vulnerable upload directory, verifying that server rules properly block access, and conducting thorough scans for malicious files such as web shells or backdoors.

Despite outreach efforts, there is still no official timeline for when a stable security patch will be released for production systems.

What Undercode Say: The Real Risk Lies in Configuration, Not Just Code

The PolyShell vulnerability highlights a recurring issue in modern web security: the dangerous intersection between application logic and server configuration. While the flaw originates in Magento’s API design, the severity of exploitation depends heavily on how the web server is configured.

This means two stores running the exact same Magento version could face drastically different risk levels. One might be fully exploitable, allowing remote command execution, while another might only be vulnerable to limited XSS attacks. This inconsistency makes the threat harder to assess and even harder to defend against at scale.

The use of polyglot files is particularly concerning. These files are designed to evade detection by appearing harmless under one context while behaving maliciously under another. Traditional security mechanisms, such as file type validation or MIME checks, often fail against such techniques. This signals a shift toward more sophisticated, multi-layered attack strategies that exploit assumptions rather than just code weaknesses.

Another critical issue is the delayed availability of a production-ready patch. Releasing a fix only in an alpha version puts businesses in a difficult position. Running alpha software in production is rarely acceptable, especially for revenue-generating platforms. This leaves store owners stuck between risk exposure and operational instability.

Additionally, the widespread reliance on hosting providers introduces another layer of vulnerability. Many store owners do not directly manage their server configurations and instead depend on default setups. If these configurations fail to restrict access to sensitive directories, attackers gain an easy entry point.

From a broader perspective, PolyShell reinforces the importance of defense-in-depth strategies. Relying solely on application-level fixes is no longer sufficient. Organizations must combine secure coding practices with hardened server configurations, continuous monitoring, and proactive threat hunting.

The mention of automated attacks is also significant. Once an exploit becomes publicly available, it is only a matter of time before attackers integrate it into scanning tools and botnets. At that point, the scale of attacks can increase exponentially, targeting thousands of vulnerable stores simultaneously.

In essence, PolyShell is not just a vulnerability. It is a warning. A reminder that modern cyber threats are evolving faster than traditional defense mechanisms, and that security must be treated as a continuous process rather than a one-time fix.

Fact Checker Results

✅ The PolyShell vulnerability affects Magento Open Source and Adobe Commerce version 2 installations.

✅ The exploit involves file upload handling via the REST API and can lead to RCE or XSS.

❌ No confirmed widespread active exploitation has been reported yet, but risk escalation is highly likely.

Prediction

The PolyShell vulnerability is likely to become a widespread attack vector within a short time frame. 🤖
Automated exploitation tools will emerge, targeting misconfigured Magento servers at scale. ⚠️
Organizations that delay mitigation steps will face increased risk of data breaches and service disruptions. 🚨