Magento and Adobe Commerce PolyShell (CVE-2026-48356): file upload flaw added to CISA KEV after hundreds of store breaches

What happened

PolyShell is an unrestricted file upload flaw in Magento and Adobe Commerce. Sansec disclosed it on 21 March 2026. The REST API accepts file uploads as part of a cart item’s custom options. When an option has type “file”, Magento takes a file_info object with base64 data, a MIME type and a file name, and writes the file to pub/media/custom_options/quote/. The name comes from polyglot files: code disguised as images. GraphQL uses a different code path and is not affected. Whether an uploaded file can run depends on the web server configuration. Adobe’s sample configuration limits the impact, but Sansec says many stores use custom hosting setups that allow code execution or account takeover through stored XSS (Security Affairs).

At disclosure, Adobe had fixed the bug only in a 2.4.9 pre-release (Security Affairs). Production fixes arrived on 14 July 2026 in bulletin APSB26-73, which lists CVE-2026-48356 as critical, CVSS 9.6, no authentication required (Adobe APSB26-73). The CVE record scores it 9.3 (CVE record).

It was exploited before the production patch existed. Sansec counted 471 stores infected in one hour during a PolyShell wave in March (Sansec). On 24 October, it tied PolyShell to a loader campaign that has hit 953 stores, mostly Magento, since July 2025. Attackers write a JavaScript loader into the cms_block table, which Magento renders into storefront pages. The loader checks whether the visitor is a real shopper and serves nothing to scanners. The final payload has not been recovered. A further 102 stores missing core patches had files uploaded through PolyShell or SessionReaper (CVE-2025-54236). One store on Magento 2.4.7-p1 had PolyShell web shells disguised as PNG files in pub/media/custom_options/quote/ (Sansec; The Hacker News).

CISA added CVE-2026-48356 to its KEV catalog on 27 October 2026, with a federal deadline of 10 November (CISA). Adobe’s bulletin, last updated on 11 August, still said Adobe was not aware of exploits when we checked (Adobe APSB26-73).

Am I affected?

Check your version from the Magento root:

bin/magento --version

Affected versions (Adobe APSB26-73):

• Adobe Commerce: 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, 2.4.4-p18 and earlier.
• Magento Open Source: 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15 and earlier. The bulletin lists no fixed build for Open Source 2.4.5 or older.
• Adobe Commerce B2B: 1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18 and earlier.
• Adobe Commerce Events: 1.6.0 to 1.20.0.

Then hunt, whatever your version. Sansec’s checks (Sansec):

-- Injected loaders in CMS content (add your table prefix if you use one)
SELECT block_id, identifier, update_time FROM cms_block
 WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
SELECT page_id, identifier, update_time FROM cms_page
 WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';

-- Admin accounts you do not recognise
SELECT user_id, username, email, created, logdate FROM admin_user ORDER BY created DESC;

# Uploaded files where none should be
find pub/media/custom_options pub/media/customer_address -type f | head -100

# A backdoor name Sansec lists
find . -name 'accesson.php'

Network indicators Sansec lists include the loader domains deepveindrilling[.]com, additionalver[.]com, lanhd6549tdhse[.]top, neswnsssn[.]click and manulfie[.]click, and payload URLs on leqdger[.]click and crypto-insider[.]top. Search CMS content and outbound logs for them.

What to do now

1. Install the -2026-jul build for your release line: 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul or 2.4.6-2026-jul (Commerce also 2.4.5-2026-jul and 2.4.4-2026-jul), the matching B2B build, and Commerce Events 1.21.0 (Adobe APSB26-73).
2. Also install the SessionReaper fix (APSB25-88, CVE-2025-54236) if you have not. Sansec found uploads through both bugs. SessionReaper has been in CISA KEV since 24 October 2025 (CISA KEV).
3. Clean, even if you are patched. Patching does not remove a loader already in cms_block. Run the queries above, remove injected scripts, and delete web shells and other files in pub/media/custom_options/ and pub/media/customer_address/ that you cannot explain.
4. Remove rogue admin users and change secrets. Sansec recommends changing the database, admin and API integration passwords after a cleanup (Sansec). One store Sansec examined was fully patched and was still infected through a rogue admin account.
5. Stop scripts from running in media folders. Sansec says Adobe’s sample web server configuration largely limits the impact, while custom setups often do not. Check that your web server never executes files under pub/media/. Uploads still land on disk, so this does not replace the patch (Security Affairs).
6. Open Source 2.4.5 or older: APSB26-73 lists no fix. Plan the move to a supported 2.4.x line.

Why this matters

PolyShell was public and attacked in March, four months before Adobe shipped a fix for production versions. The infections that happened in that window live in the database, not in files, so they survive both the patch and file-based scans. A patched store is not a clean store.

Sources

• Adobe security bulletin APSB26-73
• CVE record: CVE-2026-48356
• CISA: two known exploited vulnerabilities added, 27 October 2026
• Sansec: Magento CMS block loader campaign
• Security Affairs: PolyShell flaw exposes Magento and Adobe Commerce to file upload attacks
• The Hacker News: hackers infect 953 online stores
• The Hacker News: Adobe Commerce PolyShell attacks
• CISA Known Exploited Vulnerabilities catalog