[Vulnerability] github/github-mcp-server: Race Condition / Unauthorized Content Modification #91

fix(repos): give create_or_update_file callers a SHA they can actually get (#3131)

* fix(repos): give create_or_update_file callers a SHA they can actually get

The create_or_update_file tool description and both of its SHA errors told
the caller to run `git rev-parse <branch>:<path>`. The caller is an MCP
client talking to the GitHub API, and the same description tells it not to
use this tool for local file operations, so it has no working tree to run
that command against.

Point the description at get_file_contents instead, which returns the blob
SHA over the API. In the already-exists error the server has just fetched
the file, so return that SHA directly rather than asking for a round trip.
The stale-SHA error already interpolates the current SHA, so it only needed
the impossible instruction removed.

* fix(repos): stop disclosing the blob SHA when no sha was supplied

The already-exists path is reached only when the caller sent no sha, so
it has not read the file. Returning the current blob SHA there let it
overwrite content it never saw on the next call, which is the race the
SHA gate exists to prevent. Send the caller to get_file_contents for the
path and ref instead, so obtaining the SHA still requires reading the
file.

The stale-SHA path is unaffected: the caller did supply a sha, and that
message already reported the current SHA before this change. Only its
recovery step moved off git rev-parse, and it is now imperative rather
than conditional, since a stale SHA means the file definitely changed.

Assert the already-exists error does not contain the blob SHA so the
gate cannot be loosened again without a test failing.

* fix(repos): make SHA recovery guidance actionable

Map create_or_update_file branch arguments to get_file_contents ref arguments, identify where the requested path SHA is returned, and cover symlink, branch, and API error behavior.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Dylan Pulver <dylanpulver@users.noreply.github.com>
Co-authored-by: Sam Morrow <info@sam-morrow.com>
Co-authored-by: Sam Morrow <sammorrowdrums@github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

File already exists at %s. You must provide the current file's SHA when updating. Use git rev-parse %s:%s to get the blob SHA, then retry with the sha parameter. (previously returned currentSHA in error or description)

1. Client A calls create_or_update_file with no SHA to update docs/example.md. 2. Server checks file exists, returns error with current blob SHA (e.g., 'abc123'). 3. Client A (or attacker) immediately calls create_or_update_file again with sha='abc123' and malicious content before the actual file owner can read and update it. 4. The content is overwritten because the SHA was disclosed in the error message from step 2, allowing the attacker to bypass the intended read-before-write protection. After the patch, step 2 no longer returns the SHA, so step 3 fails unless the attacker independently fetches the file via get_file_contents.