HomeOctober 2026 patch cycleCVE-2026-48356 PolyShell: Magento and Adobe Commerce hit
Call: Patch nowCategory: Enterprisefrom 2026-10
CVE-2026-48356 PolyShell: Magento and Adobe Commerce hit
Part of October 2026 patch cycle
- Vendor
- Adobe
- Products
- Adobe Commerce, Magento Open Source, and Adobe Commerce B2B
- Published
- Status
- Open
Call: Patch now. PolyShell, CVE-2026-48356, lets anyone with an internet connection upload an executable file to a Magento or Adobe Commerce store through the guest-cart REST API. No login needed. Adobe fixed it on July 14 in APSB26-73. On Oct 27, CISA added it to KEV and gave federal agencies until Nov 10. If your store isn’t on a July 2026 build, it has been open for seven months during a mass-exploitation campaign. Patch, then go looking for what’s already on disk.
Is it exploited? Yes, and has been since March. Sansec, which found and named the bug, saw the first attacks on Mar 19 and mass scanning from Mar 23. By Mar 30 it had seen attacks against 79.5% of the stores it protects, and by Apr 14, malicious uploads on 82%. Adobe’s bulletin, last updated Aug 11, still says Adobe “is not aware of any exploits in the wild.” CISA is, and so is Sansec. Go with them. (Sansec (opens in a new tab), CISA (opens in a new tab))
What breaks: Not your store’s uptime, which is the problem. Attackers post a polyglot file (a valid GIF or PNG that’s also PHP) to /V1/guest-carts/:cartId/items, and Magento writes it to pub/media/custom_options/quote/. Magento doesn’t check the option ID or the option type, and doesn’t block .php, .phtml or .phar. Whether that turns into code execution depends on your web server config:
- nginx setups that pass every
.phpfile to FastCGI execute it. - Some Apache setups execute it too.
- Everyone else gets stored XSS at minimum.
After that come accesson.php backdoors copied into an assets/images/ folder under every top-level directory the attacker can write to, plus JavaScript skimmer loaders injected into CMS pages and blocks.
Who’s hit: Every Magento Open Source and Adobe Commerce store not on the July 2026 builds. Per APSB26-73 that means Commerce 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18 and earlier, the matching Open Source lines down to 2.4.6, and Commerce B2B. Sansec says the vulnerable code goes back to the first Magento 2 release.
Fix: Install your line’s -2026-jul build: 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul, 2.4.6-2026-jul, and for Commerce only, 2.4.5-2026-jul and 2.4.4-2026-jul. B2B has matching 1.5.3 to 1.3.3 -2026-jul builds.
Then hunt. The patch stops new uploads but doesn’t remove the ones already there. Per Sansec:
- Any
.php,.phtmlor.pharfile underpub/media/custom_options/is a strong sign of compromise. find /var/www -name 'accesson.php' -type facross the whole docroot.- Search CMS pages and static blocks for
lanhd6549tdhse[.]top,jslibrary[.]netandcanevaslab[.]com.
If you can’t patch today: Deny web access to pub/media/custom_options/. On nginx, put the deny block before your .php location, or the PHP handler wins. On Apache, check the directory’s .htaccess has php_flag engine 0 and Deny from all. That stops execution, not uploads, so the files still land on disk and wait for your next server migration. Only a WAF rule on the guest-cart item endpoints blocks the upload itself.
Sources: Adobe APSB26-73 (opens in a new tab), Sansec (opens in a new tab), CISA KEV alert, Oct 27 (opens in a new tab).