Adobe Commerce CVE-2026-48356: file-upload RCE added to CISA KEV

A vulnerability Adobe shipped a fix for in July — rated "priority 2," with the bulletin stating Adobe was "not aware of any exploits in the wild" — is, as of today, being exploited in the wild. On 2026-10-27 CISA added CVE-2026-48356, an unrestricted file-upload flaw in Adobe Commerce and Magento Open Source, to its Known Exploited Vulnerabilities catalog. The patch is three and a half months old. The exploitation is not — the vendor Sansec, which calls this flaw PolyShell, has tracked it in automated mass waves since March 2026. For the thousands of stores that read "priority 2, no known exploits" in July and moved on, CISA's listing is the overdue federal confirmation that the attacks were never hypothetical.

Developing story — first published 21:17 CET (20:17 UTC), 27 October 2026. Updated as the vendor and CISA publish more.

Update — 2026-10-28 03:34 CET

The exploitation detail this post flagged as missing has been published, and NVD now references two write-ups from the forensics vendor Sansec. Sansec names the flaw PolyShell and ties CVE-2026-48356 to a long-running CMS-block skimmer campaign — not a new attack that began with the KEV listing:

• Exploitation is months old and automated. Sansec documents a mass PolyShell wave that compromised 471 stores in a single hour on 2026-03-30, with the chain "fully automated." That reframes the UI:R reading below: whatever interaction the CVSS vector assumes, it has not slowed a scripted wave hitting hundreds of stores an hour.
• It feeds the "DeepVeinDrilling" skimmer campaign. Per Sansec's 2026-10-24 analysis, PolyShell (CVE-2026-48356) and SessionReaper (CVE-2025-54236) are the upload flaws used to plant web shells, after which the operator injects a JavaScript loader into the Magento cms_block table; the campaign has touched 953 stores since July 2025. That answers the "overlap with other Magento campaigns" question below — it is one sustained operation, and some already-patched stores were re-infected through earlier footholds.
• Concrete IOCs now exist — folded into the Hunt section below. Sansec reports it had not yet captured the final skimmer payload, and the group remains unattributed.

At a glance

CVE	CVE-2026-48356
Product / affected versions	Adobe Commerce and Magento Open Source 2.4.4–2.4.9 (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); Adobe Commerce B2B 1.3.3–1.5.3
Fixed in	APSB26-73 July 2026 security update for each branch (the 2.4.x-2026-jul / 1.x-2026-jul releases; equivalently the next patch level per branch)
CVSS	9.3 Critical · CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N · scored identically by Adobe (CNA) and NVD
Exploited in the wild	Yes — in CISA KEV 2026-10-27; Sansec (which names it PolyShell) documents automated mass exploitation since 2026-03-30 (471 stores in one hour), feeding the DeepVeinDrilling skimmer campaign
CISA KEV	Added 2026-10-27; federal due date 2026-11-10 (BOD 26-04); ransomware use Unknown; forensic triage not required
Public PoC	No public exploit code; Sansec published campaign IOCs on 2026-10-24
Official advisory	Adobe APSB26-73

What CVE-2026-48356 actually is

The weakness is CWE-434, unrestricted upload of file with dangerous type: the application accepts a file whose type it should have rejected, writes it somewhere reachable, and ends up executing it. In Adobe Commerce and Magento that means arbitrary code running "in the context of the current user" — Adobe's own phrasing — with a route to elevated access over the victim's account or session. For a platform that sits in the checkout path and touches cardholder data, "arbitrary code execution on the store" is the whole game.

Two details in the CVSS vector change how you should read this bug, and most of the write-ups that will appear overnight will get them wrong:

• PR:N — no attacker credentials. The attacker does not need an account on your store. In Adobe's advisory table this bug is marked as requiring no authentication, which is why it scores so high.
• UI:R — but a user has to act. The NVD description is explicit: "Exploitation of this issue requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page." And the scope is changed (S:C): the code executes in a security context different from the one the attacker started in.

