Adobe Commerce and Magento File Upload Flaw (CVE-2026-48356) Now Exploited

At a glance (as of 28 October 2026)

CVE-2026-48356 is an unrestricted file upload flaw (weakness type CWE-434) in Adobe Commerce, Adobe Commerce B2B, Magento Open Source and the Adobe Commerce Events module. Adobe fixed it on 14 July 2026 in security bulletin APSB26-73, rated Priority 2. On 27 October 2026 CISA added it to the Known Exploited Vulnerabilities (KEV) catalogue, with a due date of 10 November 2026 for US federal agencies. CISA records known ransomware use as 'Unknown'.

The immediate action is to confirm which Adobe security patches your store has, apply the July 2026 patch for your release line if it is missing, and then look for signs that something was uploaded before you patched. If the store is internet-facing and unpatched, patch first and investigate straight afterwards.

One point of caution. Adobe's bulletin, as we retrieved it, still says Adobe is not aware of exploits in the wild and shows a last-updated date of 11 August 2026. That predates the CISA listing, so we are treating CISA's evidence of active exploitation as the current position. The CISA directive itself only binds US federal agencies, but CISA encourages every organisation to prioritise KEV entries, and we agree with that.

Who should check

Adobe lists these as affected, meaning installed versions at or below these patch levels and without the July 2026 patch. Adobe's fixed builds carry a '2026-jul' label and are delivered as patches rather than ordinary Composer version numbers.

• 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: the 2026-jul build of each of those lines.
• Adobe Commerce B2B: 1.5.3; 1.5.2-p5 and earlier; 1.4.2-p10 and earlier; 1.3.4-p17 and earlier; 1.3.3-p18 and earlier. Fixed: the 2026-jul build of each line.
• Magento Open Source: 2.4.9; 2.4.8-p5 and earlier; 2.4.7-p10 and earlier; 2.4.6-p15 and earlier. Fixed: the 2026-jul build of each line.
• Adobe Commerce Events: 1.20.0 and earlier (the bulletin gives 1.6.0 to 1.20.0). Fixed: 1.21.0.
• Magento Open Source 2.4.5 and older are not in Adobe's table, and Adobe only lets Open Source customers download these patches for 2.4.6 or later. We have not found vendor guidance for those older Open Source lines. Third-party researchers report the weakness dates back to the first Magento 2 release, so assume those stores are exposed and plan an upgrade to a supported line.

Understand the risk

Adobe scores the flaw as Critical, with no authentication required and a changed scope. Its bulletin gives CVSS 3.1 base score 9.6, while the CVE record Adobe submitted shows 9.3 with a slightly different availability impact. Either way it is in the top severity band. Adobe's description says exploitation needs user interaction, such as a victim visiting a crafted URL, and could lead to arbitrary code execution in the context of the current user.

Independent research describes a more direct route. Sansec, a Magento security firm, has published research on a flaw it calls PolyShell, in which an unauthenticated visitor uploads a disguised file through the guest-cart REST API, which can lead to code execution or stored cross-site scripting depending on server configuration. Sansec's write-up names this as CVE-2026-48356, and the CVE record lists Sansec's PolyShell material among its references. However, Sansec's separate March 2026 mass-attack article does not itself assign a CVE, and Adobe's wording and Sansec's differ on whether user interaction is needed. We therefore treat the link as well supported but not confirmed by Adobe or CISA. The practical advice does not change either way.

Exploitation evidence: CISA's KEV entry and the CISA data in the CVE record both mark exploitation as active. CISA does not say who is behind it, how many organisations are affected or which attack path it saw. Sansec reports attacks on Magento stores from mid-March 2026 and a mass wave at the end of that month, but that reporting predates Adobe's July fix and we cannot say which of those incidents involved this exact CVE.

What to do now

Work through these in order. Most of it needs administrator access to the server or hosting platform. If an agency or managed host runs your store, send them this section and ask for written confirmation of each result.

The file checks below are read-only: they list files and change nothing. Run them from the Magento root folder as a user that can read the web files, replacing YOUR_MAGENTO_ROOT with the real path. If the first command reports that the folder does not exist, that is not a problem.

