Magento and Adobe Commerce: attackers exploit the PolyShell flaw

What happened

Adobe Commerce and its open-source edition, Magento Open Source, power a large share of the world's online stores. CVE-2026-48356, which the security firm Sansec named PolyShell, is an unrestricted file upload flaw: an attacker can get a file of a dangerous type onto the store's server and use it to run their own code.

Adobe fixed the flaw on 14 July 2026 in security bulletin APSB26-73. On 27 October 2026 CISA added it to its Known Exploited Vulnerabilities (KEV) catalog, which means it has evidence of attacks in the wild. US federal civilian agencies must apply the fix by 10 November 2026.

This isn't a new bug – it's an old one that's now confirmed as exploited. Sansec ties it to a long-running campaign that has hit 953 stores since July 2025, most of them on Magento, and in March 2026 it saw a single PolyShell wave put malicious code on 471 stores within one hour.

Technical details

According to the CVE description, successful exploitation could lead to arbitrary code execution as the current user. It requires user interaction, such as visiting a malicious URL or a compromised page, and the scope is "changed" – the impact reaches beyond the vulnerable component itself.

Adobe's public pages don't name the vulnerable upload feature, and we won't guess at it. What Sansec has published is the attack chain it sees on infected stores:

In the October wave, the loader sits in the cms_block table, which Magento renders into storefront pages. Sansec describes two parts: one script reads a stored value from the shopper's browser storage (localStorage) and runs it, so the payload can come back on later visits even if the attacker's domain is offline; a second script loads from the attacker's domain and, since 23 October, sends a browser fingerprint first. If the fingerprint looks like an automated browser, the server returns nothing harmful. That's why a quick scan of the storefront can come back clean.

Sansec says it hasn't yet captured the final payload served to real visitors, so the ultimate goal – card skimming, redirects or something else – isn't confirmed. Earlier stages routed visitors through a commercial traffic distribution tool. The same operator has also used SessionReaper (CVE-2025-54236), an older Magento flaw fixed in Adobe bulletin APSB25-88.

Who is affected

Stores on Adobe Commerce or Magento Open Source that haven't installed APSB26-73. Adobe lists these versions as affected:

• 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 Adobe Commerce B2B extension is covered by the same bulletin. Shoppers don't need to do anything – this is a job for the store owner or the agency that runs the store. Stores that patched late should treat themselves as possibly compromised until they've checked.

How to tell if you were compromised

Adobe doesn't publish indicators of compromise. Sansec does, in its 24 October 2026 report. In short:

• Database: search the cms_block and cms_page tables (mind any table prefix) for the strings fpCode, se_referrer and localStorage.getItem. The update_time column shows when a record was last written – changes nobody on your team made are a red flag.
• Files: unexpected files in pub/media/custom_options/ (Sansec saw webshells disguised as PNG images in pub/media/custom_options/quote/) and pub/media/customer_address/, and any file named accesson.php anywhere on the server.
• Accounts and processes: unknown entries in the admin_user table and processes on the server you can't explain.
• Network: connections from shoppers' browsers or from the server to the loader domains Sansec lists, including deepveindrilling.com, additionalver.com, lanhd6549tdhse.top, neswnsssn.click and manulfie.click.

Sansec's report has the full list of URLs and strings. If you need to pull domains and URLs out of exported logs or a database dump, our IOC extractor does it entirely in your browser. To compare a suspicious file with a known-good copy from backup, check its fingerprint in our hash calculator – the file never leaves your device.

Keep in mind that Sansec's server-side cloaking means a storefront can look clean to automated checks while still serving the loader to real visitors. The database is the more reliable place to look.

What to do

1. Find your version, or ask the agency that runs your store.
2. Install APSB26-73. Adobe provides an isolated patch for each release line (for example 2-4-8-p5-jul-2026.zip). You first need the latest security-only release of your line (2.4.8-p5, 2.4.7-p10 and so on); patches are not cumulative and must be applied in sequence. Open Source users can download patches for 2.4.6 and later; Adobe Commerce 2.4.5 and earlier need Composer keys. On Adobe Commerce Cloud, the fix is in the latest cloud-patches update – don't apply the isolated patch on top, because Adobe warns it can make the installation fail.
3. Verify the patch with Adobe's Commerce Version Tool, or on cloud with vendor/bin/magento-patches -n status.
4. Check for compromise as described above – even if you patched months ago.
5. Clean up properly. Removing the injected script isn't enough, Sansec warns, because it doesn't remove the attacker's database access. Change database, admin and API integration passwords after cleanup (our password generator creates strong ones locally) and install APSB25-88 for SessionReaper too if you haven't.
6. Report it. If customer data may have been exposed, check your obligations under data protection law – in the UK, report a personal data breach to the ICO within 72 hours; in the EU, to your national authority. Incidents can also be reported to the NCSC in the UK or CISA in the US.

Timeline