Adobe Commerce PolyShell Hits Hundreds of Stores, Enters KEV

CISA added Adobe Commerce PolyShell (CVE-2026-48356) and a Google Brotli decoder flaw (CVE-2026-111497) to its Known Exploited Vulnerabilities catalog on 27 October 2026, after attackers used PolyShell to plant loaders in hundreds of Magento stores. For Cyprus merchants and iGaming operators, patching alone will not settle this: the campaign has run since at least July 2025.

What did CISA add to the KEV catalog on 27 October 2026?

Two flaws, both rated above 9 on CVSS, listed on Tuesday, 27 October 2026, with evidence of active exploitation for each. They sit in very different parts of a typical stack, and many teams that read the entry will end up patching only one of them.

• CVE-2026-48356 (PolyShell), CVSS 9.3: an “unrestricted upload of a file with dangerous type” weakness in Adobe Commerce and Magento. The description says it can lead to arbitrary code execution in the context of the current user, possibly with control over that user’s account or session.
• CVE-2026-111497, CVSS 9.2: a flaw in Google’s Brotli decompression library that circulates under three names: Node2Shell, Broccoli2Shell and HTTP2Shell. A remote, unauthenticated attacker who supplies a crafted Brotli stream can corrupt decoder memory, leak memory contents, crash the process or, in some configurations, execute code.

U.S. Federal Civilian Executive Branch agencies must fix both by 10 November 2026, a 14-day window set under Binding Operational Directive 22-01. That deadline binds U.S. federal agencies only and creates no legal duty for a Limassol payment institution or a Nicosia online shop, but it is still a useful deadline to work to.

A KEV listing requires evidence of exploitation. An acquirer or auditor who asks why you took longer than a U.S. agency will not accept a CVSS argument.

The pairing matters. PolyShell is a merchant problem with confirmed victims. The Brotli bug reaches into Node.js, PHP, proxies and cloud appliances, but it only causes harm where attacker-controlled bytes reach the decoder. If you suspect a Magento compromise, our triage order is in the section on what we check first.

How did Adobe Commerce PolyShell get into hundreds of stores?

According to e-commerce security firm Sansec, attackers used PolyShell to inject a small loader into Magento CMS blocks, and hundreds of stores have been breached this way. Sansec has not published an exact count. No victims have been named, and no operator has been identified.

CMS blocks are the part of Magento built for marketing teams. They are reusable HTML snippets for headers, footers, banners and product pages, edited in the admin panel and stored in the database.

They are not files in the theme directory, and that is why they make a good hiding place. A file-integrity check against your git repository will report a clean codebase, because the injected content lives in a database row.

The loader has one job: fetch a payload from attacker-controlled infrastructure and execute it. This lets the operator change what every compromised store does without returning to any of them. It also means the important part lives somewhere else.

No next-stage malware has been recovered, so nobody can yet show whether the goal is card theft, credential harvesting, redirect fraud or resale of access.

The timeline matters more than the count. The activity is assessed to have run since at least July 2025, roughly 15 months before the KEV listing. A store patched this week may have been compromised last year. The fix stops new compromises. It does not remove a loader that is already in your database.

Magento flaws have a track record of being weaponized quickly at scale, which is reason enough to assume PolyShell scanning is widespread. It is not evidence that PolyShell’s operators are after cards, because nobody has seen the payload.

Why is a Magento CMS block a checkout problem?

Because CMS block content renders in the shopper’s browser, often on cart and checkout pages. A block injected into a global footer loads on every page, including the payment step, unless the merchant has explicitly excluded it.

The listed impact of CVE-2026-48356 is code execution as the current user, possibly with control over that user’s account or session. On a storefront, that user could be a customer or an administrator whose session can create admin accounts, change payment settings or edit more blocks. Both paths end the same way: someone else decides what loads on your checkout.

We covered the same risk class in the Convertr analytics skimmer case, where attackers rewrote a self-hosted tracker and turned merchant checkouts into card skimmers. The entry point there was different, but the rule is the same: an attacker who controls content that reaches your payment page controls the page.

For PCI DSS v4.0 merchants, requirements 6.4.3 and 11.6.1 already demand three things:

• an inventory of every script on payment pages;
• a justification for each script;
• a mechanism that detects unauthorized changes to what the browser receives.

A loader in a CMS block is exactly the change those controls exist to catch. If your monitoring only watches theme files, it will miss it.