1. Find out which security patches are installed. Adobe supplies a Commerce Version Tool with each monthly patch, which reports installed and missing security patches and the CVEs they cover. It only becomes available once the core patch file from the July 2026 package has been applied, so if you cannot find it, treat that as a strong sign the July patch is missing and go to the next section.
2. Look for script files inside the product-option upload folder. Genuine uploads there are images and other customer files, not PHP. Any result is serious and should be preserved and investigated rather than simply deleted.
   bashCopy

   cd YOUR_MAGENTO_ROOT
   find pub/media/custom_options -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \)

3. Look for a backdoor file called accesson.php anywhere in the web root. Sansec associates this filename with the March 2026 attacks. The search can take a while on a large media library, so run it at a quiet time.
   bashCopy

   cd YOUR_MAGENTO_ROOT
   find . -type f -name "accesson.php"

4. Check content that visitors load. Sansec reports injected JavaScript in CMS pages and static blocks, loading from domains such as lanhd6549tdhse[.]top, jslibrary[.]net and canevaslab[.]com. In the admin Content area, review blocks and pages for script tags you did not add. Your developer can search the CMS block and page tables for the same strings.
5. Review administrator accounts and API integrations for anything unfamiliar, and look in the web server logs for unexplained requests to the guest-cart item routes or unusual fetches from the custom_options media folder. These are indicators, not proof. A clean result does not prove a store was never compromised.

Applying Adobe's fix

Adobe provides the July 2026 fixes as isolated patch files, one ZIP per release line, and not as ordinary Composer packages. The files are named 2-4-9-jul-2026.zip, 2-4-8-p5-jul-2026.zip, 2-4-7-p10-jul-2026.zip, 2-4-6-p15-jul-2026.zip, 2-4-5-p17-jul-2026.zip and 2-4-4-p18-jul-2026.zip. Each contains separate files for the core, Commerce and extension components such as B2B. Apply only the files that match the versions you actually have, in the order Adobe gives.

You must already be on the latest security-only (-p) release for your line before the patch will apply, so a store on an older patch level has an upgrade to do first. Adobe points to its knowledge base guide on applying a Composer patch provided by Adobe, and you should follow that rather than improvising. This is a code change to a live shop, so test it on a staging copy, take a backup of the code and database and plan a short maintenance window.

Adobe Commerce on cloud infrastructure is different. Adobe says the latest cloud-patches update already resolves the issue, and you should not apply the isolated patch on top of it because that can cause installation failures. Confirm with your cloud provider or Adobe Support that the cloud-patches update is in place.

When the patch is in, run the Commerce Version Tool again and confirm it reports the July 2026 security patch as installed for each component. If Adobe's steps fail, contact Adobe Support Services or your hosting provider rather than forcing the patch. The same bulletin fixes a number of other vulnerabilities, so applying only part of the package leaves other holes open.

Interim protection if patching has to wait

Adobe's bulletin offers no workaround or hotfix other than updating. Before Adobe's backport, Sansec suggested blocking public access to the upload folder at the web server and using a web application firewall (WAF) to block the guest-cart upload calls. Those are third-party measures, not Adobe-endorsed, and they only reduce risk: blocking the folder does not stop a file being written, and a WAF is only as good as its rules. Use them if patching must wait a few days, but they are no substitute for the patch.

If you find something suspicious

Patching closes the door, but it does not evict someone already inside. If any of the checks turn up unexpected files, injected scripts or unknown admin accounts, take the store out of public service or put it behind a holding page if you can, preserve a copy of the evidence and involve whoever handles your incident response. Rotate administrator, database, API and payment-related credentials once the store is clean, not before. Consider whether customer or card data may have been exposed, as that can carry reporting duties under UK data protection law and card-scheme rules.

We have not seen a clean-up checklist from Adobe for this issue, so we are not going to invent one. Rebuilding from known-good code is generally safer than hand-removing the files you happened to find.

Real-world reporting

We have not identified any organisation publicly confirmed as compromised through CVE-2026-48356 specifically. Sansec reports large numbers of compromised Magento stores in March 2026 but names no victims in the material we reviewed and does not tie them to this CVE identifier. We are not naming anyone, and a KEV entry does not tell us who was targeted.