CVE-2026-48356 cleanup goes beyond Magento core patches

A Magento 2.4.7-p10 store with zero missing core patches picked up the campaign's loader one hour after a clean scan. That single fact means CVE-2026-48356 cleanup cannot stop at patching. The 953-store campaign now serves from deepveindrilling.com, and whatever access let the attacker write that loader is still there. Start with the database query below, then trace back to the access that made the write possible.

SecurityWeek's October 26 report draws on Sansec's October 24 research, which also documents a Magento 2.4.7-p1 store missing APSB26-73 — Adobe's PolyShell fix for supported release lines. For store operators, the risk is a storefront executing attacker-controlled JavaScript despite an apparently reassuring patch status.

Start CVE-2026-48356 cleanup with a Magento CMS search

Search stored content, not just files or visible domain names. Sansec found the loader in Magento's cms_block database table. The domains are often base64 encoded, so the recommended query hunts for code patterns instead:

SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';

1. Add your installation's table prefix if it uses one. Sansec also recommends checking cms_page. Repeat the content-pattern search there, adapting the selected columns to that table rather than blindly copying the block-specific projection.

2. The returned update_time matters: Sansec describes it as the attacker's most recent write, not the date of the initial breach. I'd record the matching identifiers, timestamps and content before editing, so the investigation retains evidence of which loader was present and when the block last changed.

This database focus reflects the observed campaign. Across 148 server installations, eComscan found the loader in CMS blocks, never in core_config_data or theme files. That is an observation about these samples, not a reason to exclude files from the later backdoor search.

The documented cmsBlocks query returns an identified block's content — HTML, CSS, hidden elements, system elements — but requires block identifiers, so it's not a substitute for the database-wide content search. A block need not look suspicious on the rendered storefront for its returned content to deserve inspection.

The loader deliberately distinguishes shoppers from automated inspection, and its delivery server can return no useful content to a scanner — so an empty browser scan is not clearance.

A matching result needs investigation in context. Sansec warns that a store loading these campaign domains has given an attacker database write access. Removing the injected script does not revoke that access.

Why patched Magento stores still received the loader

The campaign's earlier entry route and its later persistence are different problems. On March 30, 2026, the operator injected the loader into 471 stores in one hour after uploading webshells through PolyShell, identified as CVE-2026-48356.

Across the campaign, Sansec found 102 installations with files uploaded through PolyShell or SessionReaper, CVE-2025-54236. One Magento 2.4.7-p1 store had PolyShell webshells disguised as PNG images in pub/media/custom_options/quote/, alongside an injected CMS block. Its block changed to deepveindrilling.com on October 7 while the PolyShell patch remained missing.

The wider comparison strengthens the connection without proving every entry route. Of 169 Magento 2 installations carrying this loader and missing at least one core patch, 102 — 60% — also had uploads through PolyShell or SessionReaper. Among 3,024 comparable installations with a different skimmer, Sansec reported 32%. Those findings support investigating the upload flaws; they do not identify the access mechanism on every store.

The patched-store example makes a different point. Sansec had detected a rogue administrator account on September 16 and a GSocket backdoor on September 24. On October 23, that Magento 2.4.7-p10 store received the new loader despite having no missing core patches.

"Deleting the script does not remove that access."

— Sansec Forensics Team

For CVE-2026-48356 cleanup, I'd treat patch verification and removal of attacker access as separate acceptance checks. A completed upgrade is not evidence that an earlier rogue account, uploaded webshell or other backdoor has disappeared.

How browser storage keeps the loader running

The October loader can reuse code already delivered to a visitor. Its initial script reads fpCode from the browser's localStorage, places that stored code in a temporary element's onclick attribute and triggers the element.

That runs the stored code as an event handler, without eval(). According to Sansec, a visitor who received the payload once can run it again on later page views even when the delivery domain is offline or blocked. The March version instead deleted its stored payload after one execution.

Nothing in that initial CMS script writes fpCode; Sansec attributes that step to the externally loaded script. The distinction explains why stopping a fresh download and stopping execution of previously delivered code are not the same check.

The Hacker News's account of the loader variants also describes the newer fingerprinting behaviour. Sansec dates the rewrite to October 23: it checks:

• navigator.webdriver
• Selenium globals
• ChromeDriver's cdc_ properties
• Hardware and browser characteristics, including the GPU name obtained through WebGL, CPU cores, memory, screen size, time zone, languages and client hints.

The inline loader sends the fingerprint to the delivery URL's fp parameter. The current domain sits behind Cloudflare, and its front page returns a 404.

The server then chooses its response. An automated Chrome visit through urlscan.io received HTTP 200, but Sansec found no added page content. An ordinary-looking response therefore does not establish that the storefront is clean. After the injected scripts are removed, Sansec says nothing on the store reads fpCode any more.

