Security Advisory
CISA Confirms Active Exploitation of a Critical Adobe Commerce and Magento Upload Flaw Patched Since July
CISA added a critical Adobe Commerce and Magento file-upload flaw, nicknamed PolyShell, to its Known Exploited Vulnerabilities catalog on October 27, 2026, with a November 10 remediation date. Adobe fixed the flaw in July, but the campaign that exploited it in March was still planting malicious code in already compromised online stores in October. Here is what the flaw lets attackers do, how to check your store, and what to patch now.
On October 27, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-48356, an unrestricted file upload flaw in Adobe Commerce and Magento Open Source, to its Known Exploited Vulnerabilities (KEV) catalog. CISA's entry says the flaw "could result in arbitrary code execution in the context of the current user" and sets a November 10, 2026 remediation due date, which binds U.S. federal civilian agencies under Binding Operational Directive 26-04 rather than private businesses, according to CISA's Known Exploited Vulnerabilities catalog entry for CVE-2026-48356. CISA only adds a vulnerability to that catalog when it has reliable evidence attackers are already using it, so this listing is an official confirmation that online stores running an unpatched version are being compromised now, not a theoretical risk.
What makes this one unusual is timing. Adobe actually fixed this flaw more than three months ago, in its July 14, 2026 security bulletin, APSB26-73. The National Institute of Standards and Technology's National Vulnerability Database (NVD) record for the flaw shows a published date of July 14, 2026, but its entry was last modified on October 28, 2026, reflecting CISA's new KEV listing, and NVD rates the flaw 9.3 out of 10, Critical, under CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N, tracked under CWE-434, Unrestricted Upload of File with Dangerous Type, per NIST's NVD record for CVE-2026-48356. In plain terms: the flaw requires no account or password on the store (PR:N) and is reachable over the network (AV:N). NVD's description adds that exploitation requires user interaction (UI:R), in that a victim must visit a maliciously crafted URL or interact with a compromised web page, and that it can result in arbitrary code execution in the context of the current user.
The "PolyShell" Campaign
NVD's own reference list for this CVE points directly to the research behind the real-world attacks: two posts from Sansec, a security firm that specializes in monitoring Magento and Adobe Commerce stores for compromise. Sansec named the campaign "PolyShell" after a wave it caught compromising 471 stores within a single hour on March 30, 2026, and says it had already been blocking the technique since March 16 that year, per Sansec's research on the PolyShell mass attack wave. The same campaign is still running. In a separate write-up on a loader domain it calls deepveindrilling.com, Sansec ties it back to that March wave, when the operator injected its loader into 471 stores "after uploading webshells through PolyShell (CVE-2026-48356)," the same flaw CISA just added to its KEV catalog. Sansec says the new domain was registered October 6, 2026, that stores were loading it from their CMS blocks by the next evening, and that it found it on 83 stores, most of them earlier victims (60 of the 83 already ran one of the operator's previous loaders). Sansec is explicit that "the October rewrites used no new vulnerability, because 60 of the 83 stores were already infected": the operator was rotating loader domains on stores it had already compromised, 34 of them carrying its loaders since October 2025. One store Sansec checked had no missing core patches, yet received the new loader on October 23, one hour after a clean scan; Sansec's scanner had found a rogue admin account on that store on September 16 and a GSocket backdoor on September 24. Sansec does not say how the October loader got in. In other words, stores this campaign compromised months ago, including through this flaw, are still being used against their customers today, almost four months after Adobe's fix shipped, and patching alone is not shown to have stopped it.
Sansec's research describes the attack chain: an attacker uploads a PHP webshell disguised as an image file (in one store Sansec examined, PNG-named webshells sat in pub/media/custom_options/quote/), then uses that access to inject obfuscated JavaScript into the store's CMS pages and content blocks, which can serve malware or payment-skimming code to the store's own customers. Sansec's write-up lists a backdoor file commonly named accesson.php and an injected script that uses a browser localStorage key, fpCode, as indicators to check for.
Who This Affects
If your business runs an online store on Adobe Commerce, Adobe Commerce B2B, or Magento Open Source, and that store has not had Adobe's July 2026 security patch (bulletin APSB26-73) applied, it is running a version CISA has now confirmed is being actively exploited. This includes stores a developer or agency set up and has not actively maintained since: across the campaign, Sansec found its loader on 169 Magento 2 installs missing at least one core patch.
What to Do Now
- Ask whoever manages your Adobe Commerce or Magento store, in-house, an agency, or a hosting provider, to confirm in writing that Adobe's July 2026 security bulletin, APSB26-73, has been applied.
- If the store has only recently been patched, do not assume the patch alone proves it is clean: Sansec found the loader on a store with no missing core patches that had earlier been found carrying a rogue admin account and a backdoor.
- If you manage the store yourself, check for Sansec's listed indicators: an unfamiliar file named accesson.php, or any unexpected file under pub/media/custom_options/ or pub/media/customer_address/.
- Review your store's CMS pages and static content blocks for injected or obfuscated JavaScript you did not add, especially anything loading a script from a domain you do not recognize.
- If you find any of these signs, treat the store as compromised rather than just patching around it: rotate your admin, database, and API credentials, and review admin accounts for ones you do not recognize.
- Because the flaw can let attackers serve content to your own customers' browsers, also watch for customer reports of odd pop-ups, redirects, or antivirus warnings tied to your store, which can be an early signal before you find the technical indicators yourself.
Why This Belongs on Your Radar
An online store is often the single piece of software most directly tied to revenue, and customer trust, for a small or mid-size business, yet it is also easy to treat as "done" once it is live and stop checking for vendor updates. This flaw shows what that gap costs: a fix has existed since July, researchers have published exactly what to look for, and stores this campaign compromised earlier are still being used against their own customers months later. Patching stops a new intrusion through this specific flaw; it does not by itself remove a backdoor an attacker already planted before the patch went in, which is why checking for compromise matters as much as checking the patch level. Keep a dated record of both checks, since an auditor or insurer may later ask how you track known, actively exploited vulnerabilities in the software that handles your customers' transactions.
For businesses subject to the FTC Safeguards Rule or the HIPAA Security Rule, the same obligations we have flagged for earlier advisories apply here. The FTC Safeguards Rule requires nonbanking financial institutions to maintain a documented information security program that includes vulnerability monitoring under 16 CFR 314.4(d)(2), though institutions maintaining customer information on fewer than 5,000 consumers are exempt from that paragraph. HHS Office for Civil Rights guidance treats identifying and remediating known, actively exploited vulnerabilities as part of the ongoing risk analysis and risk management obligations at 45 CFR 164.308(a)(1)(ii)(A) and (B); for a covered entity or business associate, an e-commerce platform that creates, receives, maintains, or transmits ePHI falls within that scope.
Cyber One Solutions does not operate Adobe Commerce or Magento stores directly, but if we host and maintain your business website through our website design, hosting, and maintenance service, confirming vendor security patches like this one on any connected systems is part of that engagement. If you run a separately managed online store, or inherited one from a previous developer and are not certain who last touched it, our IT and security assessments can confirm what is actually running and whether Adobe's fix is in place; our coverage of why small business websites get hacked covers the broader pattern of outdated, unmaintained platforms becoming an entry point.
Sources
- CISA: Known Exploited Vulnerabilities Catalog, CVE-2026-48356
- NIST NVD: CVE-2026-48356 Record
- Adobe Security Bulletin APSB26-73: Security Update Available for Adobe Commerce
- Sansec Research: PolyShell Mass Attack Wave
- Sansec Research: Magento CMS Block Loader, deepveindrilling.com
- CISA: Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk
- Federal Trade Commission: FTC Safeguards Rule, What Your Business Needs to Know
- HHS OCR: January 2026 Cybersecurity Newsletter
