Aimogen Pro God Mode Flaw: AI Privilege Escalation CVE-2026-15982

CVE-2026-15982 carries a CVSS score of 9.8 and needs no login. The flaw sits in a function called aiomatic_call_google_ai_function, part of Aimogen Pro, the "All-in-One AI Content Writer, Editor, ChatBot & Automation Toolkit" plugin sold on CodeCanyon. Every version up to and including 2.8.4 is affected. The fix landed in 2.8.5, and the issue was disclosed on 13 July 2026.

The mechanism is a missing capability check on that function, and it lets an unauthenticated attacker reach something the plugin calls aimogen_wp_god_mode. That tool clears the plugin's function blacklist. Once the blacklist is gone, the attacker isn't limited to one action. They can drive whatever internal functions the plugin's AI engine is wired to call.

That's the part worth sitting with. Most privilege escalation bugs hand an attacker one specific capability: create a user here, change an option there. This one hands them a dispatcher. The plugin's entire reason for existing is to let a language model invoke internal WordPress functions on a site owner's behalf, and the entry point to that dispatcher had no gate on it.

How the flaw works

Aimogen Pro is built around function calling. That's the same pattern OpenAI, Google, and Anthropic all expose in their APIs: instead of just returning text, a model can request that a specific named function run, with specific arguments, and get the result fed back into the conversation. For a WordPress AI plugin, that means the model can ask the plugin to fetch a post, update an option, or call some other registered PHP function, and the plugin executes it.

aiomatic_call_google_ai_function is the endpoint that carries out those calls when the plugin is routed through Google's AI models. To keep that power in check, a function-calling plugin needs two things at minimum: a capability check on whoever is triggering the call, and a blacklist restricting which internal functions the model is allowed to invoke at all. CVE-2026-15982 breaks the first one. The function runs without verifying the requester has any permission on the site, which means an anonymous HTTP request reaches it the same as a logged-in administrator's would.

From there, the path to full compromise runs through aimogen_wp_god_mode. Based on its name and the advisory's description, this tool exists to clear the plugin's function blacklist, presumably a debug or admin convenience meant to unlock the full function set during development. With no capability check gating the request, an unauthenticated attacker can call it directly, wipe the blacklist, and open up whichever internal functions the plugin's dispatcher was built to reach.

The advisory doesn't spell out a specific post-exploitation chain beyond the capability check being missing, the god-mode tool being reachable, and it clearing blacklists to escalate privileges. That's enough on its own. An unauthenticated request that reaches an unrestricted function dispatcher on a WordPress install is a critical bug regardless of which exact function an attacker chooses to call once the gate is down.

Who is affected

Any site running Aimogen Pro 2.8.4 or earlier is vulnerable. No configuration is required to be exploitable: the endpoint doesn't sit behind a setting a site owner has to enable, and it doesn't depend on which AI provider the plugin is configured to use for content generation. The CVSS 9.8 score reflects that combination directly. No authentication, no user interaction, and a privilege escalation outcome that reaches the highest tier of impact on confidentiality, integrity, and availability.

Update to 2.8.5 or later. That's the entire remediation for the vulnerable code path itself; there's no workaround that keeps 2.8.4 safe while disabling only the broken function, because the missing check sits on the request handler itself, not on a feature toggle a site owner controls from the plugin's settings screen.

The security review questions AI function-calling plugins need

Ordinary WordPress privilege escalation bugs give an attacker one lever: an unprotected update_option call, a broken nonce check on a role change, a REST route that skips current_user_can(). You audit those by tracing what the specific vulnerable function does and what it lets an attacker touch.

AI plugins with function-calling engines change the shape of that question. The plugin's entire job is to expose a general-purpose executor to a model, which means the thing you're auditing isn't "what does this one function do." It's "what can the dispatcher be made to do, and who can reach it." When the entry point to that dispatcher misses a capability check, the attacker doesn't inherit one action. They inherit the model's whole toolset, minus whatever the blacklist was still enforcing, and in this case the blacklist itself turned out to be one tool call away from being erased.

