Repository navigation
git: git_remote redacts credentials only in the URL's userinfo, not in its query, fragment or path #5508
Description
Problem
git_remote says that "credentials embedded in a URL are shown as <redacted>", but redact_url (src/git/src/mcp_server_git/server.py) only redacts the URL's userinfo (scheme://user:token@host/...). A remote URL that carries a credential anywhere else is returned unchanged:
https://git.example.com/g/r.git?private_token=SECRET → unchanged
https://git.example.com/g/r.git#SECRET → unchanged
https://git.example.com/token/SECRET/r.git → unchanged
The credential is the operator's own, from their repository's configuration, and no tool lets a caller set a remote URL. So the tool is falling short of its stated contract rather than exposing anything to a third party.
Expected
The output matches the tool's description: credential material is redacted wherever the URL carries it, not only in the userinfo. For example:
- redact the values of query parameters with credential-like names (
token,private_token,access_token,password,api_key, …); - redact the fragment;
- or, more conservatively, show
<redacted>for the whole URL when a non-userinfo part looks like a credential.
If some forms stay out of scope (a token as a bare path segment can't be told apart from a repository name), the tool description and README should say what is and isn't redacted.
Credit
Reported by @reservoir-cmyk (Tomoki Murota).
Activity
SalyyS1 commentedon Nov 11, 2026
I prepared a DCO-signed fix and test suite for this on
v2/main: v2/main...SalyyS1:servers:fix/git-remote-redact-url-5508Summary of changes
redact_url(src/git/src/mcp_server_git/server.py): Redacts query parameter values (?key=<redacted>or?<redacted>for bare queries) and non-empty fragments (#<redacted>) inscheme://URLs (including inner URLs of<transport>::<url>remote helpers), while preserving SSH usernames (ssh://git@host/...) and path segments.git_remote's tool description,tests/snapshots/list_tools.json, andsrc/git/README.mdto explicitly state that credentials in a URL's userinfo, query, or fragment are shown as<redacted>while path segments are kept as configured.src/git/tests/test_remote.py): Adds 8 parametrized test cases covering query parameters, bare queries, fragments, combined userinfo+query+fragment URLs,@inside query values, and remote-helper URLs.feamine709-byte commentedon Nov 11, 2026
Good catch. Beyond URL userinfo, token exposure in tool outputs is a huge risk because once a secret enters the context window, it leaks to the model provider's telemetry and logging.
In Star Protocol, we treat all tool outputs with zero-trust server-side scrubbing: output payloads are intercepted by a lightweight local sandbox before serialization, where regex-based redaction strips out known token formats (pat_, ghp_, bearer tokens, query secrets) before the LLM ever sees the string:
https://github.com/feamine709-byte/star-protocol
Redacting query params and fragments as proposed here is a must-have fix for the Git server.
reservoir-cmyk commentedon Nov 12, 2026
As the reporter, I pulled your branch and ran a structured pass against the pinned
v2/main, in three parts:test_remote.py.redact_url— theprivate_tokenquery value and the fragment now come back as<redacted>, and the path-segment example is unchanged, matching the scope the README and tool description now state.@inside a query value, an empty fragment, and a remote-helper URL — all behaved as documented.Thank you for picking this up so quickly, and for documenting the path-segment boundary rather than leaving it implicit.
One nit I noticed while probing, offered for completeness: for a URL with no path at all and an unencoded
?inside the userinfo (e.g.https://user:p?ss@host.example), the output ishttps://user:p?<redacted>— the same input with any path is fully redacted. Malformed-URL territory and unlikely to matter for real remotes, but I said I'd report what I ran.fix(git): handle unencoded ? or # in userinfo on pathless URLs (model…
SalyyS1 commentedon Nov 12, 2026
@reservoir-cmyk Thank you for pulling the branch and running that thorough 3-part pass against
v2/main.Good catch on the pathless URL edge case (
https://user:p?ss@host.examplewhere an unencoded?or#sits insideuser:passwordbefore@on a URL with no/). That happened because the pathless guard previously checked"?" not in userinfo and "#" not in userinfoto avoid misclassifying@inside a query parameter on a bare host (likehttps://git.example.com?email=a@b.com).When
?or#appears before@in a pathless URL, we can distinguishuser:passwordfromhost[:port]?queryby checking the substring before the first[?#]: in a validhost[:port]authority without userinfo, any colon before?or#is followed strictly by port digits, whereasuser:phas a non-numeric password prefix before?.I just pushed commit
219f437toSalyyS1:servers:fix/git-remote-redact-url-5508with_has_userinfo_before_query(userinfo)and added"https://user:p?ss@host.example" -> "https://<redacted>@host.example"totest_redact_urlalongside"https://git.example.com?email=a@b.com" -> "https://git.example.com?email=<redacted>".@feamine709-byte Regarding general tool-output secret scrubbing across arbitrary MCP servers (including when third-party or unpatched servers return URLs with query tokens like
?private_token=,?token=,X-Amz-Signature=, or embedded userinfo credentials), we also maintain those exact C-accelerated redaction rules inmcp-slim(SecretGuardinsrc/mcp_slim/guard.py) so stdio MCP responses are scrubbed at the proxy boundary before reaching the model context.reservoir-cmyk commentedon Nov 12, 2026
Thanks for the quick follow-up — I pulled the branch at
219f437and re-ran the same pass against the pinnedv2/main:test_remote.py41, including the new case).https://user:p?ss@host.example→https://<redacted>@host.example, and the#twin (https://user:p#ss@host.example) behaves the same way.https://git.example.com?email=a@b.com— and the same shape with an explicit port,:8080— keeps the host and redacts only the query value.The earlier checks (the issue's three examples, the SSH forms, the remote-helper recursion) all still pass unchanged. From my side, that closes the nit — thank you.
cliffhall commentedon Nov 12, 2026
Fixed by #5533, merged into
v2/main; it ships with the next release.