A privilege escalation in the AutomatorWP WordPress plugin ends with an unauthenticated visitor holding a working administrator account on the site. The gap sits in how the plugin decides which roles an anonymous automation is allowed to hand out.
What happened
Wordfence published CVE-2026-104768 on 6 November 2026 with a CVSS score of 7.5. In versions up to and including 6.0.4, the create_user() function in the anonymous-user action checks only that a submitted role exists, not that it sits at or below the acting context's privilege level. The Create User and Add/Change Role WordPress-integration actions carry the same gap.
The practical path runs through a bound tag. Where a site has an anonymous automation with the Role option tied to a dynamic tag such as {comment_author}, a visitor can point that tag at administrator. The account is created when an administrator approves the comment, and the new user gets the generated password by email. Nothing on the approval screen signals that a privileged account is about to appear. Wordfence lists 6.0.5 as the fixed release.
Who is affected
- WordPress sites running AutomatorWP 6.0.4 or earlier.
- Sites with an anonymous automation configured where the Role option is bound to a dynamic trigger tag rather than a fixed role.
- Installations that only run logged-in automations, or that never fed user input into a role field, are not reachable by this path.
What to do now
Update AutomatorWP to 6.0.5, then audit every automation that creates or changes a user.
- In WP Admin, open Plugins, read the version under AutomatorWP and update anything at 6.0.4 or lower.
- Open each automation with a Create User or Add/Change Role action and replace any dynamic tag in the Role field with a fixed low-privilege role.
- Disable automations that create users from anonymous triggers if you cannot pin the role to a fixed value.
- Review wp_users for administrator accounts you do not recognise, and compare their creation dates with your comment approval history.
What this means for South African businesses
Automation plugins get installed to save admin time and then forgotten, which is exactly how a role field ends up wired to whatever a visitor types into a comment form. The update is trivial; the audit is the part that counts, because an administrator account created this way survives the patch and can put itself back. For an SME site that is the difference between a plugin advisory and a full takeover with an attacker's plugin installed, so check the user list even when the version already looks current.
Source: Wordfence Intelligence vulnerability record for AutomatorWP.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.