When attackers no longer need stolen credentials to compromise customer trust, the threat model has fundamentally changed. Deepfake impersonation, authentication abuse, and AI-powered identity deception are expanding the ways attackers exploit trust without traditional account compromise. Consltek’s Deepfake to Breach: SMB Playbook for Identity Attacks helps organizations strengthen IAM defenses before trust becomes the easiest route to breach.

The Architectural Failure That Made This Possible

The vulnerability is a permission enforcement failure at a publicly exposed API endpoint, and understanding exactly how it works clarifies both the severity and why it has attracted active exploitation rather than remaining theoretical.

Funnel Builder includes a checkout endpoint that was designed to allow incoming requests to invoke internal methods. In versions prior to 3.15.0.3, this endpoint performed no permission checking and applied no allowlist to restrict which internal methods could be called. Any request reaching that endpoint, regardless of whether it came from an authenticated administrator, a logged-in user, or a completely anonymous actor, could invoke an internal method that writes directly into the plugin’s global settings.

The specific method being exploited writes attacker-controlled data into the External Scripts configuration field within the Funnel Builder checkout settings. That field controls which scripts are injected into every checkout page the plugin renders. Once a malicious script tag is written into that field, it executes on every checkout transaction across the entire store until a site owner identifies it and removes it.

The attack path is three steps: send an unauthenticated request to the exposed endpoint, invoke the settings write method with a malicious script payload, and walk away. The skimmer does the rest indefinitely.

Why This Vulnerability Class Attracts Organized Threat Actors

Unauthenticated settings write vulnerabilities in widely deployed WooCommerce plugins represent a specific category of high-value target for organized payment fraud operations. The economics are favorable from the attacker’s perspective: a single exploitation tool can be deployed at scale across thousands of vulnerable stores simultaneously, each compromised store generates continuous payment card harvest without requiring ongoing attacker involvement, and the persistence mechanism, a setting field rather than a file modification, frequently survives routine security scans and manual reviews.

The absence of an official CVE identifier at the time of Sansec’s disclosure does not reduce the exploitation risk. Active exploitation has been confirmed. Vulnerable installations remain exposed regardless of whether the vulnerability has been formally catalogued in national vulnerability databases.

The Google Tag Manager Disguise Is the Detection Problem That Matters Most

The technical exploitation is straightforward. What makes this campaign persistently dangerous, even after public disclosure, is the evasion technique applied to the skimmer payload.

Attackers are injecting a fake Google Tag Manager script into the External Scripts settings field. To a store owner, a developer reviewing the site configuration, or a security analyst performing a routine audit, this entry appears alongside the store’s legitimate analytics tags. The format is familiar. The naming is recognizable. The immediate visual impression is that it is simply another tracking implementation.

It is not. The injected script fetches JavaScript from a remote domain, which then opens a WebSocket connection to the attacker’s C2 server at wss://protect-wss[.]com/ws. That WebSocket connection delivers a customized skimmer tailored to the specific storefront layout, enabling precise harvesting of credit card numbers, CVVs, and billing addresses as customers complete their purchases.

Sansec correctly identifies this as a recurring Magecart pattern: dressing skimmers as Google Analytics or Tag Manager code works because reviewers consistently skip past anything that resembles familiar tracking infrastructure. The social engineering element is baked into the payload design. Detection requires active verification of every GTM-formatted script against the store’s actual Google Tag Manager account, not visual inspection of whether the script looks legitimate.

The WebSocket Architecture as an Evasion Layer

The WebSocket connection to the C2 server carries a specific detection evasion advantage that enterprise security monitoring teams need to understand.

Traditional payment skimmer detection frequently relies on network-level monitoring for unexpected outbound HTTP or HTTPS POST requests carrying customer data to unfamiliar domains. WebSocket connections establish persistent bidirectional communication channels that generate different network signatures from standard HTTP requests. Security monitoring tools calibrated to detect suspicious outbound HTTP traffic may not flag a WebSocket connection to a domain named to suggest security or protection functionality.

The dynamic payload delivery through the WebSocket connection adds another evasion layer. File-based malware scanning of the site’s installed files will find nothing, because the actual skimmer code is never written to the server. It is delivered at runtime, executed in the customer’s browser, and used to exfiltrate payment data through a channel that appears to originate from the customer’s browser session rather than from the store’s server infrastructure.

Immediate Response Requirements for Affected Organizations

Every WooCommerce store running Funnel Builder prior to version 3.15.0.3 needs to execute the following response steps without delay.

Updating to version 3.15.0.3 closes the unauthenticated settings write vulnerability. This is the mandatory first step and should happen before any investigation activity, because a store that remains on a vulnerable version can be recompromised even after the injected skimmer is manually removed.

After updating, navigate to Settings, then Checkout, then External Scripts within the Funnel Builder configuration. Review every entry in that field against a verified list of scripts that the store’s development team explicitly placed there. Any entry that cannot be traced to a deliberate configuration decision by a known team member should be treated as potentially malicious and removed.

