October 28, 2026 14 min to read

Magento PolyShell Hits CISA KEV: What Store Owners Must Do Now

A guest-cart upload bug became a skimmer pipeline, and patching alone will not evict the attackers

If you run an online store on Magento Open Source or Adobe Commerce, this week brought two pieces of news that belong together. CISA has added PolyShell (CVE-2026-48356), an unauthenticated file-upload flaw in Magento’s guest cart API, to its Known Exploited Vulnerabilities (KEV) catalogue. And Sansec has published fresh research showing that the crew behind the March PolyShell mass-exploitation wave is still active, now running a scanner-evading JavaScript loader across 953 stores.

The uncomfortable part is this: Adobe shipped the backported fix in July, yet stores keep getting infected. Some were compromised before they patched and were never cleaned. At least one store was reinfected while fully patched. So this post covers more than “apply the update”. It explains how to find out whether attackers are already inside your store and how to get them out.

TL;DR / Key takeaways

• What: PolyShell (CVE-2026-48356, Adobe CVSS 9.6) lets an unauthenticated attacker upload a file through Magento’s guest cart REST API. Polyglot “image” files hiding PHP code have been used as webshells since March 2026.
• Why now: CISA added it to KEV this week (federal due date 10 November 2026). Sansec reports a long-running loader campaign on 953 stores, with a new domain (deepveindrilling[.]com) and browser fingerprinting added on 23 October.
• Patching is necessary but not enough: Files and database injections planted before you patched stay in place. Sansec documented a fully patched 2.4.7-p10 store that was reinfected.
• Also patch BlockStrap: Adobe’s October bulletin APSB26-153 fixes CVE-2026-103849, an unauthenticated CVSS 10.0 code-execution bug. Sansec has not yet seen it exploited but expects attacks soon.
• Do today: Confirm you are on the -2026-jul (PolyShell) and -2026-oct (BlockStrap) releases, block pub/media/custom_options/, hunt for webshells and cms_block injections, audit admin users, and rotate credentials.

Timeline

Dates are from Sansec, Adobe, HOL and SecurityOnline. Store counts are Sansec’s observations from its own customer base and scanning, not a census of every Magento store.

How PolyShell works

PolyShell is a classic unrestricted file upload (CWE-434), reached through a route most store owners have never thought about.

Magento products can have custom options, and one option type is a file upload (think “upload your logo for this printed mug”). Sansec found that the anonymous guest cart REST endpoints, POST /rest/V1/guest-carts/:cartId/items and PUT /rest/V1/guest-carts/:cartId/items/:itemId, accept a file_info object (base64 data, MIME type and filename) inside a cart item’s custom options and write it to pub/media/custom_options/quote/.

Three checks were missing:

• Magento did not confirm the option ID belonged to the product.
• The upload code ran even if the product had no file option at all.
• Dangerous extensions such as .php, .phtml and .phar were not blocked.

The only gate was an image-header check. A file that starts with GIF89a and then contains PHP, a polyglot, passes it. Hence the name.

Whether an upload becomes remote code execution depends on the web server. On Adobe’s sample nginx and Apache configurations the folder is not served. But Sansec lists several common setups where it is: stock nginx configs for Magento 2.0.0 to 2.2.x, any nginx config that passes every .php request to PHP-FPM, and Apache before 2.3.5 without php_flag engine 0. Custom and hand-tuned hosting configs are where this tends to go wrong. Even when execution is blocked, Sansec notes that “the uploaded file stays on disk”, ready for a later config change to expose it.

GraphQL cart mutations use a different code path and are reported as not vulnerable.

From webshell to skimmer pipeline

Sansec describes a fully automated chain:

1. Upload a GIF89a polyglot webshell through the guest cart API.
2. Use it to drop a backdoor named accesson.php into many writable directories.
3. Inject an obfuscated JavaScript loader into Magento CMS pages and static blocks (the cms_block database table, not theme files or core_config_data).