Before October, the campaign used Keitaro's asynchronous script integration as a traffic distribution system. It sent the referrer, page title and query string to a base64-encoded destination. Keitaro could return a payload, redirect or nothing according to the visitor. On October 24, Sansec's Windows desktop request to additionalver.com received QWE=123;, a no-op statement, plus a cookie marking the visitor for 24 hours. The deepveindrilling.com version drops Keitaro and moves bot filtering into the loader itself.

Five loader domains track repeat infections

The latest domain is a rotation within an existing campaign, not a count of entirely new victims. Of the 83 stores found loading deepveindrilling.com, 60 had already carried an earlier loader.

Of those repeat victims, 34 had carried an earlier loader since October 2025. The new domain was registered on October 6, 2026, and appeared on stores the following evening. By the end of October 8, Sansec's crawler had found it on 74 stores: the address changed rapidly across an already-compromised population.

Sansec's historical domain observations show how the delivery addresses changed; the store counts overlap and must not be added together.

The old domains remain relevant to CVE-2026-48356 cleanup because both manulfie.click and neswnsssn.click expired and were re-registered in May 2026. Sansec still found their loaders on stores between August and October. Those browsers send their referrer and page title to the new domain owner and execute whatever script it returns.

Remove Magento backdoors before rotating credentials

Follow the injected block back to the access that made it writable. Sansec's response guidance covers uploaded files, administrator accounts, processes, credentials and patches — not merely the visible JavaScript.

1. Inspect files in the upload locations Sansec identifies, then search for the named PHP file. Its commands are:

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

   find . -name 'accesson.php' -type f

   I'd use these results as an investigation list, not as a blanket deletion list. The first command lists files by location; it does not determine whether each file is malicious.

   Inspect the files themselves — the reported Magento 2.4.7-p1 case involved webshells disguised as PNG images — rather than accepting an image extension as reassurance. Finding the CMS loader and finding the uploaded shell are separate pieces of the same investigation.

2. Check admin_user for accounts you do not recognise and inspect unfamiliar processes. The patched-store example included both a rogue account and a backdoor, so a CMS-only review would leave part of the investigation unfinished.

   Check account findings against the earlier scan history, where available. In Sansec's patched example, the account and GSocket detections preceded the October loader insertion; looking only at the latest block change would omit that history.

3. Remove the injected scripts and identified backdoors, then change the database, administrator and API integration passwords. Sansec explicitly places credential changes after CVE-2026-48356 cleanup.

   After removal, repeat the CMS content searches and re-inspect the affected blocks. That check asks whether the injected content is gone; the account, file and process checks ask whether the means to write it back remains.

4. Apply APSB26-73 for PolyShell and APSB25-88 for SessionReaper, and bring the deployment's patches up to date. For deployments awaiting an upgrade, Sansec says its Shield product blocks both attacks; that is the vendor's mitigation claim, not evidence that an existing compromise has been removed.

I would probably retain the distinction during follow-up: confirm patch status, recheck the identified access mechanisms and repeat the stored-content search rather than relying on a single clean scan. The fully patched store's one-hour interval between a clean scan and a fresh loader insertion is the concrete reason not to treat those checks as interchangeable.

Use the campaign indicators alongside the content search

The historical payload destinations came from browser observations. On December 12, 2025, a logged-in visitor received a manulfie.click script loading crypto-insider.top, then leqdger.click five minutes later. On December 15 and 16, neswnsssn.click inserted the leqdger.click script on two more stores. These observations establish earlier delivery behaviour, not the contents of the uncaptured October payload.

These are Sansec's published indicators. They cover current and historical delivery addresses, payload destinations and stored-code markers; they are not a complete account of what the current payload does.

The current payload and complete affected-version range remain unknown

Sansec had not captured the final deepveindrilling.com payload when it published its research. Earlier versions loaded crypto-themed scripts, including a domain imitating Ledger's name, but that does not establish the current payload's behaviour. These sources do not prove payment-card theft by this loader.

They also do not provide a complete affected-version range or a single fixed Magento version. They identify Adobe patch advisories and observed installations. The fully patched example demonstrates why a version command alone cannot answer whether this campaign has left attacker access behind.

The accompanying October 24 honeypot evidence report documents PHP-engine exploitation before application code. It does not establish that PHP2Shell delivered these Magento loaders, and its evidence supports CVE-2026-109618 without establishing a distinct CVE-2026-109619 path.

I treat CVE-2026-48356 cleanup as a content-and-access investigation, with patching as a required part rather than the finish line. A clean automated visit or current core patches would not be enough for me to close a matching finding.

The content query has a narrower purpose than a complete compromise assessment: it searches for the listed patterns. Likewise, Sansec's statement that removing the scripts stops the store reading fpCode is not a claim that the stored browser value has been erased. I would probably document those limits explicitly rather than describe a negative query as proof that every attacker artifact is gone.