On 27 October 2026, CISA added CVE-2026-48356, a dangerous file upload weakness in Adobe Commerce and Magento, to its Known Exploited Vulnerabilities catalog. That listing means the weakness has been exploited in the real world. It does not mean every store is compromised, and it says nothing about who is attacking or which customers are affected. For a store owner, it changes one thing: “we updated” is no longer a complete answer. You need evidence that the fix is present, and a separate, scoped review of whether the store was compromised earlier, with its findings and any remaining uncertainty written down.

What the official sources say

Adobe’s bulletin APSB26-73 lists CVE-2026-48356 among the issues it addresses. The practical steps are in Adobe’s update article, which provides isolated patches for each supported branch and component set. Two details matter for owners. The base version shown in your admin panel does not prove these extra fixes were applied, because they can be separate from the main release. And stores on Adobe Commerce cloud infrastructure may already receive the fix through cloud patches, so reapplying it can fail. Your provider should follow Adobe’s current guidance for your branch and deployment, not an old version table.

Separately, researchers at Sansec reported malicious JavaScript loaders stored in Magento database CMS blocks, and reuse of access gained in earlier compromises. Content managed in the database therefore needs review alongside files and accounts. Removing one visible script, or patching a known weakness, is not proof that earlier access is gone.

Start with ownership and facts

Before asking for action, confirm who is responsible. Ask your provider:

  • Who owns patching and incident response for this store?
  • Which edition is installed, Magento Open Source or Adobe Commerce, on which branch and with which components?
  • Is production on Adobe Commerce cloud infrastructure, or on self-managed hosting that you or your provider run?

These answers decide which vendor fix applies and who should apply it.

Ask for dated patch evidence

Request a short written record that names CVE-2026-48356 and APSB26-73, identifies the fix Adobe recommends for your branch, and shows it was applied and verified on the live website, with a date. A version string or a generic “all updated” email is not enough, because the relevant fix can sit outside the base version. If the provider is unsure, ask them to verify against Adobe’s current guidance rather than assume.

Protect backups and evidence first

Before anyone changes production, confirm there are recent backups of both files and the database, and that a restore has actually been tested. Our guide to backup strategy rules explains what a usable restore procedure looks like. Ask that logs, upload directories and order data are preserved rather than cleaned up, because an incident review needs them intact.

Request a compromise review, not just a scan

A clean result from a file-only scan does not show that content managed in the database was reviewed. Ask for a review that covers:

  • CMS blocks, pages and other content managed in the database
  • unexpected files in upload locations
  • administrator accounts nobody recognizes
  • other signs of persistence or ongoing access

If the review finds something suspicious, agree a containment, cleanup and credential and access recovery plan with the provider. The right steps depend on what was found, so there is no universal recipe worth copying from an article.

Verify the website afterwards

After an authorized update or cleanup, check representative storefront pages, admin login and the important customer paths such as checkout. Use authorized test mode where payments are involved so no real charges occur. Write down what was checked, what remains uncertain, and how the website will be monitored in the coming weeks.

Three outputs to keep on file

Ask your provider for three things: patch evidence, the scope and result of the compromise review, and the record of restore and customer path checks. Together they document which fix was applied, what was checked for earlier compromise and what those checks found. They do not guarantee that nothing happened or that every trace is gone, because no review can certify that. This article is an owner checklist, not a diagnosis of any particular store.

If you want this handled as a documented scope for your store, you can discuss it through our Magento maintenance service.

Sources checked as of 29 October 2026.