An Adobe Commerce and Magento Flaw Joins CISA's Exploited List: Fixed in July, Attacked Since March, and What to Check

On October 27, 2026, the US CISA added a vulnerability in Adobe Commerce and Magento Open Source (CVE-2026-48356) to its Known Exploited Vulnerabilities (KEV) catalog. The deadline for US federal agencies is November 10 (CISA). The security firm Sansec calls the flaw “PolyShell”.

The fix shipped on July 14. Yet Sansec reports seeing attacks from March, and Adobe’s advisory, the CVE record and Sansec’s report describe the flaw quite differently. This article separates what is firm from what each party infers.

It is for companies that run Adobe Commerce or Magento Open Source themselves. The information is current as of October 30, 2026. The Brotli flaw, added to KEV the same day, is covered separately.

Key points

• The flaw is in the shop’s REST API (the guest cart), which accepts a file upload. According to Sansec, an unauthenticated attacker can place a file containing PHP, and on some server configurations it then runs.
• The fix is in Adobe’s update APSB26-73 (July 14). Fixed versions are named like 2.4.8-2026-jul, so look for the “-2026-jul” ending. A version with a “-p” number such as 2.4.8-p5 is still listed as affected in Adobe’s table, even if it is the latest “-p”.
• Some reports read as if PolyShell hit 953 stores. Sansec’s original does not say that. 953 is the number of stores where one criminal group has planted code since July 2025, and the entry point is not pinned to one flaw.
• The three sources describe the risk differently. Adobe’s advisory and the CVE record say “user interaction required”. The attack Sansec shows needs no victim action.
• Installing the fix does not clean a store that is already compromised. Check the files and the database.

What happened

CISA’s stated reason is “evidence of active exploitation”, but it does not say who exploited what, where, or how often.

The three sources describe it differently

(I built this table from the originals: Adobe, the CVE record and Sansec.)

Sansec assigns CVE-2026-48356 to this flaw. In what I read, neither Adobe’s advisory nor the CVE record uses the name PolyShell. I have not confirmed why the same flaw is described so differently. What matters in practice is not to lower the priority because of “victim action required”: the attack Sansec shows does not need one.

How to read the 953 stores

Some reports read as if “at least 953 stores were hit by attacks exploiting CVE-2026-48356” (for example, Security Affairs). Sansec’s original does not say that (Sansec, Oct 24).

• 953 is the number of stores where one criminal group has planted code in CMS blocks since July 2025. How it was counted is not stated.
• There is not a single entry point. Sansec says that in the March wave the code went in through webshells placed with PolyShell. It says the October rewrites used no new vulnerability.
• Of 169 installs missing at least one patch, 102 also had files uploaded through PolyShell or another flaw (SessionReaper, CVE-2025-54236).
• The other numbers are also what Sansec saw with its own protection product (Shield). For example, “79.5% of stores were targeted” uses “all stores” as the denominator in one place and “protected stores” in another (Sansec, Mar 17).

Sansec also sells protection products and scanners. Its research is detailed and useful, but it is safest to read its numbers as estimates based on its own observations.

What is affected

Adobe’s advisory lists these affected versions and fixed versions (Adobe).

Two cautions when reading it.

• The fixed versions are named “-2026-jul”, not “-pN”. Even if your “-p” number is the newest, without the -2026-jul suffix the fix is not in. This is simply how Adobe’s table reads.
• Sansec wrote in May that “2.4.9 includes the fix”. Adobe’s table lists 2.4.9 as affected, with 2.4.9-2026-jul as the fix. I have not confirmed this discrepancy. Moving to the -2026-jul version of your line is safe under either account.

A case where a team updated but was not fixed is in another article.

What to do now

1. Check your version and update to the fixed one

bin/magento --version

Compare it with the table above and move to a version with the -2026-jul suffix. For Magento Open Source 2.4.5 and earlier, Adobe’s advisory lists neither an affected nor a fixed version (no reason is given). If you are on that line, ask whoever maintains the shop, or Adobe, where you stand.

2. Check for planted files

Sansec says any PHP file in the upload folder is a sign of compromise (Sansec). Here is an example check (my own example; adapt it to your environment).

find pub/media/custom_options -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)
find . -name 'accesson.php'

If there is a PHP-type file in pub/media/custom_options, treat the store as compromised.

3. Check CMS blocks and admin accounts

In its October report, Sansec lists fpCode, se_referrer and localStorage.getItem as search terms (Sansec). Here is an example check (my own example).

SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
SELECT page_id, identifier, update_time FROM cms_page
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
SELECT username, email, created FROM admin_user;

Also look for admin accounts you do not recognize.

4. If you find something

• According to Sansec, deleting the planted script does not remove the attacker’s way in.
• Rotate the database, admin and API integration passwords (Sansec’s recommendation).
• Saving the current state before cleaning up lets you investigate later (this is my own suggestion).

5. A stopgap while you wait to update

Sansec suggests making PHP not run in the upload folder (nginx: deny the folder before the PHP location block; Apache: php_flag engine 0 and Deny from all in .htaccess), and blocking at the API level with a WAF. Blocking access to the folder does not stop the upload itself. I have not tested these settings.

What is not confirmed

• I have not confirmed why Adobe’s advisory, the CVE record and Sansec describe the flaw differently.
• Adobe’s advisory said “not aware of any exploits in the wild” on July 14, was updated on August 11, and still carried that wording when I read it on October 30. I have not confirmed how that relates to Sansec’s reports of attacks from March.
• Sansec’s October report does not pin the entry point of the 953 stores to one flaw. It also says a store on a “patched release (2.4.7-p10)” received the code. In Adobe’s table 2.4.7-p10 is an affected version. I have not confirmed what Sansec means by “patched”.
• Whether fixes are applied automatically on Adobe Commerce Cloud (the environment Adobe operates) is not stated in Adobe’s advisory.
• CISA does not say who exploited what, where, or how often. Use in ransomware campaigns is “Unknown” in the KEV data.
• I have not tried Sansec’s indicators (file names, key names) on a real store.

Related articles

• The Brotli Vulnerability Is Not Just a Node.js Problem: Where to Check and What Is Known About Exploitation: The other flaw added to KEV the same day, October 27. A flaw in a component that products bundle
• Two Critical GitLab Flaws, Not One: Why the October 12 Fix Is Not Enough: A case of updating without being fixed. Version numbers alone can hide things
• Where PHP2Shell Reports and the Primary Sources Disagree: How to read gaps between the numbers in reports and in primary sources
• VPNs, Email Gateways and Remote-Support Tools: The Edge Devices Exploited This Month, and What to Check Now: The edge devices added to KEV this month

If you’d like help checking versions, updating, or checking for compromise on your online store, get in touch.