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:
• <script> tags
• Event handlers (onerror=, onclick=)
• Attributes like javascript:, data:, or base64-encoded strings
• <iframe> tags pointing to external domains
• Obfuscated code (eval, atob, decode, unescape)
• Admin dashboard pages that show user-created content (e.g., funnel previews). Open them in a hardened browser or sandbox (do not use an admin session on a production browser until you are sure).
• Unusual admin activity in logs (new plugin/theme installs, unknown admin users).
• Outbound network connections from the server to unknown domains (check server logs and firewall).
• Unexpected changes in theme files, uploads, or wp_options.

Search examples (SQL/DB or exported SQL):

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';

SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

grep -R --line-number "<script" wp-content/uploads

Note: Many builders and editors include HTML fragments. Focus on script tags and obfuscated strings.

Short-term mitigation (fast, non-destructive)

If you cannot update immediately, implement these mitigations to reduce exposure while you plan updates:

1. Block exploit attempts with WAF rules or edge filters:

   Deploy rules to block requests that include suspicious payloads in POST/PUT fields for Funnel Builder endpoints. Tune rules to avoid false positives.

2. Restrict registrations and default role:

   Temporarily disable public registration. If registration is required, set default role to Subscriber until patched.

3. Content Security Policy (CSP):

   Add a CSP that disallows inline scripts and external script loading except from trusted domains. Example header to test:

   Content-Security-Policy: default-src 'self'; script-src 'self';

   Note: CSP can break legitimate features; deploy in report-only mode first to tune.

4. Harden admin access:

   Enable two-factor authentication for all privileged accounts and restrict WP-Admin by IP or HTTP auth where feasible.

5. Sanitize user-provided input in custom code:

   If custom templates echo plugin fields, use escaping functions (esc_html, esc_attr, wp_kses_post).

6. Scan for injected content and remove it:

   Use a reliable malware scanner to find and clean suspicious HTML/JS in posts, pages, and meta fields. Prefer manual review for high-value pages.

7. Limit Contributor capabilities:

   Temporarily remove upload capability and other unnecessary privileges from Contributor role.

8. Enable auto-updates where safe:

   Consider enabling plugin auto-updates for trusted plugins after testing on staging.

Long-term remediation and hardening

1. Update immediately to Funnel Builder 3.13.1.3 or later. Test updates on a staging copy first.
2. Audit user roles and registration policy: avoid granting Contributor or higher roles automatically.
3. Review code and templating practices: always escape output (esc_html, esc_attr, wp_kses) and sanitize input on save (sanitize_text_field, wp_kses_post).
4. Keep server components patched (PHP, web server) and enforce secure file permissions; disable direct PHP execution in uploads where possible.
5. Implement continuous scanning and virtual patching where appropriate to block exploitation patterns while patching upstream.
6. Implement monitoring and logging for user actions, plugin installations, and file changes; alert on abnormal events.

How WAFs and virtual patching can help

When a vulnerability is disclosed but immediate update is not possible, a Web Application Firewall (WAF) or edge filtering can provide time-limited protection. Typical protections include:

• Rule sets to detect and block known XSS patterns in request bodies and headers.
• Virtual patching that blocks exploit traffic to vulnerable endpoints without altering plugin code.
• Scanners that hunt for injected scripts across posts, meta, uploads, and theme/plugin files.
• Capability restrictions and alerts for suspicious actions (new plugin uploads, modified files).

Important: WAFs buy time but are not a permanent substitute for applying the official patch. Use them as a compensating control while you test and deploy the vendor-supplied update.

Incident response checklist if you suspect compromise

If you find evidence of exploitation (suspicious scripts, unexpected admin actions), follow this incident response plan:

1. Contain
   • Disable public content creation channels if possible (close registrations).
   • Put the site into maintenance mode or display a hold page.
   • Isolate the infected instance — take a filesystem snapshot and DB dump for forensics.
2. Preserve evidence
   • Export logs (webserver, access logs, plugin logs).
   • Save copies of suspicious pages and payloads (do not execute them in a live browser).
3. Identify
   • Find when the malicious content was inserted and by which user.
   • Query wp_posts, wp_postmeta, wp_options for <script> and obfuscated strings.
   • Check recently modified files and plugin/theme directories.
4. Remove & remediate
   • Remove injected scripts from posts and options (manual review preferred).
   • Reinstall the affected plugin from an official source and upgrade to 3.13.1.3.
   • Replace any altered core or theme files with fresh copies from trusted sources.
5. Credentials & access control
   • Force password resets for all privileged accounts.
   • Invalidate sessions by rotating salts in wp-config.php.
   • Review user list and remove suspicious accounts.
6. Patch & harden
   • Apply the plugin update on staging then production.
   • Harden admin area with 2FA, IP restrictions, and reduced capabilities.
7. Post-mortem & monitoring
   • Document how the incident occurred and steps taken.
   • Set up continuous scanning and appropriate WAF rules to prevent recurrence.

If you require professional containment or cleanup assistance, engage a reputable incident response provider experienced with WordPress environments.

Example WAF rules and scanner checks

Below are illustrative rules you can apply in a WAF (mod_security or nginx with Lua) or via your custom rule engine. Test on staging before production.

ModSecurity (example rule blocking scripts in specific Funnel Builder POST fields):

# Block script tags or javascript: in POST bodies for Funnel Builder endpoints
SecRule REQUEST_URI "@pm /wp-admin/admin.php /wp-json/funnelkit /funnel-builder" "phase:2,chain,deny,log,msg:'Block XSS payloads targeting FunnelBuilder',id:1001001"
  SecRule ARGS_NAMES|ARGS|REQUEST_BODY "@rx (<script|javascript:|onerror=|onload=|eval\(|atob\(|unescape\()" "t:none,t:urlDecode,t:lowercase"

NGINX (using ngx_lua to inspect POST body):

location /wp-admin/ {
  access_by_lua_block {
    ngx.req.read_body()
    local body = ngx.req.get_body_data()
    if body and body:lower():find("<script") then
      ngx.log(ngx.ERR, "Blocked request containing <script>")
      return ngx.exit(403)
    end
  }
  proxy_pass http://backend;
}

WP-CLI search to find suspicious entries in content:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

Regex to find suspicious encoded JS (use carefully):

/(?:(?:<script\b[^>]*>.*?</script>)|(?: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 "<script|javascript:|onerror=" wp-content/uploads || true

• 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