AWS Security Agent MCP Server Diff Scan Argument Injection - CVE-2026-97662
The short version: AWS's own security-scanning MCP server could be steered into writing files outside the workspace it was meant to stay in. CVE-2026-97662 affects awslabs.security-agent-mcp-server 0.1.1 up to 0.2.0 and is fixed in 0.2.0. Upgrade, then check which machines still launch an old copy.
AWS published security bulletin 2026-121-AWS on October 1, 2026, rated Important, with GitHub advisory GHSA-8g28-rj54-p5p2. The CVSS 3.1 score is 8.2 High (AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:H). AWS credits independent researcher Mario Guzmán (yud4s).
What to do first
- Upgrade to 0.2.0 or later (0.2.1, published September 8, is the current release), and restart every MCP client that launches the server so the old process is not left running.
- Until then, run diff scans only against trusted repositories, and run the server as a least-privileged user in an isolated environment, as AWS recommends.
- On machines that ran a vulnerable version against untrusted code, check shell startup files, SSH
authorized_keysand credential files for unexpected changes. - Review forks and derivative code: AWS asks that they incorporate the fix too.
How Anomity surfaces and governs it
See it. MCP servers are launched by client configuration on developer machines, not deployed by IT. The Endpoint Sensor inventories the MCP servers configured on each managed endpoint, with versions, alongside the agents and CLIs that launch them. A security-agent-mcp-server below 0.2.0 shows up as a named machine with a named version.
Bound it. The sensor also inventories secrets on those endpoints, with values redacted before anything leaves the machine, so you can see what a write to credential files would reach. On agents with a pre-execution hook, such as Claude Code PreToolUse, Anomity can allow, deny or log a tool call before it runs. Decisions land in a 90-day audit trail and route to SIEM, Slack, email or Jira.
What happened
security-agent-mcp-server lets AI assistants run AWS Security Agent scans over local source code, including differential scans that compare the working tree to a base revision. The start_diff_scan operation took a base_ref argument and placed it on git command lines, per the fix's own documentation git diff <base_ref> -- and git archive ... -- <base_ref>.
A ref that begins with - is not a ref to git. It is an option. AWS's advisory says the crafted value is interpreted as a command-line option instead of a revision, and that the server's workspace-confinement control does not cover that reference. The impact, in AWS's words: an actor who can influence it, for example by controlling content in a scanned repository, can create, overwrite or truncate files anywhere the server process can write, including shell startup files, SSH authorized keys and credential files. Written content is partially influenced by the scanned repository, which can lead to code execution.
One detail makes it worse: the operation reports that no diff was found, so a successful write produces no signal to the operator.
The fix is fifteen lines
The patch is pull request #4508 in awslabs/mcp, opened August 18 and merged August 20, 2026 as commit 7b69f2e6. It adds a _validate_git_ref check at the top of start_diff_scan that rejects an empty base_ref and any value whose trimmed form starts with -, before any git subprocess runs. It shipped to PyPI in 0.2.0 on August 26. The CVE and bulletin followed on October 1, about five weeks after the fixed version was available.
if not base_ref or not base_ref.strip():
raise ValueError('base_ref must not be empty.')
if base_ref.strip().startswith('-'):
raise ValueError(f'Invalid base_ref "{base_ref}": must be a git ref, not start with "-".')Security tools run by agents are agents too
The uncomfortable part is which server this was: a security scanner, run by an AI assistant, over code the assistant was asked to review. Untrusted repositories are exactly what a scanner is pointed at. We made the general argument in autonomous security agents are agents too: a tool that acts on behalf of security still holds the same permissions on the same laptop, and needs the same inventory and enforcement as any other agent.
It is also the latest in a line of git argument and configuration bugs in agent tooling. GitSpawn showed a repository's git configuration running commands while coding agents gathered context, with no approval. OpenAI Codex's branch-name injection put an attacker-chosen string on a shell command line. Here the string goes onto git's command line instead. The defense is the same each time: never let model-chosen or repository-supplied text reach a command line as anything but data.
What to check across your fleet
- Every machine whose MCP client configuration launches awslabs.security-agent-mcp-server, and the version each one runs.
- Other awslabs and vendor MCP servers that shell out to git or other CLIs with model-supplied arguments.
- Which repositories those assistants were pointed at before the upgrade.
- What secrets sit on those machines, since the write could reach credential files.
CVE-2026-97662 needed no exotic technique, only a leading dash and a server that trusted its arguments. For the wider MCP control set, see model context protocol security explained. To find every MCP server configured across your endpoints, book a 30-minute demo.
Frequently asked questions
Am I affected by CVE-2026-97662?
You are affected if any MCP client on a machine launches awslabs.security-agent-mcp-server version 0.1.1 or later but earlier than 0.2.0. It is a Python package from the awslabs/mcp repository that lets AI assistants run AWS Security Agent scans, including diff scans, over local source code. Because MCP servers are usually launched by a developer's client configuration rather than installed by IT, the version that actually runs can differ from machine to machine.
How does a git ref become a file write?
The diff scan placed base_ref on git command lines such as git diff with the ref followed by a double dash. A value beginning with a dash is parsed by git as an option rather than a revision. AWS has not published which option was abused, but git commands do accept options that write output to a path, which is why a leading dash in that position is dangerous. The 0.2.0 fix rejects an empty base_ref and any base_ref whose trimmed value starts with a dash before any git subprocess runs.
Who can trigger it?
AWS describes the attacker as a context-dependent actor who can influence the reference value, for example by controlling content in a scanned repository. In an agent workflow, the assistant usually chooses the arguments for an MCP tool call, so text the assistant reads can steer what it passes. The CVSS vector is local with user interaction required, and scope changed, reflecting writes that escape the workspace boundary.
Is there a workaround?
AWS says there is no workaround other than upgrading. Until you upgrade, AWS recommends running diff scans only against trusted repositories and running the server as a least-privileged user in an isolated environment so a stray write cannot reach sensitive host files.
How would we know if it was used?
Not from the tool output: per the advisory, the operation reports that no diff was found. Look instead for unexpected changes to shell startup files, SSH authorized_keys and credential files on machines that ran a vulnerable version against repositories you do not fully trust.
How does Anomity help with this?
The Anomity Endpoint Sensor inventories MCP servers configured on every managed endpoint, with versions, which turns this advisory into a list of machines still launching a version below 0.2.0. It also inventories secrets on those endpoints, redacted on the endpoint, so you can see what a write to credential files would touch. On agents with a pre-execution hook, such as Claude Code PreToolUse, Anomity can allow, deny or log a tool call before it runs, and every decision lands in a 90-day audit trail that routes to SIEM, Slack, email or Jira.
