Urgent: Privilege Escalation in Automation By Autonami (FunnelKit) — What WordPress Site Owners Must Do Now

Summary

A privilege escalation vulnerability affecting Automation By Autonami (also distributed as FunnelKit Automations) versions ≤ 3.6.3 has been publicly disclosed (CVE-2025-7654). The issue allows an authenticated user with the Contributor role to escalate their privileges to higher levels (potentially Administrator) under certain conditions. The vendor released a patch in version 3.6.4. This post explains what the vulnerability means, who is impacted, how to quickly assess exposure, immediate steps to mitigate and remediate, how to investigate potential compromises, and practical defensive measures you can apply immediately.

This guidance is written from the perspective of an experienced Hong Kong-based security practitioner and is intended for site owners, developers, agencies and security teams responsible for WordPress sites.

What happened (simple explanation)

• Vulnerable software: Automation By Autonami / FunnelKit Automations plugin
• Affected versions: ≤ 3.6.3
• Fixed in: 3.6.4
• CVE: CVE-2025-7654
• Attack prerequisite: an account with the Contributor role (authenticated)
• Impact: privilege escalation (Contributor → higher privileges, potentially Administrator)
• Severity / CVSS: High / CVSS 8.8 (as reported)

In short: a low-privileged account (Contributor) can perform actions that should be restricted to higher-privileged users. Once an attacker obtains Administrator-level access, they can take full control of the site: create admin users, install backdoors, alter content, inject malicious code, and steal data.

Why this is serious

Contributor accounts are common on multi-author blogs, agencies and larger WordPress installs. They can create and edit posts but cannot publish or modify plugin settings. This vulnerability breaks the “least privilege” model by allowing Contributor accounts to perform privileged actions that can lead to full site takeover.

Threat actors frequently scan for vulnerable plugins. Privilege-escalation exploits are especially valuable because they convert seemingly harmless accounts into powerful footholds. The time between disclosure and active exploitation can be short — hours to days, depending on profile and exposure.

Technical overview (what likely went wrong)

I will not publish exploit code, but here is a high-level explanation for defenders and developers:

• The plugin exposed administrative functionality through AJAX/REST/admin-post endpoints or other action handlers.
• Those endpoints relied on insufficient capability checks (e.g., checking for a generic capability or relying only on authentication) or they missed nonce verification for state-changing requests.
• A Contributor account could call the endpoint(s) with crafted parameters and trigger actions normally restricted to administrators or editors.
• Possible outcomes include modification of user roles/capabilities, creation of new admin users, or changes to plugin/site settings that lead to escalated control.

Common root causes:

• Missing or incorrect use of current_user_can() checks.
• Direct access to critical functionality that assumes only administrators can reach it.
• Lack of nonces or improper nonce verification for AJAX/REST requests.
• Predictable or unprotected action slugs that allowed lower-privileged users to invoke sensitive code paths.

If you run the plugin, assume your site is exposed until you’ve confirmed otherwise and taken corrective actions.

Immediate actions (what to do in the next 60 minutes)

1. Check your plugin version
   Dashboard: Plugins → Installed Plugins → Automation By Autonami / FunnelKit Automations
   WP-CLI:

   wp plugin get wp-marketing-automations --field=version

   If version is 3.6.4 or later, the official fix is present. Continue with detection steps below.

2. If you cannot patch immediately, temporarily deactivate the plugin
   Dashboard: Plugins → Deactivate
   WP-CLI:

   wp plugin deactivate wp-marketing-automations

3. If deactivation is not acceptable, harden access now
   • Remove or suspend Contributor accounts you don’t fully trust.
   • Require strong passwords and apply two-factor authentication for higher privileges where possible.
   • Limit access to wp-admin by IP (host-level rules) where feasible.
   • Restrict access to plugin admin pages via .htaccess or server rules if you can.
4. Apply the official update
   Update to 3.6.4 immediately when possible.
   WP-CLI:

   wp plugin update wp-marketing-automations

