The Dutch company Sansec reports a large-scale campaign in which attackers have infected 953 online stores, mainly running on the Magento (Adobe Commerce) platform. The campaign has been active since July 2025 and uses the Magento CMS-block mechanism to inject a malicious JavaScript loader that deliberately bypasses automated security scanners and only serves malicious code to real shoppers. Owners of stores running Adobe Commerce and Magento Open Source must immediately check the cms_block and cms_page tables for suspicious code and apply the latest security patches.
Attack mechanism: CMS blocks as a persistence vector
The attackers insert a small fragment of code into Magento CMS blocks — the cms_block database table, which is used to render static content (header, footer, promo banners) on store pages. When a compromised page is visited, the customer’s browser contacts the attackers’ server, which first checks whether the visitor is a real person or an automated scanner. Scanners receive nothing — this is a key reason why the campaign remained undetected for so long.
According to Sansec, five domains have been used during the campaign:
manulfie[.]click— since July 2025neswnsssn[.]click— since December 2025lanhd6549tdhse[.]top— since March 2026additionalver[.]com— since June 2026deepveindrilling[.]com— since October 2026
The last domain, registered on October 6, 2026, has, according to Sansec, been found in the CMS blocks of 83 stores.
Two loader versions and defense evasion
Researchers have identified two versions of the loader. The first stores the payload in the browser’s localStorage, which ensures repeated execution of the malicious code on subsequent visits — even if the attackers’ external domain becomes unavailable. The second version also uses browser fingerprinting to filter out bots and security scanners.
Earlier iterations of the campaign used the Keitaro platform as a traffic distribution system (TDS), allowing different responses to be returned depending on visitor characteristics. The latest domain, deepveindrilling[.]com, has abandoned Keitaro and embedded the bot-filtering logic directly into the loader.
The final payload delivered by the loader had not been captured at the time Sansec’s research was published. This means that the exact nature of the threat to customers — whether theft of payment data, redirects, or other malicious activity — remains undetermined.
Initial access vectors and conflicting assessments of exploitation
Sansec estimates that 471 stores were compromised via the CVE-2026-48356 (PolyShell) vulnerability — a critical dangerous file upload vulnerability (CWE-434) in Adobe Commerce, rated CVSS 9.6 by Adobe. Another 102 stores, according to Sansec, were compromised via PolyShell or CVE-2025-54236 (SessionReaper) — an input validation vulnerability with a CVSS score of 9.1.
There is an important discrepancy here: in advisory APSB26-73, Adobe states that the company was not aware of exploitation of the vulnerabilities covered by this update in real-world attacks, whereas Sansec directly links CVE-2026-48356 to the mass infection. The situation is different for CVE-2025-54236 — Adobe confirms exploitation in the wild. Both vulnerabilities are listed in the CISA KEV catalog.
Affected Adobe Commerce versions for CVE-2026-48356: 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.
Patches do not guarantee security
One of the most troubling findings in Sansec’s research: a fully patched Magento 2.4.7-p10 store with no missing core updates was compromised via the creation of a fake administrator account, which was then used to inject malicious code. This means that updating to the latest version is a necessary but insufficient protection measure. The loader is stored in a database table rather than in the file system, so removing the script from files will not eradicate the infection if the database has not been checked and compromised accounts have not been revoked.
Connection to PHP2Shell
Sansec’s publication coincided with active exploitation of two critical PHP RCE vulnerabilities — CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2 each), known as PHP2Shell. According to a report by researcher Adel Karimi, 35 instances of shell command execution were recorded on honeypots running PHP 8.4.26 under Apache mod_php on October 24, 2026. Both vulnerabilities are listed in the CISA KEV catalog. We have already written about these vulnerabilities — they affect PHP versions earlier than 8.2.35, 8.3.36, 8.4.27 and 8.5.12. It is important to stress that this is a separate threat vector from the Magento CMS-block campaign: PHP2Shell is associated with vulnerabilities in the PHP interpreter itself, whereas the Magento campaign exploits application-level vulnerabilities.
Indicators of compromise
Loader domains:
manulfie[.]click,neswnsssn[.]click,lanhd6549tdhse[.]topadditionalver[.]com,deepveindrilling[.]comhdfdsi84j3h[.]top,c85grt98sd[.]com
IP addresses: 15.204.59.70, 104.28.208.84, 144.48.4.242, 162.35.99.94
Recommendations
- Check the database: search the
cms_blockandcms_pagetables for the patternsfpCode,se_referrer,localStorage.getItemand the listed domains. - Audit accounts: review the list of administrators for unknown or suspicious accounts — even on fully updated systems.
- Apply patches: install update APSB26-73 to remediate CVE-2026-48356 and make sure the patch for CVE-2025-54236 has already been applied.
- Update PHP: to versions 8.2.35, 8.3.36, 8.4.27 or 8.5.12 to fix the PHP2Shell vulnerabilities.
- Strengthen authentication: implement strong passwords and two-factor authentication for administrative panels.
The campaign demonstrates the evolution of web skimming tactics: storing the loader in the CMS database instead of the file system, persistence via the browser’s localStorage, and active scanner filtering make detection with standard tools extremely difficult. Owners of Adobe Commerce and Magento stores should immediately audit the cms_block database table and administrative accounts — simply updating to the latest platform version is not enough to guarantee there has been no compromise.
