PolyShell: the unpatched Magento vulnerability you need to act on now

On March 17, 2026, Sansec disclosed a critical vulnerability in Magento named PolyShell. Unlike the standard APSB security bulletins that Adobe releases on a schedule, PolyShell arrived mid-cycle and affects all production versions of Magento and Adobe Commerce up to 2.4.9-alpha2.

The severity is high. Adobe has not released a production patch as of this writing. That combination warrants immediate attention.

What PolyShell does

PolyShell exploits a flaw in Magento’s REST API that allows unauthenticated attackers to upload executable files to the server. No login required. No admin credentials required.

Depending on your server configuration, a successful exploit can result in:

• Remote code execution (RCE) — an attacker runs arbitrary code on your server with the permissions of the web server process
• Account takeover — if the uploaded file is a web shell, an attacker can use it to extract session tokens, admin credentials, or customer data

The attack surface is the REST API — specifically, endpoints that accept file uploads. The vulnerability exists at the framework level, meaning stores using Magento Open Source and Adobe Commerce are both affected.

Who is affected

All stores running Magento 2.x through 2.4.9-alpha2. The fix Adobe included in 2.4.9 (GA, released May 12, 2026) addresses PolyShell, but that version is a major release with PHP 8.4/8.5 requirements and framework-level changes. Upgrading to 2.4.9 is not a quick patch — it’s a full version upgrade.

For stores on 2.4.8-p4, 2.4.7-p9, and all earlier production versions, there is no official Adobe patch at the time of writing.

What you can do now

Without a vendor patch available, mitigation is the only option. The following steps reduce your exposure:

1. Restrict access to REST API upload endpoints.

If your store doesn’t use file upload functionality via the REST API — or if that functionality is only used by known, authenticated systems — restrict access at the web server or WAF level.

For nginx, you can block upload-related REST endpoints from public access:

location ~* ^/rest/.*/upload {
    allow 10.0.0.0/8;  # internal/known systems only
    deny all;
}

Adjust the allowed IP range to match your actual integration sources. If you have no REST-based file upload integrations, denying all traffic to those endpoints is low risk.

2. Review your upload directories.

Check whether unexpected files have appeared in directories that should not contain executables — particularly within pub/media/, var/, and generated/. Sansec’s public disclosure provides indicators of compromise to look for.

# Look for PHP files in media directories (should not exist legitimately)
find pub/media/ -name "*.php" -type f
find pub/media/ -name "*.phtml" -type f

# Check for recently modified files in sensitive directories
find . -newer pub/index.php -name "*.php" \
  -not -path "./vendor/*" \
  -not -path "./generated/*" \
  -not -path "./.git/*"

A PHP file in pub/media/ is almost certainly malicious. Investigate any unexpected results immediately.

3. Enable a Web Application Firewall (WAF) if you haven’t already.

A WAF with Magento-specific rulesets can detect and block exploitation attempts for known attack patterns. Cloudflare, AWS WAF, and Sucuri all have Magento-aware configurations. This is a general security improvement that pays dividends beyond PolyShell.

4. Audit your API authentication configuration.

Check Stores → Configuration → Services → Magento Web API → Web API Security. Guest API access should be restricted to what your integrations actually require. If you don’t have integrations that need unauthenticated API access, disabling it reduces the attack surface regardless of the specific vulnerability.

5. Monitor for the patch.

Adobe is expected to release a targeted security patch for production release lines. Watch the Adobe security bulletins page and apply as soon as it’s available. Set a reminder — don’t let this slip off the radar in the day-to-day.

The broader point about unpatched vulnerabilities

PolyShell illustrates a challenge that recurs in the Magento ecosystem: critical vulnerabilities occasionally arrive outside the quarterly patch cycle, and the response window before active exploitation begins is short.

Sansec typically observes mass scanning for newly disclosed Magento vulnerabilities within 48–72 hours of public disclosure. By the time a bulletin is publicly known, attackers are already probing for unpatched stores.

The stores most at risk are those running EOL versions (2.4.3 and earlier) that receive no patches at all, and those where patch application is slow because there’s no process for emergency security updates. If your current setup means a security patch takes more than a few days to apply to production, that’s the underlying risk to address — PolyShell is just the current expression of it.

If you’re on 2.4.9

The PolyShell fix is included in Magento Open Source 2.4.9 and Adobe Commerce 2.4.9. If you completed the 2.4.9 upgrade, you’re covered for this specific vulnerability (alongside the APSB26-49 fixes that shipped in the same release). The 2.4.9 release notes confirm the REST API upload path validation that addresses PolyShell is part of the security improvements in that release.

For everyone else: apply the web server restrictions, run the file system audit, and watch for the targeted patch.