PolyShell CVE-2026-48356: exploited Adobe Commerce and Magento upload

PolyShell, tracked as CVE-2026-48356, needs no account, no admin access and no third-party extension, only a guest shopping cart. Magento's REST API lets an anonymous shopper attach a file to a cart item and writes it to disk with almost no checks. Whether it then runs as PHP, renders as a script or just sits there depends on the web server.

Sansec named the flaw and warned about it on 17 March 2026, when no patch existed for production releases. Attacks began on 19 March, and on 30 March Sansec counted 471 stores compromised in one hour. Adobe backported a fix to its supported release lines on 14 July in bulletin APSB26-73, rated priority 2. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 27 October 2026, with a 10 November deadline for federal agencies.

Who is affected

Adobe Commerce (on-premises and on cloud infrastructure), Magento Open Source and Commerce B2B without the July 2026 patch:

The "2026-jul" fixes are isolated patch files, not Composer releases. Magento Open Source 2.4.5 and older get no patch; Sansec says the vulnerable code dates back to the first Magento 2 release. Sources disagree on 2.4.9: Sansec says the 12 May release carried the fix, but Adobe lists it as affected and patches it.

How PolyShell works

When a cart item carries a custom option of type "file", the REST API accepts an embedded file_info object with base64 data, a MIME type and a filename, and writes the file under pub/media/custom_options/quote/. Sansec found three checks missing: the option ID is never matched against the product's options, the upload runs even when the product has no file option, and no extension is refused. The only check, an image header test, passes a polyglot: a valid GIF or PNG that is also PHP.

The guest-cart item routes, POST /V1/guest-carts/:cartId/items and its PUT counterpart, need no credentials. Sansec says the GraphQL path is not vulnerable.

The outcome varies. Sansec lists code execution where the server runs PHP from that folder: stock nginx configuration on 2.0.0 to 2.2.x, nginx rules that pass every .php file to FastCGI, and Apache before 2.3.5 without php_flag engine 0. Some older or custom setups allow stored cross-site scripting instead. Where nothing executes, the file still waits on disk for a later configuration change.

Is it being exploited?

Yes. CISA added CVE-2026-48356 to KEV on 27 October "based on evidence of active exploitation". Most public detail comes from Sansec:

• Timeline. Probing from 16 March 2026, first attacks on 19 March, mass scanning from more than 50 IP addresses after 23 March.
• Payloads. Polyglot web shells, often named like 780index.php, that run PHP or shell commands behind a cookie or password.
• Persistence. An accesson.php backdoor copied under every writable top-level directory, and a JavaScript loader injected into CMS pages and static blocks.
• Scale. 471 stores in one hour on 30 March. On 24 October Sansec found the same operator's loader on a new domain, deepveindrilling.com, in 83 stores, most of them earlier victims.

Sansec also called PolyShell the likely entry point for a WebRTC payment skimmer it found in March, an assessment rather than a confirmed route. Adobe's bulletin, last updated on 11 August, still says Adobe is not aware of exploits in the wild.

Check your exposure

Run these from the Magento root on each web server:

# Installed release
php bin/magento --version
 
# Anything in the upload folder besides .htaccess deserves a look
find pub/media/custom_options/ -type f ! -name '.htaccess'
 
# The backdoor Sansec found sprayed across writable folders
find . -name 'accesson.php' -type f
 
# Requests for uploaded files or the backdoor (adjust the log path)
grep -E "custom_options/|accesson\.php" /var/log/nginx/access.log

A version string cannot show an isolated patch. After the July CE patch, Adobe's Commerce Version Tool (php vendor/bin/patch-status) reports each CVE as protected or vulnerable, writing cache and log files under var/.

Fix it

1. Move to the newest patch release in your line: 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 or 2.4.4-p18. The 2.4.9 patch applies to 2.4.9 itself.
2. Download the July isolated patch for that release from Adobe's KA-37421 article. Apply the CE file first, then EE and B2B if you run them, each matching your installed version.
3. On-premises, apply each file with patch -p1 and refresh the cache. On cloud infrastructure, the latest Magento Cloud Patches update already includes the fix; adding the isolated patch on top can break the install.
4. Confirm with the Commerce Version Tool. Monthly patches are non-cumulative and go on in sequence; two later Commerce flaws, CVE-2026-75650 and CVE-2026-71362, are also in KEV.

As a stopgap, Sansec advises denying web access to that folder with an nginx rule placed before any .php handler, or on Apache confirming that its .htaccess disables PHP. Akamai shipped a WAF rule on 27 March.

Detect attempts and compromise

Sansec has published these signals:

• Uploaded files. Any .php, .phtml or .phar file in pub/media/custom_options/.
• Backdoors. accesson.php anywhere in the document root. It prints the beacon 8194460 on every request.
• CMS content. Static blocks or pages containing fpCode, se_referrer or localStorage.getItem, or loading lanhd6549tdhse[.]top, additionalver[.]com, deepveindrilling[.]com, jslibrary[.]net or canevaslab[.]com. The update_time column of cms_block shows the latest write.
• Accounts. Admin users you do not recognize. Sansec found a rogue admin account and a GSocket backdoor on a fully patched store that still received the loader in October.

If any fired, treat the server as compromised: the attacker ran code as the web server user and could write to your database, which deleting the script does not undo. Clean up, then change the database, admin and API integration passwords.

Beyond this patch

PolyShell was public for four months before Adobe backported a fix, and reached KEV seven months after attacks began. A priority rating and a "not aware of exploits" line are inputs, not verdicts. After patching, look for what the bug already left behind, and confirm the fix with evidence, not a version string; how a retest verifies a fix explains Rokkhe's approach for findings it has reproduced.