Funnel Builder WordPress Exploit: How Attackers Steal Payment Data from 40,000+ WooCommerce Stores

A critical vulnerability in the FunnelKit Funnel Builder plugin — installed on more than 40,000 WooCommerce stores worldwide — is under active exploitation right now. Attackers are injecting JavaScript payment skimmers directly into checkout pages, harvesting credit card numbers, CVVs, and billing addresses before the transaction even reaches the payment gateway. For any Saudi merchant or financial institution that processes card-present or card-not-present transactions, this campaign is a live demonstration of why PCI-DSS Requirement 6 and SAMA's e-commerce security controls are non-negotiable.

How the Funnel Builder Exploit Works

The vulnerability affects all versions of Funnel Builder prior to 3.15.0.3. It resides in a public checkout endpoint that accepts incoming requests specifying which internal plugin method to execute. The fatal flaw: affected versions perform zero permission validation. Any unauthenticated attacker can send a crafted HTTP request that directly invokes internal functions responsible for updating plugin settings — including the "External Scripts" configuration that controls what JavaScript loads on every checkout page.

In observed attacks, threat actors inject a payload masquerading as a legitimate Google Tag Manager (GTM) loader. The fake GTM script fetches additional JavaScript from an attacker-controlled domain, which then opens a WebSocket connection to a command-and-control server. The C2 responds with a checkout skimmer dynamically tailored to the victim's storefront layout, field names, and payment form structure. Stolen cardholder data — card number, expiration date, CVV, and billing details — is exfiltrated over the same WebSocket channel, making it nearly invisible to traditional HTTP-based monitoring tools.

Why WebSocket-Based Skimmers Evade Detection

Most Web Application Firewalls (WAFs) and Content Security Policy (CSP) configurations are tuned to inspect HTTP request-response pairs. WebSocket connections, once established, operate as persistent bidirectional channels that many legacy monitoring solutions treat as a single long-lived connection rather than discrete data transmissions. This means the actual card data exfiltration often bypasses signature-based detection entirely. Additionally, the dynamic nature of the skimmer — customized per-victim from the C2 — ensures that static file hash comparisons and known-bad JavaScript signature lists fail to catch the payload.

Attackers are also leveraging domain names that closely mimic legitimate analytics and tag management services, further reducing the likelihood that a manual code review would flag the injected script as suspicious. Security teams that rely solely on periodic vulnerability scanning without continuous JavaScript integrity monitoring are particularly exposed.

Impact on Saudi E-Commerce and Financial Institutions

Saudi Arabia's e-commerce sector surpassed SAR 80 billion in transaction volume in 2025, with WooCommerce powering a significant share of small and mid-sized merchant storefronts. Many of these merchants operate under acquiring agreements with Saudi banks regulated by SAMA, making any compromise of cardholder data a direct compliance incident that cascades from the merchant to the acquirer and ultimately to the card network.

Under PCI-DSS v4.0 Requirement 6.4.3, any entity that includes scripts on payment pages must implement a mechanism to confirm that each script is authorized, that its integrity is assured, and that an inventory of all scripts is maintained with written justification for each. The Funnel Builder exploit directly violates this control — attackers are adding unauthorized scripts to the payment page through a vulnerable plugin endpoint, and without script integrity monitoring, the injection goes undetected.

SAMA's Cyber Security Framework (CSCC) Section 3.3.8 on Application Security mandates that financial institutions and their service providers implement controls to detect unauthorized modifications to web applications, particularly those handling financial transactions. A compromised WooCommerce checkout at a merchant that feeds into a Saudi acquiring bank's payment ecosystem creates Requirement 12.8 (third-party service provider management) exposure for the bank itself.

Immediate Remediation Steps

1. Patch immediately: Update Funnel Builder to version 3.15.0.3 or later. If you cannot patch within 24 hours, deactivate the plugin entirely until the update is applied. No checkout funnel is worth an active skimmer on your payment page.
2. Audit External Scripts settings: Navigate to FunnelKit Settings → Checkout → External Scripts and review every entry. Remove any script reference you did not explicitly add. Pay special attention to anything resembling a GTM loader that points to a domain other than googletagmanager.com.
3. Implement Subresource Integrity (SRI) and strict CSP: For every legitimate third-party script on your checkout pages, use SRI hashes. Configure your Content Security Policy to whitelist only known script sources and block inline script execution with script-src directives that exclude unsafe-inline.
4. Deploy real-time JavaScript monitoring: Tools like PerimeterX Code Defender, Jscrambler, and Akamai Page Integrity Manager can detect unauthorized DOM modifications and script injections on payment pages in real time — a direct implementation path for PCI-DSS 6.4.3 compliance.
5. Review WebSocket traffic: Ensure your WAF or network monitoring solution inspects WebSocket frames, not just HTTP traffic. Flag any WebSocket connection initiated from a checkout page to a domain outside your approved list.
6. Notify your acquiring bank: If you suspect any period of compromise, your PCI-DSS obligations under Requirement 12.10 (Incident Response) require timely notification to your acquirer and potentially to the card brands. In Saudi Arabia, this also triggers SAMA incident reporting requirements under CSCC Section 3.6.

Broader Lessons: Plugin Supply Chain Risk in E-Commerce

This incident reinforces a pattern that has become the dominant attack vector against e-commerce platforms: targeting third-party plugins rather than the core CMS. WordPress itself may be patched and hardened, but a single vulnerable plugin with write access to checkout page settings becomes the equivalent of a master key to cardholder data. Saudi organizations operating WooCommerce storefronts — or any plugin-extensible e-commerce platform — must treat plugin supply chain management as a first-class security control, not an afterthought.

This means maintaining a formal plugin inventory, enforcing automatic update policies for security patches, removing unused plugins entirely, and conducting periodic code reviews of any plugin that touches authentication, payment, or personally identifiable information. Under Saudi Arabia's PDPL (Personal Data Protection Law), the exfiltration of billing names, addresses, and payment credentials constitutes a personal data breach that carries regulatory notification obligations and potential penalties.

Conclusion

The FunnelKit Funnel Builder exploitation campaign is not a theoretical risk — it is happening now, on live storefronts, stealing real cardholder data. For Saudi merchants and the financial institutions that process their transactions, the remediation window is measured in hours, not weeks. Patch the plugin, audit your checkout scripts, and ensure your monitoring covers the WebSocket channels that attackers are using to evade traditional defenses.

Is your e-commerce infrastructure secure? Contact Fyntralink for a complimentary PCI-DSS gap assessment and SAMA Cyber Maturity evaluation tailored to Saudi merchants and acquiring banks.