Security alert · Updated 2026-05-17
WooCommerce Checkout Skimming: Funnel Builder Fix
Attackers are exploiting a Funnel Builder WordPress flaw to inject checkout skimmers into WooCommerce stores. Here is the patch, cleanup checklist, and protection stack.
What happened
A critical weakness in the Funnel Builder plugin for WordPress, also known in many stores as FunnelKit Funnel Builder, moved from quiet vulnerability to active checkout-skimming incident. Public reporting from The Hacker News cited Sansec research showing that attackers were abusing older plugin versions before 3.15.0.3 to place malicious JavaScript into WooCommerce checkout pages. The injected code was disguised as ordinary analytics, often as a fake Google Tag Manager-style script, but its purpose was direct payment theft: card numbers, CVVs, billing names, addresses, email addresses, and other checkout fields entered by real customers.
This is an S-level Omellody radar item because it combines three high-risk signals: active exploitation, payment-page compromise, and broad WordPress/WooCommerce exposure. A store owner does not need to be a large brand to be targeted. Skimmer campaigns are automated, and attackers usually scan for vulnerable plugins at scale. If the plugin is installed and not updated, the checkout page can become the collection point even when the store uses a legitimate payment gateway. Customers see a familiar page, the transaction may still complete, and the theft can remain hidden until fraud reports arrive.
The most important detail is that the reported issue was not only theoretical. Attackers were already planting code into live stores. The plugin maintainer released version 3.15.0.3, so the first defensive line is patching immediately. But patching alone does not prove that a store was never modified. Owners should inspect Funnel Builder external script settings, theme files, tag manager containers, recently changed options, and unfamiliar administrator accounts. Payment skimmers are built to look boring. Treat any unexpected checkout script as hostile until it is verified.
Immediate checklist for WooCommerce store owners
- Update Funnel Builder/FunnelKit to 3.15.0.3 or later. Do this before reviewing logs so the exposure window closes.
- Clear caches and CDN edge copies. A patched origin can still serve stale malicious checkout JavaScript if cache rules are too aggressive.
- Review plugin settings. Check External Scripts, tracking snippets, custom checkout fields, and any recently added global scripts.
- Search the database for unfamiliar tags. Look for odd Google Tag Manager IDs, remote JavaScript from unrelated domains, obfuscated code, and newly modified options.
- Rotate administrator passwords and enforce MFA. Even if this flaw was unauthenticated, compromised admins can reinsert skimmers later.
- Notify your payment processor if evidence appears. Card-data exposure has legal and contractual reporting duties.
- Add a WAF rule set and file integrity monitoring. Skimmer cleanup without monitoring invites repeat compromise.
Customers who shopped at a potentially affected WooCommerce store should monitor card activity, consider replacing the card used at checkout, and watch for phishing emails that reference the purchase. A skimmer can capture enough billing context to make follow-up scams look convincing.
Recommended protection stack
| Product | Best for | Rating | Typical price | Pros | Cons |
|---|---|---|---|---|---|
| Sucuri Website Security | WordPress malware cleanup and WAF | 4.7/5 | From about $199/year | Strong site cleanup, server-side scanning, virtual patching | More website-focused than endpoint-focused |
| Bitdefender GravityZone | Small business endpoint protection | 4.6/5 | Varies by seat count | Excellent malware blocking, policy controls, ransomware defense | Management console can feel heavy for tiny teams |
| Norton Small Business | Simple device protection for store teams | 4.4/5 | Plan dependent | Easy deployment, reputable consumer and small-business coverage | Less specialized for WordPress cleanup |
| Malwarebytes Teams | Fast remediation on staff PCs | 4.3/5 | Per device/year | Good at removing adware, trojans, and browser threats | Needs another layer for website WAF |
| 1Password Business | Admin credential control | 4.6/5 | Per user/month | Strong vaults, MFA workflows, breach alerts | Does not scan website code |
No single product fixes a checkout skimmer end to end. The practical stack is website WAF plus endpoint security plus password management plus log review. Store owners should also limit plugin count, remove abandoned extensions, back up before updates, and test checkout after each security change. If you process high transaction volume, pay for professional incident response rather than relying only on automated scanners.
How to know whether you were hit
Look for indicators in four places. First, check the Funnel Builder settings for new external scripts or tags that no marketing team member recognizes. Second, inspect HTML source on the checkout page in a private browser session and compare it with a clean staging site. Third, review access logs around suspicious option changes. Fourth, watch fraud reports from customers who used the store recently. A payment skimmer rarely announces itself with a visible error; the page often works normally because a broken checkout would reduce the attacker’s yield.
If you find injected code, preserve evidence before deleting everything. Capture the script URL, timestamp, plugin version, server logs, user accounts, and database changes. Then remove the code, update the plugin, rotate credentials, invalidate sessions, and contact your payment processor or legal adviser. The right disclosure path depends on jurisdiction and whether card data, names, addresses, or email addresses were exposed. Customers deserve clear instructions: replace the card, monitor statements, beware order-themed phishing, and use identity monitoring if personal data was also captured.
Bottom line
The Funnel Builder incident is a reminder that ecommerce security is not only about the payment gateway. The checkout page itself is sensitive infrastructure. If a plugin can inject JavaScript there, attackers can turn a trusted store into a credential and card-harvesting page. Patch now, audit checkout scripts, and add monitoring that alerts when payment-page code changes unexpectedly.
72-hour recovery plan
Use the first hour to stop new exposure. Put the site into a controlled maintenance window if you can do that without hiding evidence, update the plugin, disable unfamiliar checkout scripts, and purge every cache layer. If sales must continue, route checkout through the most minimal verified flow and remove optional conversion tools until the audit is complete. The second phase is evidence capture: export plugin settings, list administrator users, save web server access logs, save recent WordPress option changes, and record the exact script URLs found in checkout source. This evidence helps a payment processor, insurer, or incident responder decide whether card data was likely intercepted.
During hours six through twenty-four, rebuild trust controls. Rotate WordPress administrator passwords, database passwords if exposed in backups or panels, hosting control-panel passwords, SFTP keys, and API keys used by marketing tools. Review every user with the ability to edit plugins, themes, snippets, tag manager containers, or checkout settings. Remove dormant accounts. Add MFA to the hosting panel, WordPress admin, DNS provider, payment gateway, and email accounts that receive order exports. A skimmer campaign often starts with one vulnerability and continues through any credential the attacker can reuse.
During the second and third day, communicate carefully. If you have confirmed checkout compromise, do not bury the message in vague language. Tell customers the date range under investigation, what information may have been entered, what you have fixed, and what they should do next. Good communication reduces panic because it gives people concrete steps: monitor card statements, replace the card if advised by the issuer, beware order-themed phishing, and contact the store through a known support address. For store owners, this is also the moment to document a permanent security baseline: weekly plugin updates, daily backups, checkout change alerts, and a quarterly review of all scripts that run on payment pages.
How this affects customers
Customers usually cannot see a checkout skimmer. The form looks normal because the attacker's script silently copies information in the background. That is why consumers should treat unexpected fraud, fake delivery emails, and payment-verification calls seriously after shopping at a compromised site. If a store confirms exposure, replacing the specific card used at checkout is faster than trying to guess whether the number will be sold. If the store also collected name, address, phone, or email, customers should expect more convincing phishing attempts. A password manager helps by refusing to autofill credentials on lookalike domains, and identity monitoring can catch broader misuse if billing data is combined with other leaks.
The best customer-side defense is layered. Use credit cards rather than debit cards for online purchases when possible, enable bank transaction alerts, avoid saving cards in small stores unless you shop there often, and use unique passwords for store accounts. If a checkout page suddenly asks for extra identity details that do not match the purchase, stop and contact the merchant through a known channel. Payment theft is not always caused by the buyer's device; sometimes the trusted merchant page is the infected surface. That is why store-side patching and transparent disclosure matter.
Frequently asked questions
Which Funnel Builder version fixes the reported issue?
Public reporting says Funnel Builder versions before 3.15.0.3 were affected, and the maintainer released 3.15.0.3 as the patched version. Update to that version or later.
Can a payment gateway protect me from this?
A gateway reduces how much card data your server stores, but checkout-page JavaScript can steal information before it reaches the gateway. You still need to audit scripts.
Should customers cancel cards?
If a customer entered card details on a store that confirms compromise, replacing the card is the safest move. At minimum, monitor statements and enable transaction alerts.
Is antivirus enough for WooCommerce skimming?
No. Antivirus helps staff devices, but this incident requires plugin patching, WAF coverage, checkout script review, and credential security.
Do I need to disclose the incident?
If you confirm card or personal data exposure, consult your payment processor and legal adviser. Disclosure rules vary by location and data type.