Funnel Builder Flaw Under Active Exploitation Enables WooCommerce Checkout Skimming

A previously unknown vulnerability in the Funnel Builder plugin for WordPress is now being weaponized in the wild. Security researchers at Sansec observed attackers injecting malicious JavaScript into WooCommerce checkout pages, turning ordinary e‑commerce sites into credit‑card skimmers. The issue affects every version of Funnel Builder released before 3.15.0.3, a plugin that powers more than 40,000 WooCommerce stores worldwide.

---

How the flaw works

Funnel Builder exposes a public endpoint that accepts a request parameter indicating which internal method should be executed. In older releases the plugin never validated the caller’s permissions or restricted the set of callable methods. This oversight allows an unauthenticated attacker to:

1. Send a crafted request to the endpoint, specifying an internal method that writes data to the plugin’s global settings.
2. Supply attacker‑controlled JavaScript as the value for the External Scripts setting, which the plugin later renders on every checkout page.
3. Mask the payload as a legitimate Google Tag Manager (GTM) or Google Analytics snippet, tricking store owners and auditors into overlooking it.

Once the malicious script runs in a shopper’s browser, it opens a WebSocket connection to a remote command‑and‑control server (e.g., wss://protect-wss[.]com/ws). The C2 delivers a payment skimmer tailored to the victim’s storefront, harvesting credit‑card numbers, CVVs, billing addresses, and other personally identifiable information.

“Dressing skimmers up as Google Analytics or Tag Manager code is a recurring Magecart pattern, since reviewers tend to skim straight past anything that looks like a familiar tracking tag,” notes Sansec analyst Michele van der Veen.

---

Why this matters for e‑commerce operators

• Direct financial loss – Stolen card data can be sold on underground markets, leading to chargebacks and fraud penalties for the merchant.
• Brand reputation damage – Customers who discover their payment details were compromised may abandon the store permanently.
• Compliance risk – A breach of payment data can trigger PCI DSS violations, resulting in fines and mandatory remediation.

The attack vector is especially dangerous because it does not require any privileged access to the WordPress admin panel. Even a site that appears fully patched on the surface can be compromised simply by exposing the vulnerable endpoint.

---

Immediate steps for site owners

1. Update the plugin – Upgrade Funnel Builder to version 3.15.0.3 or later. The patch adds proper permission checks and restricts the callable methods.
2. Audit the External Scripts setting – Navigate to Settings → Checkout → External Scripts in the WordPress dashboard. Remove any script tags you do not recognize, especially those referencing gtm.js, analytics.js, or unknown domains.
3. Scan for remnants – Run a file‑system scan for stray JavaScript files or hidden .php backdoors that may have been dropped during the attack. Tools like Wordfence or Sucuri SiteCheck can automate this.
4. Rotate credentials – Regenerate API keys, database passwords, and any secrets that might have been exposed through the skimmer.
5. Monitor network traffic – Look for outbound WebSocket connections to unknown hosts. A sudden spike in wss:// traffic from your web server is a strong indicator of a compromised checkout.
6. Enable a Web Application Firewall (WAF) – Block the vulnerable endpoint (/wp-json/funnelbuilder/v1/execute) for unauthenticated IPs. Services such as Cloudflare or AWS WAF can enforce this rule with minimal impact on legitimate traffic.

---

Longer‑term hardening recommendations

• Principle of least privilege – Ensure that only authenticated admin users can invoke internal plugin methods. Review the plugin’s capability_type and adjust WordPress roles accordingly.
• Content Security Policy (CSP) – Deploy a CSP that restricts script sources to your own domain and trusted CDNs. This can prevent a malicious <script> tag from loading external code, even if it slips into the checkout page.
• Subresource Integrity (SRI) – When you deliberately load third‑party scripts (e.g., GTM), add an SRI hash. Browsers will reject the script if the content changes.
• Regular dependency audits – Use tools like npm audit, Snyk, or GitHub Dependabot to keep all WordPress plugins and themes up to date. Automated alerts can surface similar permission‑check bugs before they are exploited.
• Threat‑intel feeds – Subscribe to feeds from security firms (Sansec, Sucuri, Mandiant) that track Magecart activity. Early warnings often include IoC indicators such as malicious domains or script fingerprints.

---

Related incidents

The Funnel Builder case follows a wave of Magecart‑style attacks targeting e‑commerce platforms. Just weeks earlier, Sucuri disclosed a campaign that back‑doored Joomla sites with heavily obfuscated PHP loaders, allowing attackers to serve spam or malicious redirects on demand. Both incidents illustrate a common tactic: remote loaders that let threat actors change a site’s behavior without touching the underlying files again.

“The script acts as a remote loader, contacts an external server, sends information about the infected website, and waits for instructions,” explains researcher Puja Srivastava.

---

Bottom line

If you run a WooCommerce store powered by Funnel Builder, treat this vulnerability as a critical priority. Apply the official patch, scrub the External Scripts configuration, and tighten your overall security posture. The cost of a single successful skimmer can far exceed the effort required to remediate the flaw today.

---

For further reading, see the original Sansec advisory here and the Funnel Builder release notes for version 3.15.0.3.