For iGaming operators, the cashier plays the same role as a checkout. Check whether a Magento or Adobe Commerce store sits on the same parent domain as the player account, or shares cookies or single sign-on with it. If it does, the shop is in scope for the cashier.

Our iGaming and online casino penetration testing regularly finds session sharing between the “merch store” and the wallet.

What we check first on a suspected Magento compromise

On e-commerce engagements, the database is where we find what file scans miss, and admin access is usually where the trouble started. On a suspected PolyShell case, we work in this order:

1. Snapshot before cleaning. Preserve web, admin and database logs, plus a database and disk snapshot. If you delete the loader first, you destroy the evidence your forensic investigator, acquirer and regulator will ask for.
2. Read CMS content by modification date. Sort blocks and pages by last update and review every change since the campaign began. Do the same for design configuration fields that inject HTML or scripts into the page head and footer. Look for script tags, encoded strings and domains you do not recognize.
3. Audit admin users and integrations. Unexpected administrators, new API integration tokens and admin logins from unfamiliar networks are the usual signs of account or session takeover.
4. Check writable directories. New PHP files under media or temporary folders are where upload flaws tend to leave artifacts.
5. Check egress. A loader that fetches a payload has to call out. PHP-FPM and web nodes rarely need to open connections to arbitrary hosts, so outbound logs often answer the question faster than code review.

The weakness we report most often in Magento assessments is not a missing patch. It is an admin panel reachable from the whole internet with password-only login, shared between an agency, a freelancer and in-house staff.

Restricting admin by IP or VPN and enforcing two-factor authentication reduces the account and session half of PolyShell’s impact, whatever the bug.

When does the Node2Shell Brotli flaw actually affect your stack?

Only when an application decompresses Brotli data that an attacker can influence. Running Node.js, or serving Brotli-compressed responses, is not the vulnerable path on its own.

Rapid7 states the precondition: “An attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory,” and that corruption “can lead to a process crash, disclosure of sensitive process memory, or remote code execution.”

CISA’s entry classifies the root cause as an unchecked return value; the practical effect is corruption of decoder memory. Use the classification from the Node.js and Google advisories when you log it in a risk register.

Sysdig makes the same point: “Node2Shell is not a bug in every Node.js service, but a bug in services that decode attacker-influenced Brotli.” It warns that Express 5 with default JSON parsing puts a large number of services in that group. For Cyprus fintech and EMI teams, Express-based payment, onboarding and account APIs come first.

Sysdig says the impact demonstrated so far is crashes at scale, plus code execution in a narrow configuration. Its advice is to set patch order by reachability.

Evidence of exploitation is thin but real:

• Previdian’s honeypots recorded one exploitation attempt from a U.S.-based IP address as of 27 October. Whether that reflects wider activity is unknown.
• On 26 October, ELLIO reported in-the-wild traffic “carrying the public exploit that we confirmed gets a shell on vulnerable builds.” The payload was a correctly built attempt against Node.js v24.22.0 that matched public tooling exactly. ELLIO called this “indicative of the RCE being adopted by an operator focused on mass exploitation.” The traffic came from one IP geolocated to the Netherlands that had also targeted the separate PHP2Shell flaws. Pull IOCs directly from ELLIO’s advisory rather than from secondary summaries.

Each sensor network saw one source. That is not a global count, and geolocation does not identify an operator. It does show that the public tooling is being used in the wild, and ELLIO separately confirmed that the same exploit gets a shell on vulnerable builds.

Google-owned Wiz says 91% of cloud environments have resources vulnerable to the flaw, and 82% have publicly exposed Node.js instances. Treat these as inventory figures: having a vulnerable version installed is not the same as having a reachable decoder.

Fixed releases:

• Node.js: 22.23.4, 24.22.1 and 26.12.1. Akamai notes that “the Node.js advisory does not offer a workaround, so upgrading is the only complete remediation.” Teams on discontinued release lines must move to a supported one.
• PHP: 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1.
• Others: Bun, Envoy Proxy, Istio, .NET, Python, ClickHouse, the PHP Brotli extension and the Ruby brotli gem have shipped fixes. Downstream advisories have come from vendors including Amazon Linux, Cisco, Cloudflare, F5, Fortinet, Palo Alto Networks, Red Hat and Ubuntu.

Sequence these by reachability, as Sysdig advises: internet-facing services that decode client-supplied Brotli first, everything else after.

An advisory from a vendor on that list is not proof that the product you run is affected. Read the advisory for each product in your estate and check what it says about your version.

