FunnelKit WooCommerce Checkout Skimmer: How a Plugin Flaw Turns Online Stores Into Card-Harvesting Traps

Attackers are actively exploiting an unauthenticated injection flaw in the FunnelKit Funnel Builder plugin — installed on more than 40,000 WooCommerce stores — to plant invisible payment skimmers on checkout pages. The malicious code disguises itself as a Google Tag Manager snippet, opens a covert WebSocket channel to a command-and-control server, and silently harvests credit card numbers, CVVs, and billing addresses in real time. For any Saudi financial institution or merchant operating an e-commerce checkout, this campaign is a direct PCI-DSS and SAMA compliance threat.

What the FunnelKit Vulnerability Does

The flaw resides in the "External Scripts" setting within FunnelKit Funnel Builder versions prior to 3.15.0.3. Because the plugin fails to sanitize input in this field, unauthenticated attackers can inject arbitrary JavaScript that executes on every WooCommerce checkout page served by the plugin. No admin credentials are needed — the attacker simply writes to the External Scripts configuration endpoint, and the payload fires for every customer who reaches checkout. Sansec researchers documented the campaign this week after observing multiple compromised storefronts across different hosting providers and geographies.

Anatomy of the Attack: Fake GTM Loader and WebSocket C2

The injected payload masquerades as a legitimate Google Tag Manager container script. To a site administrator reviewing page source, it looks indistinguishable from the store's real analytics tags. However, instead of loading Google's measurement libraries, the script fetches JavaScript from an attacker-controlled domain. That script then opens a persistent WebSocket connection back to a command-and-control server, which delivers a payment skimmer customized to match the victim store's checkout form field IDs, CSS selectors, and input names. This per-victim tailoring makes generic web application firewall signatures largely ineffective — each skimmer variant is unique to its target.

Once the skimmer is active, every piece of payment data entered at checkout — card number, expiration date, CVV, cardholder name, and full billing address — is exfiltrated to the attacker's infrastructure in real time, before the legitimate payment gateway ever processes the transaction. Customers receive their order confirmation as expected, giving no indication that their card data has been stolen.

Why This Matters for PCI-DSS Compliance

PCI-DSS v4.0.1 introduced Requirements 6.4.3 and 11.6.1 specifically to address client-side payment page threats like JavaScript skimmers. Requirement 6.4.3 mandates that all scripts executing on payment pages be inventoried, authorized, and integrity-checked. Requirement 11.6.1 requires mechanisms to detect unauthorized modifications to HTTP headers and payment page content. A store running a vulnerable FunnelKit version with an injected skimmer fails both requirements immediately. For Saudi merchants processing card payments, non-compliance can trigger fines, increased transaction fees, and potential revocation of card processing privileges by their acquiring bank.

Impact on Saudi Financial Institutions and Regulated Entities

Saudi Arabia's digital commerce ecosystem has grown rapidly under Vision 2030, with SAMA-regulated payment service providers, fintech firms, and banking subsidiaries operating e-commerce platforms that process thousands of card transactions daily. The SAMA Cyber Security Framework (CSCC) requires regulated entities to maintain secure payment processing environments and to conduct regular vulnerability assessments of internet-facing applications — explicitly including web storefronts. An unpatched FunnelKit instance on a regulated entity's e-commerce platform would constitute a direct violation of SAMA CSCC Domain 3 (Technology) and Domain 4 (Third-Party Security) controls.

The NCA Essential Cybersecurity Controls (ECC) further require government-linked commercial entities to implement web application security controls and to monitor for unauthorized script injection on public-facing sites. Organizations subject to the Personal Data Protection Law (PDPL) face additional exposure: cardholder data combined with billing addresses constitutes personal data under PDPL, and a breach resulting from a known, unpatched vulnerability could trigger enforcement action by the Saudi Data and AI Authority (SDAIA).

Indicators of Compromise and Detection Steps

Security teams should immediately audit their WooCommerce installations for signs of compromise. Navigate to FunnelKit Settings, then Checkout, then External Scripts, and inspect every entry. Any script reference pointing to a domain other than your authorized analytics providers — particularly those mimicking Google Tag Manager container URLs with subtle character substitutions — should be treated as malicious and removed. Review server access logs for unauthenticated POST requests to the FunnelKit settings API endpoints. Check browser developer tools on your checkout page for WebSocket connections to unfamiliar hosts; legitimate checkout pages should not initiate WebSocket handshakes to external servers.

Recommended Remediation Steps

1. Patch immediately: Update FunnelKit Funnel Builder to version 3.15.0.3 or later. This version closes the unauthenticated injection vector in the External Scripts field.
2. Audit External Scripts: Review every entry in the FunnelKit External Scripts configuration. Remove any script you did not explicitly authorize. Compare entries against your documented analytics and tag management inventory.
3. Implement Content Security Policy (CSP): Deploy a strict CSP header on all checkout pages that whitelists only approved script sources. This prevents injected scripts from loading external resources even if the injection vector is exploited again before patching.
4. Deploy client-side integrity monitoring: Use Subresource Integrity (SRI) hashes for all authorized scripts and implement a real-time monitoring solution that alerts on any DOM modification to checkout page payment fields — directly addressing PCI-DSS v4.0.1 Requirements 6.4.3 and 11.6.1.
5. Scan for historical compromise: If your store ran a vulnerable version during the active exploitation window, assume potential compromise. Notify your acquiring bank, initiate PCI forensic investigation procedures, and review transaction logs for anomalous patterns.
6. Harden WordPress admin access: Enforce multi-factor authentication on all WordPress admin accounts, restrict admin panel access by IP whitelist, and disable XML-RPC and REST API endpoints that are not required for store operations.

Conclusion

The FunnelKit checkout skimming campaign demonstrates how a single plugin vulnerability can transform a legitimate online store into a silent card-harvesting operation — with zero visible impact on the customer experience. For organizations operating under SAMA, NCA, and PCI-DSS requirements, this is not a theoretical risk but an active threat requiring immediate action. Patch, audit, and implement client-side monitoring before your next checkout transaction becomes someone else's payday.

Is your organization prepared? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment and PCI-DSS readiness review to ensure your e-commerce payment pages are protected against client-side skimming attacks.