- NIST's record for CVE-2026-19807 says ByteCoreStack's MCP Connector plugin, through version 1.2.3, lets a Subscriber-level user become Administrator. It is rated CVSS 8.8.
- The cause is a plugin coding error: a weak own-account check and a blocklist missing the role field. An MCP endpoint made it reachable; AI did not cause it.
- Check whether the plugin runs on your sites, disable it until a fix is confirmed, and review administrator accounts.
Every new entry point into your systems needs its own authorization checks. A WordPress plugin flaw shows what happens when one tool endpoint lets a basic account write to privileged data.
The NIST National Vulnerability Database (NVD) published CVE-2026-19807 on October 1, 2026. The entry concerns a ByteCoreStack plugin that connects WordPress to AI tools. In every version through 1.2.3, an account with Subscriber-level access or above can raise itself to Administrator.
What the plugin does
MCP stands for Model Context Protocol. It is a common way for AI tools to ask another system to perform actions. The plugin offers WordPress actions to AI tools through an MCP endpoint that accepts JSON-RPC, a simple request format. One action, wp_update_user_meta, writes extra data fields attached to a user account.
How the flaw works
Two weak controls combine here. Neither is enough alone.
The first control asks whether the caller may edit a given user. The NVD record says this is the only gate on the write. When a user targets their own account, WordPress core resolves that question to its basic read permission. A Subscriber-level account clears it.
The second control is a blocklist, a list of fields the tool refuses to write. It names just three: the password field, the activation key field and the session token field. Every other field is open to writes. That includes wp_capabilities and wp_user_level. WordPress uses wp_capabilities to store a user's role.
The attack is short. A Subscriber sends one wp_update_user_meta call to the endpoint. The key is wp_capabilities and the value is a role array such as administrator set to true. The target is the sender's own user ID. On the next request, WordPress treats that account as an Administrator.
The severity score comes with a coded breakdown of how the attack works. Read plainly, it says the attacker reaches the plugin over the network and needs no special conditions. The attacker must hold a low-privilege account, and no one else has to take any action. The damage to data confidentiality, integrity and availability is rated high on all three.
What this does and does not show
This is a plugin implementation error. The vendor's code did not enforce the right authorization for a sensitive write. AI and MCP did not cause it. The same mistake could sit in any web endpoint that writes user data.
What MCP did was supply a new, direct route to that write. The publication's view is that every new tool-calling endpoint can give attackers a fresh path to privileged actions. Each endpoint must enforce its own authorization.
The own-account check suits a person editing their own profile. As the only gate on arbitrary field writes, it is far too weak. The blocklist adds a second problem. A list of forbidden fields protects only what its authors thought of, and here it missed the role field. An allowlist of writable fields fails in a more visible way, by refusing legitimate writes.
The limits matter. This is one plugin and one record. The record does not say the flaw is being exploited or how many sites run the plugin. It lists no fixed version, only the affected range. It also does not describe how the plugin's endpoint authenticates callers.
What to ask your team
Start with inventory. Does any WordPress site we run use the ByteCoreStack MCP Connector plugin, and which version? If so, ask the vendor whether a version later than 1.2.3 exists. Disable the plugin until you know.
Then check exposure. The flaw needs a logged-in account. On most WordPress setups, that means asking whether anyone can register on the site. If so, an attacker may be able to get the Subscriber access this flaw needs. Ask your team how the plugin's endpoint authenticates callers, since the record does not say. Review the administrator list for accounts you do not recognise.
Finally, use a checklist for any AI connector you approve. Which actions does it expose? Does each action check permissions itself? Does it limit writes to an allowlist of fields? Treat these as questions worth asking, not as proof of a wider pattern.
A new endpoint is a new door. Check what each door lets a basic account do.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
