CISA lists Adobe Commerce’s PolyShell flaw as exploited, three months after the fix

March 17, 2026. Sansec publishes its research on PolyShell, a way to upload files through Magento’s REST API without authenticating, disguised as images. March 30, 2026. The firm observes a large automated attack wave: attackers drop web shells and then inject JavaScript into store pages. October 27, 2026. CISA adds CVE-2026-48356 to its KEV catalog, with a federal remediation deadline of November 10, 2026. The point that matters: Adobe fixed the flaw on July 14, 2026 — three and a half months before the US agency listed it as exploited — and a patch does not remove what was already planted.

A flaw known since March, fixed since July

PolyShell is neither a zero-day nor a fresh discovery. Sansec documented it on March 17, 2026, and named it after the way the malicious payload — a PHP file hidden inside an image — masquerades as a harmless “shell.” The flaw itself is CWE-434, an Unrestricted Upload of File with Dangerous Type: the REST API of Adobe Commerce and Magento Open Source accepts a dangerous file type without requiring prior authentication.

The scoring reflects the severity. NVD and the CVE record rate the flaw at 9.3 in CVSS v3.1, and Adobe’s bulletin at 9.6; both vectors are AV:N/AC:L/PR:N/UI:R/S:C, differing only on availability impact. In practice: no privileges required, user interaction required (the victim must visit a crafted URL or interact with a compromised page), and a changed scope that explains the high score.

Adobe shipped the fix on July 14, 2026 in bulletin APSB26-73, as isolated patches rather than Composer packages: each patch only applies to the latest patch level of its line (2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, or 2.4.4-p18). A store on an older level must first upgrade, then patch. That mechanism is exactly what creates the lag: three months on, a meaningful share of the install base still runs a vulnerable version.

What the KEV listing actually changes

The October 27, 2026 addition to the Known Exploited Vulnerabilities catalog adds no new technical detail. It changes the nature of the instruction: CISA now asserts active exploitation in the wild, and imposes a November 10, 2026 remediation deadline on US federal agencies under BOD 26-04.

For everyone else, it is a dated alarm. CISA only adds a flaw to KEV when it judges it is or has been exploited; its ransomware field remains “Unknown” here, meaning the agency does not yet confirm ransomware use — without ruling it out. Adobe, for its part, still said as of August 11, 2026 that it was “not aware of any exploits in the wild” — a line that predates the KEV listing and bears watching.

Sansec has been documenting exploitation for a long time. As early as March 30, 2026, the firm described a large automated attack: attackers dropped web shells and then injected JavaScript into store pages to steal payment data — the same Magecart pattern seen on Convertr. On October 24, 2026, Sansec tied PolyShell to a long-running campaign, active since July 2025, that loads attacker scripts from the stores’ content blocks.

The trap of “I patched, so I’m done”

The hardest lesson here fits in one sentence: patching closes the door, but it does not remove what already got in. A fix removes the vulnerability; it does not remove the planted files, the backdoors, or the admin accounts created during the months the flaw was open.

This is precisely the scenario Sansec describes. Attackers dropped a file named accesson.php in new assets/images/ subfolders, and stored unexpected files — including images containing PHP — under pub/media/custom_options/. The decisive point: the file stays on disk even when the web server blocks it from running. A store can be “patched” and still host a dormant payload waiting for a more permissive server configuration.

Sansec therefore recommends a precise sequence: first block web access to the pub/media/custom_options/ folder (this limits damage without stopping the upload itself), then check CMS blocks and pages for injected scripts, review admin accounts you do not recognize, and rotate the database, admin, and API integration passwords after cleanup. The script-loader campaign’s domains (deepveindrilling[.]com, additionalver[.]com, and similar) are indicators, not proof: some were in use before PolyShell was disclosed.

Why the Magento install base stays vulnerable for so long

Magento and Adobe Commerce power a substantial share of online retail, from independent shops to major brands. That install base has a structural quirk: every store is a bespoke assembly of extensions, themes, and modified payment code. The direct consequence is that an upgrade is never a single click — it is a project that touches the heart of the revenue pipeline, and merchants postpone it for fear of breaking checkout.

The July fix’s mechanics make it worse. Adobe shipped the patch as isolated patches, applicable only to the latest level of each release line, rather than through Composer like ordinary updates. A store two levels behind must therefore migrate first, then patch — two operations too often lumped into “we’ll do it later.” That is exactly the ground attackers thrive on: a flaw that is fixed yet still exploitable on thousands of stores that have not moved.

The Magecart economy explains the persistence. Stolen card data resells in bulk, and a single compromised store can yield thousands of numbers in days. For an attacker, the return on an automated scan for PolyShell — Sansec lists more than fifty IP addresses that scanned for the flaw — is wildly disproportionate to the cost. Once an unauthenticated upload flaw is documented, it becomes a commodity exploited at scale, long after the vendor shipped the patch.

What to do, in order

1. Confirm the fix is actually in place. Bulletin APSB26-73 points to Adobe’s Commerce Version Tool, which lists installed and missing security patches. Do not trust the displayed version: an isolated patch can be absent even on a current line.

2. Move your line forward. The July fixes only apply to the latest level of each line (2.4.8-p5, 2.4.7-p10, and so on). A store on an older level must first migrate, then patch. Fixed versions carry the -2026-jul suffix.

3. Hunt what was planted before the patch. Inspect pub/media/custom_options/ for unexpected files, search for accesson.php and its variants, and scan CMS blocks (cms_block, cms_page) for injected JavaScript.

4. Cut residual access. Review admin accounts, rotate database and API integration credentials, and — for US federal agencies — meet the November 10, 2026 deadline.

Verdict

If you run an Adobe Commerce or Magento Open Source store, treat this KEV listing as a hunt order, not just a patch order. Verify that APSB26-73 (or a -2026-jul release) is truly applied, then inspect the upload folders, CMS blocks, and admin accounts for anything planted between March and your patch. If you delegate your store to an agency or a marketplace, ask for proof that the July fix is in place and that planted files were checked: a partner that cannot answer both questions does not know its own platform. CVE-2026-48356 will not be the last Magento flaw to reach KEV; next time, the gap between patching and hunting will again be what separates a clean store from a compromised one.

References

• CISA — Known Exploited Vulnerabilities, CVE-2026-48356 (October 27, 2026)
• NVD — CVE-2026-48356 (Adobe Commerce)
• Adobe — security bulletin APSB26-73 (July 14, 2026)
• Sansec — PolyShell research (March 17, 2026)
• Sansec — PolyShell mass attack wave (March 30, 2026)
• Sansec — deepveindrilling.com CMS block loader (October 24, 2026)
• Rescana — CVE-2026-48356 analysis (October 28, 2026)