← All insights
Industry newsOct 02, 2026Source: AWS

AWS MCP server CVE turns diff scans into a workspace-boundary test

An MCP security scan checks repository diffs while a boundary control stops file writes outside the approved workspace

AWS published security bulletin 2026-121-AWS on 1 October 2026 for CVE-2026-97662, an argument injection issue in security-agent-mcp-server. The open-source Model Context Protocol server is published in the AWS Labs MCP repository and is used by AI assistants to run local security scans, including diff scans, over source code.

The bulletin says a crafted reference value supplied to the diff scan can be treated as a command-line option rather than a revision. In the affected versions, that can let a context-dependent actor create, overwrite or truncate files on the host outside the intended workspace directory. AWS says versions from 0.1.1 through versions before 0.2.0 are affected, and that upgrading to 0.2.0 is the fix.

What AWS disclosed

The affected component is not a general cloud service. It is a local MCP server that gives AI assistants a security-scanning capability over code. That distinction matters. MCP servers often sit close to source files, terminals, credentials, repositories and developer machines. A bug in an agent-facing local tool can therefore turn an otherwise bounded code-review task into a host-file integrity problem.

AWS states that there is no workaround other than upgrading. Until teams upgrade, the bulletin recommends running diff scans only against trusted repositories and running the server as a least-privileged user in an isolated environment. Rapid7's vulnerability database independently records the same publication date, affected behavior and upgrade guidance, and lists CVSS v4.0 base score 6.9 and CVSS v3.1 base score 8.2.

Why this matters

AI coding and security assistants are most useful when they can inspect real changes, reason over diffs and call tools. That usefulness is also the risk. A repository reference, branch name, comparison target or other scan input may look like ordinary developer context, but it can cross into command execution, file writes or host mutation if the MCP server passes it to lower-level tooling without enough delimiter control.

For security teams, the lesson is broader than this one package. MCP servers are software supply-chain assets. They need inventory, version tracking, owner assignment, exposure analysis and patch evidence. They also need task boundaries: which assistant can call the server, which repositories are trusted, which paths are writable, which environment variables are reachable and whether the server runs with privileges that exceed the task.

Maetra's prompt injection controls for AI agents cover the same boundary problem from the agent side. Tool input is not just text. Once a model can cause a tool call, untrusted context can become an action envelope.

What teams should verify now

First, find every instance of AWS security-agent-mcp-server, including developer machines, CI helpers, internal agent stacks and experimental MCP registries. Search for package versions, generated lockfiles, Docker images and local wrappers. Record the owner and the agent or assistant that can call each instance.

Second, upgrade affected installations to version 0.2.0 or later. Keep evidence of the before version, package source, change approval, install output and after version. If a fork or derivative copied the diff-scan code, compare it against the fixed release rather than assuming the fork is safe.

Third, reduce blast radius. Run MCP servers as least-privileged users, isolate them from sensitive host paths, avoid scanning untrusted repositories until patched and log which assistant invoked which operation with which repository reference. That evidence is useful both for assurance and for incident review.

What remains uncertain

The AWS bulletin does not claim exploitation in the wild. It does not say that customer systems were compromised, and it does not prove remote compromise from a default deployment. The risk depends on whether untrusted or attacker-influenced reference values can reach the diff scan and what the local server can write.

The practical conclusion is therefore specific: affected versions should be patched, and agent-facing local MCP tools should be treated as privileged execution surfaces even when their purpose is defensive scanning.

Maetra analysis

This CVE is a clean example of why agent security is not only model behavior. The model may be well behaved, but the tool boundary can still be wrong. If a crafted input crosses from repository context into command options, a security agent can damage the workspace it was meant to inspect.

That changes governance requirements for developer tooling. Teams need an inventory of MCP servers, not just an inventory of models. They need policy over which agents can invoke local tools. They need runtime checks on tool arguments. They need evidence that patches landed and that isolated execution remains isolated.

The control question is simple to state and hard to fake: can the organization show that an agent-assisted scan stayed inside the workspace it was authorized to inspect? CVE-2026-97662 is a reminder to make that answer explicit before the next local agent tool ships.

Sources

Primary source: AWS security bulletin 2026-121-AWS.

Corroboration: Rapid7 CVE-2026-97662 entry.

MCP securityAI agent securityAWSCVE-2026-97662