5. If you operate a managed WAF or security stack
   Ensure any virtual patches, rules or blocking logic you control are applied for the plugin endpoints until the update is deployed.

How to detect if you were attacked

Check for these indicators of compromise. Even if you update, attackers active before the patch might have already acted.

Essential checks

• New administrator users
  Dashboard: Users → All Users
  WP-CLI:

  wp user list --role=administrator --format=table

• Unexpected role changes
  Search usermeta for capability changes:

  wp db query "SELECT user_id, meta_key FROM wp_usermeta WHERE meta_key LIKE '%capabilities%';"

  Inspect suspect accounts’ capabilities (wp_usermeta ‘wp_capabilities’).

• Unauthorized changes to plugin settings or site options
  Look for recently modified timestamps in plugin-related database options (wp_options). Check the plugin’s settings page for suspicious entries or webhooks.
• Recent logins from unusual IPs
  Inspect server access logs and wp-login.php requests. If you have logging/audit plugins, export recent login events.
• Files modified recently
  Use file integrity monitoring or manually check:

  find /path/to/wordpress -type f -mtime -7

  (Adjust -7 to the timeframe you care about.)

• Scheduled tasks (cron) added by attackers
  Dashboard → Tools → Scheduled Actions (if using Action Scheduler or WP-Crontrol)
  WP-CLI:

  wp cron event list --fields=hook,next_run

• Strange outbound connections
  Webserver logs showing connections to unexpected IPs/domains. Host provider network monitoring can help.

If you find signs of compromise, follow the incident response checklist below.

If you’re compromised — incident response checklist

1. Isolate
   Take the site offline (maintenance page) or restrict admin access by IP if possible. Create a forensic backup (files + DB) and preserve logs before making changes.
2. Identify the scope
   Determine which accounts were created/modified, what files changed, and which scheduled tasks are new.
3. Remove persistence
   Delete malicious admin accounts. Remove suspicious plugin/theme files, cron jobs, and custom code injections. Revoke API keys and regenerate any exposed credentials.
4. Clean and restore
   If you have a clean backup prior to compromise, restore it. Otherwise, clean the infection with a known-good baseline or rebuild from trusted sources.
5. Rotate credentials
   Reset passwords for all admin users, FTP/SFTP, database and hosting control panel accounts. Rotate any API or third-party credentials.
6. Hardening and monitoring
   Apply the plugin update (3.6.4). Re-enable any protective measures you have (WAF, virtual patching). Enable file integrity monitoring and nightly backups. Add 2FA for all admin-level accounts and audit user privileges.
7. Post-mortem
   Document the incident: entry point, impact, remediation steps, and timeline. Share lessons learned and update your incident response playbooks.

If you are not comfortable performing these steps, engage a professional incident response service or your host for assistance.

How layered defenses help (practical, vendor-neutral)

Privilege-escalation bugs are dangerous because they can abuse legitimate accounts. Combine multiple defensive controls to reduce risk quickly:

• Virtual patching: Apply rules at the edge (WAF or server) to block known exploit patterns aimed at plugin endpoints.
• Access control: Restrict access to admin/AJAX/REST endpoints by IP where possible, and throttle suspicious authenticated requests.
• Monitoring: Watch for authenticated misuse — e.g., Contributor accounts calling admin endpoints.
• File and DB integrity checks: Detect unexpected modifications early.
• Alerting: Configure alerts for new admin creation, role changes, and unusual login activity.

These measures buy time between disclosure and full remediation. Implement targeted rules to avoid disrupting legitimate workflows.

Recommended WAF mitigations (high level)

• Block or rate-limit suspicious admin/AJAX requests that manipulate user roles or plugin settings.
• Block HTTP POST requests to plugin-specific admin action hooks unless originating from trusted admin IPs.
• Deny access to known plugin endpoints for logged-in users with Contributor role unless properly validated with nonces and capability checks.
• Inspect POST payloads for fields used to change roles and block attempts from Contributor accounts when suspicious.

Test rules in monitoring mode first where possible to avoid blocking legitimate behaviour.

Long-term hardening for WordPress sites

