Events Secure.com at Black Hat USA 2026

PolyShell Hit Magento Stores 222 Days Before CISA Called It

PolyShell attacks on Magento stores began in March. CISA listed the flaw 222 days later, on 27 October. Here is what to patch and hunt.

Magento’s PolyShell Flaw Spent 222 Days Off the Radar

Attackers dropped web shells into Magento stores in March. The federal catalog that tells agencies what to patch did not list the flaw until 27 October. That is a 222-day gap, and online stores sat inside it.

What Happened?

Security firm Sansec logged probing against Magento stores on Monday 16 March 2026, then live attacks on Thursday 19 March. The bug, now tracked as CVE-2026-48356 and nicknamed PolyShell, lets anyone upload a file disguised as an image through the guest cart REST API. No login. No password. Adobe shipped a fix on Tuesday, 14 July, and rated the flaw 9.3 out of 10. CISA added it to the Known Exploited Vulnerabilities catalog on Tuesday, 27 October, 105 days after the patch, with a federal deadline of Tuesday, 10 November.

What Is the Impact?

Sansec reports that one March wave planted a loader on 471 stores inside a single hour. The exploit prediction score told a different story. It sat at 1% every day through October, then jumped to 30.6% on listing day. Anyone watching that number saw calm water for a month.

The Patch Is Not Where You Think

Here is where it gets messy. Adobe’s bulletin lists 2.4.9 as affected, while the research that broke the story calls 2.4.9 the fix. Both cannot be right. Adobe’s own fixed builds carry July labels like 2.4.8-2026-jul, which are not normal version strings and will not match what most teams type into a composer file. Adobe also states it is not aware of exploits in the wild for anything in that July update. Sansec had been publishing attack evidence since March.

Patch levels · APSB26-73

The fix does not look like a normal version number.

Adobe’s July builds carry a date label rather than a patch number, so a store can read as current and still be exposed. Match the exact string before you call it done.

Listed as affected
  • Adobe Commerce 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
  • 2.4.4-p18 and earlier
  • Magento Open Source 2.4.9 and earlier
  • Commerce Events 1.6.0 to 1.20.0
Listed as fixed
  • 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
  • 2.4.4-2026-jul
  • B2B 1.5.3 / 1.5.2 / 1.4.2 / 1.3.4 / 1.3.3-2026-jul
  • Commerce Events 1.21.0
Read this before you file the ticket
2.4.9 sits on the affected list, while the research that broke the story calls 2.4.9 the fix. The sources disagree. Go by the exact July build string in the bulletin, not by the major version.

Source: Adobe security bulletin APSB26-73, published 14 Jul 2026, last updated 11 Aug 2026.

This Is the Third One

CISA has now added three Adobe Commerce and Magento flaws to the catalog in 49 days, starting on 8 September. The same crew keeps reusing the access it already has. A report published on Saturday, 24 October tracked a storefront loader across 953 stores and found that, of the infected Magento 2 installs missing a core patch, 60% also carried files uploaded through PolyShell or an older flaw. The web shell opens the door. The loader walks through it months later.

How to Avoid This

  • Move to Adobe’s July 2026 release levels
  • Hunt pub/media/custom_options for stray PHP files
  • Block guest cart uploads at the edge
  • Check cms_block rows for injected loader code
  • Treat vendor research as a patch trigger

Your Scanner Knew in July. Did Anyone Act on It?

The flaw was public for 105 days before the catalog moved, and the scoring stayed quiet the whole time. The delay lives between the finding and the fix.

  • Shows CVE-2026-48356 on the exact asset carrying it, with KEV status, exploit prediction score, and exploit evidence in one place
  • Ranks a network-reachable code execution flaw on an internet-facing host as an attack path entry point, not another row in a list
  • Routes runtime alerts, such as a web worker spawning a shell, into the SOC Teammate for investigation
  • Holds every consequential change behind a named approver in Slack or Teams
  • Retests after the fix and keeps the before and after as evidence