PolyShell: Unauthenticated RCE in Every Production Magento 2 Store

A critical vulnerability in Magento 2 and Adobe Commerce is under active mass exploitation, and every production store running a stable version is exposed. There is no patch available for any current release. Adobe has fixed the issue only in a pre-release alpha build, leaving the entire production install base dependent on web server mitigations that most stores do not have in place.

The vulnerability, named PolyShell by eCommerce security firm Sansec, was disclosed on March 17, 2026. Automated mass scanning began on March 19, and by March 25 Sansec had observed active exploitation attempts against more than half of all vulnerable stores.

What is PolyShell

PolyShell is an unrestricted file upload vulnerability in Magento's REST API. Specifically, it affects the guest cart item endpoints that Magento uses to handle product options with file attachments. The name comes from the attack method: attackers upload polyglot files - valid GIF or PNG images that simultaneously contain executable PHP code - directly to the server's file system.

The vulnerable code has existed since the very first Magento 2 release. Sansec's analysis identifies three missing checks in the file handling logic:

• The submitted option ID is never validated against the product's actual configured options
• File upload processing triggers regardless of whether the product has a file-type option at all
• There is no restriction on file extensions - .php, .phtml, and .phar are all accepted

The only validation present is an image header check, which is trivially bypassed by prepending a valid GIF header to the PHP payload.

No authentication required

The most significant aspect of PolyShell is that exploitation requires no credentials whatsoever. The vulnerable endpoints are the anonymous guest cart routes:

• POST /V1/guest-carts/:cartId/items
• PUT /V1/guest-carts/:cartId/items/:itemId

Any visitor to the storefront can create a guest cart. That cart ID is all an attacker needs to upload an executable file to pub/media/custom_options/quote/ on the server.

Impact depends on web server configuration

Whether a successful file upload translates to remote code execution depends on how the web server is configured to serve the upload directory.

The worst-case scenarios are:

• nginx 2.0.0 to 2.2.x (stock configuration): RCE via the index.php filename trick - uploaded PHP files can be executed directly
• Any nginx with a non-stock configuration passing all .php requests to fastcgi: full RCE
• Apache pre-2.3.5 without php_flag engine 0: full RCE

Even where direct code execution is blocked by a correctly configured web server, a stored XSS attack remains possible on all versions prior to 2.3.5. And critically, even when execution is currently blocked, the uploaded file persists on disk. A future server migration, web server swap, or configuration change could expose the already-planted payload weeks or months later.

What attackers are deploying

Sansec has analysed payloads from active exploitation attempts and identified two primary variants in circulation.

The most common is a GIF89a polyglot webshell dropped as index.php. It authenticates via a cookie value checked against a hardcoded MD5 hash, then accepts arbitrary PHP for execution via eval(base64_decode()). Once installed, the attacker has persistent, authenticated access to execute any code on the server.

A second variant uses a password-protected shell with a different hardcoded hash. Both variants follow the same pattern: a valid image header at the start of the file, followed by a self-contained PHP backdoor.

Since March 23, Sansec has recorded more than 50 distinct IP addresses probing for PolyShell across protected stores. The scanning is automated and indiscriminate - every exposed Magento store is a target.

Affected versions

The unrestricted file upload affects all Magento Open Source and Adobe Commerce stable versions up to and including 2.4.9-alpha2. The fix is present only in 2.4.9-alpha3 and later pre-release builds.

Adobe's patch is catalogued as APSB25-94. However, there is no backported fix for any current production release. Adobe has not announced a timeline for releasing a standalone security patch for supported stable versions.

How to protect your store now

There is no official patch to apply. Until Adobe releases one, store administrators should take the following steps immediately.

Restrict access to the upload directory. The upload destination is pub/media/custom_options/. Your web server should deny all HTTP access to this path. For nginx, confirm that a location block with deny all exists for this directory and is not overridden by a .php$ regex match elsewhere in the configuration. For Apache, verify that an .htaccess file is present and effective. Note that blocking web access prevents execution but does not prevent the upload itself - the malicious file will still be written to disk.

Verify your configuration is actually effective. Many stores run a web server configuration supplied by their hosting provider rather than Magento's recommended setup. Do not assume the block is in place - verify it by attempting to access a test file in that directory directly.

Scan for existing compromise. If your store has been publicly accessible since mid-March, there is a realistic chance an upload attempt has already occurred. Check pub/media/custom_options/ for any files with PHP-compatible extensions or any files with an anomalous creation date. A full malware scan with a tool such as eComscan is advisable.

Monitor for the patch. Watch Adobe's security bulletins for a production release of APSB25-94. When it becomes available, apply it immediately - do not wait for a scheduled maintenance window.

The broader pattern

PolyShell follows a pattern that has become familiar in the Magento ecosystem. The vulnerability sat undetected for years in widely deployed code, the fix arrives in a version that is not yet released to production, and exploitation begins before most store operators are even aware of the issue.

The CosmicSting vulnerability in 2024 followed exactly the same trajectory: disclosed in June, patched in a release that a large proportion of stores had not installed by October when mass exploitation began. The attack surface was identical in one respect - unauthenticated endpoints in the REST API.

For anyone running Magento 2 or Adobe Commerce, the lesson is the same one that keeps repeating. Keeping the platform updated is necessary but not sufficient. Web server configuration needs to be independently verified against Magento's own recommendations, not delegated entirely to a hosting provider. And stores should have a process for detecting compromise, not just for preventing it.

If you are running Magento and are unsure whether your store is protected, check your web server configuration against the guidance above today. This is being actively exploited at scale.