# Critical Funnel Builder Vulnerability Under Active Exploitation in WooCommerce Payment Card Attacks


A critical vulnerability in the widely-used Funnel Builder plugin for WordPress is actively being exploited by attackers to inject malicious payment-skimming code into checkout pages of thousands of online stores. Security researchers at Sansec revealed this week that the flaw, affecting all versions before 3.15.0.3, allows unauthenticated attackers to inject arbitrary JavaScript that harvests credit card numbers, CVVs, and billing addresses from unsuspecting customers.


The vulnerability impacts more than 40,000 WooCommerce storefronts, making this one of the most significant e-commerce security threats to emerge in recent months. The plugin vendor, FunnelKit, has released a patch, but many store owners may remain unaware of the exposure or have failed to update.


## The Vulnerability: Unauthenticated Code Injection


The core flaw is a permissions and validation bypass in Funnel Builder's publicly exposed checkout endpoint. Sansec's analysis revealed that older versions of the plugin failed to implement proper access controls on internal methods, allowing an attacker to:


1. Issue an unauthenticated HTTP request to the vulnerable endpoint

2. Invoke an unspecified internal method without permission checks

3. Write attacker-controlled data directly into the plugin's global settings

4. Inject arbitrary JavaScript into every Funnel Builder checkout page


This design flaw means that an attacker with no prior authentication or credentials can compromise a vulnerable store within seconds. The injected code executes on every transaction, ensuring persistent exposure of customer payment data.


Affected Versions: All Funnel Builder releases prior to 3.15.0.3


## How the Attack Works in Practice


The attackers are deploying a particularly sophisticated variant of the Magecart payment-skimming approach:


### Step-by-Step Attack Chain


| Stage | Action | Result |

|-------|--------|--------|

| 1. Reconnaissance | Attacker identifies vulnerable Funnel Builder installation | Target store identified |

| 2. Code Injection | Unauthenticated request injects malicious script tag | Script added to External Scripts setting |

| 3. Obfuscation | Payload disguised as Google Tag Manager (GTM) loader | Bypasses visual inspection |

| 4. Remote Loading | Injected script opens WebSocket to attacker C2 server | wss://protect-wss[.]com/ws |

| 5. Payload Delivery | C2 server sends tailored skimmer code to victim site | Customized per-storefront attack |

| 6. Data Theft | Skimmer captures checkout form data in real-time | Credit cards, CVVs, addresses stolen |


### The Deception Layer


One of the most insidious aspects of this attack is how the malicious code conceals itself:


  • Masquerades as Google Tag Manager — legitimate analytics code that store owners expect to see
  • Uses WebSocket connections — difficult to detect with standard network monitoring
  • Customized payloads — each infected store receives a tailored skimmer, complicating detection and blocking
  • Remote control capability — attackers can modify the skimmer's behavior without touching the infected server again

    • Sansec observed live examples where the injected code loaded JavaScript from attacker-controlled domains and established persistent command-and-control communication to retrieve dynamically generated payment skimming code.


    ## Scope and Active Exploitation


    The vulnerability is not theoretical—it's actively exploited in the wild. Sansec's research confirms that real attackers are targeting vulnerable Funnel Builder installations, with the primary objective of harvesting payment card data at scale.


    Key Impact Metrics:

  • 40,000+ WooCommerce stores use Funnel Builder
  • All versions before 3.15.0.3 are vulnerable
  • No CVE identifier has been officially assigned (as of publication)
  • Active attacks confirmed across multiple victim stores

    • The scale of potential exposure is enormous. Even if only a fraction of these 40,000 stores are still running vulnerable versions, the number of compromised transactions and stolen payment records could reach into the hundreds of thousands.


    ## Technical Deep Dive: The Permissions Bypass


    The vulnerability stems from a fundamental security architecture flaw:


    Vulnerable Code Pattern:

    Public Endpoint → Accepts Method Parameter → No Permission Checks → 
