Digital skimmer hits global supermarket chain

The affected company, with about €100 billion in annual revenue and over 10,000 stores across 25 countries, runs some of its ecommerce operations on the PrestaShop platform. As of publication, the skimmer is still active (since February 16th).

This is the second time in just over a month that Sansec has found a major global brand being hit by digital skimming. In January, we discovered a keylogger on a top-3 US bank employee store that also went under the radar of other vendors.

The attack combines two components: a seemingly off-the-shelf skimmer framework with integrations for four popular ecommerce platforms, and a carefully localized fake payment form. This fraud is called "double-tap skimming": customers enter their card details into the fake form first, then see the real payment form where they have to enter their data again. Most people just accept that and complete the order, unaware their data was just stolen.

This is the fake form presented to customers:

After submitting their data, they get redirected to the actual payment form:

Double tap skimming boosted by AI

PCI-DSS requires merchants to redirect customers to heavily fortified payment forms run by their payment provider. This has made double-tap skimming the preferred method for cyber criminals, and generative AI accelerates this. Threat actors can now produce localized payment overlays for any language and style in minutes.

PrestaShop under increased attack

This breach comes amid a broader wave of attacks targeting PrestaShop stores. In January 2026, PrestaShop issued a security alert urging merchants to check their stores for skimmers injected into theme template files. That campaign also used fake payment forms to replace legitimate checkout buttons.

With nearly 300,000 stores worldwide, PrestaShop is a high-value target.

Reusable skimmer toolkit

The skimmer's codebase contains a reusable framework, which is likely sold or operated as a service.

Before activating, the framework runs admin detection routines for four CMS platforms:

• WordPress: checks for #wpadminbar, admin-bar/logged-in body classes, wp-settings-/wordpress_sec_ cookies
• Magento: checks for admin=/admin_sid cookies, adminhtml body class, FORM_KEY global
• PrestaShop: checks for employee/prestashop.employee globals, #header_employee_box, psAdmin cookie
• OpenCart: checks for common-dashboard body class, /admin/ in the URL path

If any admin indicator is found, the script logs [GATEWAY] Admin detected and aborts. Store operators browsing their own checkout will never see the fake form.

The framework supports seven configurable injection modes (replace, before, after, popup, overlay, offscreen, substitute), making it adaptable to any checkout layout. An "aggressive hiding" mode ensures replaced original forms stay hidden even if the page's own JavaScript tries to re-show them.

Technical analysis

The skimmer activates only on checkout pages, using localStorage to track state and prevent double-firing. Beyond the fake form, it monitors every input, select, and textarea on the page via input, change, blur, and focus listeners. Captured values are stored in localStorage with a mn_ prefix. It even watches custom dropdown renderers (Select2, Chosen, Vue Select) via MutationObserver.

Card data is saved to localStorage keys cardNum, exp, and cvv. A monkey-patched localStorage.setItem prevents these values from being overwritten with shorter strings, ensuring captured card numbers aren't wiped by page scripts.

When the victim clicks checkout, the skimmer validates the card number (13+ digits), builds a JSON payload with card data, billing info, and browser user agent, then Base64-encodes and sends it via GET to stylemercedes.top/api/send-metrics?metrics=<payload>. The exfiltration URL is disguised as an analytics endpoint.

After exfiltration, the skimmer hides all injected forms, restores the original page, triggers the real checkout button, and disconnects all observers. It also force-enables disabled checkout buttons every 1.5 seconds by stripping disabled, aria-disabled, and readonly attributes plus 20+ CSS classes (is-disabled, btn-disabled, processing, loading), ensuring the victim can always trigger exfiltration even if the platform's own validation would block submission.

Disclosure

Sansec notified the affected company six times since February 16th, 2026: via the general contact email listed on the website, the security contact published in their security.txt file, and a direct message to the company CISO on LinkedIn. As of publication, we received no response and the skimmer remains active.

Having a security.txt file is a good start, but it only works if someone actually reads the incoming reports. As we wrote last month, the lack of responsive security contacts at large organizations is a systemic and costly problem.

Recommendations

Run malware & security software that integrates with your eCommerce platform. Disclaimer: Sansec is pretty good at that!

1. Block attacks: Deploy Sansec Shield to block exploitation attempts in real-time
2. Scan for compromise: Run eComscan to detect malware, backdoors, and vulnerabilities
3. Monitor client-side: Use Sansec Watch to detect unauthorized JavaScript and limit the impact of future attacks

PrestaShop merchants should additionally verify their theme template files, particularly _partials/head.tpl, for injected script tags.

Timeline

IOCs

stylemercedes.top

Read more

• Keylogger targets 200,000+ employees at major US bank
• MagentoCore group hacks 7,339 stores and counting
• Building a faster YARA engine in pure Go
• Claude finds 353 zero-days on Packagist
• The billion-dollar security.txt problem