That loader is the long game. It stores its payload in the shopper’s browser localStorage, so a visitor who received it once runs it again on every later page view, even after the attacker’s domain is blocked. The October version fingerprints each visitor, checking for automation signals such as navigator.webdriver, Selenium globals and ChromeDriver properties, plus GPU, CPU, screen, time zone and language. The server then decides what to send, and scanners get a harmless decoy. As Sansec puts it, “scanners get nothing”. This is why an external website scan can report a store as clean while real customers are being served malicious code.

Sansec has not yet captured the final payload, so the end goal is not confirmed. Earlier stages redirected visitors to crypto-themed domains, including one imitating the Ledger wallet brand.

The campaign also uses other doors. Sansec found that of 169 infected Magento 2 installs missing at least one core patch, 102 (60%) showed uploads via PolyShell or SessionReaper (CVE-2025-54236). The broader e-commerce threat is wide too: on 27 October BleepingComputer reported a separate skimming gang that hijacked a shared analytics script on the Brazilian checkout platform Convertr to steal card data. Checkout pages are a prime target right now.

Am I affected?

You are exposed if you run any of these below the fixed release (per Adobe APSB26-73):

Older, end-of-life Magento 2 lines and Magento 1 have no official fix. Forks such as Mage-OS ship their own releases, so check your vendor.

You may already be compromised, even if you have patched, if any of these are true:

• You were unpatched at any point between 19 March and your July patch date.
• Your web server config is custom, or you have changed it since installation.
• pub/media/custom_options/ contains anything other than .htaccess.
• CMS blocks or pages contain script tags you did not add.
• There are admin accounts you do not recognise.

Check for compromise

Run these from your Magento root on the server (read-only commands; take a backup and snapshot first if you suspect compromise, so you preserve evidence). The file and database checks come from Sansec’s published guidance; the extra image grep is a simple addition of ours.

1. Uploaded files and backdoors

~|#| Anything except .htaccess here is suspicious; .php/.phtml/.phar is a strong compromise signal
find pub/media/custom_options/ pub/media/customer_address/ ~|-|type f ! ~|-|name '.htaccess'

~|#| The backdoor dropped after the March wave
find . ~|-|name 'accesson.php' ~|-|type f

~|#| Image~|-|named files that actually contain PHP
grep ~|-|rl ~|-|~|-|include~|=|'*.gif' ~|-|~|-|include~|=|'*.jpg' ~|-|~|-|include~|=|'*.png' '~|<|?php' pub/media/ 2>/dev/null

2. Injected loaders in the database

Add your table prefix if you use one. The update_time column shows the attacker’s most recent write.

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%';

Also search CMS content for the published loader domains below, and review admin_user for accounts you did not create.

3. Logs

Look in web server logs for POST or PUT requests to /rest/V1/guest-carts/ that carry file_info or unusually large bodies, followed by requests for files under pub/media/custom_options/. A successful request to a .php file in a media folder is a red flag.

Published indicators (Sansec)

Remember Sansec’s caveat: manual searches only find known indicators. A clean result reduces risk; it does not prove a store is clean.

Lock down the upload folder

Block access to the folder even after patching. For nginx, place this before any \.php$ location block:

location ~* ^/pub/media/custom_options/ {
    deny all;
    return 403;
}

For Apache, confirm pub/media/custom_options/.htaccess contains:

~|<|IfModule mod_php.c>
    php_flag engine 0
~|<|/IfModule>
Deny from all

Sansec stresses that blocking web access “does not prevent uploads”. A WAF rule on the guest cart API or the patch itself is what stops the upload.

Don’t forget BlockStrap (CVE-2026-103849)

On 13 October Adobe released APSB26-153, fixing 11 CVEs. The headline is CVE-2026-103849, nicknamed BlockStrap by Sansec: a CVSS 10.0 template-engine injection that lets an unauthenticated attacker run arbitrary PHP. Adobe rated the bulletin Priority 2 and reports no known exploitation. Sansec reports “no exploitation observed yet”, but it reproduced four code-execution routes within 24 hours and argues Priority 2 is too low, given that the related StyleSmuggler bug went from hotfix to mass exploitation in three days.

Fixed releases are the -2026-oct builds (for example 2.4.9-2026-oct, 2.4.8-2026-oct, 2.4.7-2026-oct). BlockStrap and the September StyleSmuggler hotfix are separate; you need both. Sansec suggests checking that the fix actually landed, because Composer patch plugins can silently skip hunks:

