[Security] AgentAudit Scan: Unauthenticated R2 Endpoint, Stack Trace Exposure

[starbuck100]

Summary

We scanned this package using AgentAudit as part of a security audit of the top 20 most-used MCP servers. AgentAudit uses multi-model LLM analysis to detect AI-specific security patterns.

Trust Score: 80/100 | 2 findings (1 high, 1 medium)

Findings

1. R2 Setup Endpoint Lacks Authentication

• ASF-ID: ASF-2026-2048
• File: src/api/test-setup.ts:36
• Description: The handleR2TestSetup function relies only on an environment variable check (ENVIRONMENT !== 'test') to prevent access. If misconfigured, unauthorized users could upload arbitrary content to the R2 bucket.

2. Stack Traces Exposed in Error Responses

• ASF-ID: ASF-2026-2047
• File: app/routes/api.chat.ts:194
• Description: Error messages returned directly to clients without sanitization, potentially revealing internal paths and application structure.

Full Report

View the complete scan report: https://agentaudit.dev/packages/git-mcp

Note

These findings were detected by automated LLM-based security analysis and may contain false positives. We welcome your feedback and are happy to update our records if any findings are disputed.

---

Scanned with AgentAudit — open-source security scanner for AI agent packages.

[sorlen008]

Opened #228 to address finding 2 (stack trace exposure).

Wanted to add a note on finding 1 (R2 endpoint) as well, since I was looking at the code:

The handleR2TestSetup function in src/api/test-setup.ts gates access on env.ENVIRONMENT === "test", but this is more fragile than it looks. In most Cloudflare Workers deployments, environment variables that aren't explicitly set default to undefined — so the check env.ENVIRONMENT !== "test" would correctly block access in that case. But the concern is really about misconfiguration scenarios:

1. If someone sets ENVIRONMENT=test in production (copy-paste from a dev config, for example), the endpoint becomes fully accessible with no authentication. It allows uploading arbitrary content to the R2 bucket via env.DOCS_BUCKET.put().

2. The check happens in the main fetch handler in src/index.ts (line 118-124), so the endpoint is part of the production routing table even when it's not reachable. This means it shows up in code analysis tools (like AgentAudit) and expands the attack surface conceptually even if it's not exploitable in practice.

A couple of options to harden this:

• Remove it from production builds entirely. If the endpoint is only needed for E2E tests against a test deployment, it could be conditionally included only in test builds (e.g., behind a build-time flag or in a separate worker entry point for the test environment).

• Add explicit auth. If it needs to exist in all builds, gate it behind a shared secret (e.g., a TEST_SETUP_SECRET env var that must be sent as a header). This way even if ENVIRONMENT is misconfigured, the endpoint can't be hit without the secret.

• At minimum, add a check for the R2 bucket binding name. If the production R2 bucket has a different binding name than the test one, the endpoint would fail anyway — but that's failing open, not closed.

The env var check is fine for a "this should never be reachable" guard, but for an endpoint that can write to object storage, explicit auth or build-time exclusion would be more appropriate.