A security flaw hiding in Magento's codebase since its very first release has finally surfaced — and it's bad.
Researchers at Sansec disclosed this week that every version of Magento Open Source and Adobe Commerce up to 2.4.9-alpha2 contains an unrestricted file upload vulnerability that requires zero authentication to exploit. They've named it "PolyShell."
The attack works through Magento's REST API, specifically the cart item custom options endpoint. When a product option is configured as type "file," the API accepts an embedded object containing a filename, MIME type, and base64-encoded file data — without adequately validating what that file actually is.
Attackers can pass off a PHP webshell (a script that gives remote control over a server) as an image, and Magento will write it directly to the server's pub/media/custom_options/quote/ directory. From there, depending on how the web server is configured, that file could execute arbitrary code or be used to steal customer sessions through stored XSS (cross-site scripting, where malicious code runs in a victim's browser).
The term "polyglot" — which inspired the PolyShell name — refers to files crafted to be simultaneously valid in two formats. In this case, a file that looks like a legitimate image but functions as executable code when the server processes it.
Adobe has quietly fixed the issue in the 2.4.9-alpha3 pre-release branch as part of security advisory APSB25-94, but no backported patch exists for any current production version. That leaves the vast majority of live stores unprotected. Sansec says the exploit method is already circulating in the wild, and automated attacks are expected to follow shortly.
The blast radius varies. Remote code execution is possible on stock nginx configurations between versions 2.0.0 and 2.2.x, or on any version with non-standard nginx configurations that route .php requests to FastCGI.
Apache stores on pre-2.3.5 without proper engine flags are equally exposed. Even where execution is blocked, the uploaded file sits on disk — a ticking time bomb through any future server migration or misconfiguration.
Until Adobe ships a production patch, Sansec recommends three immediate steps: deploy a web application firewall capable of blocking PolyShell payloads, restrict all access to pub/media/custom_options/ at the web server level, and audit existing deployments for signs of compromise.