On paper this is not the bare "POST a webshell to a public endpoint and get instant RCE" that StyleSmuggler was. The CVSS vector reads it as an unauthenticated-but-interaction-gated flaw: the attacker still has to get a user — in the worst case an admin with an active session — to trip the upload. That nuance matters for scoring. It does not make the bug safe, and in practice it has not slowed anyone down: as the Update above records, Sansec observed a fully automated PolyShell wave hitting hundreds of stores an hour. Treat it as a live mass-exploitation flaw, not a conditional one.

Why a July patch is a today problem

Adobe disclosed this in APSB26-73 on 14 July 2026, inside a routine batch of fourteen Commerce CVEs, and gave it a priority rating of 2 — Adobe's "elevated risk, patch within 30 days" tier, not the "patch immediately" tier reserved for priority 1. The bulletin's boilerplate at the time: Adobe "is not aware of any exploits in the wild for any of the issues addressed in these updates."

That sentence was true in July. It is a snapshot, not a forecast, and the Magento ecosystem is the textbook case of why the two are different:

• Every Adobe Commerce patch ships as source. Within days of a release, attackers diff the "before" and "after" and reconstruct the bug — the fix is the exploit spec.
• Magento stores patch slowly. Upgrades touch payment flows, so merchants defer them; a large fraction of live stores run several patch levels behind at any moment. This is the same dynamic that made CosmicSting (CVE-2024-34102) and this September's StyleSmuggler (CVE-2026-75650) mass-exploitation events.
• EPSS now puts CVE-2026-48356 in the 98th percentile of all CVEs for exploitation likelihood (per FIRST's EPSS model, score refreshed 2026-10-27) — the model had been flagging this one as a probable target for weeks.

The honest read of the timeline: a "priority 2, no known exploits" bug matured into an actively exploited one over fourteen weeks, exactly the window attackers need to weaponize a disclosed patch against a slow-patching fleet. If your prioritization is driven by the vendor's day-one severity label, you are always a quarter of a year behind the people attacking you.

Am I exposed?

Every supported line is in scope. Check your running version against the fixed releases:

# From the Magento/Adobe Commerce root:
php bin/magento --version
# or inspect the composer lock:
grep -m1 '"magento/product-community-edition"' composer.lock
grep -m1 '"magento/product-enterprise-edition"' composer.lock

If your branch is at or below the "and earlier" line in the table above — for example Commerce 2.4.7-p10, 2.4.6-p15, or any 2.4.9 before the July security release — you are affected and should treat this as an active incident, not a maintenance ticket.

Remediation

1. Patch — exact fixed versions

Apply the APSB26-73 July 2026 security update for your branch. Per Adobe's advisory, the fixed releases are:

Product	Affected	Apply
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	the 2.4.x-2026-jul security release for your branch (next patch level)
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	the 1.x-2026-jul release for your branch
Magento Open Source	2.4.9; 2.4.8-p5 and earlier; 2.4.7-p10 and earlier; 2.4.6-p15 and earlier	the 2.4.x-2026-jul release for your branch

Confirm the exact package name for your branch in APSB26-73 before you deploy — the same bulletin fixes thirteen other CVEs, several of them CVSS ≥ 9, so there is no partial-patch option worth taking.

2. Can't patch this hour? Compensating controls

A full Commerce upgrade is a payment-path change and often needs a maintenance window. Until it lands:

• Lock down file-upload and admin surfaces at the WAF. Block uploads with executable extensions or mismatched MIME types reaching Commerce endpoints; rate-limit and geofence /admin (or your custom admin path) to known operator networks.
• Enforce the admin-path and 2FA basics so the "lure an authenticated user" half of the chain is harder: unique admin URL, mandatory 2FA, short admin session lifetime.
• Serve pub/media with execution disabled. Media and upload directories must never run PHP. In nginx, ensure no location passes pub/media to fastcgi; on Apache, confirm the shipped pub/media/.htaccess denies script execution and has not been overwritten by a theme or extension.

3. Hunt for compromise

Because the KEV listing means exploitation is live, assume probe traffic has already reached you. Look for the post-upload stage, mapped to MITRE ATT&CK:

• Web shells (T1505.003): new or recently modified .php files under pub/media/, pub/static/, var/, media/, or anywhere outside your deploy artifact. find pub/ media/ var/ -name '*.php' -newermt '2026-07-14' -type f is a fast first pass; compare the file list to a known-good release checkout.
• Exploit of a public-facing app (T1190): POST requests to upload or import endpoints from a single source, odd Content-Type/extension mismatches in access logs, 200s on paths that should 403.
• Execution (T1059): the web-server user spawning sh, curl, wget, or PHP processes with network sockets you can't account for.
• Data exfiltration / skimmer injection: unexpected outbound connections from the web node, and injected JavaScript in checkout/cms_block/cms_page content — the usual Magecart endgame once RCE lands on a store.

Sansec's DeepVeinDrilling write-up published the concrete indicators for the campaign exploiting this CVE — check your estate against them directly:

• PolyShell web shells disguised as images under pub/media/custom_options/quote/ and pub/media/customer_address/ — a .php payload carrying a PNG header is the tell; the earlier wave also dropped accesson.php backdoors across multiple directories.
• Loader injected into the database, not the filesystem: query cms_block.content and cms_page for fpCode, se_referrer, and localStorage.getItem — the loader lives in CMS content Magento renders into storefront pages, so a clean file tree does not mean a clean store.
• The loader domain deepveindrilling.com (and its predecessors additionalver.com, neswnsssn.click, manulfie.click, lanhd6549tdhse.top) appearing in storefront HTML or outbound requests.
• Persistence beyond the shell: rogue admin accounts and, on at least one already-patched store, a GSocket backdoor — patching alone does not evict an operator who already has a foothold.

4. Eradicate and verify

If you find anything: patch first (an un-patched store gets re-owned within hours), then remove implants, then rotate every secret the web node could read — the Magento crypt/key in env.php, admin and integration credentials, API tokens, and payment-gateway keys. Invalidate all admin sessions. Only after the host is patched and cleaned do you re-test: confirm the upload endpoint now rejects the dangerous type, and confirm no web shell survives a redeploy from source control. Verification after patching is the step most breach post-mortems record as skipped.

What is not known yet

• The final payload. Sansec reports it had not captured the end-stage skimmer/fingerprinting payload the loader serves as of its 2026-10-24 write-up — the server decides per-visitor what to return. Treat any "complete IOC list" that claims the end payload with caution until a named source publishes it.
• Attribution. Sansec describes "a criminal group" running the DeepVeinDrilling campaign but names no actor, and whether it overlaps with the CosmicSting crews is still unestablished.
• The SSVC lag. NVD's SSVC decision for this CVE trailed the exploitation reality at publication; KEV is the authoritative exploitation signal now, and NVD's record was last modified 2026-10-27.

We will update this post as primary sources publish.

Validate exploitability before you panic-patch everything — and watch the wire

The operational question this CVE forces is not "is it bad" (CVSS says yes) but "where, in my estate, is it bad right now" — because a vendor's day-one priority label just proved to be a poor guide to that. Zero Hunt's AI Remediation Advisor answers it by ranking findings on real exploitability rather than catalog severity: CISA KEV first, then what the campaign actually proved exploitable in your environment, then CVSS, then EPSS. A bug like CVE-2026-48356 jumps the queue the moment it lands in KEV — and the advisor hands back the exact fixed release for your branch, with rollout and rollback notes and the compensating control to run until the window opens, then re-verifies the fix with the same proof that demonstrated the issue.

Because the bug is interaction-gated (UI:R), "am I affected" is genuinely conditional on your configuration, and that is where an autonomous AI red team earns its place over a scanner that only reads version banners. Zero Hunt's 10-agent swarm runs gray-box against the exact installed version, and its Exploit Forge iterates a sealed proof-of-concept until the upload chain either demonstrably works on your store or demonstrably doesn't — every attempt in an ephemeral container that never touches the host, every finding signed at write time for the audit trail. That is the difference between "patch everything, in no order, and hope" and a ranked plan proven against your own deployment. On the detection side, the same engine's traffic model watches for the Magecart endgame these stores keep suffering — the skimmer's outbound card-data egress — on the wire, while it is happening, not in next morning's log review. For merchants, this is also the PCI DSS Requirement 11.4 testing duty met continuously instead of once a year. It runs on-premise on Zero Hunt's own models, with a human approving every action that matters — no store data leaving the appliance, no external party able to switch the capability off.