# We run awslabs.security-agent-mcp-server so an assistant can start code scans. What are CVE-2026-97662 and CVE-2026-87913, which version fixes them, and is upgrading enough?

**Short answer:** Version 0.2.0 of awslabs.security-agent-mcp-server (on PyPI August 26, 2026) fixes both, and 0.2.2 (November 9) was the newest on November 14, 2026. CVE-2026-97662 (GHSA-8g28-rj54-p5p2, high, published October 1) affects 0.1.1 up to 0.2.0: the diff scan put a caller-influenced base_ref on a git command line, so a value starting with a dash was read as a git option, letting whoever controls it, for example through a scanned repository, create, overwrite or truncate files anywhere the server can write while the scan reports no diff. CVE-2026-87913 (GHSA-3jxw-vj8m-8x77, published September 10) affects 0.1.0 to 0.1.5: the scan bucket's name was predictable from your account ID and Region and the server checked only that it existed, so someone who registered that name first in their own account would receive your source archive. Upgrading is not enough for the second one: AWS says an upgrade doesn't free a name already taken, so confirm security-agent-scans-<account-id>-<region> belongs to your account.

## Checklist
1. Upgrade awslabs.security-agent-mcp-server to 0.2.0 or later (0.2.2 was current on November 14, 2026), and restart clients that launch it through uvx @latest so they load the new build.
2. Confirm the bucket security-agent-scans-<account-id>-<region> exists in your own account for each Region you scan in. If it doesn't, pre-create it in your account, as AWS advises.
3. If an affected version ran, check where archives went. A bucket you can't see in your account but that the server wrote to means your source, and any credentials or infrastructure state in it, went to someone else: rotate those secrets.
4. Look for unexpected file changes in the server user's home directory (shell startup files, ~/.ssh/authorized_keys, credential files) if an affected version ran diff scans on repositories you didn't control.
5. Until you upgrade, AWS says to run diff scans only on trusted repositories and run the server as a least-privileged user in an isolated environment.
6. If you build MCP servers that call git: reject refs that start with "-" or put --end-of-options before them. A "--" placed after the ref doesn't help, because git reads it as the revision/path separator.
7. If your server writes to S3: never trust a bucket because its name is predictable. Pass ExpectedBucketOwner on every request so S3 refuses buckets owned by another account.

## What is CVE-2026-97662 in the AWS Security Agent MCP server?
- AWS's advisory GHSA-8g28-rj54-p5p2 (CVE-2026-97662, CWE-88 argument injection, CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:H, published October 1, 2026) says the diff scan put a caller-influenced revision reference into git in a way that let a crafted value be read as a command option, and that the server's workspace confinement didn't cover that reference. 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, with content partly from the repository, which can lead to code execution. The scan then reports that no diff was found, so nothing tells the operator.
- The fix commit (7b69f2e6c6, August 20, 2026, "validate base_ref in start_diff_scan") adds a check before any git command runs: an empty base_ref, or one that starts with "-" after trimming, is refused. The comment in the code notes the value sits on lines such as git diff <base_ref> --, where the trailing -- can't protect it.
- Git's own documentation explains why: -- separates revisions from paths in commands like git diff, so it can't also separate options from revisions, and --end-of-options exists for that. Scripts that handle untrusted input should mark which arguments are which.

## What is CVE-2026-87913, the S3 bucket-squatting issue in the AWS Security Agent MCP server?
- AWS's advisory GHSA-3jxw-vj8m-8x77 (CVE-2026-87913, CWE-283 unverified ownership and CWE-341, CVSS 4.0 subsequent-system confidentiality high, published September 10, 2026) says the server derived the scan-input bucket name from your AWS account ID and Region and accepted the bucket if it existed, not if you owned it. S3 bucket names are global and account IDs aren't secret, so a third party could register the name first and the server would upload your workspace's source archive, which can include credentials and infrastructure state, to their bucket. Only your account ID was needed.
- The fix commit (6d289e1281, August 14, 2026, "enforce S3 bucket ownership to prevent bucket-squatting code leak") passes ExpectedBucketOwner set to your account ID on the upload, checks ownership with a HeadBucket call before use, and turns BucketAlreadyExists into a security alert instead of a hint to pick another name. Amazon S3's documentation describes this bucket owner condition as the way to make sure the buckets in your requests belong to the accounts you expect.
- AWS's workaround text adds the part an upgrade can't do: a name someone else already registered stays theirs. That's why the bucket check in the checklist matters even on 0.2.2.

