WooCommerce Skimmer Exploits Funnel Builder Plugin: 40,000 Stores at Risk

A critical vulnerability in the Funnel Builder plugin for WordPress is being actively exploited in the wild to inject malicious payment skimmers into WooCommerce checkout pages. The campaign, detailed by Dutch e-commerce security firm Sansec on 16 May 2026, affects all versions of the plugin prior to 3.15.0.3 and puts more than 40,000 WooCommerce stores at immediate risk.

How the Exploit Works

The flaw does not yet carry an official CVE identifier. It stems from a publicly exposed checkout endpoint within Funnel Builder that allows incoming requests to invoke internal plugin methods. In older versions, this endpoint performed no permissions check and placed no restriction on which internal methods could be called. An unauthenticated attacker can send a crafted request that reaches an unprotected internal method and writes attacker-controlled data directly into the plugin's global settings. Any JavaScript injected through this route is then rendered on every Funnel Builder checkout page across the affected store, reaching every customer at the exact moment they are entering payment details.

The Google Tag Manager Disguise

Sansec researchers observed attackers using this technique to plant code that masquerades as a Google Tag Manager (GTM) loader script. Placed alongside a store's genuine GTM and analytics tags, the injected script is designed to blend into the existing tag stack. Once loaded, the fake GTM script opens a WebSocket connection to the attackers' command-and-control infrastructure at wss://protect-wss[.]com/ws, from which a tailored skimmer payload is retrieved and executed. The skimmer harvests credit card numbers, card verification values (CVVs), billing addresses, and any other personal data submitted at checkout, transmitted to the attacker in real time.

"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." - Sansec

This technique of disguising payment skimmers as legitimate analytics code is well established in Magecart-style attacks. The sophistication of this particular campaign lies in the dynamic payload delivery. By retrieving the skimmer from a remote C2 server via WebSocket rather than embedding it statically, attackers can modify the attack behaviour at any time without touching any files already on the victim's server.

Why This Matters for GCC Merchants

This campaign is directly relevant to merchants across the GCC and MENA region. The e-commerce sector across the Gulf has expanded significantly in recent years, and payment checkout pages have become an increasingly valuable target for financially motivated threat actors. The pattern mirrors an earlier attack covered by MENA Cyber Wire, where a WebRTC-based payment skimmer bypassed Content Security Policy controls entirely through encrypted UDP channels, specifically because standard HTTP monitoring tools cannot see WebRTC data in transit.

In Oman alone, e-commerce scams account for up to 80 percent of financial phishing attempts, with the sector projected to reach $3.26 billion by the end of 2026. Dubai and the wider UAE market are similarly exposed given the rapid growth of WooCommerce-based digital commerce among small and medium-sized retailers in the region.

Immediate Remediation Steps

Store operators should update the Funnel Builder plugin to version 3.15.0.3 or later immediately. Following the update, the plugin's Settings panel under Checkout then External Scripts should be reviewed carefully for any unfamiliar script entries. Any script that cannot be positively identified as legitimate should be removed and treated as a potential indicator of compromise.

Security teams responsible for e-commerce environments should also implement Content Security Policy (CSP) headers to limit which domains are authorised to execute JavaScript at checkout, conduct regular reviews of all third-party scripts loaded on payment pages, and consider server-side payment processing solutions that remove client-side JavaScript from the card data capture flow entirely.