A vulnerability in the Funnel Builder WordPress plugin is being actively exploited to plant credit card skimmers on WooCommerce checkout pages. The plugin, also marketed as FunnelKit, is installed on more than 40,000 stores, and the flaw allows an unauthenticated attacker to write arbitrary JavaScript into the checkout flow without ever logging in. Dutch e-commerce security firm Sansec disclosed the issue, and exploitation is already happening in the wild.
The problem sits in a public checkout endpoint exposed by Funnel Builder. The endpoint lets the caller specify which internal method to execute. In versions before 3.15.0.3, the plugin never verifies the caller's permissions and places no restriction on which methods can be invoked. That is a combination an attacker can walk straight through. By picking the internal method that writes to the plugin's global settings, an unauthenticated request can drop attacker-controlled data into configuration the store then trusts.
The settings entry being abused is the External Scripts field, which exists to let store owners add legitimate analytics tags such as Google Tag Manager. Attackers are writing fake GTM loaders into that field. The injected entry looks indistinguishable from the genuine analytics scripts already sitting next to it, which is precisely why it survives a cursory glance at the admin panel.
When a customer loads the checkout page, the fake GTM tag fetches JavaScript from a remote domain. That script then opens a WebSocket connection to the attacker's C2 server at wss://protect-wss[.]com/ws. The server responds with a skimmer tailored to the specific storefront, which then harvests card numbers, CVVs, billing addresses, and any other personal information the customer types into the checkout form. Data exfiltration happens in real time as the customer fills in the fields.
This is a Magecart-style web-skimming operation, but adapted in a way that matters for defenders. A traditional skimmer modifies PHP or JavaScript files on disk, which triggers file integrity monitoring. This campaign does not touch the file system. The malicious script is written through the plugin's own settings interface and stored in the database alongside legitimate configuration. When the skimmer loads on the checkout page, it loads through a sanctioned plugin mechanism doing exactly what it was designed to do, which is render external scripts the administrator configured.
Security tools that scan WordPress files for unexpected changes will see nothing wrong. The malicious payload lives in wp_options or equivalent plugin tables, not in any file an integrity check would flag. This is a deliberate choice by the attackers, and it is becoming a common pattern in plugin-targeted intrusions. It also expands a store's effective attack surface in a way many operators do not account for, because plugin settings are rarely treated as a security boundary.
The fix is version 3.15.0.3, which adds the missing permission check and restricts which internal methods can be invoked through the public endpoint. Every site running Funnel Builder or FunnelKit should update immediately. No CVE has been assigned at the time of publication, but active exploitation is confirmed.
There is an important caveat. Updating the plugin closes the entry point. It does not remove anything that was already written into the settings before you patched. If your store was compromised last week and you update today, the skimmer entry in External Scripts will still be there, still loading on every checkout, still siphoning card data to the C2 server. The patch stops new infections. It does not clean existing ones.
Every store running an affected version should therefore treat the update as step one of two. Step two is opening Settings > Checkout > External Scripts in the Funnel Builder admin panel and reviewing every entry. Anything you did not personally add should be deleted. Pay particular attention to entries that look like Google Tag Manager loaders, because that is the disguise this campaign is using. Searching your site's source code for the string protect-wss[.]com is a fast initial check and a reliable indicator of compromise for this specific operation.
If you find a malicious entry, assume card data has been exfiltrated for the period it was present. That has reporting implications under PCI DSS and, depending on your jurisdiction and the residency of affected customers, under data protection law. Preserve logs before you clean up. Knowing when the skimmer was planted, and how many checkout sessions ran while it was active, will matter to your acquirer and to any regulator that asks.
Patching closes the vulnerability and prevents new injections, but it does not remove any skimmer that was already planted before you updated. You must separately open Settings > Checkout > External Scripts and delete any entry you did not add yourself. A skimmer already present will keep harvesting card data through every checkout until it is manually removed.
Check the External Scripts setting in the Funnel Builder plugin and compare each entry against the tags you deliberately configured in your Google Tag Manager account. Any script loading JavaScript from a domain you do not recognise — particularly one establishing a WebSocket connection — should be treated as malicious and removed immediately. Sansec observed attackers using the domain protect-wss[.]com for their C2 WebSocket; searching your site's source code for that string is a quick initial check.
This specific vulnerability is in Funnel Builder / FunnelKit versions before 3.15.0.3. Other checkout plugins have their own code bases and vulnerability histories. However, the underlying attack pattern — injecting skimmer JavaScript through a plugin's settings rather than into server files — is not unique to FunnelKit. Any checkout plugin that exposes settings endpoints without strict permission verification is a candidate for the same approach. Reviewing access controls on all checkout-related plugins is worthwhile regardless of this specific disclosure.