## When were the AWS Security Agent MCP server fixes released, and what should MCP builders test for?
- PyPI lists 0.1.0 on June 2, 0.1.1 (which added the diff scan) on June 17, 0.1.5 on August 10, 0.2.0 on August 26, 0.2.1 on September 8 and 0.2.2 on November 9, 2026. Both fixes shipped in 0.2.0, about two weeks before the bucket advisory and five weeks before the git one, so an install pinned before late August that nobody revisited stayed exposed after the advisories appeared.
- Both bugs share a shape worth testing for in any MCP server that drives local tools or cloud storage: a value the model or a repository can influence reaches a command line or a resource name without the server checking what it means. Write tests that feed option-like strings to every argument that reaches a subprocess, and assert ownership on every bucket or resource you derive by name.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "We upgraded the AWS Security Agent MCP server to 0.2.2 and confirmed our scan bucket in us-east-1 is owned by our account. Record that change with a hash of the bucket ownership check output."

```json
{
  "tool": "record_action",
  "arguments": {
    "action_type": "security.config_change",
    "outcome": "success",
    "occurred_at": "2026-11-14T15:00:00Z",
    "client_event_id": "security-agent-mcp:upgrade-0.2.2-2026-11-14",
    "summary": "Upgraded awslabs.security-agent-mcp-server to 0.2.2 (fixes CVE-2026-97662 and CVE-2026-87913); verified security-agent-scans-<account-id>-us-east-1 is owned by our account via HeadBucket with ExpectedBucketOwner.",
    "action_sha256": "<sha256 of the HeadBucket output you saved>"
  }
}
```
- Needs your API key (or accept_terms:true once to open a free account; the key comes back once). It returns a ledger-committed receipt of what you submitted and when. It proves the entry was recorded, not that the upgrade or the bucket check happened.
- It doesn't check your server version, call S3, look at bucket owners or scan repositories. Run those checks in your own account; the hash ties the receipt to the output you kept.

_Rightshold isn't affiliated with AWS. It doesn't scan MCP server code, repositories or S3 buckets, and a ledger record isn't a finding that a server is safe. Advisory details are as published by AWS in GitHub's advisory database (GHSA-8g28-rj54-p5p2, GHSA-3jxw-vj8m-8x77), fixes as shown in the linked awslabs/mcp commits, git behavior as described in Git's documentation and release dates as listed on PyPI, all read November 14, 2026; advisories get updated, so confirm fixed versions on the linked pages._

## Sources
- [GitHub Advisory: GHSA-8g28-rj54-p5p2 / CVE-2026-97662, argument injection in awslabs.security-agent-mcp-server](https://github.com/awslabs/mcp/security/advisories/GHSA-8g28-rj54-p5p2)
- [GitHub Advisory: GHSA-3jxw-vj8m-8x77 / CVE-2026-87913, missing S3 bucket ownership verification in the AWS Security Agent MCP server](https://github.com/awslabs/mcp/security/advisories/GHSA-3jxw-vj8m-8x77)
- [awslabs/mcp fix commit 7b69f2e6c6: validate base_ref in start_diff_scan](https://github.com/awslabs/mcp/commit/7b69f2e6c6)
- [awslabs/mcp fix commit 6d289e1281: enforce S3 bucket ownership](https://github.com/awslabs/mcp/commit/6d289e1281)
- [Amazon S3: Verifying bucket ownership with bucket owner condition](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-owner-condition.html)
- [Git documentation: gitcli (--end-of-options)](https://git-scm.com/docs/gitcli)
- [PyPI: awslabs.security-agent-mcp-server release history](https://pypi.org/project/awslabs.security-agent-mcp-server/#history)

## Related
- [Can opening an untrusted repository with the MCP git server run code on your machine?](https://www.rightshold.com/answers/can-opening-an-untrusted-repository-with-the-mcp-git-server-run-code-on-your-machine)
- [Which AWS Labs Postgres, MySQL and DocumentDB MCP server versions fix the read-only mode bypasses?](https://www.rightshold.com/answers/which-aws-labs-postgres-mysql-and-documentdb-mcp-server-versions-fix-the-read-only-mode-bypasses)
- [Pinning MCP server versions and reviewing changes before you upgrade](https://www.rightshold.com/answers/how-to-pin-mcp-server-versions-and-review-changes-before-upgrading)
- [Sandboxing a local stdio MCP server to only the files and hosts it needs](https://www.rightshold.com/answers/how-to-sandbox-a-local-stdio-mcp-server-to-only-the-files-and-hosts-it-needs)

_Not legal advice. Updated 2026-11-14. JSON: https://www.rightshold.com/answers/which-aws-security-agent-mcp-server-version-fixes-the-diff-scan-file-write-and-s3-bucket-squatting-advisories.json_