What Holiday 2025 eSkimming Attacks Reveal About Retail Risk in 2026
Retailers entering the 2026 holiday season face a browser-side security problem that can be difficult to identify during a conventional website review. A script may come from an approved source. A tag manager may support a legitimate business function. A familiar checkout page may pass routine testing. None of those observations fully explains what code will do when it executes in a shopper’s browser.
Source Defense research published during the 2025 holiday period documented several attacks that illustrate this gap. Three campaigns used different delivery techniques but followed a similar operational pattern: malicious code entered through trusted infrastructure, waited for the right page or user action, and then activated inside the browser.
A fourth attack expanded the target beyond payment card data. It collected identity, contact, and credential information from multiple parts of the customer journey. Together, these incidents provide retailers with a practical model for reviewing browser-side risk before peak shopping traffic begins.
Three attacks followed a repeatable pattern
eSkimming is the theft of information entered into a website through malicious code executing in the user’s browser. Payment card information remains a common target, but modern attacks can also capture credentials, personal information, and other sensitive form data. The delivery mechanism can vary considerably from one campaign to another.
October 28: Trusted tag-management infrastructure delivered the attack
The first campaign affected more than 30 ecommerce websites.
Attackers used compromised or reused Google Tag Manager infrastructure to deliver malicious code. Google Tag Manager, commonly called GTM, allows organizations to deploy and manage website tags without changing the underlying application code for every update.
In this campaign, that trusted delivery path helped the attackers place their code inside legitimate shopping sessions. The attack could present fake payment forms, use browser WebSocket connections for communication, and operate through a same-origin iframe that appeared to belong to the affected site.
The use of GTM was significant because tag managers are common and often approved components of an ecommerce environment. The service itself was not the risk. The problem was the behavior of code delivered through compromised infrastructure.
November 18: Ordinary website content became part of the activation chain
The second attack concealed malicious code inside shipping-policy content. That code did not need to force its way directly into the checkout application. The website’s own logic moved the content into the checkout experience, where it became active. A compromised GTM container then helped deliver the skimmer.
This approach shows how content and functionality from one part of a site can affect another. A component that appears harmless on a policy page may behave differently after it is rendered in a payment flow. Security teams reviewing only the original location of a script or content block may miss the context in which it eventually executes.
December 9: The attack adapted to the page and customer journey
A third campaign used GTM to deliver an adaptable skimming framework. The framework could choose between presenting a fake checkout experience and silently monitoring fields on the legitimate page. It also used separate WebSocket connections to receive malicious code and transmit stolen information.
This flexibility allowed the attack to adjust its behavior based on the website and page conditions it encountered. A point-in-time scan might observe an approved container or an inactive script. A shopper reaching a specific step in the checkout process could see something very different.
The delivery methods changed, but the operating model remained consistent
These attacks were published during the 2025 holiday period. The available evidence does not establish that each campaign was scheduled specifically for Black Friday, Cyber Monday, or another retail event. They still reveal a repeatable technical pattern relevant to holiday readiness:
- The attacker gains access to infrastructure the website or browser already trusts.
- Malicious behavior remains hidden until the appropriate page, field, or user action appears.
- The attack assembles or activates inside the browser.
- Sensitive information leaves through communication methods that can resemble legitimate website activity.
Source approval establishes where a script came from and why the business expects it to be present. Runtime evaluation shows what that script actually does after execution begins. Retail security reviews should account for both.
Payment information was only part of the target
Research published on December 23 documented an attack embedded in a first-party ecommerce theme file. Because the code resided in a first-party resource, it inherited a high level of trust within the website. It monitored form elements across checkout and account pages, including input fields, selection menus, and larger text-entry areas. The information at risk extended beyond card numbers. The attack could collect:
- Names and contact information
- Billing and shipping details
- Account credentials
- Payment information
- Other data entered into website forms
The stolen information was transmitted through image requests designed to resemble ordinary browser or analytics activity. This incident broadens the holiday security discussion. Checkout remains an important control point, but it is one part of a longer customer journey. Registration pages, account sign-in, profile management, billing forms, customer-service workflows, and loyalty experiences may also handle sensitive information.
Full-site visibility is a security recommendation rather than a statement that every page falls within PCI DSS scope. It allows security teams to identify where sensitive data appears and how scripts interact with that data across the customer experience.
Five questions for a holiday browser-side security review
Retailers preparing for peak traffic can use five questions to evaluate their exposure.
1. Which scripts execute across sensitive customer journeys?
The inventory should include first-party, third-party, and downstream scripts introduced by other services. Teams should also account for code delivered through tag managers, consent platforms, ecommerce extensions, and marketing tools.
2. Which fields and page elements can those scripts access?
Script presence alone does not establish risk. The more useful question is whether a script can read, modify, replace, or monitor sensitive fields and forms.
3. What causes the behavior to activate?
Some attacks respond to a page URL, checkout stage, user interaction, browser characteristic, or stored value. Testing should include the conditions a real customer encounters instead of relying solely on a static page scan.
4. What changes while the site is running?
Retail environments change frequently during the holiday season. Promotions, tags, extensions, analytics tools, and checkout components may be updated quickly. Security teams need a way to recognize when script behavior changes, even when the script’s source or filename remains the same.
5. Where does information go?
Teams should examine browser communications for unexpected destinations and methods. This includes standard web requests, image requests, WebSockets, and other browser-native channels.
Browser-side controls should evaluate behavior
Traditional security controls remain important, but many operate before code reaches the shopper’s browser or focus on whether a resource is permitted to load. The attacks documented during the 2025 holiday period used legitimate website functionality, trusted services, and browser-native communication methods. That makes runtime behavior a necessary part of the security review.
Behavior-based controls can help teams observe how scripts interact with fields, forms, and external destinations. Where appropriate, those controls can also restrict unauthorized access to sensitive elements or prevent data from being transmitted to an unapproved destination.
This approach can support the script-management and change-detection objectives addressed by PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1. It does not replace an organization’s PCI assessment or determine compliance on its own.
Prepare for the customer journey attackers will see
Holiday readiness often focuses on availability, fraud, infrastructure capacity, and checkout performance. The 2025 research shows why browser behavior also belongs in that review. Attackers do not need to create an obviously malicious website experience. They can use infrastructure the retailer already trusts, activate only under selected conditions, and blend data theft into ordinary browser traffic.
The December 23 attack adds a further warning. The information at risk may extend across the customer journey, from account access and personal details to the final payment step.
See What Your Website Scripts Can Access
Understand which scripts operate across your website, how they interact with sensitive customer information, and where unauthorized behavior could expose your business.
