CISA lists exploited Adobe Commerce flaw as storefront research exposes persistent access

October 27 listing establishes the immediate news

CISA added CVE-2026-48356, the Adobe Commerce and Magento vulnerability known as PolyShell, to its Known Exploited Vulnerabilities catalog on October 27. The entry lists November 10, 2026, as the remediation date. That designation is the new development for October 28: it establishes known exploitation, not that the vulnerability was just discovered or that hundreds of storefronts were first compromised yesterday. [1][2]

The underlying history stretches back months. Sansec disclosed PolyShell on March 17 and dates its first observed attacks to March 19. Adobe released security fixes on July 14. Its bulletin, updated August 11, still says the company was unaware of exploitation. That older statement should not override CISA's October 27 designation. Read together, the sources show that the vendor's published exploitation statement predates the official confirmation now driving remediation urgency. [1][2][4]

File upload and code execution are different outcomes

PolyShell permits unauthenticated file uploads through Magento's cart-related REST API. Searchlight Cyber independently traced the vulnerable code path and demonstrated how a file could pass image validation while containing executable content. Adobe classifies CVE-2026-48356 as a critical unrestricted-upload vulnerability requiring no authentication. Together, those findings explain why operators cannot limit their assessment to whether an attacker possessed a legitimate account. [3][4]

Successful upload does not automatically mean successful code execution. Searchlight found that execution depends on web-server configuration, and Adobe's recommended access restrictions can prevent uploaded files from being accessed or executed. Those restrictions do not necessarily remove the files from disk. The defensive inference is that a blocked execution path reduces immediate exposure but does not, by itself, establish that a store is free of malicious uploads. [3]

The 953-store figure spans a much longer campaign

Sansec reports 953 affected stores, mostly Magento, across a campaign dating to July 2025. That is neither a count of new October compromises nor proof that every intrusion used PolyShell. Its investigation separately links a March wave affecting 471 stores to PolyShell webshell uploads. The distinction matters: the broader campaign began before the vulnerability's public disclosure, and its total cannot simply be relabeled as the flaw's confirmed victim count. [2][5]

The recent development inside that campaign is a rewritten loader observed on October 23 and described in Sansec's October 24 investigation. It appeared on 83 stores, 60 of which already carried earlier loaders. The new code filters visitors using browser characteristics, complicating automated inspection. Sansec had not captured its final payload, so the findings establish unauthorized storefront code and persistent access, but not a campaign-wide payment-card theft total, customer victim count or financial loss. [5]

The corroboration has limits. SecurityWeek published a separately authored report, but its campaign totals come from Sansec rather than a second victim census. Searchlight provides independent technical analysis of the vulnerable code path, not verification of those totals. CISA supplies an official known-exploited designation. These sources reinforce different parts of the story; their agreement must not be presented as multiple independent measurements of the same storefront population. [1][3][5][7]

Check installed fixes, not just the version label

Adobe's affected-product matrix covers Adobe Commerce, Magento Open Source, Adobe Commerce B2B and Adobe Commerce Events. Its prescribed remedies include the corresponding 2026-jul security updates, while affected Events versions 1.6.0 through 1.20.0 require version 1.21.0. Operators should check the product and component tables rather than assume that updating one part of a deployment establishes complete coverage. [4][6]

There is a consequential difference between dated version guidance. Sansec's May update says Magento 2.4.9 contains the fix, but Adobe's later bulletin lists 2.4.9 as affected and specifies a July update. The practical resolution is to verify actual patch coverage against Adobe's later instructions. A displayed base version is not sufficient evidence that the required security fix has been installed. [2][4][6]

Installation details also matter. Adobe distributed the July fixes as isolated patches, not simply new Composer packages. Its instructions specify prerequisite patch levels, component-specific files and verification with the Commerce Version Tool. The documentation says security patches are non-cumulative and must be applied in sequence. Cloud deployments may already receive the fix through cloud-patches; applying it again can cause installation failures. [6]

Investigate existing access while closing the upload flaw

The operational inference from the patch documentation and campaign findings is that closing the upload flaw and removing an existing compromise are separate tasks. Operators should inspect CMS content, unauthorized administrator accounts, uploaded executable files and backdoors. Sansec's findings support removing attacker access and rotating relevant credentials after cleanup, rather than deleting only the visible loader and treating that as complete remediation. [5][6]

Upload directories warrant inspection even where the current web-server configuration blocks execution. Searchlight warns that malicious files can remain and become executable after a later configuration change. This connects the technical analysis to the persistence problem: access restrictions can interrupt one route to execution without eliminating planted files. They are useful safeguards, but not substitutes for patching and investigation. [3][5]

Watch for payload evidence and distinguish new infections

The most important unresolved question is what the October loader ultimately delivers. Capturing its final payload could clarify the consequences for shoppers and merchants; the current evidence does not establish those consequences across the campaign. Future infection reports should also distinguish newly affected stores from stores carrying earlier loaders. CISA lists ransomware involvement as unknown, so this should not be described as a ransomware campaign. [1][5]

November 10 is CISA's listed remediation date, not evidence of a safe waiting period. The immediate priorities are to establish whether the relevant fixes are actually installed and whether attacker access already exists. That recommendation follows from the combination of known exploitation, configuration-dependent execution and documented storefront persistence, rather than from an unsupported assumption that every affected store has suffered the same downstream harm. [1][3][5][6]