AWS Patched an AI Security Agent That Could Write Outside Its Workspace. Are You Affected?

October 9, 2026

AWS fixed a high-severity MCP flaw that could write outside its workspace. Check the affected versions, limits, and exact upgrade action.

AWS Patched an AI Security Agent That Could Write Outside Its Workspace. Are You Affected?

Short answer: If you run awslabs.security-agent-mcp-server version 0.1.1 or newer but older than 0.2.0, you are in the affected range for CVE-2026-97662. AWS says a crafted reference used during a differential code scan could be interpreted as a command-line option, allowing the MCP server to create, overwrite, or truncate files outside its intended workspace. Upgrade to 0.2.0 or later; AWS says there is no complete workaround.

This is not a reported breach of the managed AWS Security Agent service, and it is not evidence that every AWS account or every MCP client is vulnerable. It is a high-severity flaw in one open-source, locally run MCP server. Exploitation requires the vulnerable server to perform the relevant diff-scan operation with attacker-influenced input. No reviewed source reports exploitation in the wild.

Research cutoff: October 9, 2026.

The Answer in One Minute

AWS published security bulletin 2026-121-AWS on October 1 for awslabs.security-agent-mcp-server, an open-source Model Context Protocol server that lets compatible AI assistants request AWS Security Agent operations.

The affected versions are:

The vulnerable diff-scan path passed a caller-influenced revision reference to Git in a way that could make the reference behave like a command-line option. The GitHub security advisory says this could bypass the server's workspace-confinement control and write wherever the server process had permission.

That is the important lesson: a directory boundary can be correct and still fail if supposedly inert data later becomes a command-line argument. The model is not the security boundary. The MCP server, subprocess interface, operating-system account, filesystem permissions, and isolation layer all have to enforce the boundary too.

What Is Confirmed

The flaw affects a specific AWS Labs MCP package

The vulnerable component is the Python package named awslabs.security-agent-mcp-server. It lives in AWS Labs' public MCP repository and connects MCP-compatible clients to AWS Security Agent functions such as code scanning and penetration-testing workflows.

This distinction matters. The advisory does not say that Amazon Bedrock, every AWS AI service, every MCP implementation, or the managed AWS Security Agent service itself was compromised. It names one open-source bridge that users install and run in their own environment.

The package's current PyPI page describes local uvx and Docker launch patterns. In both cases, the server runs with the permissions and AWS credentials provided to that process. A file-write flaw therefore inherits the reach of that runtime identity.

A diff reference could cross the workspace boundary

A differential scan normally compares one source revision with another. A branch name, tag, or commit reference should be data. In the vulnerable implementation, the advisory says a crafted reference could instead be treated as an option by the underlying Git invocation.

That changes the security question from “is this path inside the workspace?” to “what will the next program do with this string?”

According to GitHub's advisory, an actor able to influence the reference—for example through content in a scanned repository—could cause the process to:

AWS's public bulletin describes arbitrary host files within the server process's write permissions. The GitHub advisory gives shell startup files, SSH authorized_keys, and credential files as examples of sensitive targets.

The write could be quiet

The GitHub advisory says the affected operation could report that no diff was found. In other words, the scan's visible result might not advertise that an out-of-workspace write happened.

That does not make the attack invisible to every security control. Filesystem auditing, endpoint monitoring, container restrictions, immutable paths, or a changed-file review could still detect or prevent effects. It does mean an operator should not treat a normal-looking “no diff” result as proof that the subprocess performed no other action.

File integrity and availability are the direct impacts

GitHub rates the advisory High, with a CVSS v3.1 base score of 8.2. Its vector assigns high integrity and availability impact but no direct confidentiality impact.

That matches the core primitive described by the advisory: writing, overwriting, or truncating files. It is not a direct “read every secret” vulnerability.

The advisory also says partially attacker-influenced file content could create a path to code execution. For example, modifying a file that another program later executes or trusts can turn a write primitive into a second-stage compromise. That is more serious than a harmless stray file, but it should not be inflated into an unauthenticated remote-shell bug. The public record describes a context-dependent local tool path with required user interaction.

Version 0.2.0 contains the fix

AWS says the issue was addressed in version 0.2.0 and recommends upgrading to the latest version. At the cutoff, PyPI listed version 0.2.1 as current.

Version 0.2.0 was published before the October 1 disclosure, consistent with a coordinated disclosure process. AWS also advises maintainers of forks or derivative implementations to incorporate the fix rather than assuming an upstream version number protects custom code.

There is no complete workaround short of upgrading

AWS's wording is direct: there is no workaround other than upgrading.

Until an upgrade is complete, its risk-reduction guidance is to:

Those measures can reduce impact. They do not repair the argument-handling flaw.

Are You Affected?

