PolicyCortex
Request Access
Summary
  • CISA added the Adobe Commerce upload flaw to its exploited list on October 27, 2026.
  • Adobe rates the flaw 9.6. No login is needed to exploit it.
  • The fix is the July 2026 build for your release line.
  • Patching alone does not remove code an attacker already planted.

What changed on October 27

The Cybersecurity and Infrastructure Security Agency (CISA) added a new flaw to its list. The list is the Known Exploited Vulnerabilities (KEV) catalog. CISA lists a flaw there only when exploitation is known. The new entry is CVE-2026-48356. Common Vulnerabilities and Exposures (CVE) is the record system for public flaws. Federal civilian agencies must act by November 10, 2026.

How the flaw works

Adobe Commerce and Magento Open Source let a store accept uploaded files. The flaw is an unrestricted upload of a file with a dangerous type. An attacker uploads a file that looks like an image. The file carries code inside it. The server then treats that file as code. Adobe rates the flaw 9.6 on its severity scale. No login is needed to exploit it. The score still needs a victim interaction step. Adobe published the fix in bulletin APSB26-73 on July 14, 2026.

What researchers found

Sansec is a security research firm that tracks store attacks. Sansec said attackers used this flaw to breach hundreds of stores. The attackers injected a loader through a Magento content block. A content block is a reusable piece of store content. The loader fetches and runs an attacker controlled payload. No next stage malware has been recovered yet. That gap makes the final goal hard to name. The activity dates back to at least July 2025. A patch stops new uploads through this flaw. A patch does not remove a loader already in place.

What to patch

Affected Commerce versions run from 2.4.4 through 2.4.9, with earlier patch lines included. Affected Magento Open Source versions run from 2.4.6 through 2.4.9. Commerce B2B lines and Commerce Events are also affected. Each line has its own July 2026 build. Commerce 2.4.9 moves to 2.4.9-2026-jul. Magento Open Source 2.4.9 moves to 2.4.9-2026-jul. Check the exact build after install. A version number that looks close is not proof.

What to check after patching

Check upload folders for files that should not be there. Check admin accounts for names you do not recognize. Check content blocks and content pages for injected scripts. Check for files disguised as images in media folders. If you find a webshell, a rogue admin, or an injected script, assume the store was breached. Rotate database, admin, and integration credentials in that case. Rebuild from a known good copy when cleaning in place is unclear. Record what you checked and what you found.

The governance lesson

A catalog listing changes the priority of a flaw. Before the listing, a July fix could sit in a normal queue. After the listing, exploitation is known, so the flaw moves to the front. That is how a KEV listing should work in your own process. When CISA lists a flaw, your tracker should move it up at once. The proof habit matters as much as the patch. Record the version before and after the patch. Record the patch date and the scan result. Record the hunt result for planted code. A patch note with no hunt result leaves the breach question open.

Sources

Next step

Patch your store to the July 2026 build, then record the hunt result.

Questions on this record
What is PolyShell?
PolyShell is the research name for the Adobe Commerce upload flaw. An attacker uploads a file that looks harmless but carries code. The server then treats that file as code.
Which versions are fixed?
Use the 2026-jul build for your release line. For example, Commerce 2.4.9 moves to 2.4.9-2026-jul. Magento Open Source lines use the matching 2026-jul build.
What is the federal deadline?
Federal civilian agencies must act by November 10, 2026. That date comes from the CISA listing. Other teams should treat it as their deadline too.
Is exploitation confirmed?
Yes. CISA lists a flaw in this catalog only when exploitation is known. The listing itself is the confirmation.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

proof.state
Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change
Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency
Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture
Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.

Further reading in this register

  1. CISA Adds the Brotli Decoder Flaw to Its Exploited ListA flaw in the Brotli decoder is now on the federal exploited list. Federal agencies must act by November 10, 2026.4 min
  2. Two Wasmtime Flaws Break the Sandbox PromiseTwo flaws score 9.9. Each lets a crafted module escape its sandbox. The fix is a version check, not a new tool.5 min
  3. Three NGINX Memory Flaws Score 9.2: Check Your Config and PatchF5 published an out-of-band notice on October 14, 2026. It fixes three NGINX memory flaws. Each scores 9.2 under the newest scoring version.5 min

Verify the record this entry describes.

Request AccessBook a call
Published
Last updated
Unchanged since publication
Author
Leonard Esere