The Tool Was Marked Read Only. Git Still Wrote the File.

The exact mechanism, read from both layers that were supposed to catch it

git-mcp-server's own architecture already separates two layers a caller supplied value passes through before it reaches git: a Zod schema at the MCP tool boundary, and a validateGitArgs allow list inside git-executor.ts, called by every operation immediately before the process spawns, confirmed directly by this record's own reading of the import and call site. Both layers existed at v2.15.1. Neither did what its own presence would suggest.

The schema layer, CommitRefSchema in src/mcp-server/tools/schemas/common.ts, is imported by git-log.tool.ts, git-diff.tool.ts and git-show.tool.ts alike, confirmed directly in each file, and at v2.15.1 its own definition was z.string().min(1), nothing further. A value beginning with a hyphen is, to that schema, indistinguishable from any other non empty string.

The executor layer, validateGitArgs in command-builder.ts, is more interesting, because it shows a check that existed specifically to catch this class of value and was deliberately left incomplete. Reading the exact v2.15.1 source, the function walks every argument, and for one beginning with a hyphen, computes three booleans: whether it is a short flag matching a single letter pattern, whether its name before any equals sign is on a fixed safe list, and whether the argument contains an equals sign at all, named isFlagWithValue. If none of the first two hold, the function's own comment states the intended behavior directly, in a high security production environment you might want to throw here, followed immediately by the actual behavior, for now, we allow it to maintain flexibility, with the throw statement itself present in the file as a commented out line. A branch value of --output= fails both the short flag and safe list checks, and satisfies isFlagWithValue, so it reaches neither the safe path nor the rejection path. It reaches git.

The fix, confirmed by reading the exact version the advisory names

This record read the current source on the project's default branch, which carries the same version number, 2.15.3, that the advisory's own affected range extends through, confirmed directly against the project's own package.json. CommitRefSchema now carries a refine check, rejecting any string starting with a hyphen, with a comment stating the reason directly: a ref like --upload-pack=evil would otherwise be parsed by git as an option flag when passed positionally, naming the same CVE-2017-1000117 class the underlying issue itself invokes. validateGitArgs was rewritten independently of the schema change: the function now computes a flag's name as the portion before any equals sign and checks that name, not the raw argument, against an expanded allow list, with no equals sign exception anywhere in the function and no commented out throw. A flag whose name is not a recognized short form and not on the allow list now throws, unconditionally, naming the rejected flag in its own error message.

This record separately read the npm registry's own publish record for the package rather than relying on the project's own git history alone. Version 2.15.2 published 24 August 2026 at 21:05 UTC, carrying the security fix commit, whose own message reads, fix(security): block argument injection via positional git args, and whose own description states the change directly: a value starting with a hyphen reached git as an option flag, schemas now reject leading hyphen refs, paths and URLs, validateGitArgs enforces a strict flag allow list, and clone/remote emit an end of options marker before positionals. Version 2.15.3 published the same day at 21:56 UTC, a regression fix restoring a small number of legitimate git rev-parse flags the new allow list had started rejecting and changing how a commit message beginning with a hyphen is passed, as an attached --message= form rather than a standalone argument after a separate -m flag, so a message is never a bare positional value either. Version 2.15.3 is npm's own current latest tag for the package, confirmed directly against the registry's own dist tags field.

A gap this record states rather than resolves

The advisory's own affected range extends through version 2.15.3. This record's own direct reading of that exact version's source shows the fix already present: the schema rejects the reporter's own proof of concept value before it reaches any provider code, and the executor's own allow list would independently reject it a second time even if the schema check were somehow bypassed. Eleven days separate the fix reaching npm's own latest tag and the advisory's own publication date. This record does not know why the advisory's affected range was not narrowed to reflect the fix, and states that plainly as something this record's own available sources do not establish, rather than inferring a reason from the pattern this weakness class shows elsewhere. What this record does know, because it read the exact version itself, is that a deployment running the version the advisory names as the upper bound of what is affected is running code that independently confirmed source shows does not reproduce the reported mechanism.

readOnlyHint did not cause this, and did not fix it either

git_log, git_diff and git_show each still carry readOnlyHint: true in the current source, unchanged from v2.15.1, confirmed directly in each tool's own annotations object. This record does not read that annotation as the cause of the vulnerability, and does not read its continued presence as evidence the fix is incomplete. readOnlyHint is a declaration a tool author makes about the operation's own intended effect, read by an MCP client to decide whether a call needs a confirmation step before it runs. Before the fix, that declaration was true about what git_log, git_diff and git_show were meant to do and false about what a specific crafted value could make them actually do, a gap between declared intent and executor level effect that no annotation, on its own, has any mechanism to close. The fix does not change the annotation. It changes whether the value reaching the executor can still produce an effect the annotation never claimed.

The Authority Provenance ledger

Declared capability. git_log, git_diff and git_show each carry readOnlyHint: true, confirmed directly at both v2.15.1 and the current source, a claim about the tool's own intended, non mutating effect.

Input semantic. A branch, source, target or object value, schema typed as a commit reference, a ref, a hash, a branch or tag name, or a relative expression such as HEAD~1.

Executor interpretation. git's own argument parser, which does not know or care what an upstream schema called the value; a token beginning with a hyphen, reaching git positionally, is read as an option regardless of what the caller or the tool's own schema intended it to mean.

Effect before the fix. A filesystem write to a path the caller's own value named, outside the repository the tool was scoped to, confirmed directly by this record's own reading of the v2.15.1 source and the exact validateGitArgs branch that let it through.

Failed limit. Two, not one. The schema layer never encoded the constraint at all. The executor layer encoded it, named the risk directly in its own comments, and then declined to enforce it for exactly the shape of value, a flag carrying an equals sign, that the reporter's own proof of concept used.

Recovery path. Both layers rewritten together, confirmed directly in the current source: a schema level refine rejecting any leading hyphen, and an executor level allow list keyed to a flag's own name rather than its shape, with no equals sign exception remaining in either.

Recovery timing. Shipped to npm's latest tag on 24 August 2026, confirmed directly against the registry's own publish timestamp, eleven days before the advisory's own 4 September 2026 publication date.

Tracking state. Issue 53 remains open at the time of this record, with no maintainer reply recorded, even though the source it describes has already changed under the same version number the advisory lists as affected.

Exploitation. Unknown. No source available to this record states this was exploited against a production git-mcp-server deployment.

Provenance evidence quality. Strong for the mechanism itself, both before and after the fix: this record downloaded and read the exact source at the v2.15.1 tag, the exact tag the reporter's own proof of concept names, and separately at the current default branch, confirming the shared schema, the executor's own validateGitArgs function and its exact branching logic, and the tool annotations, at both points directly. Strong for the fix's own timing: the npm registry's own time field for this package records the precise publish timestamp for 2.15.2 and 2.15.3, read directly rather than inferred from a changelog date alone. Weaker for the CVE Program's own formal record: cve.org and nvd.nist.gov were both blocked to direct fetch in this session, and this record relies on the GitHub Advisory Database's own record rather than a direct read of the Program's own page, which does not independently confirm which body served as the assigning CVE Numbering Authority.

Where this sits in the pattern