CISA says the Magento upload flaw is being exploited. Adobe's bulletin for it still says the company knows of no exploits

CVE-2026-48356 went on CISA's Known Exploited Vulnerabilities catalogue on 27 October with a due date of 10 November. It is an unrestricted file upload in Adobe Commerce and Magento Open Source, classed CWE-434, and the entry CISA links to is Adobe's own bulletin.

That bulletin, APSB26-73, was published on 14 July and last updated on 11 August. It scores the flaw 9.6, marks it Critical, records that no authentication is required, and carries this sentence: "Adobe is not aware of any exploits in the wild for any of the issues addressed in these updates."

What the flaw is

Sansec, which found the attacks and named the technique PolyShell, describes a REST API that accepts a file upload as part of a cart item. A product option of the file type makes the API process an embedded object carrying base64 data, a MIME type and a filename, then write the result into the store's media directory. 3 checks are missing from that path.

The option identifier is not validated, the option type is not gated, and the file extension is not restricted. The only validation left is a check of the image header, which Sansec calls "trivially bypassed".

The dangerous routes are the guest cart ones, which by design need no account. GraphQL mutations go through a different code path and are not affected.

The timeline Sansec published

Sansec's dated account starts on 16 March, when it added protection and saw probing begin. The first attacks in the wild came on the 19th. Mass scanning launched on the 23rd, reaching 23% of the stores it protects. By the 24th it recorded malicious PHP uploaded to 56.7% of them, and tied PolyShell to a skimmer on a retailer it describes as being worth over one hundred billion dollars.

A larger wave on 30 March reached 79.5%, deploying a backdoor named accesson dot php along with JavaScript loaders. By 14 April the figure was 82%. More than 50 source addresses have been recorded probing since late March.

Those percentages are of stores Sansec protects, not of every Magento store on the internet, and the page is loose about the distinction. The direction of travel is not in doubt either way.

The upload is an image, again

The file written is a valid GIF or PNG that also contains executable PHP, usually named with the option identifier followed by index dot php. One variant checks a cookie against a hardcoded value before running code; another is password protected and passes commands straight to the system call.

This is the second story we have written today in which the payload is a real image. The YOOtheme Pro flaw being exploited against Joomla and WordPress sites writes a valid JPEG with the code in its metadata. A file that genuinely is an image survives the pipelines that process images, and it does not look wrong in a media folder full of them.

Whether it becomes code execution depends on your web server

The flaw looks smaller than it is here, and then larger. The polyglot only runs if the server executes PHP from the upload directory. Sansec lists the conditions: stock nginx on 2.0.0 through 2.2.x, any nginx configuration that hands every PHP file to FastCGI, and Apache before 2.3.5 without the directive that turns the PHP engine off in that folder.

Adobe's own sample configurations block execution, so a shop following them is not immediately running attacker code. Sansec's warning is what to do with that comfort: "Even when execution is blocked, the uploaded file stays on disk." A configuration change, a server migration or a new hosting provider converts a harmless file into a live shell months later, and nobody will connect the two events.

The patch history is genuinely confusing

Sansec's page says the fix landed first in the 2.4.9 pre-release branch under an earlier bulletin, that Adobe released 2.4.9 with it on 12 May without backporting, and then lists a backport on 14 July under APSB26-73. Its own FAQ still says no production patch exists, which contradicts the later entry on the same page.

Adobe's bulletin resolves it. APSB26-73 lists fixed builds across the 2.4.4 through 2.4.9 lines, all dated 2026-jul, plus B2B and the Events module. If you are running a supported line, there is a build for you, and it has been there since July.

What to do

• Patch to the July builds for your line, or later. The version string ends in 2026-jul.
• List everything in the custom options media directory. A file ending in php, phtml or phar in there is not a false positive.
• Search the whole web root for a file named accesson dot php.
• Search the CMS page and static block tables for injected script, including the domains Sansec names in its report.
• Turn off PHP execution in media directories whatever your version says, because that is the control that makes the next one of these a failed write.
• If you find anything, treat admin accounts, API keys and payment integrations as compromised, and check for admin users you did not create.

What is not established

• How many stores were actually compromised. Sansec publishes percentages of its own protected estate, not a count.
• Who is behind the activity. Sansec links PolyShell uploads to skimming infrastructure without naming an operator.
• Why the catalogue listing took until 27 October, more than 7 months after the first attacks Sansec logged.
• Whether Adobe will revise the sentence in APSB26-73 now that CISA has listed the CVE on evidence of active exploitation.
• How many stores on unsupported versions exist, for which the fixed builds above do not apply.