PolyShell CVE-2026-48356: Secure Your Adobe Commerce & Magento Stores

PolyShell is back in the news. On October 27, 2026, CISA added this Adobe Commerce and Magento flaw to its list of vulnerabilities that attackers are using in real attacks, and gave U.S. federal agencies until November 10 to fix it. The date formally applies only to federal agencies. Even so, the listing tells you the flaw is being exploited, and has been for months.

It also arrives days after PHP2Shell, the critical PHP flaws we covered in our guide to PHP2Shell and Adobe Commerce and guide to PH2Shell and Magento. If you run Magento or Adobe Commerce, this blog explains what PolyShell does, which versions need patching, how to check whether your store was already hit, and where Codilar can help.

What is PolyShell (CVE-2026-48356)?

PolyShell is a file upload flaw in the REST API of Magento Open Source and Adobe Commerce. Sansec, the Dutch eCommerce security firm that found and named it, says the vulnerable code has been in Magento 2 since its first release. The flaw carries a CVSS score of 9.3, which is critical.

It starts with how Magento handles custom product options. When a product has a file-upload option, the API accepts the file as base64 data inside the cart request and writes it to pub/media/custom_options/quote/. Sansec's analysis found three checks missing: the code never confirms the option exists on the product, never confirms the product takes uploads at all, and never blocks dangerous extensions such as .php, .phtml and .phar.

The only real test is an image header check, and attackers get past it with polyglot files. A polyglot reads as a valid image and also contains PHP code. The guest-cart routes need no login, so anyone who can reach your store can send the request.

Whether an uploaded file can then run depends on your web server setup, and Sansec found many configurations that allow it. Where execution is blocked, the file still sits on disk, and a later server migration or config change can bring it back to life.

PolyShell timeline: from disclosure to the CISA deadline

PolyShell is more than seven months old, and CISA's October 27 listing is the latest step in a longer story.

CISA lists a flaw only when it has evidence of active exploitation, which is why the October 27 entry matters to every merchant and not only to federal agencies.

How attackers use PolyShell

Sansec watched the same sequence play out across hundreds of stores in March. The attacker first uploads a PHP webshell through the flaw. The shell then drops copies of a backdoor named accesson.php into many folders, so removing one copy leaves others behind. Finally, the attacker injects JavaScript into CMS pages and blocks.

That script profiles each visitor and fetches more code from a server the attacker controls. On March 30, Sansec counted 471 stores compromised in a single hour, which shows how much of the chain runs without a human.

The story did not stop in March. In October, Sansec described a loader stored in the cms_block database table, where file-based scanners tend to miss it. That campaign has infected 953 stores, mostly on Magento, and traces back to July 2025. Sansec also reports finding the loader on stores that had been patched, so a patch alone does not tell you a store is clean.

No one has recovered the second-stage malware, so the attackers' goal is still unknown. The risk for a merchant is concrete anyway: injected JavaScript runs in the browser of every shopper who loads a page that renders the infected block.

Is your store affected? Affected and fixed versions

Adobe's July 2026 bulletin, APSB26-73, lists the affected releases and the builds that fix them. If you run anything in the middle column, you need the matching July release.

Sansec's advisory says the May 2.4.9 release already carried the fix, while Adobe's bulletin lists 2.4.9 as affected and 2.4.9-2026-jul as fixed. Follow Adobe's bulletin and move to the July build.

The July bulletin fixes many vulnerabilities at once, so apply the whole release. Adobe notes that its security patches are non-cumulative and must be applied in sequence, and its Commerce Version Tool shows whether an installation is fully patched.

How to fix PolyShell and check for compromise

Patch first, then check whether someone got in before you did.

Step 1: patch

• Apply Adobe's July 2026 security release, or a newer one, for your release line. Test it in staging before production.
• Confirm the result with Adobe's Commerce Version Tool rather than assuming the patch landed.

Step 2: check for compromise

Sansec's advice covers CMS content, backdoors and admin accounts. It also tells merchants to patch SessionReaper (CVE-2025-54236), an earlier Magento flaw that attackers have used alongside PolyShell.

