OpenClaw MCP configuration missing owner authorization: authorized non-owner senders can save a command that runs on the host

Who is affected

No source says which version introduced the flaw. OSV starts the range at “0”, meaning every version before 2026.7.1 is treated as affected.

On the exact range: the vendor advisory and the CVE record say “below 2026.7.1” in semver terms. npm also has 2026.7.1-1 and 2026.7.1-2, published after the 2026.7.1 stable release, plus 2026.6.33 to 2026.6.35. By semver all of these are below 2026.7.1, so they fall inside the vendor’s affected range, and the vendor doesn’t say whether they contain the fix. We checked the git history on GitHub: v2026.7.1-1 and v2026.7.1-2 come after ad5a26c and include the fix, while the v2026.6.33 to v2026.6.35 tags don’t include ad5a26c, and their /mcp handler lacks the owner check that ad5a26c added. That is our reading of the git history, not a vendor statement. The safe choice is to install 2026.7.1 stable or a later stable version, and readers on the 2026.6.x line should not go by the release date alone.

The attacker must already be an allowed sender on an external channel (the CVSS vector says PR:L, low privileges needed, and no user interaction), so not just anyone can use it.

Neither the vendor advisory nor the CVE record lists whether the /mcp chat commands are enabled as a condition. However, the official docs at commit 259877d, the parent of fix commit ad5a26c, say /mcp is “Disabled by default — enable with commands.mcp: true”, and the v2026.6.35 /mcp handler checks that switch first and does nothing if it is off; the current docs also keep it off by default. So at least in those pre-fix versions, the owner has to set commands.mcp to true before this flaw can be used. We found no source on whether earlier versions had the same switch or default, so deployments on very old versions should simply upgrade.

How it works

OpenClaw provides /mcp set and /mcp unset chat commands for changing the Gateway’s MCP server configuration. MCP (Model Context Protocol) is a standard that lets AI applications connect to external tools. A “stdio” MCP server is started as a local program, so its configuration is literally the command to run.

Commands that change configuration are supposed to be owner-only. In affected versions, that owner authorization check could be skipped: an authorized sender on an external channel who is not the owner could save a stdio command of their choice into the configuration. Later, when OpenClaw loads its MCP configuration, that command runs with the privileges of the system user running OpenClaw. The vendor says this could affect the host’s confidentiality, integrity and availability.

This is CWE-862 (missing authorization). The vendor advisory also lists CWE-78 (OS command injection); the CVE record lists only CWE-862.

The flawed approach (conceptual illustration, not OpenClaw’s source code):

function handleMcpSet(sender, serverConfig) {
  // Only checks that the sender is authorized, not that they are the owner
  if (!isAuthorizedSender(sender)) return deny();
  saveMcpConfig(serverConfig); // the stdio command runs the next time config loads
}

The fixed approach:

function handleMcpSet(sender, serverConfig) {
  // MCP commands that change configuration are owner-only
  if (!isOwner(sender)) return deny();
  saveMcpConfig(serverConfig);
}

Timeline

Our analysis: the fixed release came out about two months before the advisory.

Further reading

• Scoring: in the CVE record, the CNA (VulnCheck) gives CVSS 4.0 8.7 and CVSS 3.1 8.8, and the vendor advisory’s CVSS 3.1 score is also 8.8. NVD has marked it “Deferred” and has not published its own score; this page uses CVSS 3.1 8.8 and its vector.
• Exploitation: not in CISA KEV as of 2026-09-28. No source reports exploitation in the wild, and no source says it was exploited before a patch existed, so both are unconfirmed. TheHackerWire says no public exploit code has been confirmed. GitHub’s data puts EPSS at about 0.25% (percentile about 14%).
• Sources disagree on the disclosure date: the vendor advisory and CVE record say 2026-09-11, while TheHackerWire says 2026-09-26, which is actually when the CVE record was published. This page uses 2026-09-11.
• CWE difference: the CVE record lists only CWE-862; the vendor advisory also lists CWE-78.
• Reported by: yetval (per the vendor advisory).