WordPress Funnel Builder (FunnelKit) XSS (CVE-2025-66067): What Site Owners Must Do — Security Guide

Author: Hong Kong Security Expert

Summary: A Cross-Site Scripting (XSS) vulnerability affecting Funnel Builder by FunnelKit (versions ≤ 3.13.1.2) was disclosed as CVE-2025-66067. This advisory explains the technical details, realistic risk scenarios, detection and remediation steps, and practical mitigations you can apply immediately.

Table of contents

• Overview: what happened
• Technical details and scope
• Who can exploit it and how likely it is
• Realistic attack scenarios and impacts
• Immediate detection: what to look for
• Short-term mitigation (fast, non-destructive)
• Long-term remediation and hardening
• How WAFs and virtual patching can help
• Incident response checklist if you suspect compromise
• Example WAF rules and scanners you can use now
• Recommended policy additions and best practices
• Start protecting now — immediate actions
• Frequently asked questions
• Appendix: useful commands and detection queries

Overview: what happened

On 6 December 2025 a Cross-Site Scripting (XSS) vulnerability affecting the Funnel Builder by FunnelKit WordPress plugin was publicly disclosed (CVE-2025-66067). The vendor released a patch in version 3.13.1.3. Versions ≤ 3.13.1.2 are affected.

Patch details indicate the vulnerability allows injection of HTML/JavaScript payloads that can be stored and rendered in the admin or front-end context. The reported required privilege for exploitation was Contributor, and the vulnerability was assigned a CVSS score of 6.5. While not a direct remote code execution, XSS remains a valuable primitive for attackers who can phish admins, steal session cookies, or insert persistent scripts that affect visitors and administrators.

Every XSS in a widely used plugin warrants careful attention: it enables social engineering, stolen cookies, and potential admin session hijacking. Treat this as high priority for investigation and remediation on affected sites.

Technical details and scope

• Affected plugin: Funnel Builder by FunnelKit
• Affected versions: ≤ 3.13.1.2
• Fixed in: 3.13.1.3
• Vulnerability type: Cross-Site Scripting (XSS) — likely stored XSS, delivered via plugin UI or content saved to the database and then rendered without proper escaping or sanitization
• Required privilege: Contributor (the attacker needs at least Contributor level)
• CVE: CVE-2025-66067
• OWASP Category: A3 (Injection)

Root cause (summary): the plugin accepted data (form fields, custom content, or admin inputs) that were stored and later output in an admin or front-end context without appropriate escaping (esc_html, esc_attr, wp_kses) or sanitization, allowing an attacker with contributor access to include arbitrary HTML/JS.

Important nuance: Contributor accounts can create and edit their own posts but not publish. However some sites allow Contributors to upload files or use shortcodes or builder widgets; in those contexts an attacker can plant payloads that later render for administrators (a high-value target), or for visitors if a public view displays the payload.

Who can exploit this and how likely is it?

• Privilege required: Contributor.
• If your site allows public registration and assigns Contributor by default, exploitation risk is higher.
• If registrations are restricted and users are vetted, risk is lower.
• Attack complexity: Low to moderate. XSS payloads are simple to craft; the main challenge for an attacker is acquiring a Contributor account or compromising one.
• Likelihood: Medium for sites that allow open registration, lower for tightly managed sites. A single compromised Contributor on a high-traffic site can cause meaningful damage.

Realistic attack scenarios and impacts

1. Stored XSS targeting administrators:

   An attacker creates a funnel, form, or content block containing malicious JavaScript. When an admin visits the Funnel Builder admin pages or inspects submissions, the script executes in the admin’s browser, allowing cookie theft, session token exfiltration, or authenticated actions via XHR. Impact: admin account takeover, plugin/theme installation, privilege escalation.

2. Customer-facing persistent XSS:

   The script executes in visitors’ browsers, enabling phishing, affiliate skimming, redirects, or cryptominer placement. Impact: brand damage, SEO penalties, user account compromise for logged-in visitors.

