Adobe Commerce PolyShell CVE-2026-48356 Added to CISA KEV
Security

Adobe Commerce PolyShell CVE-2026-48356 Added to CISA KEV

CISA lists Adobe Commerce PolyShell, CVE-2026-48356, as exploited. Patch to the July 2026 release and check upload folders for planted files.

adobe commercemagentocisa kevfile uploadskimming

CISA added Adobe Commerce PolyShell, tracked as CVE-2026-48356, to its Known Exploited Vulnerabilities catalog on October 27, 2026. The flaw is an unrestricted file upload in Adobe Commerce and Magento Open Source that Sansec found being exploited in March, months before Adobe shipped a fix in APSB26-73 on July 14. Federal agencies must remediate by November 10. Every store owner should confirm the July patch is installed, then check for files and scripts left behind by earlier attacks, because patching does not remove them.

What happened

Sansec published its PolyShell research on March 17, 2026. It described a file upload weakness in the Magento REST API: unauthenticated visitors could attach files to cart item custom options, and those files could be disguised as images to pass validation. Sansec said the weakness has existed since the first Magento 2 release.

Thirteen days later, on March 30, Sansec reported a mass exploitation wave. It counted 471 compromised stores within one hour, with attackers uploading a web shell, dropping backdoor copies named accesson.php across several directories, and injecting a JavaScript loader into CMS pages and static blocks. The speed pointed to a fully automated chain.

Adobe fixed the issue for supported release lines in security bulletin APSB26-73 on July 14, 2026, rated Priority 2. At the time, Adobe said it was not aware of any exploits in the wild for the issues in that bulletin, and the page was last updated on August 11. CISA's KEV listing on October 27 now records the CVE as exploited, with the federal due date of November 10 and ransomware use marked as unknown.

On October 24, Sansec tied PolyShell to a long-running skimming campaign that loads attacker scripts from Magento CMS blocks. It has tracked 953 affected stores since July 2025 and saw the operator move to a new loader domain, deepveindrilling[.]com, registered on October 6.

Who is affected by Adobe Commerce PolyShell

Adobe's bulletin lists these affected versions, all fixed by the July 2026 releases:

  • 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. Fixed in 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 and 2.4.4-2026-jul.
  • Adobe Commerce B2B: 1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17 and 1.3.3-p18 and earlier. Fixed in the matching 2026-jul releases.
  • Magento Open Source: 2.4.9, 2.4.8-p5, 2.4.7-p10 and 2.4.6-p15 and earlier. Fixed in 2.4.9-2026-jul through 2.4.6-2026-jul.
  • Adobe Commerce Events: 1.6.0 to 1.20.0. Fixed in 1.21.0.

Sources disagree on one point. Sansec says the May 12, 2026 release of 2.4.9 already contained the fix, while Adobe lists 2.4.9 as affected and fixed only in 2.4.9-2026-jul. Follow Adobe's table: if you run 2.4.9, install the July update.

Stores on release lines older than 2.4.4, or on Open Source lines older than 2.4.6, have no isolated patch download from Adobe. Treat them as exposed until they are upgraded.

Technical analysis

Adobe classifies CVE-2026-48356 as CWE-434, unrestricted upload of a file with a dangerous type. Its bulletin scores it 9.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L) with no authentication required. The CVE record and NVD carry 9.3, with no availability impact. Adobe's description says exploitation requires user interaction, such as a victim visiting a crafted URL.

Sansec's account is broader. It says the upload itself needs no login and lands in pub/media/custom_options/. Whether that file can then run as code depends on the web server. Sansec lists stock nginx configurations on Magento 2.0.0 to 2.2.x, nginx setups that pass every .php request to FastCGI, and Apache before 2.3.5 without PHP execution disabled as the configurations that allow remote code execution. Other stores can still face stored cross-site scripting. GraphQL mutations use a different code path and are not affected, according to Sansec.

Two details matter for defenders. First, the uploaded file stays on disk even when execution is blocked, so a later config change can expose it. Second, Sansec's October data shows the skimming loader also appears on patched stores: 60 of the 83 stores on the newest loader domain were already infected before the switch. Of 169 infected Magento 2 installs that were missing at least one core patch, 102 also showed files uploaded through PolyShell or SessionReaper (CVE-2025-54236).

For background on what attackers do once a script lands on the server, see what a web shell is and how it gets on a server.

What to do now

  1. Patch. Move to the 2026-jul release for your line, or apply the matching APSB26-73 isolated patch. Isolated patches only apply to the latest patch level of each line (for example 2.4.7-p10), so older stores must catch up first. Our guide on why Magento isolated patches need the latest patch level covers how to plan that. Adobe Commerce Cloud merchants should use the latest cloud-patches update instead and not stack the isolated patch on top.
  2. Verify. Adobe's knowledge base article KA-37421 points to the Commerce Version Tool, shipped with each monthly patch, to confirm which patches and CVEs are covered.
  3. Block execution in the upload folder. Deny web access to pub/media/custom_options/ at the web server. Sansec notes this limits damage but does not stop uploads. Our walkthrough on how to block PHP execution in Magento media folders has the nginx and Apache settings Sansec published.
  4. Hunt for leftovers. Sansec recommends listing every file in pub/media/custom_options/ other than .htaccess, and searching the document root for accesson.php:
find pub/media/custom_options/ -type f ! -name '.htaccess'
find /var/www -name 'accesson.php' -type f

Any .php, .phtml or .phar file in that folder is a strong sign of compromise. Also check pub/media/customer_address/, which Sansec flags in the October campaign.

  1. Check the database. Search the cms_block and cms_page tables for injected scripts, using the update_time column to spot recent writes, and review admin_user for accounts you do not recognize.
  2. Rotate secrets if you find anything. Removing the script does not remove the attacker. Change database, admin and API integration passwords, as Sansec advises. Our earlier guide on how to rotate every secret after a server compromise lists what to cover.

Images in uploads can carry more than pixels. Our explainer on what a polyglot file is and why upload checks miss it explains why a file that passes an image check can still be dangerous.

What to watch next

Adobe has not published indicators of compromise or updated its "not aware of exploits" statement since the KEV listing. Watch for a bulletin revision. Sansec reports that the skimming operator rotates loader domains every few months and has already switched from a Keitaro traffic distribution system to browser fingerprinting that hides from automated scanners, so expect new domains. This is the second Adobe Commerce flaw exploited this autumn, after the StyleSmuggler template injection, CVE-2026-75650, so keep Magento patch cadence on a monthly calendar.

Sources