~|#| 0 means the BlockStrap fix is missing
grep ~|-|c resolveDeferredDirectives vendor/magento/framework/Filter/Template.php

~|#| StyleSmuggler hotfix status (Adobe Commerce / Quality Patches Tool)
vendor/bin/magento~|-|patches ~|-|n status | grep "39341\|Status"

Response checklist

Immediately (today)

1. Patch to the -2026-oct release for your line, which includes the July PolyShell fix. If you cannot, at minimum apply APSB26-73 and the BlockStrap isolated patch, and put WAF rules in front of the guest cart API.
2. Block pub/media/custom_options/ at the web server, as above.
3. Run the compromise checks. If you find anything, treat it as an incident: snapshot the server and database before cleaning.
4. Check payments. If you find a loader or skimmer, notify your payment provider or acquirer promptly; card-data exposure has contractual and regulatory reporting duties.

This week

1. Clean thoroughly: remove webshells, accesson.php copies and injected cms_block/cms_page content. As Sansec warns, removing the script “leaves an attacker’s write access to the database intact”.
2. Delete unknown admin accounts and check for unfamiliar processes and cron jobs. Sansec’s reinfected patched store had a rogue admin and a GSocket backdoor.
3. Rotate secrets: database, admin, SSH/SFTP, API integration tokens and payment gateway credentials. Adobe also advises rotating the encryption key after StyleSmuggler.
4. Confirm SessionReaper (APSB25-88) is applied; the same crew uses it.
5. Rescan from a real browser profile and with a server-side scanner. Remote scanners alone can be fooled by the fingerprinting.

Longer term

1. Subscribe to Adobe security bulletins and set a Magento patch SLA in days, not months. Two critical template-engine bugs arrived in six weeks.
2. Use file-integrity monitoring on the code base and alerting on changes to cms_block, cms_page and admin_user.
3. Deploy a Content Security Policy with reporting on checkout pages, and limit third-party scripts. The Convertr case shows trusted analytics scripts can be turned against you.
4. Plan your way off unsupported versions. Stores on end-of-life lines will keep missing fixes.

OffensioX perspective

PolyShell is a lesson in how long an e-commerce compromise lasts. The flaw was public in March and patched for most stores in July, yet in October the same operators are still re-infecting the same shops: 60 of the 83 stores on the newest domain had already been infected by an earlier loader. Attackers who gain a foothold put their persistence in the database, not in files a patch overwrites. And because the loader hides from scanners and caches itself in shoppers’ browsers, a store owner who only patched and ran an online scan may honestly believe they are clean.

CISA’s KEV listing is useful pressure, but most store owners do not track KEV. For Pakistan’s fast-growing e-commerce sector, where many stores run Magento on agency-managed or shared hosting with custom web server configs, the risk is real: the setups that turn an upload into code execution are the hand-tuned ones. If you run Magento, treat this week as a prompt to patch, verify and hunt, not just update. If you would like a second pair of eyes, OffensioX offers penetration testing and e-commerce security assessments covering the application, server configuration and checkout scripts.

References

• SecurityOnline – CISA KEV Catalog Adds Magento and Brotli Vulnerability
• HOL – Magento PolyShell (CVE-2026-48356) is on CISA KEV
• Adobe – Security bulletin APSB26-73 for Adobe Commerce
• Sansec – PolyShell: unrestricted file upload in Magento and Adobe Commerce
• Sansec – Mass PolyShell attack wave hits 471 stores in one hour
• Sansec – deepveindrilling.com: Magento CMS block loader hits 953 stores
• Infosecurity Magazine – Hackers Infect 953 Online Stores With Scanner-Evading Code
• Sansec – BlockStrap: Magento and Adobe Commerce RCE (CVE-2026-103849)
• Meetanshi – Adobe Commerce Security Update APSB26-153 (October 2026)
• BleepingComputer – Hackers hijack Convertr analytics script to steal payment card data
• NVD – CVE-2026-48356
• CISA – Known Exploited Vulnerabilities Catalog