3. Supply-chain pivot:

   Attacker uses XSS to deliver payloads that inject iframes or load external scripts, establishing persistence and a foothold for later attacks.

4. Social engineering / phishing:

   Injected content may prompt admins to provide credentials to fake login prompts or click links performing destructive actions.

Immediate detection: what to look for

If you use Funnel Builder, check the following immediately:

• Plugin version: Is it ≤ 3.13.1.2? Upgrade if so.
• Recent posts, funnels, forms, or builder blocks created by Contributor users since the vulnerability appeared. Look for suspicious JS patterns such as:
• )|(?:javascript:)|(?:onerror\s*=))/is

  Important: Tune rules to avoid false positives — many builders and shortcodes include legitimate HTML fragments.

  Recommended policy additions and best practices

  • Do not give Contributor or Author roles file upload capability unless strictly necessary.
  • Treat any user capable of adding HTML fragments as higher risk; apply stricter approval workflows.
  • Maintain an inventory of plugins and enable alerts for outdated or vulnerable plugins; perform monthly plugin reviews.
  • Use staging environments for plugin updates and test Funnel Builder in a sandbox before production upgrades.
  • Maintain offsite backups and regularly test restore procedures.
  • Restrict XML-RPC and REST API endpoints unless explicitly used.
  • If you accept user-supplied HTML, apply server-side sanitization using wp_kses with a tight allowed tags policy.

  Start protecting now — immediate actions

  Take these immediate steps to reduce risk while you plan a full update and hardening effort:

  1. Verify plugin version and update to 3.13.1.3 as soon as possible (test on staging first).
  2. Close or limit new user registrations; set default role to Subscriber if registrations are required.
  3. Scan for injected scripts and remove suspicious content from posts, meta, and uploads.
  4. Deploy tuned WAF rules or edge filters to block common XSS payloads against Funnel Builder endpoints.
  5. Enable two-factor authentication for all admin/editor accounts.
  6. Restrict admin access by IP or HTTP auth where operationally possible.
  7. Rotate passwords and salts if you suspect compromise; force privileged users to reset credentials.

  Frequently asked questions

  Q: If my site has no Contributors, am I safe?
  A: You are safer but not immune. Attackers often use credential reuse or phishing to escalate. Also check theme and other plugins for similar issues.

  Q: Can I rely entirely on a WAF instead of updating the plugin?
  A: No. WAFs and virtual patches buy time and reduce risk, but they are not a permanent substitute for applying the official vendor patch. Update as soon as practicable.

  Q: What about Content Security Policy (CSP)?
  A: CSP is a powerful control but must be implemented carefully. For complex builder sites, CSP can break legitimate inline scripting. Use report-only mode first to tune your policy.

  Q: How do I remove injected scripts safely?
  A: Manual removal by a knowledgeable administrator is safest. Automated removals can cause collateral damage; ensure you have backups before running automatic cleanups.

  Appendix: useful commands and detection queries

  • List plugin version:

  wp plugin get funnel-builder --fields=name,version,status

  • Find posts containing suspicious strings:

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content REGEXP '<(script|iframe|object|embed)';"

  • Find postmeta with scripts:

  wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value REGEXP '<(script|iframe|javascript:)';"

  • Grep uploads for suspicious content:

  grep -R --line-number -E "

  • Check recently modified files:

  find . -type f -mtime -30 -print

  Closing thoughts

  XSS vulnerabilities like CVE-2025-66067 demonstrate a recurring pattern in the WordPress ecosystem: user-facing features that accept and render HTML must do so defensively. For site owners, the correct response is layered and practical:

  • Patch the plugin promptly (update to 3.13.1.3).
  • Apply short-term mitigations (disable registrations, tighten roles, deploy WAF rules).
  • Harden admin endpoints and implement continuous monitoring to detect suspicious activity early.

  If you require an incident walkthrough or help with triage and remediation, engage a reputable security professional experienced with WordPress incidents. Act quickly and decisively.

  — Hong Kong Security Expert