• Principle of least privilege: Re-evaluate roles and give users the minimal capabilities needed. Consider custom roles for specific workflows.
• Role audits: Conduct quarterly audits of user roles and accounts to catch stale users.
• Strong authentication: Enforce strong passwords and two-factor authentication for administrative accounts.
• Plugin hygiene: Install plugins from reputable authors, minimise plugin count, and remove unused plugins.
• Automated updates: Enable automatic updates for plugins that provide critical security fixes if you can test and rollback.
• File integrity & backups: Maintain versioned off-site backups and monitor filesystem changes; keep backups offline where practical.
• Logging & alerting: Capture audit logs for logins, user changes, plugin installs/updates, and file changes; integrate alerts with your ops workflow.
• Secure development practices (for plugin/theme authors): Validate capabilities with current_user_can(), sanitize inputs, use nonces for state changes, and log admin actions.

Developer guidance (for plugin authors and integrators)

If you maintain plugins or custom code, follow these rules:

• Always validate user capabilities with current_user_can() for any action that modifies data, users, or options.
• Use wp_verify_nonce() for POST/GET requests where an authenticated user initiates a state change.
• For AJAX and REST endpoints, validate both capability and nonce and ensure request methods are limited (e.g., only POST for writes).
• Avoid weak changeable slugs that can be invoked from the front-end by lower roles.
• Treat any authenticated request as potentially hostile: sanitize, validate, and fail safely.
• Implement robust logging for admin actions (role changes, user creation, plugin updates) so audits are possible.

Short code checklist:

• Do not rely on is_user_logged_in() alone.
• Use nonces (wp_create_nonce / wp_verify_nonce).
• Use current_user_can(‘manage_options’) or a more specific capability as needed.
• Sanitize all user-supplied data before use.

How to verify your site after remediation

After updating to 3.6.4 and performing cleaning/hardening, verify:

• No unexpected admin users exist.
• No unexpected scheduled tasks remain.
• File timestamps align with expected updates.
• No suspicious outgoing connections in logs.
• No malicious entries in wp_options or plugin tables.
• Run a full malware scan and a file-diff against a clean copy of WordPress core + active plugins/themes.

Frequently asked questions (FAQ)

Q: I have only Contributor accounts. Am I safe?

No — Contributors are the exact risk profile here. If you run the vulnerable plugin, a Contributor account could be used to escalate privileges.

Q: I updated to 3.6.4 — do I still need to investigate?

Yes. Updating stops new exploitation attempts but does not retroactively remove changes an attacker may have made before the patch. Perform the detection checklist.

Q: Can I rely on backups instead of cleaning?

Backups are valuable. If you have a clean pre-compromise backup, restoring is often the fastest recovery path. Ensure the backup is clean and rotate credentials after restore.

Q: I cannot update the plugin because my site uses custom plugin extensions — what should I do?

Apply virtual patching and restrict access to plugin endpoints. Audit your custom extensions for unsafe calls or assumptions about user capabilities. If possible, test the updated plugin in staging with your custom extensions and deploy when safe.

Timeline & attribution

• Published: 18 August 2025 (public disclosure)
• Credited researcher: wesley (wcraft)
• CVE assigned: CVE-2025-7654
• Fixed version released: 3.6.4

If you maintain a site that uses this plugin, treat this as urgent.

Practical checklist — quick reference (copy/paste)

Closing thoughts from a Hong Kong security expert

Privilege escalation vulnerabilities convert common, low-privileged accounts into keys for full compromise. The vendor has released a patch (3.6.4) — apply it. Combine a quick update with edge/server-based protections, monitoring and good incident response procedures to reduce risk in the crucial hours after disclosure.

If you are responsible for multiple WordPress installs or run sites for clients, implement automated monitoring, role audits and edge protection so you can mitigate threats as soon as they are discovered, not hours later. Take the immediate steps above, review your logs, and if you find suspicious signs, follow the incident response checklist or engage professional help.

Stay vigilant — a small account can become a major problem quickly.

— Hong Kong Security Expert