If you're reviewing or building a WordPress plugin that lets a model call internal functions, that reframing points to a specific set of questions, distinct from a standard security audit:

Who can reach the tool dispatcher? Every entry point that lets the model (or a request pretending to be the model) trigger a function call needs a capability check, same as any other privileged action. aiomatic_call_google_ai_function didn't have one. If your plugin has multiple AI provider routes, as Aimogen Pro does, check each one separately. A capability check on the OpenAI path doesn't imply one exists on the Google path.

What's actually on the tool allowlist, and where does it come from? A function-calling engine needs a defined set of internal functions it's willing to expose to the model, not "whatever PHP function the model asks for by name." List that set explicitly and keep it as narrow as the feature requires. An AI writing assistant doesn't need access to user management functions, and a chatbot answering support questions doesn't need access to plugin settings.

Can the allowlist or blacklist be modified at runtime, and by whom? This is the specific design decision that turned CVE-2026-15982 from a bad missing-check bug into a full site takeover path. A "clear the blacklist" tool is a reasonable thing to have during development. Shipping it as a reachable, unauthenticated production endpoint means the plugin built its own kill switch for its own safety mechanism and left the switch exposed.

Is there an audit trail of invoked tools? When a model can trigger internal WordPress functions, knowing which functions actually ran, with what arguments, and on whose behalf, is the difference between catching abuse in hours and finding out from a client's hosting provider weeks later. If the plugin doesn't log tool invocations anywhere a site owner can review them, that's a gap worth flagging even outside a specific CVE.

This isn't an isolated pattern. In August 2026, AI Copilot - Content Generator disclosed CVE-2026-14526, CVSS 9.8, where unauthenticated attackers could save and execute a malicious workflow containing a wp_create_user action node with role=administrator. Different plugin, different specific bug, same underlying shape: a function-execution surface reachable without proper authorization. We cover that one in more depth separately.

The recurrence across two unrelated AI automation plugins in the same few months says the pattern isn't a fluke in one codebase. It's a category of mistake that shows up wherever a plugin wires a model up to real WordPress functions and treats the wiring as an implementation detail instead of a security boundary. Our WordPress AI plugins security checklist covers the baseline questions to ask before trusting any plugin with this kind of access, and the broader risk profile of pairing AI generation with plugin code is worth reading in AI-generated plugin security risks.

Tool-calling isn't the only place this class of plugin exposes new surface, either. Our look at AI Engine's MCP bearer token flaw covers a related but distinct failure mode: authentication material for a different kind of AI integration point, exposed in a way that let it be read out. And on the input side, prompt injection in WordPress AI chatbot plugins covers what happens when the thing feeding instructions to the model isn't trusted either. Function-calling security, credential handling, and input trust are three separate review questions for this plugin category, and a clean answer on one doesn't say anything about the other two.

What to do now

If you run Aimogen Pro, check the plugin's version in your WordPress admin under Plugins. Anything at 2.8.4 or earlier is vulnerable; update to 2.8.5 or later immediately. This isn't a bug you can mitigate through configuration. The fix has to be the patched code.

If you were running an affected version before you updated, there's no documented indicator of compromise specific to this CVE beyond what a full site compromise would leave. Check for administrator accounts you don't recognize, created around or after 13 July 2026. Review the plugin's own settings for a function blacklist or allowlist configuration, if it exposes one in the admin UI, and confirm it reflects what you originally configured rather than an empty list.

Check your site's access logs for POST requests to admin-ajax.php or REST routes referencing aimogen_wp_god_mode or aiomatic_call_google_ai_function around that window. Their presence from an IP you don't recognize, without a corresponding logged-in session, is the clearest sign the endpoint was probed or hit. A WordPress vulnerability scanner that checks plugin versions against known CVEs, which is what WP Vanguard does, will flag an install running 2.8.4 or earlier before it becomes an incident to investigate after the fact.

References

• Wordfence Threat Intelligence: Aimogen Pro - All-in-One AI Content Writer, Editor, ChatBot & Automation Toolkit
• NVD: CVE-2026-15982
• OffSeq Threat Radar: CVE-2026-15982