What should Cyprus commerce and fintech teams do this week?

If you run Adobe Commerce or Magento, patch PolyShell first, because it has confirmed victims. Then work through the Brotli flaw by reachability.

• Magento and Adobe Commerce: apply Adobe’s fix for CVE-2026-48356 for your release line, then run the database review above. Once the store is clean, invalidate admin sessions and rotate admin passwords and integration tokens.
• Payment pages: refresh your 6.4.3 script inventory. Confirm that 11.6.1 change detection covers content rendered from the CMS, not only theme files.
• Node.js: list services that accept compressed request bodies, uploads, queue messages or proxied content. For each, identify which runtime actually decodes those bytes. Upgrade those services to 22.23.4, 24.22.1 or 26.12.1 first, then the rest.
• Bundled copies: updating the OS Brotli package does not fix a copy bundled into Node.js, a container base image, an Envoy or Istio sidecar, or an appliance. Each needs its own fixed build. Rebuild images, redeploy, restart long-lived processes, then check the version of the running process, not the lockfile. We made the same point about PHP workers that stay exploitable after a patch: a fix on disk is not a fix in memory.
• Write it down: for each asset, record the version before and after, whether the decoder path was reachable, the change time and who approved it. One table like this answers most PCI, NIS2 and DORA evidence requests.

If you cannot say which of your APIs decode client-supplied compressed data, settle it with a scoped test rather than a guess.

PCI DSS penetration testing covers payment pages and the segmentation around the cardholder data environment. E-commerce penetration testing covers the admin, CMS and checkout logic that PolyShell abuses.

When does patching become a reportable incident?

Once you find a loader in a CMS block, you are handling an incident, not a vulnerability. For a Cyprus merchant or iGaming operator, a compromised checkout can trigger three obligations at once.

• PCI DSS: notify your acquirer.
• GDPR: notify the Commissioner for Personal Data Protection within 72 hours where the breach poses a risk to individuals.
• NIS2: for entities in scope, an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month.
• DORA: for financial entities, a major ICT-related incident requires an initial notification within four hours of classification and no later than 24 hours after awareness, an intermediate report within 72 hours, and a final report within one month.

Whether a specific intrusion crosses those thresholds is a separate assessment. Document it even when the answer is no.

Time works against you here. An EMI that finds a loader dated March 2026 faces a harder conversation with its supervisor than one that patched on 28 October, reviewed its CMS content and found nothing.

What is still unknown?

Three gaps limit what anyone can say. First, the PolyShell payload: without a recovered next stage, the objective is unknown, and unknown does not mean harmless.

Second, scale and attribution: Sansec says hundreds of stores without giving a number, and no operator has been named for either campaign.

Third, the breadth of Brotli exploitation: the public record is one honeypot hit and one Netherlands-geolocated source. ELLIO says the public exploit gets a shell on vulnerable builds, so expect those numbers to grow. Watch Sansec and Adobe for payload analysis, and the Node.js project for any revision to the fixed releases.

FAQ

Is PolyShell the same issue as CVE-2026-48356?

Yes. PolyShell is the public name for CVE-2026-48356, an unrestricted file-upload flaw in Adobe Commerce and Magento rated CVSS 9.3.

Does patching Magento remove a PolyShell CMS-block loader?

No. The loader sits in the database as CMS content, so code updates and theme rebuilds leave it in place. Review blocks, pages and design configuration changed since July 2025, and preserve evidence before you delete anything.

Is every Node.js service exposed to CVE-2026-111497?

No. Exposure requires the application to decompress attacker-influenced Brotli data. Sysdig flags Express 5 with default JSON parsing as a common path, so prioritize those services.

Which Node.js versions fix Node2Shell?

Node.js 22.23.4, 24.22.1 and 26.12.1. The Node.js advisory offers no workaround, so upgrading is the only complete remediation.

Does the 10 November 2026 deadline apply to Cyprus companies?

Not legally. It binds U.S. Federal Civilian Executive Branch agencies under BOD 22-01. Because both flaws are confirmed exploited, it is still a reasonable target date for EU firms.

Has the PolyShell payload been identified?

No. The loader fetches and runs an attacker-controlled payload, but no next-stage malware has been recovered, so the campaign's goal is still unknown.

We review CMS content, admin access and checkout scripts on live Adobe Commerce and Magento stores, and test which of your APIs actually decode client-supplied data. See our e-commerce penetration testing service.