Magento PolyShell (CVE-2026-48356) is on CISA KEV: install APSB26-73, then hunt the webshells

CISA added CVE-2026-48356 to its Known Exploited Vulnerabilities catalog on Tuesday, October 27 (catalog 2026.10.27, released 3:00 PM ET). This is PolyShell: any visitor can upload a file through a Magento store's guest cart REST API, with no login, and it lands on disk under pub/media/custom_options/quote/. If the web server will serve or run files from that folder, the upload becomes a webshell. Federal agencies have until November 10 to fix it. Store owners should not wait that long, because this bug has been exploited at scale since March.

Adobe fixed it for supported release lines in APSB26-73 on July 14. That bulletin still says Adobe "is not aware of any exploits in the wild." Sansec has been documenting the opposite for seven months: 471 stores hit in one hour on March 30, and a skimmer loader crew that has used PolyShell uploads to plant code on Magento shops ever since.

How to fix

Install the APSB26-73 update for your release line, then clean up. The patch only stops new uploads. It does not remove a shell that is already on disk.

# 1. What are you running? (run from the Magento root)
bin/magento --version
composer show magento/product-community-edition 2>/dev/null || composer show magento/product-enterprise-edition

# 2. Until the update is deployed, stop the web server from serving the upload folder.
#    nginx: put this BEFORE any \.php$ location block
location ~* ^/pub/media/custom_options/ {
    deny all;
    return 403;
}
#    Apache: pub/media/custom_options/.htaccess must exist and deny access,
#    and pub/media/.htaccess must keep "php_flag engine 0"

Blocking the folder is a stopgap, not a fix. Uploads still succeed through the API and the files stay on disk, where a later server migration or config change can expose them. Only the update, or a WAF rule on the API call itself, stops the upload.

What PolyShell actually does

Magento lets a product have a "file" custom option, so a shopper can attach artwork to a print order. The REST endpoints POST /rest/V1/guest-carts/:cartId/items and PUT /rest/V1/guest-carts/:cartId/items/:itemId accept a file_info object with base64 data, a MIME type and a filename. Sansec found three missing checks: Magento never confirmed that the option ID belongs to the product, never checked that the product even has a file option, and never restricted the extension. The only gate was an image header check with getimagesizefromstring, so a PHP file that starts with GIF89a passes. A guest cart ID and any SKU are enough, and both are free to get on a public store.

Whether the file becomes remote code execution depends on the web server. On Adobe's sample nginx and Apache configs, the folder is denied and PHP is off, so the request for the file returns 404. Searchlight Cyber reproduced RCE only after removing both .htaccess files. The catch is that many stores do not run Adobe's sample config. They run whatever the host shipped, and Sansec found many stores serving files from the upload directory.

Adobe scores this 9.3 with "user interaction required" and calls the impact privilege escalation. That reflects the stored XSS case on a locked-down server. The upload itself needs no victim and no account. The attacks Sansec logged were server-side webshells, not phishing.

Check your store

These checks come from Sansec's October 24 write-up on the crew still using PolyShell uploads. Run them even if you patched in July.

# Anything uploaded through cart custom options or address uploads
find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'

# Backdoor name dropped in the March wave
find . -name 'accesson.php' -type f

-- Injected skimmer loaders live in CMS content, not theme files
SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';
-- repeat on cms_page

A legitimate custom options folder holds images a shopper attached. A .php or .phtml file there, or a "PNG" that starts with <?php after the GIF header, is a shell. Sansec found one store on 2.4.7-p1 with PolyShell webshells disguised as PNG files in pub/media/custom_options/quote/. Also check admin_user for accounts you did not create.

Patching does not evict anyone

This is the part most write-ups skip. Sansec saw the deepveindrilling.com loader land on a store running 2.4.7-p10 with no missing core patches, one hour after a clean scan. That store had a rogue admin account from September 16 and a GSocket backdoor from September 24. The attacker came back through access they already had. If your store was ever exposed, the update closes the door that was used, not the ones that were added.

The loader itself is quiet on purpose. Its domains rotate every few months (lanhd6549tdhse.top in March, additionalver.com in June, deepveindrilling.com in October), and the October version fingerprints the browser so automated scanners get a clean page. Deleting the script from cms_block does not remove the database access that wrote it. After cleanup, change the database, admin and API integration passwords.

Who is not in scope

• Stores already on the APSB26-73 releases (the -2026-jul builds) are not open to new PolyShell uploads. They still need the cleanup checks above if they were exposed before the update.
• Magento's GraphQL cart mutations take a different code path and are not the vulnerable entry point, per R-fx Networks' analysis. The REST guest cart endpoints are.
• A server that denies pub/media/custom_options/ and disables PHP there turns a successful upload into a dead file. That limits damage. It does not make you unaffected.

What this is not

This is not a new bug and there is no new patch today. The fix has existed since July 14. What changed is that the US government now officially lists it as exploited, which usually pulls in compliance-driven scanning and a second wave from people who were not paying attention before.

Timeline

• March 17, 2026: Sansec publishes PolyShell research. No patch for production lines.
• March 30, 2026: Mass wave, 471 stores compromised in one hour.
• May 12, 2026: Magento 2.4.9 ships with the fix. Older lines still exposed.
• July 14, 2026: Adobe APSB26-73 assigns CVE-2026-48356 and backports the fix to supported lines.
• October 7 to 23, 2026: Same crew moves its loader to deepveindrilling.com, mostly on stores it already owned.
• October 27, 2026: CISA KEV add, due date November 10.

The HOL Guard evidence pack for CVE-2026-48356 keeps the source record. Earlier Magento coverage: CVE-2026-103849 unauthenticated RCE and CVE-2026-71362 on KEV.

References

• Adobe APSB26-73
• CISA KEV entry for CVE-2026-48356
• NVD CVE-2026-48356
• Sansec: PolyShell technical analysis
• Sansec: PolyShell mass attack wave
• Sansec: deepveindrilling.com CMS block loader
• Searchlight Cyber: PolyShell file upload to RCE
• R-fx Networks: PolyShell detection and mitigation