Active Exploitation: Funnel Builder Plugin Flaw Skimming WooCommerce Data
Heads up everyone, Sansec just dropped a report on an actively exploited flaw in the Funnel Builder WordPress plugin. It looks like attackers are leveraging this to inject malicious JavaScript directly into WooCommerce checkout pages to skim payment info.
The tricky part is that there isn't an official CVE assigned yet, which complicates the triage process for vulnerability management teams. The vulnerability allows attackers to inject arbitrary JS, effectively turning your checkout into a Magecart-style skimmer.
If you are managing WordPress/WooCommerce instances, I'd recommend auditing your plugin list immediately.
Immediate Detection Steps:
- Check for the 'Funnel Builder' plugin and update or remove it immediately.
- Inspect the HTML source of your checkout pages for any obscure or obfuscated external scripts.
You can use the following command to hunt for recently modified PHP or JS files within your plugins directory that might indicate a backdoor or injection:
find /path/to/wp-content/plugins -type f \( -name "*.php" -o -name "*.js" \) -mtime -7 -ls
Additionally, querying the database for common obfuscation patterns can help locate payloads hidden in post content or options:
SELECT * FROM wp_postmeta WHERE meta_value LIKE '%base64_decode%' OR meta_value LIKE '%eval(%';
Since there is no CVE yet, how are you all handling the detection logic in your scanners? Are you relying on file integrity monitoring or looking for specific script signatures?
Good callout on the mtime check. From a SOC perspective, we are also hunting for the egress traffic. If the skimmer is exfiltrating data, it usually phones home to a specific domain. We've added a KQL rule to catch non-CDN JS loads on checkout pages:
DeviceNetworkEvents
| where InitiatingProcessFileName has "php"
| where RemoteUrl endswith ".js"
| where RemoteUrl !contains "cloudflare" and RemoteUrl !contains "googleapis"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP
I found this on two legacy client sites this morning. The easiest mitigation before a full investigation is disabling the plugin via WP-CLI to stop the bleeding immediately. Don't wait for the patch if you aren't using it heavily.
wp plugin deactivate funnel-builder --path=/var/www/html
Sansec noted the injection is very similar to previous Magecart campaigns, so checking your access logs for unusual admin login attempts around the time of file modification is a good idea.
Solid advice on immediate containment. Beyond just disabling the plugin, remember to scan the wp_options table for the injected script, as these payloads often persist even after deactivation. I've seen similar stashes use base64 encoding to evade simple detection.
You can run a quick SQL query to hunt for script tags in options:
SELECT * FROM wp_options WHERE option_value LIKE '%<script%';
Also, verify your wp_posts table for any modified scripts injected directly into page content.
Solid advice on persistence. Since Funnel Builders interact directly with page content, you should also audit the wp_posts table for injected scripts.
Run this SQL query to hunt for any suspicious script tags in published posts:
SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' AND post_status = 'publish';
This catches payloads embedded directly in the content, not just options.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access