AUTOMATORWP · CVE-2026-104768 · Package
FIX → 6.0.5
The AutomatorWP WordPress plugin, up to and including 6.0.4, does not check that a role assigned by an automation is at or below the privilege of the acting context. An unauthenticated attacker can post a comment that makes an admin approval create a new administrator account tied to an email they control, giving full control of the site.
first public Nov 7, 2026 · 2 sources
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Sites running AutomatorWP up to and including 6.0.4 that have an anonymous automation with the Role option bound to {comment_author}. The exposure requires a site administrator to approve a comment from the attacker. Sites without the plugin or without such an automation are not exposed.
Not affected if fixed-role-option, no-anonymous-automation, plugin-not-installed
Who cares automatorwp, privilege-escalation, wordpress, wordpress-plugins
Upgrade to 6.0.5
Update AutomatorWP to 6.0.5 or later (changelog: 'Security improvements to role assignment across all actions that can modify user roles').
The AutomatorWP – No-Code Workflow Automation, Integration & Webhooks Plugin, now with AI plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 6.0.4. This is due to missing privilege-ceiling validation in the create_user() function within the anonymous-user action (and equally in the Create User and Add/Change Role WordPress-integration actions), which verify only that the submitted role exists via automatorwp_get_editable_roles() without confirming the role falls at or below the acting context's privilege level — allowing attacker-controlled trigger tag data (e.g., a {comment_author} tag bound to the Role option) to supply any role, including administrator, unchallenged. This makes it possible for unauthenticated attackers to create a new administrator-role account tied to an attacker-controlled email address, receiving the generated password via WordPress's new-user notification email and thereby gaining full administrative access to the site. Exploitation requires the site to have an anonymous automation configured with the Role option bound to a dynamic trigger tag such as {comment_author}, and is triggered when a site administrator performs the routine action of approving a comment — an action that provides no in-UI indication that it will mint a new privileged account from the comment author field.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
This page as .md · .json · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.