On October 27, 2026, the US Cybersecurity and Infrastructure Security Agency added a long-running online store flaw to its Known Exploited Vulnerabilities catalog. The flaw, known as PolyShell and tracked as CVE-2026-48356, affects Adobe Commerce and Magento Open Source. CISA now lists it as actively exploited, and US federal civilian agencies must remediate it by November 10, 2026.
Direct answer: If you run an Adobe Commerce or Magento Open Source store, check whether the July 2026 security update from Adobe bulletin APSB26-73 is installed, then check the store for anything an attacker may already have planted. The patch closes the hole, but it does not remove a webshell, a rogue admin account, or injected script code that was put in place before the patch. Sansec, the e-commerce security firm that tracked the related campaign, reports 953 online stores infected with a loader since July 2025, most of them running Magento.
What CISA just added and why it matters
CISA added CVE-2026-48356 to the Known Exploited Vulnerabilities catalog, usually called KEV, on October 27, 2026. KEV is not a list of theoretical risks. It is CISA’s list of vulnerabilities with reliable evidence of exploitation in the wild. When a flaw lands on KEV, it moves from something to patch in the next maintenance window to something to treat as an active threat.
The November 10, 2026 due date in the KEV entry binds US federal civilian agencies under CISA’s binding operational directive. It does not legally bind a private online store in the same way. For everyone else, the date still works as a clear priority signal: this flaw is being used against real stores right now, and the fix has been available for more than three months.
CISA records the use of this flaw in ransomware campaigns as unknown. That is not the same as saying ransomware is involved. It means CISA has not confirmed ransomware use for this entry.
What PolyShell actually is
PolyShell is the name researchers gave to CVE-2026-48356. The National Vulnerability Database describes it as an unrestricted upload of a file with a dangerous type, classified as CWE-434. In plain terms, the application accepts a file it should have refused, such as a script disguised as something harmless. Once that file is on the server, it can run as code in the context of the current user, which can give an attacker elevated access or control over the account or session.
The CVE record scores the flaw 9.3 out of 10 on the CVSS 3.1 scale, rated critical. The vector shows it can be exploited over the network, it is low in complexity, and it needs no privileges. It does require some user interaction, described in the record as a victim visiting a maliciously crafted URL or interacting with a compromised web page, and its scope is changed, meaning a successful attack can reach beyond the vulnerable component itself. Adobe’s own security bulletin APSB26-73 lists a slightly higher score of 9.6, because it rates the availability impact as low rather than none. Both scores agree on the important point: this is a critical flaw.
Researchers have also reported webshells disguised as image files in upload folders, including in pub/media/custom_options/quote/. A webshell is a small script left on a server so an attacker can return later and run commands. That detail matters because it explains why a store can look normal from the outside while still being under someone else’s control.
Which versions are affected and what to install
Adobe fixed the flaw on July 14, 2026 in security bulletin APSB26-73. The fixed builds carry a 2026-jul suffix. Store owners should confirm the exact build from Adobe’s bulletin before changing anything, and test in staging first if the store has custom code.
- Adobe Commerce 2.4.9 and earlier lines: move to 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul, 2.4.6-2026-jul, 2.4.5-2026-jul, or 2.4.4-2026-jul, matching the store’s release line. Affected versions include 2.4.9, 2.4.8-p5 and earlier, 2.4.7-p10 and earlier, 2.4.6-p15 and earlier, 2.4.5-p17 and earlier, and 2.4.4-p18 and earlier.
- Adobe Commerce B2B: move to the matching 2026-jul build, up to version 1.5.3 and its earlier patch lines.
- Magento Open Source: move to the matching 2026-jul build for the 2.4.6 to 2.4.9 lines, including 2.4.9, 2.4.8-p5 and earlier, 2.4.7-p10 and earlier, and 2.4.6-p15 and earlier.
- Adobe Commerce Events: version 1.20.0 and earlier are affected, with 1.21.0 listed as unaffected.
One practical trap is worth calling out. Adobe tests the isolated patch only on the latest security release of each line, so a store still running an older patch level, for example 2.4.7-p1, generally needs to move to 2.4.7-p10 first. Skipping that step can leave the patch unapplied or the store in an inconsistent state, so check the bulletin for the store’s exact line rather than applying a build meant for a different version.
How 953 stores got hit
Sansec reported the campaign on October 26, 2026, one day before the KEV listing. The campaign has been running since July 2025 and has infected 953 online stores with loader code, most of them running Magento. The loader is JavaScript injected into CMS blocks, which are the content blocks a store uses for pages and promotions. It activates when a real shopper visits a page.
The scale of one wave stands out. In March 2026, Sansec reports that 471 Magento stores were injected with the loader within one hour, through webshells placed using PolyShell. Sansec also found more than 100 stores with files uploaded through PolyShell or through a second flaw, SessionReaper (CVE-2025-54236), which allows unauthenticated session takeover in older Adobe Commerce and Magento versions. The campaign evidence does not establish that every one of the 953 stores was breached through either flaw, and Sansec also found compromised stores with rogue administrator accounts or backdoors despite current core patches. The honest reading is that PolyShell was a major entry point, not the only one.
The loader itself is built to hide. It fingerprints visitors and serves its payload only to real shoppers, while security scanners get nothing. Sansec puts it plainly in its report: the server first checks whether the visitor is a real shopper or a security scanner, so scanners get nothing. That is why a clean external scan cannot be treated as proof that a store is clean.
The loader has moved through five domains over the life of the campaign. The earlier domains were manulfie.click, neswnsssn.click, lanhd6549tdhse.top, and additionalver.com. In October 2026, the campaign switched to deepveindrilling.com, which sits behind Cloudflare and only responds to requests from scripts loaded in the browsers of infected stores’ visitors. Sansec found the deepveindrilling.com loader on 83 stores, including 60 that had been running previous loader versions. Sansec has not yet captured the final payload for the current loader, but previous versions served visitors scripts from crypto-themed domains, including one mimicking the Ledger wallet brand.
Why patching alone is not enough
The most uncomfortable case in Sansec’s report involves a store that did everything right on paper. A store running Magento 2.4.7-p10, with no missing core patches, picked up the deepveindrilling.com loader at 16:46 UTC on October 23, 2026, one hour after a clean scan. Sansec had already found a rogue admin account on that store on September 16 and a GSocket backdoor on September 24.
The lesson is straightforward. The attacker was already inside before the latest loader appeared, and the injected script lives in the store’s database content, which installing a patch does not clean. Patching closes the original entry point. It does not evict an attacker who already created an admin account, planted a backdoor, or gained write access to the database. Removing the JavaScript alone can leave that access intact, which means the store can be reinfected while the original way in looks closed.
This pattern is not unique to Magento. The same month, CISA added the Brotli decoder flaw behind Node2Shell to KEV on the same day as PolyShell, and earlier October KEV additions covered PHP and Plex flaws that were also being exploited while fixes were already available. For more on those cases, see our coverage of the HTTP2Shell Brotli flaw behind Node2Shell, the PHP2Shell emergency patch, and the Plex2Shell flaws CISA ordered patched. The recurring theme is the same: a known fix, a slow rollout, and attackers working through the stores and servers that never got it.
What store owners should do now
Work through these steps in order. Patching first is right, but cleanup and credential rotation after cleanup matter just as much.
- Confirm the installed build. Check the Adobe Commerce or Magento version and patch level in the admin panel or from the command line, and compare it against APSB26-73. Do not assume a July update was applied because it was scheduled.
- Apply the 2026-jul fix for the store’s line. Update to the matching 2026-jul build, or to Adobe Commerce Events 1.21.0 where that module applies. Test in staging, then deploy, and verify the new build number after the update.
- Search CMS blocks and pages for loader code. Look for the loader domains, including deepveindrilling.com and the earlier domains listed above, and for obfuscated script patterns and suspicious code in CMS content. Check the indicators Sansec published in its report.
- Audit upload folders. Review pub/media/custom_options/quote/ and other upload directories for files that do not belong there, especially scripts disguised as images.
- Review admin accounts and integrations. Look for administrator accounts nobody on the team recognizes, unexpected API integrations, and changes to CMS content, configuration, or scheduled tasks.
- Hunt for backdoors and persistence. Check for webshells, unexpected cron jobs, modified core files, and unfamiliar server-side scripts. If the store uses a malware scanner, treat a clean result as one data point, not a verdict, given how this loader hides from scanners.
- Clean properly, then rotate credentials. Remove injected code and backdoors, then change database passwords, admin passwords, and API integration credentials. Sansec advises rotating after cleanup, because rotating while a webshell is still on the server risks handing the attacker the new credentials.
- Review logs for unauthorized changes. Check access logs, admin activity, and order data for suspicious requests, logins from unfamiliar locations, and changes made outside normal working hours.
- Check the second flaw too. If the store runs an older release line, confirm whether SessionReaper (CVE-2025-54236) is also in scope and apply its fix from Adobe’s earlier bulletin.
If any sign of compromise turns up, treat the store as compromised until the investigation says otherwise. That may mean taking checkout offline briefly, rebuilding from a known-clean backup, or bringing in an incident response firm. A short outage is cheaper than weeks of shoppers being served a skimmer loader.
What shoppers should know
Shoppers cannot patch someone else’s store, but they can reduce their own risk. Be cautious with payment pages that behave strangely, avoid entering card details on a store that shows unexpected popups or redirects, and check card statements after shopping on smaller stores. If a store you use announces a security incident, change your password for that store and watch for phishing messages that reference a real order. The loader in this campaign is designed to target real shoppers, not scanners, which is exactly why store owners need to find it in their own content rather than relying on an outside scan.
Frequently asked questions
What is Magento PolyShell?
PolyShell is the researcher name for CVE-2026-48356, an unrestricted file upload flaw in Adobe Commerce and Magento Open Source. An attacker can upload a dangerous file type that the server then treats as code, leading to arbitrary code execution in the context of the current user.
Is PolyShell being actively exploited?
Yes. CISA added CVE-2026-48356 to its Known Exploited Vulnerabilities catalog on October 27, 2026, based on evidence of active exploitation. Sansec also reported a related loader campaign that has infected 953 online stores since July 2025.
Which Magento and Adobe Commerce versions need the PolyShell patch?
Adobe Commerce 2.4.4 through 2.4.9 lines up to the patch levels listed in APSB26-73, Adobe Commerce B2B up to 1.5.3, Magento Open Source 2.4.6 through 2.4.9 lines, and Adobe Commerce Events up to 1.20.0. The fix is the matching 2026-jul build from Adobe’s July 14, 2026 bulletin, or Events 1.21.0.
Does installing the July patch remove an existing infection?
No. The patch closes the upload flaw, but it does not remove a webshell, a rogue admin account, injected CMS code, or a backdoor planted earlier. Stores must also search CMS blocks and pages, audit upload folders and admin accounts, clean any injected code, and rotate database, admin, and API credentials after cleanup.
What is the CISA deadline for PolyShell?
CISA set a remediation due date of November 10, 2026 for US federal civilian agencies. Private stores are not bound by that date in the same way, but the KEV listing is a strong signal to patch and check for compromise now, not at the next scheduled maintenance window.