CISA added CVE-2026-48356, an unrestricted-file-upload flaw in Adobe Commerce and Magento, to its Known Exploited Vulnerabilities catalog on October 27. The operational task has two parts: verify that the relevant Adobe fix is installed, and investigate access that an earlier intrusion may have left behind.

Sansec’s October 24 investigation describes a storefront-injection campaign that repeatedly revisited infected stores. It connects earlier compromises to the upload flaw, which it calls PolyShell, and to other vulnerabilities. Adobe’s July 14 bulletin, APSB26-73, supplies the patch guidance.

Evidence status: CISA-recognized exploitation, with researcher-reported campaign observations. October 27 is the catalog-addition date, not the flaw’s publication or first-exploitation date.

What the official records establish

Adobe’s CVE record describes possible code execution in the current user’s context and control over a victim’s account or session. It says exploitation requires a victim to visit a crafted URL or interact with a compromised page. The bulletin marks authentication as unnecessary but user interaction as required.

Sansec describes a server-side upload and backdoor path in its campaign research. The public sources do not fully reconcile that path with Adobe’s user-interaction wording. Keep both qualifications visible; neither a universal zero-click claim nor an authenticated-admin-only assumption follows from the official description.

Adobe’s older bulletin still says it knew of no exploitation. The newer CISA catalog changes that assessment. Its entry marks ransomware use Unknown and forensic triage No, and supplies November 10 as the due date. That federal catalog date is not a universal deadline for private merchants, and the triage field does not certify an individual store as clean.

Check the actual patch coverage

The bulletin’s affected storefront versions are:

  • 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; 2.4.8-p5 and earlier; 2.4.7-p10 and earlier; 2.4.6-p15 and earlier.

Adobe identifies the July fixed targets as 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul and 2.4.6-2026-jul. Commerce additionally has 2.4.5-2026-jul and 2.4.4-2026-jul targets. Preserve those identifiers when matching the bulletin to deployment records.

Adobe’s installation guidance explains why a familiar version label can be misleading:

  • Isolated fixes have prerequisites. For example, the 2.4.7 isolated patch applies to 2.4.7-p10. An earlier patch level must first reach that base.
  • Installed components need matching files. Community, Enterprise and B2B components can require separate patches. Follow the vendor’s component-specific selection and order.
  • Monthly security patches are non-cumulative. Adobe says to apply them in sequence and use its Commerce Version Tool to check coverage and missing CVEs.
  • Cloud Patches may already contain the fix. Adobe warns that applying the isolated patch again can fail. Check the actual coverage before choosing an installation route.

An ordinary Composer update or a base -p version alone cannot establish that these isolated fixes were applied. Use the current vendor instructions and retain evidence that the deployed installation is protected against this exact CVE.

A clean-looking storefront can retain attacker access

Sansec reports 953 stores across a campaign tracked since July 2025. That is its campaign population, not 953 newly compromised stores or 953 proven CVE-2026-48356 victims.

Its October loader appeared on 83 stores, of which 60 already carried an earlier loader. The researcher found injected content in Magento’s CMS blocks, database-stored storefront content. It also describes rogue administrator accounts and persistent server backdoors. Removing one visible script leaves those access paths unresolved.

For affected merchants, the supported response is to inspect CMS blocks and pages, unfamiliar administrators, integrations, uploaded files and unexpected processes. Preserve incident evidence before cleanup. Investigate the original access path, remove persistence, apply the applicable fixes, then replace database, administrator and API-integration credentials as the response requires.

Sansec says the October loader filters visitors and has not yielded its final payload to researchers. A browser request returning nothing, or a scan that sees a clean page, therefore has limited meaning. The research does not establish a complete stolen-card inventory.

Caveat: Sansec sells ecommerce security products and supplies the campaign evidence. Its store counts and initial-access attributions are source-reported, while the official records leave some exploit-path details unresolved.