Six-year sleeper backdoor activates in April
A supply chain attack involving 21 backdoored Magento extensions has compromised between 500 and 1,000 e-commerce stores. Sansec researchers who found it say one of the hit stores belongs to a $40 billion multinational. The extensions were backdoored as far back as 2019, but the malicious code only came to life in April 2025.
Sansec's note on the case is blunt: "Multiple vendors were hacked in a coordinated supply chain attack, Sansec found 21 applications with the same backdoor." And then the kicker: "Curiously, the malware was injected 6 years ago, but came to life this week as attackers took full control of ecommerce servers."
The timing is what makes it sting. Extensions that had been sitting in production, updated and trusted for years, suddenly became remote access points. That's not a drive-by script. That's a long game.
21 extensions from three vendors named
Sansec lists the compromised modules by vendor.
From Tigren: Tigren Ajaxsuite Tigren Ajaxcart Tigren Ajaxlogin Tigren Ajaxcompare Tigren Ajaxwishlist Tigren MultiCOD
From Meetanshi: Meetanshi ImageClean Meetanshi CookieNotice Meetanshi Flatshipping Meetanshi FacebookChat Meetanshi CurrencySwitcher Meetanshi DeferJS
From MGS: MGS Lookbook MGS StoreLocator MGS Brand MGS GDPR MGS Portfolio MGS Popup MGS DeliveryTime MGS ProductTabs MGS Blog
Sansec also flagged a compromised version of the Weltpixel GoogleTagManager extension, but couldn't confirm whether the compromise happened at the vendor or at the website.
That's 21 confirmed names with the same backdoor pattern. BleepingComputer independently confirmed the backdoor is present in the MGS StoreLocator extension, which is free to download from the vendor site. It did not independently verify the other extensions.
How the license check file turns into remote code execution
In every observed case, the extensions include a PHP backdoor added to a license check file, License.php or LicenseApi.php, used by the extension for licensing.
The malicious code checks for HTTP requests containing special parameters named "requestKey" and "dataSign". Those are used to perform a check against hardcoded keys inside the PHP files.
If the check succeeds, the backdoor exposes admin functions in the file, including one that allows a remote user to upload a new license and save it as a file on the server.
That file is then included using PHP's include_once() function, which loads the file and automatically executes any code within the uploaded license file.
Past versions of the backdoor didn't require authentication. Newer ones use a hardcoded key.
Sansec told BleepingComputer this backdoor was used to upload a webshell to one of their customer's sites. With the ability to upload and run any PHP code, the potential repercussions are broad: data theft, skimmer injection, arbitrary admin account creation, and more.
It's a clean supply-chain design. No need to patch the extension itself, just talk to the license checker that the extension already loads.
Vendor responses range from silence to denial
Sansec contacted the three vendors and got three different answers.
MGS didn't respond.
Tigren denied a breach and, according to Sansec, continues to distribute backdoored extensions.
Meetanshi admitted to a server breach but not an extension compromise.
BleepingComputer also reached out to the three vendors and had not received a response at the time of publication.
The split responses make triage harder for merchants. If a vendor denies the problem, the extension stays in the marketplace and keeps getting installed.
Sansec commented on the peculiarity of the backdoor laying dormant for six years and activating only now, and said it would provide additional insight from its ongoing investigation.
Indicators and immediate cleanup steps
Users of the mentioned extensions are recommended to perform complete server scans for the indicators of compromise Sansec shared in its report and, if possible, restore the site from a known-clean backup.
That's the standard playbook for a supply-chain compromise, and it's the only one that works here. Patching the file isn't enough if the attacker already has a foothold and knows your admin patterns. Restoring from a known-clean backup before the dormant code activated is the safer bet.
The report underscores a pattern we've seen repeatedly: license checks, update mechanisms, and third-party modules are attractive targets because they run with high privileges and get trusted by default. Once they're in, attackers can sit quietly for years.
For Magento merchants, the immediate checklist is simple and uncomfortable. Inventory every installed extension, cross-check against the 21 names above, remove or replace them, scan for webshells and unexpected license files, and audit admin accounts created in the last months.
The attack also highlights how a single compromised vendor can cascade. Twenty-one extensions, three vendors, and an estimated 500 to 1,000 stores. That's a lot of customer data, payment forms, and session tokens exposed because a license file was quietly turned into a backdoor six years ago.
The dormant period is the part that keeps me up. Code that sits idle for years avoids detection, evades signature updates, and builds trust. When it finally wakes up, cleanup is messy and expensive.
If you're running Magento and you rely on any of those modules, don't wait for a vendor statement. Treat it as compromised until proven otherwise.