You are in the advisory's affected scope if all of these are true:

  1. You installed or vendored awslabs.security-agent-mcp-server.
  2. The effective running version is at least 0.1.1 and below 0.2.0.
  3. Your workflow can invoke its differential scan operation.
  4. An untrusted actor can influence repository content or another value that reaches the affected reference.

You are not automatically affected merely because you use AWS, an AI coding assistant, MCP generally, or another package from the AWS Labs MCP repository.

Check the version that actually runs

Do not rely only on a configuration file that says latest. Check the process, lockfile, container image, or environment that launches the server.

Depending on how it was installed, useful checks can include:

python -m pip show awslabs.security-agent-mcp-server

or:

uv tool list

For a containerized deployment, inspect the image digest and package version inside the image rather than assuming the tag was refreshed. A long-running container does not change just because PyPI has a newer release.

If a wrapper launches uvx ...@latest, confirm that the resolved environment was recreated after the fixed release. Cached tool environments, pinned lockfiles, internal mirrors, forks, and golden images can keep an older package alive.

Treat forks as code, not as version labels

A fork may report its own version while retaining the vulnerable call pattern. AWS explicitly tells derivative-code maintainers to incorporate the fix. If your organization copied the server, review the relevant Git invocation and its tests rather than mapping the fork's version string to the upstream table.

Look for reach, not just presence

Finding version 0.1.5 on a disk is important, but the practical exposure depends on how that copy is used:

The answer determines urgency and incident-review scope. It does not change the patch recommendation.

What Should You Do Now?

1. Upgrade to 0.2.0 or later

Use your normal Python, uv, container, or internal artifact workflow to move the package out of the affected range. Prefer the latest approved version—in this case 0.2.1 was current at the cutoff—unless your organization has a validated reason to pin 0.2.0.

After updating, restart the actual MCP server process and verify the runtime version. Updating a lockfile without redeploying the process does not remove the vulnerable instance.

2. Inventory every copy

Check developer workstations, CI runners, shared agent hosts, containers, internal package caches, templates, and forks. MCP tools often arrive through editor or assistant configuration rather than a centrally visible application deployment.

Search for the package name as well as server-registration names. A configuration can refer to a wrapper script, Docker image, or uvx command without containing a conventional Python requirements file.

3. Review the writable blast radius

Identify the user account that runs the server and enumerate the sensitive locations it can modify. Pay special attention to:

This is also a good reason to stop running agent tools with administrator privileges or a broad personal account.

4. Investigate suspicious scans without assuming compromise

If an affected version scanned untrusted repositories, preserve relevant logs and inspect changes around scan times. Look at command traces where available, filesystem audit events, recently changed sensitive files, unexpected keys, new startup commands, and unusual child processes.

The advisory does not prove that your system was attacked. An affected version plus untrusted input creates a reason to investigate, not a reason to announce a breach without evidence.

5. Keep untrusted repositories out of privileged agent environments

A repository is not just source code. It can contain filenames, refs, configuration, issue text, build files, hooks, generated metadata, and content that an agent may interpret or pass to tools.

Use disposable, least-privileged environments for first contact with code you do not control. Mount only the files the task needs. Make sensitive host paths read-only or unavailable. Separate cloud credentials from scan inputs, and give the runtime only the API permissions required for the current operation.

6. Test the boundary below the model

Prompt instructions such as “stay inside the workspace” can help model behavior, but they do not repair unsafe subprocess construction. Security tests should exercise:

The test passes only if the tool layer rejects or safely delimits hostile values and the operating system prevents writes beyond the intended scope.

Why Workspace Confinement Was Not Enough

“Workspace-only” sounds like a filesystem promise: the tool validates a directory and refuses paths outside it. CVE-2026-97662 demonstrates a different route across that boundary.

The server did not need to accept an obvious path such as ../../sensitive-file. The next component—Git—could interpret a reference as an option. Once a string crosses into another parser, the original application's validation assumptions may no longer hold.

This pattern is older than AI. Command-line injection, option injection, shell metacharacters, archive extraction, symlink traversal, and confused-deputy bugs all predate MCP. Agents make the pattern more important because they connect probabilistic decisions and untrusted content to tools with deterministic authority.

A sound agent architecture therefore uses several independent boundaries:

No single prompt or directory check substitutes for those controls.

What Is Still Unclear

Whether anyone exploited the flaw in the wild

AWS and GitHub do not report observed exploitation. The public advisory also does not provide affected-install counts, telemetry, or incident-response findings.

Absence of a public exploitation report is not proof that no attempt occurred. It does mean claims about a known AWS customer breach, stolen credentials, or widespread compromise would go beyond the available evidence.

How much attacker control is practical in each deployment

The GitHub advisory says an actor can influence the reference, for example through scanned repository content. The exact route from repository content to a reference depends on the surrounding client, prompt, tool call, and workflow.

