CISA Adds Magento PolyShell to KEV

Quick verdict: CISA added CVE-2026-48356, the Magento and Adobe Commerce unrestricted file upload that Sansec calls PolyShell, to its Known Exploited Vulnerabilities catalog on October 27, 2026. The KEV entry gives federal civilian agencies until November 10 to remediate. Adobe shipped the backport for supported release lines in APSB26-73 on July 14, 2026, so the federal deadline arrives 119 days after a patch was available. A separate CMS-block malware campaign has infected 953 stores, mostly Magento, since July 2025; Sansec estimates 471 of those stores were injected through PolyShell. Patching is necessary. It is not sufficient if a webshell or a rogue administrator is already inside.

What CISA added

CISA’s October 27 alert names CVE-2026-48356 as "Adobe Commerce and Magento Unrestricted Upload of File with Dangerous Type Vulnerability" and adds it to the KEV catalog based on evidence of active exploitation. The other entry in the same alert is CVE-2026-111497, a Google Brotli flaw. Only the Magento entry is in scope here.

The deadline is a federal compliance date, not a private-sector mandate. The practical consequence for everyone else is that CISA has now attached its name to the evidence of exploitation. A KEV listing also feeds scanner signatures and vulnerability-management priorities. It does not patch a store.

The four-month gap

Adobe’s APSB26-73 bulletin was published July 14, 2026, and last updated August 11. It carries a Priority 2 rating and lists fixed builds for Adobe Commerce, Adobe Commerce B2B, and Magento Open Source across the 2.4.4 through 2.4.9 lines. The bulletin describes CVE-2026-48356 as critical, with a CVSS base score of 9.6 and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L. Authentication required to exploit: No. The vector includes UI:R, so the exploit path assumes user interaction; Sansec’s description focuses on direct uploads through the guest cart REST API. The two are not a contradiction so much as different parts of the attack surface.

Adobe’s July bulletin also says the company was not aware of any exploits in the wild for the issues it addressed. CISA’s KEV addition is the later, contrary signal: the catalog is built on evidence of active exploitation.

The same bulletin also fixes CVE-2026-48358, an arbitrary code execution flaw in the webhooks component. Adobe rates it 9.1, requires authentication, and notes that it applies to webhooks only. That is a separate issue; it explains why APSB26-73 is a larger patch than the PolyShell fix alone, not why PolyShell matters less.

Sansec’s PolyShell research says Adobe fixed the underlying code in the 2.4.9 line in May 2026, but did not backport it to older supported lines until APSB26-73 in July. The KEV entry arrived on October 27, 105 days after the July backport. The federal due date is 119 days after it. That gap is the story: the fix was not new on the day CISA listed it.

What PolyShell actually does

Sansec named the vulnerability PolyShell and published the research on March 17, 2026. The flaw is in Magento’s REST API handling of cart item custom options. When a product option has type "file," Magento processes an embedded file_info object containing base64-encoded file data, a MIME type, and a filename. The file is written to pub/media/custom_options/quote/ on the server.

Sansec identifies three missing checks: the submitted option ID is not validated against the product’s actual options, the file-upload path triggers even when the product has no file-type option, and dangerous extensions such as .php, .phtml, and .phar are not blocked. The only validation is an image header check, which a polyglot file can satisfy. The most exposed endpoints are the anonymous guest cart routes:

• POST /V1/guest-carts/:cartId/items
• PUT /V1/guest-carts/:cartId/items/:itemId

Those routes require no credentials. GraphQL mutations use a different code path and are not vulnerable, according to Sansec. Whether an uploaded file becomes code execution depends on the web server configuration; Sansec documents the combinations that make it executable and the blocking rules that stop it.

What the 953-store campaign does and does not show

The 953-store campaign is a separate CMS-block malware campaign, not a count of PolyShell uploads. The Hacker News, citing Sansec, reported on October 26 that an unknown actor has infected 953 online stores, most of them Magento, since July 2025. The payload is a JavaScript loader hidden in Magento CMS blocks; it checks whether a visitor is a real shopper or a security scanner before serving the next stage.

Within that 953-store campaign, Sansec estimates 471 stores were injected through PolyShell and another 102 through files uploaded via PolyShell or SessionReaper, CVE-2025-54236. One store on Magento 2.4.7-p1 had PolyShell webshells disguised as PNG images in pub/media/custom_options/quote/, next to the loader in a CMS block. Another store on 2.4.7-p10 had no missing core patches but was compromised through a rogue administrator account, which was then used to inject the code. That second case is the caution: patch level is not the same as clean.

Sansec also reports that its Shield blocked PolyShell attempts against 79.5% of protected Magento stores after the March disclosure, and that the CMS-malware campaign’s loader domains have rotated through manulfie[.]click, neswnsssn[.]click, lanhd6549tdhse[.]top, additionalver[.]com, and deepveindrilling[.]com. Those figures come from Sansec’s telemetry, not an independent census.

What to do

1. Patch to an APSB26-73 build. Check your exact Commerce or Open Source version against the bulletin’s affected and updated version tables. A patch for one line does not cover another; Adobe’s table is the authority.
2. Scan for webshells before you declare victory. Look for .php, .phtml, or .phar files under pub/media/custom_options/, and search the document root for accesson.php, the secondary backdoor Sansec describes. A patched store can still contain an intruder’s files.
3. Audit CMS content and administrators. Search cms_block and cms_page for unexpected script references, and review admin accounts for ones you did not create. The 2.4.7-p10 case shows why the admin audit is not optional.
4. Block the upload directory at the web server. Sansec’s nginx and Apache rules deny access to pub/media/custom_options/. Blocking web access does not prevent the upload itself; a WAF rule that blocks the vulnerable API call is the control that stops the write.
5. Set your own deadline. November 10 is the FCEB date. If you run a store, the useful date is the one you set for patch verification plus a compromise scan, not the federal calendar.

Bottom line

CISA’s KEV entry is a prioritization signal, not a new vulnerability. The patch has been available since July 14, the exploit path has been public since March, and the CMS-malware campaign has had more than a year to run. The remaining risk is concentrated in stores that treated APSB26-73 as a routine Priority 2 update, and in stores that patched without checking whether an intruder was already inside. Patch, scan, audit admins, and block the upload path. The order matters less than doing all four.

Sources and References

• CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog, October 27, 2026
• CISA Known Exploited Vulnerabilities Catalog
• Adobe Security Bulletin APSB26-73: Security update available for Adobe Commerce, July 14, 2026; last updated August 11, 2026
• Sansec: PolyShell, unrestricted file upload in Magento and Adobe Commerce, March 17, 2026
• The Hacker News: Hackers Infect 953 Online Stores With Scanner-Evading JavaScript, Mostly on Magento, October 26, 2026
• CVE Record: CVE-2026-48356