Each GTM-formatted script should be checked against the Google Tag Manager account associated with the store. Login into your Google Tag Manager and make sure that all the container IDs mentioned in the External Scripts field have been assigned to containers that belong to the store. Mentioning a GTM-formatted script with an unknown container ID is the key indicator of whether the attack was successful.

Access your web server’s access logs for POST requests to the checkout page of the Funnel Builder without any authentication. If you can find these requests in the log files, it indicates that the exploit has been successfully executed.

For stores that confirm active compromise, the response extends beyond technical remediation into breach management. Payment card data was potentially harvested from every customer who completed a checkout during the compromise period. That exposure carries specific obligations.

The Payment Card Breach Liability That Store Owners Cannot Ignore

A confirmed skimmer on a WooCommerce checkout page is a payment card data breach. The technical remediation required to remove the skimmer and patch the vulnerability is the immediate security response. The legal and financial response runs in parallel and cannot be deferred.

The PCI DSS requirements are applicable to all merchants that conduct transactions through payment cards. The discovery of a skimmer is an example of a security event under the definition of PCI DSS, leading to reporting to the acquirer banks of the merchant as well as forensic examinations by security assessors where necessary.

In most cases, the billing addresses and personal information harvested alongside payment card numbers constitute personal data under GDPR for European customers, CCPA for California residents, and a growing body of state-level privacy legislation across the United States. Breach notification obligations to affected individuals may apply, with specific timeframes that vary by jurisdiction and the number of affected records.

Store owners who discover they have been compromised should contact their payment processor immediately to report the incident and understand their specific reporting obligations, document every aspect of the incident timeline for the regulatory records that compliance frameworks require, and consider whether to temporarily suspend checkout processing while verification and remediation are completed rather than continuing to expose customers to potential ongoing harvest.

The financial consequences of delayed response, including chargeback liability for fraudulent transactions that continue to occur after a store owner becomes aware of a compromise, are substantially more damaging than the cost of a brief checkout suspension during confirmed breach investigation.

The Remote Loader Pattern Connecting This Campaign to a Broader Threat Architecture

The concurrent Joomla backdoor campaign documented by Sucuri shares an architectural characteristic with the Funnel Builder skimmer that has direct implications for how enterprise security and web application security teams should approach detection across their full web property portfolio.

Both campaigns deploy remote loader architectures that decouple the code planted on the victim site from the malicious payload delivered at runtime. The WooCommerce External Scripts injection fetches the active skimmer through a WebSocket connection. The Joomla PHP backdoor contacts a C2 server to receive dynamic content injection instructions. In both cases, the code present on the compromised site is a delivery mechanism rather than the complete attack payload.

This architectural pattern provides threat actors with operational flexibility that fundamentally challenges file-based malware detection. The payload can be modified, withdrawn, or replaced without touching the compromised site. A store that appears clean in a malware scan may still be delivering an active skimmer to every checkout visitor, because the scan found no malicious files while missing the loader that fetches the payload dynamically at runtime.

Security researcher Puja Srivastava’s characterization of the Joomla loader captures the strategic advantage of this approach precisely: attackers can change the behavior of a compromised site at any time without modifying local files. The same principle applies to the WooCommerce campaign. The loader planted through the Funnel Builder vulnerability is the persistent asset. The skimmer it delivers is interchangeable.

For security teams responsible for web application monitoring across enterprise e-commerce portfolios, the implication is clear. File integrity monitoring and static malware scanning are necessary but insufficient controls against remote loader-based attacks. Runtime monitoring of checkout page JavaScript execution, including analysis of outbound network connections initiated from checkout page context, provides the detection coverage that file-based approaches cannot.

Why This Campaign Signals an Escalating Threat to WooCommerce Ecosystems

The WooCommerce ecosystem, encompassing tens of thousands of plugins with varying levels of security maturity and permission enforcement discipline, represents one of the most attractive attack surfaces in web-based commerce security. The Funnel Builder vulnerability is not an outlier. It represents a vulnerability class, unauthenticated settings modification with checkout page JavaScript injection capability, that researchers and threat actors are systematically examining across the full WooCommerce plugin ecosystem.

The economic incentive is substantial. A single exploitation tool deployed against 40,000 potentially vulnerable stores, even assuming a fraction are successfully compromised, generates a harvest of payment card data that funds continued campaign investment. The asymmetry between the cost of running the campaign and the value of the harvested data is why organized payment fraud groups invest in identifying and weaponizing WooCommerce plugin vulnerabilities.

Enterprise organizations managing WooCommerce deployments at scale, including retailers, e-commerce aggregators, and managed WordPress hosting providers, should treat this campaign as a category-level signal rather than a plugin-specific incident. The appropriate security investment response includes not just patching this specific vulnerability but establishing the monitoring infrastructure, plugin governance frameworks, and checkout page integrity verification capabilities that can detect and contain the next campaign in this class before it generates a payment card breach.

The threat actors targeting WooCommerce checkout infrastructure have demonstrated both the technical sophistication and the organizational patience to operate these campaigns at scale. The organizations that match that sophistication with commensurate detection and prevention investment are the ones that will avoid discovering a breach through a payment processor fraud alert rather than their own security monitoring.