These seven CVEs cover several failure mechanisms in agent tooling: unsafe configuration changes, path handling, command injection and exposed local development services. Their severity scores and affected versions come from the linked advisories; different scoring authorities sometimes disagree. Fixes must address each mechanism, rather than assuming that a single authorization layer resolves them all.
The useful common question is where untrusted data acquires authority. In some cases a model helps cross that boundary. In others, vulnerable client or server code is sufficient and no model decision is required.
The config write that becomes RCE
The cleanest version writes a file the tool applies without confirmation. In CVE-2025-54135 (Cursor; NVD 9.8, GitHub's advisory 8.5 High), an injection gets the agent to write a fresh .cursor/mcp.json; creating that file needs no approval, and the newly declared MCP server runs. CVE-2025-54136 (Cursor, reported by Check Point as MCPoison; NVD 8.8, vendor advisory 7.2) is the persistent cousin: trust was bound only to a config key's name, so swapping what sits behind that name gives silent, durable execution on every repo open.
CVE-2025-53773 (GitHub Copilot and Visual Studio, CVSS 7.8) is the same move aimed at a different file: the injection writes .vscode/settings.json with chat.tools.autoApprove: true, which bypassed the affected tool-approval checks. It was shown to be wormable, because an agent that can turn off its own approvals can propagate.
Every one of these is a privilege the tool granted a file, and a file the agent could be talked into writing. The approval that was supposed to gate the action was gated on the wrong thing.
The parameter that escaped its box
The second variant does not even need a config. It abuses a tool argument the model controls. CVE-2026-50548 (Cursor; NVD 9.8, GitHub's advisory 9.3 on CVSS 4.0) needs, in the advisory's words, no user interaction beyond a benign prompt: the working_directory on a terminal tool is controlled by the model, so an injection points it outside the workspace and writes where it should not, reaching execution. Its companion CVE-2026-50549 (NVD 9.8, advisory 9.3) escapes the same sandbox through a symlink when path canonicalization fails. The lesson is that "the tool is sandboxed" is only true for the parameters the sandbox actually constrains, so tests need to include values outside the intended scope.
The endpoint the client trusted
The third variant flips direction: a malicious server attacks the client. In CVE-2025-6514 (mcp-remote, CVSS 9.6, found by JFrog), a crafted authorization_endpoint from a malicious MCP server becomes an OS command on the client that connected to it, on a package with millions of weekly downloads. CVE-2025-49596 (Anthropic MCP Inspector, CVSS 9.4, found by Oligo) is the version that runs on a developer's machine: no authentication between the Inspector client and its proxy means a page in the developer's browser can reach the local Inspector and execute commands. This is a local-service access problem, distinct from the malicious-server command injection in mcp-remote.
Update, September 3, 2026: the original text described mcp-remote as having hundreds of thousands of weekly downloads. npm reported 2,991,887 downloads for the week of August 23 to 29, 2026.
Why does patching not end the pattern?
A patch fixes a documented vulnerability in affected versions. Similar mistakes can exist elsewhere, so review configuration loading, path canonicalization, shell invocation and local service exposure separately. Recurrence across tools motivates broader testing; it does not mean that patches cannot remove a class of bug.
The defense literature provides additional tests for prompt injection, but those benchmark results do not explain every CVE in this list. A command-injection flaw in a client requires safe command construction; an exposed local service requires appropriate access controls.
What actually closes it?
Match the control to the exploit mechanism. For the cases above, review these boundaries after applying the vendor fixes:
- Config changes are privileged actions, not free writes. Writing an
mcp.jsonor changingautoApprovecan enable later code execution or remove an approval step. Treat these changes as security-sensitive configuration. All three config write CVEs fall under this. - Tool parameters are inputs to authorize, not just to pass. A model controlled
working_directorygets checked against an allowed scope before the call, which is what CVE-2026-50548 needed. - Trust across a boundary is verified, not assumed. A client does not turn an endpoint the server supplied into a command; mcp-remote requires safe handling of an untrusted authorization endpoint. Inspector separately requires access controls around its local command-launching service. We drew that map in what an MCP server actually exposes.
- Keep the evidence. When a config does change or a parameter does go out of range, a protected record helps reconstruct the change, covered in agent work needs evidence, not trust.
What this means for defenders
Maintain a patch inventory and reproduce the relevant vendor checks. Restrict agent modification of security configuration, constrain paths after canonicalization, avoid shell interpretation of untrusted values and protect local development endpoints. Keep evidence of the versions and controls tested.
Oktsec Control applies policy to supported tool calls routed through configured enforcement points and records signed evidence of the decision. Calls that bypass those points still need controls at the application, host or network boundary.