Hackers are actively exploiting Magento PolyShell flaw to upload webshells and seize store access

A newly disclosed Magento and Adobe Commerce flaw named PolyShell is under active exploitation, and attackers are using it to upload disguised PHP payloads through guest cart endpoints. Sansec says the bug lets unauthenticated attackers push executable files to stores through the REST API, with remote code execution possible on many real-world server setups.

The issue is serious because it does not need a login on the most dangerous routes. Sansec says the vulnerable flow sits in anonymous guest cart API endpoints, where attackers can abuse file upload logic meant for product custom options and write files into pub/media/custom_options/quote/.

The campaign has already moved beyond proof of concept. Sansec says it saw first probing on March 16, 2026, active exploitation from March 19, and mass automated scanning by March 23. The company says PolyShell exploitation attempts hit 23% of protected stores, and it logged more than 50 IPs probing targets.

What makes this bug especially dangerous is the way attackers hide the payload. Sansec says they upload polyglot files, which appear to be valid GIF or PNG images but also contain executable PHP code. In the wild, the firm has seen cookie-authenticated webshells, command-execution shells, and obfuscated filenames designed to slip past basic checks.

How the Magento flaw works

Sansec says Magento’s REST API accepts file uploads for cart item custom options. When that code path handles embedded file_info data, the application writes the uploaded file to disk. According to Sansec, three missing checks make the bug exploitable: Magento does not properly validate the option ID, does not require the option to actually be a file-type field, and does not block executable extensions such as .php, .phtml, or .phar.

That combination lets attackers bypass normal expectations around product setup. In other words, a store does not need to expose a normal file-upload product option for the attack to work the way admins might assume. Sansec also says GraphQL uses a different code path and is not vulnerable in this case.

Why “complete account access” is a fair warning

Once a malicious PHP file lands on a server and the web server executes it, the attacker can move from simple upload to remote command execution or persistent webshell access. Sansec says some observed payloads allow arbitrary code execution through requests, while others support file upload or password-gated shell access.

Even where direct execution is blocked, the risk does not disappear. Sansec warns that the file can remain on disk, which means a later config change, migration, or web server swap could suddenly expose the payload. That creates a long tail of risk for merchants who assume a blocked execution path equals a clean system.

Who is affected

Sansec says all Magento Open Source and Adobe Commerce versions up to 2.4.9-alpha2 are affected by the unrestricted file upload issue. It adds that remote code execution depends on web server configuration, including stock Nginx 2.0.0 through 2.2.x in one common path, plus broader cases where .php files get passed to FastCGI or Apache lacks the expected PHP restrictions.

Adobe’s earlier APSB25-94 bulletin from October 2025 lists production security updates for Adobe Commerce and Magento Open Source, including 2.4.8-p3, 2.4.7-p8, and 2.4.6-p13, and says Adobe was not aware of in-the-wild exploitation of the issues covered there at that time. Sansec’s key point is narrower: it says the PolyShell fix exists in the 2.4.9-alpha3 pre-release branch, but no isolated production patch specifically for this flaw is currently available to merchants running today’s stable production lines.

PolyShell at a glance

What admins should do right now

Sansec says merchants should treat this as an active incident response problem, not just a routine patching issue. Since attackers are already mass scanning, stores should check for compromise immediately and not wait for a future maintenance cycle.

Recommended actions:

• Block direct access to pub/media/custom_options/ at the web server level.
• Review Nginx and Apache rules to make sure PHP execution cannot occur from that upload path.
• Scan for uploaded webshells and suspicious files in pub/media/custom_options/quote/.
• Review recent requests to guest cart endpoints for unusual file upload behavior.
• Use a WAF or equivalent controls to block exploitation attempts while waiting for a production-safe remediation path.

FAQ