Some deployments may let a user choose the reference directly. Others may require the model to derive it from repository content. Approval settings, client behavior, and input validation outside the MCP server can change exploitability without changing the underlying vulnerable version.

Whether a particular host reached code execution

The advisory says partially influenced writes can lead to code execution. That is a credible impact path, not evidence that code executed on every affected host.

Whether a write becomes execution depends on the target file, generated content, user account, later programs, and host configuration. Incident responders should distinguish the vulnerable capability, evidence of a file modification, and evidence that modified content was executed.

How many forks still carry the bug

The upstream package is fixed. Public advisories cannot inventory every internal copy, fork, vendored snapshot, or derivative server. Organizations that copied the implementation need to review their own code.

Does This Mean MCP Is Unsafe?

No single CVE proves an entire protocol is unsafe. MCP standardizes how models and clients discover and invoke tools; it does not automatically make every tool implementation secure.

The useful conclusion is narrower: an MCP server is executable integration code. Its name, vendor, tool descriptions, and workspace setting do not replace package inventory, version management, input validation, least privilege, isolation, and monitoring.

Treat MCP servers the way you would treat command-line plugins, IDE extensions, CI actions, or automation services. Review what they can access, how they parse arguments, which credentials they receive, and how updates are applied.

Where OpenVeil Fits—and Where It Does Not

This incident is most relevant when deciding how much authority an AI task actually needs.

If an adult wants help drafting, analyzing, brainstorming, or discussing sensitive text without giving an agent repository, shell, Git, or MCP authority, OpenVeil offers a narrower hosted conversational workspace. OpenVeil's normal reopenable chat history is stored in the browser, and documented product content is not used to train foundation models.

That narrower scope reduces the number of tool boundaries involved in a plain chat task. It does not patch CVE-2026-97662, inspect your MCP configuration, secure a developer workstation, detect malicious repositories, or protect data already sent to another product.

OpenVeil is also not fully offline or anonymous. Active requests still require processing by OpenVeil and necessary providers. The right comparison is not “cloud versus perfect privacy.” It is whether the task needs an autonomous tool with host authority at all.

Frequently Asked Questions

Is AWS Security Agent itself compromised?

The advisory names the open-source awslabs.security-agent-mcp-server, not a breach of the managed AWS Security Agent service. The MCP server is a bridge that users run to expose service operations to compatible assistants.

Which versions are vulnerable?

Versions 0.1.1 and newer but older than 0.2.0 are affected. Version 0.2.0 contains the fix. PyPI listed 0.2.1 as current at the October 9 research cutoff.

Is version 0.1.0 affected?

Not by the published range for CVE-2026-97662. That does not mean 0.1.0 is generally safe or supported. Use the latest approved release and review other advisories that may apply to the package.

Can this vulnerability read secrets?

The published CVSS vector assigns no direct confidentiality impact. The core ability is to create, overwrite, or truncate writable files. A resulting second-stage compromise could have broader consequences, but that requires additional conditions and evidence.

Can it execute arbitrary commands?

The direct primitive is argument injection leading to an out-of-workspace file write. GitHub says partially attacker-influenced writes can lead to code execution. That is a possible chain, not the same as an immediate, unauthenticated arbitrary-command endpoint.

Does exploitation require user interaction?

GitHub's CVSS vector marks user interaction as required and the attack vector as local. A vulnerable server must process the relevant diff scan with attacker-influenced input.

Is there a workaround if I cannot upgrade today?

AWS says there is no complete workaround. Until you upgrade, scan only trusted repositories and run the server as a least-privileged user in an isolated environment. Disabling the vulnerable server or diff-scan workflow is safer than continuing broad untrusted scans.

Does using latest mean I am safe?

Not necessarily. Confirm the version resolved by the environment that actually runs. Cached uvx environments, containers, mirrors, lockfiles, and long-running processes may remain on an older version.

Was customer data stolen?

No reviewed source reports customer-data theft or exploitation in the wild. If your affected deployment scanned untrusted input, inspect it; do not treat the existence of the CVE as proof of a breach.

Bottom Line

CVE-2026-97662 is a concrete warning about agent tool boundaries. AWS's Security Agent MCP server promised workspace confinement, but a diff reference crossed into Git's option parser and could produce writes outside that workspace.

If you run awslabs.security-agent-mcp-server, verify the live version now. Upgrade every affected copy to 0.2.0 or later, restart it, reduce its filesystem and credential reach, and review suspicious scans involving untrusted repositories.

The broader lesson is durable: model instructions are not containment. When an AI assistant can invoke tools, the parser, process, filesystem, credentials, and audit trail must enforce the boundary even when the model or input gets it wrong.

Sources

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.