GHSA-382C-VX95-W3P5: Root-Cause Access Control Fix for Gittensory Profile Exposure

Vulnerability

GHSA-382C-VX95-W3P5 describes missing access control on Gittensory's contributor profile exposure paths. Based on the patch summary and tests, any authenticated user could query another contributor's profile through the REST endpoint and the MCP tool, receiving data that should have been restricted to the contributor. The disclosed data included cryptographic identifiers such as hotkeys and operational financial metrics such as alphaPerDay, taoPerDay, and usdPerDay.

The root issue was authorization omission, not merely overbroad serialization. The REST route lacked a contributor-specific permission gate before returning profile data, and the MCP tool similarly allowed cross-user profile access. In the MCP path, the pre-patch filtering only removed a subset of secret-like fields:

.filter(([key]) => !/hotkey|coldkey|wallet|private_key|privateKey|mnemonic/i.test(key))

That filter did not address the more fundamental problem that unauthorized callers could invoke the tool at all, and it also left financial fields exposed. The advisory and commit together indicate two distinct but related weaknesses: missing object-level authorization and incomplete output redaction. See the advisory and patch commit for the disclosed impact and code changes: GitHub Security Advisory, commit 811ef5f.

Patch

The patch introduces an explicit contributor access check in the REST route:

const unauthorized = await requireContributorAccess(c, login);
if (unauthorized) return unauthorized;

This is the critical control because it binds access to the requested login before profile data is returned. The tests confirm the intended behavior by asserting that a request for another user's profile now returns HTTP 403 with { error: "forbidden_contributor" } on the REST endpoint.

For the MCP server, the patch adds an authorization gate before profile retrieval and expands the redaction regex:

this.requireContributorAccess(login);
.filter(([key]) => !/hotkey|coldkey|wallet|private_key|privateKey|mnemonic|alphaPerDay|taoPerDay|usdPerDay/i.test(key))

This change does two things. First, it prevents unauthorized users from invoking the contributor profile tool for arbitrary logins. Second, it removes additional sensitive business and financial fields from the MCP response payload even for authorized access. The integration test validates both properties: the owner can retrieve a profile but does not receive hotkey, alphaPerDay, taoPerDay, or usdPerDay; a different authenticated user receives an error-shaped MCP response and the forbidden payload does not contain the redacted fields.

The source-grounded evidence for these changes is in the commit and tests: github_code_digest and GHSA advisory.

Review

Pros

• The patch fixes the primary vulnerability class by adding contributor-level authorization checks on both disclosed access paths, REST and MCP.
• The access control is enforced close to request handling, which reduces the chance of accidental bypass within those entry points.
• The MCP response filtering is strengthened to remove not only wallet/secret-like fields but also financial metrics explicitly called out in the disclosure.
• Regression coverage is materially improved. The tests verify positive access for the owner, negative access for another authenticated user, and absence of sensitive fields in both structured and textual MCP output.
• The REST test asserting 403 for another contributor directly validates the object-level authorization requirement.

Cons

• The redaction strategy remains regex-on-key-name based. That is brittle against schema drift, alternate field names, nested objects, or future additions that are sensitive but not matched by the pattern.
• The patch evidence shows redaction changes only in the MCP path. If the REST profile serializer shares the same underlying data source, it is not clear from the provided snippets whether sensitive-field minimization is centralized across all output surfaces or only addressed where tests were added.
• The authorization logic appears duplicated across route and MCP entry points rather than obviously centralized in a single policy layer. That is acceptable for a targeted fix but increases long-term maintenance risk.
• The MCP forbidden behavior is validated by matching generic error text in a 200 JSON-RPC response. While protocol-compliant behavior may require this, the test is less strict than asserting a stable structured error contract.

Verdict

Root-cause.

The patch addresses the core defect identified in GHSA-382C-VX95-W3P5: missing authorization on contributor profile access. The newly added requireContributorAccess checks on both the REST endpoint and MCP tool directly remediate the insecure direct object access condition. The additional MCP redaction is a useful defense-in-depth improvement and closes part of the overexposure problem for authorized views.

That said, the patch would be stronger if sensitive-field handling were driven by an allowlist or typed DTO layer shared across all profile renderers, rather than regex filtering at one output boundary. Even so, for the disclosed issue and the demonstrated attack paths in the sources, the fix is appropriately targeted and substantively complete.