A vulnerability in the Funnel Builder WordPress plugin allowed attackers to inject malicious JavaScript into WooCommerce checkout pages and harvest credit card data in real time. The plugin, active on more than 40,000 websites, contained a flaw affecting all versions before 3.15.0.3. Sansec detected the exploitation in the wild before FunnelKit released a patch.
This was not a sophisticated supply chain attack. It was a preventable failure in third-party component management that left checkout flows exposed to card skimming.
Timeline
Pre-exploitation period: Funnel Builder versions below 3.15.0.3 contained the vulnerability. The exact discovery date is not publicly documented, but Sansec identified active exploitation before the vendor issued a fix.
Detection: Sansec's monitoring systems flagged malicious JavaScript injection on WooCommerce checkout pages using the vulnerable plugin.
Vendor response: FunnelKit released version 3.15.0.3 to address the vulnerability.
Current status: The patch is available, but any site running an earlier version remains vulnerable to the same exploitation technique.
The window between detection and patch availability is unknown, but the fact that exploitation was observed before the fix means attackers had working code targeting this specific plugin.
Which Controls Failed or Were Missing
No input validation on script injection points: The plugin allowed untrusted input to reach checkout page rendering without sanitization. This is the core failure—if the plugin properly validated and encoded any data that could influence page output, the JavaScript injection wouldn't have succeeded.
Missing Content Security Policy (CSP): A properly configured CSP would have blocked inline script execution or restricted script sources to known-good origins. Most WordPress installations run without CSP headers, leaving checkout pages vulnerable to any injected script.
No runtime integrity monitoring: The compromised sites had no mechanism to detect unauthorized JavaScript on payment pages. Card skimmers operate by silently intercepting form data—they don't trigger error logs or crash the application.
Delayed patch deployment: Even after FunnelKit released the fix, sites running automatic updates on a weekly or monthly schedule remained exposed. Organizations without a defined process for emergency plugin updates had no way to prioritize this patch over routine maintenance.
Third-party component inventory gap: Many security teams don't maintain a complete inventory of WordPress plugins in production. Without knowing which sites run Funnel Builder, you can't identify affected systems or verify patch deployment.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.4.3 states: "All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: A method is implemented to confirm that each script is authorized."
This requirement exists specifically to prevent the attack that succeeded here. You must either:
- Maintain an inventory of authorized scripts with integrity verification (subresource integrity hashes)
- Use CSP to whitelist script sources and block inline execution
- Implement a script monitoring solution that alerts on unauthorized JavaScript
The Funnel Builder vulnerability bypassed all three controls on affected sites.
PCI DSS Requirement 6.3.2 requires: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
If you don't know which sites run Funnel Builder, you can't patch them. The 40,000+ installations suggest many organizations lack this inventory.
OWASP ASVS v4.0.3 requirement 5.3.3 (Level 2) specifies: "Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables)."
The injection vector likely involved parameter manipulation that the plugin failed to sanitize.
Lessons and Action Items for Your Team
Build a complete plugin inventory today: Run wp plugin list --allow-root on every WordPress instance you manage. Export the results to a spreadsheet with site URL, plugin name, installed version, and latest available version. Update this weekly. You can't patch what you don't know exists.
Implement CSP on all checkout pages: Start with Content-Security-Policy: script-src 'self' https://trusted-cdn.example.com; object-src 'none'; base-uri 'self'; and adjust based on your legitimate script sources. Test in report-only mode first, then enforce. This single header would have blocked the JavaScript injection even with the vulnerable plugin installed.
Set up script integrity monitoring: Use a service like Sansec, Jscrambler, or Magecart to monitor your checkout pages for unauthorized JavaScript. Configure alerts to fire within minutes of detecting new scripts. The detection-to-notification path should be automated—manual review adds dangerous delay.
Create an emergency patch process: Define criteria for "patch immediately" vs "patch in next maintenance window." A checkout page vulnerability with active exploitation always qualifies for immediate action. Document who has authority to approve emergency changes and how to deploy outside normal change windows.
Enable automatic updates selectively: WordPress supports automatic updates for plugins. Enable this for security-focused plugins on non-production environments first, then production. Monitor for breakage. The risk of an outdated plugin usually exceeds the risk of an automatic update causing issues.
Validate all third-party plugins before installation: Before adding any plugin to your approved list, review its update history, check for known vulnerabilities, and verify the vendor has a security contact. Plugins without recent updates or security documentation don't belong on payment pages.
Test your incident response for payment page compromise: Run a tabletop exercise where your monitoring system flags unauthorized JavaScript on checkout. Who gets the alert? How quickly can you disable the affected plugin? What's your customer notification process? The Funnel Builder incident gave you the scenario—use it.
The vulnerability in Funnel Builder exposed a systematic failure in how most organizations manage third-party code on payment pages. The plugin itself was the immediate problem, but the underlying issue is treating WordPress plugins as trusted code instead of as external dependencies that require active management.
Your checkout page is a target. Every plugin that touches it is an attack surface. Manage them accordingly.
