Sansec tracks a Magento skimmer campaign that infected 953 stores, using five domains, bot filtering and malicious code hidden in CMS blocks.
A criminal group has infected 953 online stores since July 2025, mostly Magento shops, according to Sansec researchers. The attackers add a small piece of code to store pages. When someone visits a shop, their browser contacts the attackers’ server to get further instructions. The server checks whether the visitor is a real shopper or a security scanner. If it detects a scanner, it hides the malicious activity.
“deepveindrilling.com is the newest web address of a criminal group that breaks into online stores. The group adds a small piece of code to the store’s pages.” Sansec’s analysis states. “The group has done this to 953 stores since July 2025, mostly Magento shops. It moves to a new address every few months.”
The group’s latest domain is deepveindrilling.com. Sansec found it in the CMS blocks of 83 stores, almost all running Magento. CMS blocks are content sections that Magento adds to store pages. The domain was registered on October 6, 2026, and the first stores began loading it the following evening.
This is the fifth domain linked to a campaign that Sansec has tracked since July 2025 and reported in March as the PolyShell mass attack. Most stores using the latest domain had already been targeted. Of the 83 stores, 60 had previously loaded one of the group’s malicious scripts, and 34 had been doing so since October 2025.
The domain sits behind Cloudflare, and its front page returns a 404. It only answers script requests from visitors of infected stores. The loader code lives in the cms_block table, and Sansec’s scanner, eComscan, found it there on 148 server installs over the campaign, never in core_config_data or theme files.
eComscan first found the new loader at 21:54 UTC on October 7. By the end of October 8, Sansec’s crawler had found it on 74 stores, as two scripts. The first reads a value called fpCode from the visitor’s browser storage, and when the value is set, the script puts the stored code in an invisible div and clicks it. The browser then runs the code as an event handler, without using eval().
Nothing in the block writes fpCode, so the script from deepveindrilling.com has to set it. A visitor who received the payload once runs it again on every later page view, even when the domain is offline or blocked. The March version deleted its stored payload after one run.
On October 23 the operator rewrote the blocks again, and the loader appeared on 9 more stores. All 71 stores Sansec re-crawled by October 24 run the new version. It replaces the plain script tag with an inline loader that sends a browser fingerprint to https://deepveindrilling.com/?s=49b7ca5f&fp=.
The fingerprint flags automated browsers through navigator.webdriver, Selenium globals and ChromeDriver’s cdc_ properties. It also adds the GPU name from WebGL, CPU cores, memory, screen size, time zone, languages and client hints. The server picks its response from all of that.
The filter works. When urlscan.io loaded an infected store with an automated Chrome browser, it got HTTP 200, and Sansec found no added content in the page. Sansec hasn’t captured the final payload yet.
Older payloads give a hint of what real visitors get. Sansec Watch, the firm’s monitoring service for content security policies, shows what the earlier stage served. On December 12, 2025, a customer logged in to an infected store got a script from manulfie.click that loaded https://crypto-insider.top/ssl/ and, five minutes later, https://leqdger.click/ssl/.
On December 15 and 16, neswnsssn.click inserted the same leqdger.click script on two more stores. leqdger.click is a misspelling of the crypto wallet brand Ledger. It was registered on September 12, 2025 and has since expired.
Before October, the second script was the “Script (async)” integration of Keitaro, a commercial ad tracker that doubles as a traffic distribution system, a tool that sorts visitors. It sends the referrer, page title and query string to a base64 encoded URL such as https://additionalver.com/Mb2z8J?&se_referrer=, where the path is the Keitaro campaign alias. The system then decides per visitor whether to return a payload, a redirect or nothing.
“When Sansec requested the additionalver.com script as a Windows desktop visitor on October 24, it returned QWE=123;, a statement that does nothing, and set a cookie that marks the visitor for 24 hours. deepveindrilling.com drops Keitaro and moves the bot filtering into the loader.” continues the report.
Here are the five loader domains over 15 months:
Domain
Registered
First seen on stores
Stores
manulfie.click
before July 2025, re-registered 2026-05-23
2025-07-09
863
neswnsssn.click
before December 2025, re-registered 2026-05-22
2025-12-12
494
lanhd6549tdhse.top
2026-03-25
2026-03-30
355
additionalver.com
2026-06-07
2026-06-08
246
deepveindrilling.com
2026-10-06
2026-10-07
83
Two other domains were found on a small number of stores: hdfdsi84j3h.top, registered three minutes after lanhd6549tdhse.top, and c85grt98sd.com.
Two older domains, neswnsssn.click and manulfie.click, expired and were registered again in May 2026. Both now use the nameservers of abovedomains.com, a domain parking service. Between August and October 2026, Sansec still found the manulfie.click loader on nine stores and the neswnsssn.click loader on six. When visitors open these stores, their browsers send information about the previous page and the current page title to the new domain owner. The browsers also run any script returned by that domain.
Sansec Watch received reports of visitors’ browsers connecting to all four earlier domains. One domain, additionalver.com, was linked to around 52,000 reports.
The October activity did not rely on a new vulnerability. Of the 83 affected stores, 60 had already been infected. Earlier attacks appear to have exploited file upload flaws in Magento. In March, the group injected its malicious code into 471 stores in just one hour by uploading webshells through PolyShell (CVE-2026-48356).
Some infected Magento stores had files uploaded through PolyShell or SessionReaper (CVE-2025-54236). In a separate group of 3,024 stores affected by another skimmer, the infection rate was 32%.
One Magento 2.4.7-p1 store contained PolyShell webshells disguised as PNG images, alongside malicious code in a CMS block. The code switched from additionalver.com to deepveindrilling.com on October 7. The store had not installed Adobe’s PolyShell fix, APSB26-73.
However, installing all patches does not guarantee a store is safe. Another store running Magento 2.4.7-p10 had no missing core patches but was infected on October 23. Earlier scans had already found a rogue admin account and a GSocket backdoor.
Sansec recommends checking CMS content for malicious code, including base64-encoded domains. Administrators should search both the cms_block and cms_page tables for suspicious patterns such as fpCode and se_referrer. They should also inspect uploaded files for webshells, check for unknown admin accounts, and look for suspicious processes. Removing the malicious scripts is not enough: store owners must also identify and fix the vulnerability or backdoor that allowed the attackers in.
After cleanup, change the database, admin and API integration passwords. Install APSB26-73 for PolyShell and APSB25-88 for SessionReaper. Sansec Shield blocks both attacks while you schedule the upgrade.
Sansec lists the indicators of compromise at the end of its report.
“If your store loads any domain from the indicators of compromise, the attacker can write to your database. Deleting the script does not remove that access. See How to check your store.” concludes the report.
Expect to see quite a few websites serving error pages today: Nearly 70 percent of websites need to update their core software to fix a pair of vulnerabilities that allow an attacker to seize full control over affected servers. Experts say there are working exploits for the flaws, and that these critical bugs are already being exploited in the wild.
Image: Shutterstock.com, Sashkin.
The flaws at issue are present in PHP, the programming language that powers sites running on a large number of web publishing systems, including Drupal, Magento, Joomla and WordPress. Earlier today, PHP released an emergency security update to fix two critical bugs that can allow an attacker to execute code of their choosing on a vulnerable server.
Reutersreports that government websites in Europe and elsewhere went offline today after the PHP vulnerabilities were disclosed. Cloudflare said it has already detected some exploitation of the flaw, and that at 3:02 am (UTC) it implemented web application firewall rules to protect websites from attack traffic seeking to exploit the bugs, which could cause a denial of service condition, remote code execution, and data exposure.
OpenAI, which was involved in the vulnerability research and outreach, said “given the severity of these flaws and PHP’s widespread use, we consider this one of the most impactful security issues in recent memory.”
Censys, a company that tracks the technology used by Internet hosts, said a recent scan identified approximately 2.58 million Internet facing hosts and 54.9 million web properties running PHP.
Security experts at Wiz said every PHP version released in the last decade is affected by at least one of these vulnerabilities [full disclosure: Wiz is an advertiser on this blog].
“These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history,” reads a blog post published today by a team of researchers at Wiz, which was one of several organizations credited with discovering the vulnerabilities. “The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.”
The Wiz researchers say it is likely the PHP vulnerabilities will be mass-exploited to install web-based backdoors or “web shells,” which give attackers a web-based panel that allows them to remotely control infected sites. Wiz said that prior to the PHP bugs being publicly disclosed, the company worked with the PHP team, Calif and OpenAI to measure the size of the problem and coordinate patch verification and disclosure.
The PHP zero-day vulnerabilities are being tracked by their CVE numbers, CVE-2026-109618 and CVE-2026-109619, and they affect all web servers running PHP 5.4 or later. The bugs are fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
According to Wiz, PHP is so deeply embedded in many web applications that we are likely to see organizations struggling to patch these vulnerabilities for some time to come, comparing this PHP vulnerability pair with the Log4Shell weakness that emerged in 2021 — a widespread, severe-as-it-gets security flaw in Log4j, a popular Java logging framework.
“A vulnerability in core PHP reaches far beyond a single application,” the Wiz researchers wrote. “PHP runs across clouds, hosting providers, content-delivery networks and millions of independently managed servers. Reducing exposure before the technical details became public required coordinated work across that entire ecosystem.”
The SANS Internet Storm Center is keeping an eye on major software platforms that are shipping updates to deal with these PHP flaws. For example, Ubuntu just released updated PHP packages. For a technical deep-dive on these vulnerabilities that tells the timeline of the discovery of these bugs in a comic book style, check out this post from Calif, another technology company credited with finding the PHP flaws.
A snapshot of php2shell.censys.com, the website Censys set up to track the PHP vulnerabilities.
This is a fast-moving story. Updates will be noted here with timestamps.
Update, 2:30 pm ET: Add figures from Censys and a link to Calif’s writeup.
CVE-2026-71362 Adobe Commerce and Magento Incorrect Authorization Vulnerability
The first flaw added to the catalog, tracked as CVE-2026-5430 (CVSS score 10.0), is an authentication bypass in multiple WSO2 products caused by improper verification of JWT signatures, allowing an attacker to use an unsupported signing algorithm to gain unauthorized access and potentially take over accounts.
The second flaw added to the catalog, tracked as CVE-2026-71362 (CVSS score 9.1), is an incorrect authorization vulnerability in Adobe Commerce that can allow an unauthenticated attacker to escalate privileges and gain access to sensitive resources without user interaction. In August 2026, hackers began targeting CVE-2026-71362 shortly after its public disclosure. The vulnerability allows unauthenticated attackers to switch customer sessions, hijack accounts and access private data.
Cybersecurity firm Sansec blocked the first exploitation attempts after Adobe published its advisory. The flaw affects Commerce, Commerce B2B and Magento Open Source versions through the July 2026 patches. Adobe released an isolated fix and urged users to patch.
“Adobe has released APSB26-92 as isolated patch files. The update fixes seven vulnerabilities, including an unauthenticated customer account takeover with a CVSS score of 9.1. Sansec Shield already blocks exploitation attempts.” reads the advisory published by Sansec. “Sansec reviewed the patch and confirmed that the vulnerability lets attackers switch a customer session to another customer account. This gives them access to the victim’s account and private customer data.”
Sansec pointed out that an attacker can exploit the flaw without an existing account, administrator privileges, or user interaction.
Adobe fixed how Magento handles customer identity in account sessions. The remaining flaws include stored cross-site scripting and authorization issues.
StyleSmuggler Magento zero-day is under active attack, letting unauthenticated attackers execute code and install backdoors on stores that may already be patched.
A new zero-day flaw, dubbed StyleSmuggler, in Magento and Adobe Commerce is under active attack, giving unauthenticated attackers a path to run code on vulnerable online stores. Sansec researchers say it affects current Magento Open Source releases, including 2.4.7, 2.4.8 and 2.4.9. According to the experts, exploitation began on September 4.
“Sansec discovered StyleSmuggler, an unpatched Magento and Adobe Commerce zero-day that gives unauthenticated attackers remote code execution. All current versions are affected, including 2.4.9.” reads the report published by Sansec. “Attacks started September 4th. Sansec is rolling out emergency mitigation.”
This is not a routine patch-cycle problem. Sansec reproduced the full attack chain on clean installations and observed a first victim running Magento 2.4.6-p15 with July and August 2026 patches already applied and a clean patch-status result. In plain terms, a store could be fully updated according to its normal process and still be exposed.
“StyleSmuggler injects malicious code into Magento’s template system.” states Sansec. “By using the styles properties, it can evade existing safeguards. It works in two stages:
Inject (poison) PHP code, for example by generating a failure report.
Let Magento execute the poisoned code via a failed payment email“
The attack is especially dangerous because it does not require a victim to open an attachment, click a link or even receive a successful email. Magento can execute the injected code while it renders its standard “Payment Transaction Failed Reminder” notification, and the chain can still work if email delivery itself fails.
That makes unusual spikes in failed-payment reminders a useful detection clue, although not conclusive proof of compromise. Legitimate payment failures happen. A sudden burst of them combined with strange system activity is a different conversation.
StyleSmuggler works by placing PHP code into Magento’s templating path and later causing the platform to evaluate it. The first stage creates or poisons a record, while the second stage turns a routine email-rendering process into remote code execution.
The attack reportedly uses GraphQL-related handling and the styles property to evade safeguards that would normally reject dangerous input. Sansec says moving sessions to Redis or a database does not stop the attack, because operators have already adapted their methods when one delivery route fails.
“Moving sessions to Redis or the database does not stop the attack. One merchant reported an attempt that failed against session storage and, eight seconds later, a second attempt that succeeded by using a file uploaded through Magento’s custom options instead.” continues the report. “Both came from the same operator.”
That detail matters because it shows an active operator, not a static proof-of-concept circulating online. Defenders should assume attackers are testing several paths, watching failures and changing tactics quickly.
Once the exploit succeeds, Sansec observed a lightweight Rust backdoor that connects to attacker-controlled infrastructure and waits for commands. At the time of the report, Sansec had not seen evidence that operators had yet used the implant for follow-on actions, but a backdoor that is installed and waiting is not an idle technical curiosity.
The malware initially hid behind a process name resembling [kworker/u:8:0], then appeared as fc-cache on September 6 and as chronyd on September 7.
These names are designed to blend into Linux environments, where administrators may expect to see kernel workers, font-cache utilities and Network Time Protocol daemons.
The fc-cache variant copies itself into a font-cache directory, writes a PID lock file and uses cron to restart twice an hour. The chronyd version can persist through cron as well, but Sansec also observed a build that relaunched itself without relying on a visible cron entry. An empty crontab is not proof that a host is clean.
The command channel is disguised as time synchronisation traffic. The implant sends 48-byte UDP packets to port 123, the standard NTP port, and uses domains that resemble time servers.
“Command and control is disguised as time sync. Every 60 seconds it resolves ntp.timesync.to and sends 48-byte UDP packets to port 123 that look like NTP server replies.” continues the report.
Only the first four bytes look like a normal NTP message; the remaining data can carry the agent ID, hostname, username, operating-system version, memory and disk use, uptime, root status and implant version.
That is a smart concealment choice. Many networks allow NTP traffic without close inspection because reliable time synchronisation is a normal operational requirement. Calling your malware chronyd and making it speak something that resembles NTP is not subtle genius. It is just clever enough to pass a lazy allowlist.
Sansec also found signs of a second, apparently unrelated attacker operating against stores compromised through StyleSmuggler. This actor deployed a compact PHP dropper that placed a web shell inside the product-image cache, using hash-like directory names to make the extra PHP file less obvious.
The web shell returns a normal-looking 404 response unless a request contains the correct X-Cache-Token header. With the header present, it can execute PHP supplied through a POST parameter. That design helps the attacker keep the shell invisible during casual checks and automated scans.
“Before writing that file, the dropper calls out to 457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site, a subdomain of a public service that developers and testers use to confirm that injected code ran.” states the report. “This actor came in through StyleSmuggler. We recovered the dropper from a Store: request header, and its PHP tags are still JSON-escaped from the record Magento logged it into.”
The lesson is not merely to remove the obvious background process. Stores need a full compromise assessment, including a review of PHP files under pub/media, cron spool files, unexpected processes, altered templates, report records, web-server logs and outbound connections.
Adobe was working on a patch as of September 7, according to Sansec, but no release date had been confirmed. A scheduled Adobe security release was due on September 8, although it was not known whether it would address StyleSmuggler.
Until an official fix is available and applied, merchants should consider temporarily disabling GraphQL if they do not have a compensating control capable of blocking this exploit. This can affect storefront and integration functions, so it should be treated as a risk decision rather than a casual configuration change.
Operators should also hunt for processes named [kworker/u:8:0], fc-cache and chronyd that run from unusual paths such as temporary directories, user cache directories or hidden folders. A legitimate chronyd process does not normally emit nine NTP server-mode packets in rapid succession every minute.
Security teams should inspect outbound traffic to suspicious NTP-like domains and UDP port 123 destinations, particularly 185.157.160.251, which Sansec linked to the observed domains on September 7. They should also search authentication and system logs for repeated crontab command not allowed messages generated by the web-service user, such as www-data.
If compromise indicators appear, treat the system as compromised, not merely vulnerable. Isolate the host, preserve logs and forensic evidence, rotate Magento administrator credentials, API tokens, database credentials, payment-provider secrets and cloud keys, then search for secondary backdoors before restoring normal operations.
The Sansec StyleSmuggler report includes current indicators of compromise, malware hashes, C2 infrastructure, suspicious process names and file paths. Its guidance will likely change as the campaign develops, because the attackers have already changed payload names and persistence methods within days.
Entrar