Writes to Global Settings → Output Rendered on All Checkout Pages

    This chain of trust violations creates a direct pipeline from the internet to the database without intermediate security validation. The plugin accepted incoming requests to run internal methods without verifying:


  • Who is making the request (authentication)
  • What methods are allowed to be called (authorization)
  • When to reject suspicious patterns (rate limiting)

    • FunnelKit's patch (v3.15.0.3) addresses this by implementing proper permission validation and method whitelisting.


    ## Broader Pattern: Magecart's Evolution


    This attack fits squarely within the broader Magecart ecosystem of e-commerce compromise campaigns. Sansec noted that disguising skimmers as Google Analytics or Google Tag Manager code is a "recurring Magecart pattern"—reviewers tend to overlook familiar tracking tags, making this an effective obfuscation technique.


    The timing is notable: this disclosure comes just weeks after Sucuri documented a Joomla backdoor campaign using similar remote-loading tactics. The pattern suggests that attackers are systematizing e-commerce compromise, with modular skimmers deployed across multiple CMS platforms.


    ## Remediation and Recommendations


    ### Immediate Actions for Store Owners


    Critical Priority:

    1. Update Funnel Builder immediately to version 3.15.0.3 or later

    2. Audit Settings > Checkout > External Scripts for unfamiliar code

    3. Remove any suspicious script tags, particularly those referencing external domains or WebSocket connections

    4. Review recent transaction logs for evidence of skimming activity

    5. Notify customers if payment data exposure is confirmed


    ### Detection Indicators


    Watch for these red flags in the External Scripts setting:

  • Scripts loaded from unfamiliar domains
  • References to WebSocket connections (wss:// or ws://)
  • Obfuscated or minified code that isn't part of your legitimate setup
  • Recent additions that your team didn't create
  • Code containing variable names like "skimmer," "stealer," or "grabber"

    • ### Long-Term Security Posture


  • Implement Web Application Firewalls (WAF) with rules to detect JavaScript injection attempts
  • Enable Content Security Policy (CSP) headers to restrict external script loading
  • Conduct regular security audits of all installed plugins
  • Maintain an inventory of scripts loaded on checkout pages
  • Implement payment card scanning detection to identify signs of active skimming

    • ---


    ## HackWire Analysis


    This vulnerability represents a critical inflection point in the weaponization of WordPress plugin flaws. What makes this incident particularly concerning is not just the technical flaw—permission bypasses are unfortunately common—but rather the sophistication of the exploitation methodology and the scale of potential exposure.


    Why This Matters Now: We're witnessing a shift in e-commerce attacks from broad spray-and-pray campaigns to highly targeted, per-storefront customization. The attackers are delivering tailored skimmers to each infected site through WebSocket-based C2 communication, making traditional signature-based detection nearly impossible. This is industrialized payment card theft with force-multiplier tactics.


    The Pattern Recognition Angle: This attack chain directly mirrors the Joomla backdoor campaign disclosed by Sucuri weeks ago—both use remote-loading architectures that separate the initial compromise from the final payload delivery. Attackers are converging on a modular model: gain a foothold through one vulnerability, then inject a loader that remotely retrieves attack-specific code. This separation of concerns makes defense reactive and forensics difficult.


    Hidden Risk: The 40,000-store figure is likely understated. Not every store owner monitors their plugin settings, and even those who do may miss a malicious script embedded among legitimate analytics tags. Given that WooCommerce powers roughly 30% of all e-commerce sites globally, the actual exposure may be orders of magnitude higher than currently understood.


    Concrete Next Steps for Defenders:

  • For platform administrators: Audit all external script inclusions immediately; implement a whitelist of approved script sources
  • For payment processors and acquirers: Monitor for signature-level anomalies in checkout transaction sequences (rapid card tests, geographic mismatches)
  • For incident response teams: Begin proactive hunting for WebSocket connections to attacker infrastructure; correlate infected sites by their C2 beacon patterns

    • The pressure is now on FunnelKit and the broader WordPress ecosystem to close these permission-validation gaps before the next wave of attacks targets a different plugin in the checkout pipeline.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)