Thursday, October 29, 2026
IT BusinessDigest
Get the Daily Brief
News

Magento PolyShell hits CISA's list: the July fix and what to check

Adobe shipped the fix in July and its bulletin still says it knows of no attacks. Sansec counts hundreds of stores hit through the same hole, so patching is the first step, not the last.

Morgan Reid Security and infrastructure writer · · 3 min read
a computer screen with a woman looking at a laptop

CISA added CVE-2026-48356, the Adobe Commerce and Magento Open Source flaw that researchers call PolyShell, to its Known Exploited Vulnerabilities catalog on October 27, The Hacker News and SecurityOnline report. Federal agencies have until November 10 to fix it. The fix is not new: Adobe shipped it on July 14 in bulletin APSB26-73, rated Critical with a CVSS score of 9.6, and no login is needed to use the flaw.

The odd part is Adobe's own page. APSB26-73, last updated August 11, still says Adobe knows of no attacks using these bugs. Sansec, an e-commerce security firm, reported on March 23 that attacks had been under way since March 16, months before Adobe had a fix for production stores. If your store team is waiting for Adobe to raise the alarm before patching, it has been waiting since spring.

How the attack works

Magento's REST API lets a shopper attach a file to a cart item as a custom option. PolyShell abuses that to upload files without logging in, and the files land in pub/media/custom_options/quote/. Depending on how the web server is set up, the result is a web shell or a stored script that takes over accounts. Sansec warned in March that blocking that folder does not stop the uploads themselves.

The damage shows up later, in the database. Sansec's October 24 research tracks one group that has planted a JavaScript loader in 953 stores since July 2025, hiding it in Magento's cms_block table. The Hacker News, reporting Sansec's figures, puts 471 of those stores down to PolyShell, with another 102 hit through PolyShell or SessionReaper (CVE-2025-54236). Sansec also found the loader on fully patched stores, including one where Sansec had already found a backdoor and an admin account nobody had set up.

Which builds fix it

APSB26-73 lists these as affected:

  • Adobe Commerce 2.4.9, and 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18 and earlier
  • Magento Open Source 2.4.9, and 2.4.8-p5, 2.4.7-p10 and 2.4.6-p15 and earlier
  • Adobe Commerce B2B 1.5.3, and 1.5.2-p5, 1.4.2-p10, 1.3.4-p17 and 1.3.3-p18 and earlier
  • Adobe Commerce Events versions 1.6.0 through 1.20.0

The fixed builds carry July labels: 2.4.4-2026-jul up to 2.4.9-2026-jul for Commerce, 2.4.6-2026-jul up to 2.4.9-2026-jul for Magento Open Source, 1.3.3-2026-jul up to 1.5.3-2026-jul for Commerce B2B, and 1.21.0 for Commerce Events. The same bulletin fixes 13 other CVEs.

There is a catch for anyone checking a fleet of stores. Adobe's knowledge base article KA-37421 says the July fix also ships as an isolated patch, as patch files with no Composer package. Safeguard points out that an isolated patch leaves the version string as it was, so bin/magento --version can show an old number on a fixed store. Adobe says to confirm with its Commerce Version Tool, and notes that its security patches are not cumulative and have to go on in order. Adobe says a store must be on the latest -p release for its line before applying the isolated patch. Adobe Commerce Cloud merchants can take the fix through Cloud Patches instead; Adobe warns that applying the isolated patch as well can cause installation failures.

What IT teams should do

  1. Confirm APSB26-73 is installed on every Commerce, B2B and Magento Open Source instance with the Commerce Version Tool, not the version string. Stores still missing SessionReaper's fix need APSB25-88 as well, Sansec says.
  2. Look for planted files in the pub/media/customer_address/ and pub/media/custom_options/ folders, and search the web root for accesson.php, a file name Sansec's cleanup steps tell you to look for.
  3. Search the cms_block and cms_page tables for scripts you did not add. Sansec's query looks for fpCode and se_referrer.
  4. Review admin_user for accounts nobody recognizes, and check web logs for calls to the REST guest cart routes.
  5. If you find anything, assume the attacker still has a way in. Sansec says removing the injected script leaves the attacker's access in place. Remove backdoors, then reset the passwords for the database, admin users and API integrations.

Stores hosted by an agency or a managed provider are in the same position. Ask them for the Version Tool output, not a yes.

Sources