Magento malware campaign infects 953 online stores
Magento malware has infected 953 online stores, most of them running Magento, in a campaign that Sansec says has remained active since July 2025. The unidentified attacker inserts a compact loader into store pages through Magento content management system (CMS) blocks, which are database-managed sections used to place static material on storefront pages. When a shopper opens an affected page, the added code contacts attacker-controlled infrastructure for further instructions.
Sansec found that the remote system attempts to distinguish genuine shoppers from automated security scanners. Requests judged to come from scanners receive nothing, while selected visitors can be served malicious JavaScript, code that runs inside the web browser. This selective delivery makes routine automated checks less likely to see the same response as a customer. The precise final payload remains unknown, so it has not been confirmed what the attacker ultimately does in shoppers’ browsers.
Five domains have been connected to the campaign over time. Sansec first observed manulfie[.]click in July 2025, neswnsssn[.]click in December 2025, lanhd6549tdhse[.]top in March 2026, additionalver[.]com in June 2026 and deepveindrilling[.]com in October 2026. The security company found deepveindrilling[.]com inside the CMS blocks of 83 stores after the domain was registered on October 6, 2026. That domain is hosted behind Cloudflare and responds only to script requests associated with real visitors to compromised shops.
The loader is placed in Magento’s cms_block database table. Once Magento renders the affected block as part of a page, the browser runs the attack-controlled code. Sansec did not determine whether the attacker edits existing blocks, such as a header, footer or promotional section, or creates new ones. Either method can cause the script to appear on customer-facing pages. Site administrators therefore need to inspect both familiar blocks that may have been altered and unfamiliar blocks that should not exist.
Sansec identified two loader versions. One downloads external JavaScript and saves the payload in localStorage, an area where a website can retain data in a visitor’s browser. This persistence allows the saved code to run during later visits even when the attacker’s external domain is no longer available. A second version adds browser fingerprinting, which examines browser characteristics to separate likely shoppers from bots and security tools. That filtering is intended to expose fewer automated systems to the malicious response.
Earlier campaign activity used Keitaro, an advertising tracking and analytics platform, as a traffic distribution system (TDS). A TDS chooses what response to give a visitor based on observed characteristics. In this campaign, that could mean returning a payload, redirecting the visitor or returning nothing. When Sansec requested the additionalver[.]com script while appearing to be a Windows desktop visitor, the server returned “QWE=123;”. The response did not execute another action beyond setting a cookie, a small browser record, that marked the visitor for 24 hours. The newer deepveindrilling[.]com loader no longer uses the Keitaro component and instead performs its bot filtering directly.
Sansec estimates that 471 Magento stores received the loader through PolyShell, also tracked as CVE-2026-48356. A further 102 stores had files uploaded through either PolyShell or SessionReaper, tracked as CVE-2025-54236. In one investigated store running Magento 2.4.7-p1, PolyShell webshells were disguised as PNG image files under pub/media/custom_options/quote/. A webshell is a malicious file that lets an attacker issue commands through a compromised website. The same store contained the additionalver[.]com loader in a CMS block, which changed to deepveindrilling[.]com on October 7. Sansec said the store still lacked APSB26-73, Adobe’s PolyShell fix for supported release lines.
Another compromise affected a store running Magento 2.4.7-p10 even though it had no missing Magento core patches. In that case, an unauthorised administrator account was added and then used to insert the code. The finding means an investigation should not stop after confirming that core updates are installed. Owners should also review administrator accounts, database content and unexpected changes to storefront pages.
Sansec recommends checking for suspicious accounts and examining both the cms_block and cms_page tables for unexpected content. Magento installations should be kept current, and administrator accounts should use strong passwords. Because the loader can retain code in a shopper’s localStorage, removing the database injection and disabling an attacker’s domain may not immediately remove code already stored in browsers that previously visited the affected shop.
The disclosure coincides with exploitation activity involving PHP2Shell, a pair of critical PHP vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619. Following their disclosure the previous week, widespread exploitation attempts were observed. A Perplexity researcher also recorded what appeared to be the first successful in-the-wild exploitation on honeypot servers, which are deliberately monitored systems used to observe attacks. Commands used wget, curl or the PHP command-line interface to request more payloads from 162.35.99[.]94:80, although no downloaded second-stage files were observed.
For organisations responsible for e-commerce environments, AEU-I provides security-first IT, infrastructure and consulting. Regardless of provider, store owners should treat unexplained CMS blocks, unknown administrators and files disguised as images as reasons for an immediate security investigation.