• CMS content: review the cms_block and cms_page tables for scripts you did not add, especially references to lanhd6549tdhse[.]top, jslibrary[.]net, canevaslab[.]com, additionalver[.]com or deepveindrilling[.]com.
• Upload folder: any .php, .phtml or .phar file in pub/media/custom_options/ is a strong sign of compromise.
• Backdoors: search the whole document root for accesson.php.
• Admin accounts: remove any you do not recognize.

Two commands from Sansec cover the file checks. Swap /var/www for your own document root.

find pub/media/custom_options/ -type f ! -name '.htaccess'

find /var/www -name 'accesson.php' -type f

If you find anything, treat the store as compromised. Remove the files, clean the CMS content, rotate admin and database credentials, and get a forensic review before you call the incident closed.

Step 3: add layers while you work

Blocking web access to pub/media/custom_options/ stops an uploaded file from running, but it does not stop the upload itself. Sansec says only a web application firewall that blocks the vulnerable API calls does that, so keep both measures in place until your patch is verified.

The Brotli flaw (Node2Shell): does it affect your store?

Magento runs on PHP, so exposure to this second flaw usually sits in the Node.js services around it, such as a headless or PWA storefront, a GraphQL gateway or middleware.

CISA added CVE-2026-111497 (CVSS 9.2) to its catalog on the same day as PolyShell. It sits in Google's Brotli library, which many tools use to unpack compressed web data. A crafted stream can corrupt memory, and depending on the setup that can crash the process, leak data or let an attacker run code.

Not every Node.js service is exposed. According to The Hacker News, security vendors say the risk depends on whether an application hands attacker-influenced Brotli data to the decoder. Sysdig names Express 5 with default JSON parsing as a common case, and says the impact demonstrated so far is mass crashes and code execution in a narrow configuration. Exploitation has started all the same: one firm recorded traffic carrying a public exploit that opens a shell on vulnerable builds.

Node.js offers no workaround, so upgrading is the only complete fix, and teams on a discontinued release line need to move to a supported one. PHP's Brotli extension, Bun, .NET and Python have also shipped fixes, so check each vendor's advisory.

Why speed matters: attackers are automating too

PolyShell went from public disclosure to automated mass scanning in two days. By March 30, Sansec says the whole chain, from first upload to injected script, ran without a human and hit 471 stores in an hour. PHP2Shell moved at a similar pace: according to our PHP2Shell analysis, honeypots recorded an exploitation attempt on October 17, four days before PHP had a fix.

AI is speeding this up. Reuters reported in October that, according to NorForge researcher Snorre Fagerland, a Chinese-speaking operator gave autonomous AI agents instructions of fewer than 100 characters and pointed them at eCommerce sites in the U.S., Canada, Australia and Japan. The agents attempted more than 1,200 sites and reached sites tied to more than 100 companies. A successful break-in took about 23 hours of automated probing, and researchers put the cost near $5,000 in AI tokens.

A patch window measured in weeks no longer matches how attackers work. Secure what you can quickly, and plan for the day something gets through anyway: know your exposure today, and keep customer data protected even if an attacker reaches your database.

How Codilar can help

Codilar is an Adobe Gold Solution Partner with Adobe Commerce and Magento implementations across the world. If you want a second pair of eyes on your store this week, this is where we can help.

PolyShell Exposure Check

Our PolyShell Exposure Check tells you whether your store is affected, so you know whether you need to patch, clean up or both. To request one, reach the Codilar team.

PII Shield

PII Shield is our field-level encryption extension for Adobe Commerce and Magento 2. It encrypts customer names, emails, phone numbers, addresses and order data in the database, so a copied backup or direct database access exposes encrypted values instead of customer details. It works alongside patching and monitoring, not in place of them. Clients across the UAE, Saudi Arabia and other regions already run it.

Ongoing support

If you would rather hand day-to-day store operations to a team, Codilar also offers managed services and Magento hosting, alongside Adobe Commerce development.