From C to A grade: a week-by-week MCP server remediation plan

Fix 1: SSRF in fetchReadme

The fetchReadme tool accepts a repoUrl argument and passes it to fetch() without hostname validation. An adversarial prompt injection that changes repoUrl to http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS metadata service) or http://10.0.0.1/admin will exfiltrate internal credentials or trigger actions on internal services.

// Dangerous: repoUrl passed directly to fetch with no hostname check
server.tool('fetchReadme', {
  schema: { repoUrl: { type: 'string' } },
  handler: async ({ repoUrl }) => {
    const res = await fetch(repoUrl); // SSRF — any URL accepted
    return res.text();
  }
});

// Safe: reconstruct the URL from validated owner/repo components only
server.tool('fetchReadme', {
  schema: {
    owner: { type: 'string', pattern: '^[a-zA-Z0-9_.-]{1,100}$' },
    repo:  { type: 'string', pattern: '^[a-zA-Z0-9_.-]{1,100}$' }
  },
  handler: async ({ owner, repo }) => {
    // Constructed from validated components — no user-supplied URL reaches fetch()
    const url = `https://raw.githubusercontent.com/${owner}/${repo}/HEAD/README.md`;
    const res = await fetch(url, { redirect: 'error' }); // block redirects
    if (!res.ok) throw new Error(`README fetch failed: ${res.status}`);
    return res.text();
  }
});

The key change: the tool no longer accepts a URL. It accepts structured fields (owner and repo) that are each validated against a strict pattern, then constructs the URL deterministically. There is no longer any LLM-controlled value that reaches the network layer. The redirect: 'error' option on fetch prevents open-redirect chains that could bypass the validation via 301 responses.

Fix 2: workflow-dispatch ref without allowlist

The dispatchWorkflow tool accepts a ref argument (branch or tag name) and passes it to the GitHub API workflow dispatch endpoint. Without an allowlist, prompt injection can target any branch — including branches that have more permissive CI permissions, branch protection bypasses, or deploy-to-production workflows that only run on protected branches.

// Dangerous: any ref accepted — attacker can target any branch
server.tool('dispatchWorkflow', {
  schema: {
    workflow: { type: 'string' },
    ref:      { type: 'string' } // no validation
  },
  handler: async ({ workflow, ref }) => {
    return octokit.actions.createWorkflowDispatch({
      owner: REPO_OWNER, repo: REPO_NAME, workflow_id: workflow, ref
    });
  }
});

// Safe: ref must be in an explicit server-side allowlist
const ALLOWED_REFS = new Set(['main', 'develop', 'staging']);

server.tool('dispatchWorkflow', {
  schema: {
    workflow: { type: 'string', enum: ['ci.yml', 'deploy-staging.yml'] },
    ref:      { type: 'string', enum: ['main', 'develop', 'staging'] }
  },
  handler: async ({ workflow, ref }) => {
    // Double-check even with enum — schema validation can be bypassed in some transports
    if (!ALLOWED_REFS.has(ref)) throw new Error(`Ref not allowed: ${ref}`);
    return octokit.actions.createWorkflowDispatch({
      owner: REPO_OWNER, repo: REPO_NAME, workflow_id: workflow, ref
    });
  }
});

The allowlist is enforced at two layers: in the JSON Schema enum (which the MCP client validates before the handler runs) and in the handler itself as a server-side guard. The schema-level validation stops the LLM from generating an invalid value; the server-side check catches any transport or schema-bypass path. Both are needed because the JSON Schema enum constraint in MCP is a suggestion to the client, not a guaranteed enforcement point.

The over-scoped token problem

The example server requests repo scope on GitHub token creation. The repo scope grants full read/write access to code, issues, pull requests, actions, secrets, and webhooks across all private repositories the token owner can access. The server only uses three GitHub API endpoints: list issues, create comment, and trigger workflow dispatch. The minimum scopes for those operations are repo:issues (read/write issues), and actions:write (dispatch workflows).

The fix is a configuration change in the token creation step, not a code change. In the server's documentation and setup instructions, change the token scope from repo to the minimum required scopes. If the server generates tokens programmatically, update the scope parameter in the OAuth flow.

// In docs/SETUP.md — change scope from:
// Required token scopes: repo

// To:
// Required token scopes: issues:write, actions:write
// (read:issues is included in issues:write; no other scopes required)

// If your server generates tokens via GitHub App OAuth flow:
const REQUIRED_SCOPES = ['issues:write', 'actions:write']; // was: ['repo']

// At startup, verify the token has only the required scopes:
async function verifyTokenScopes(token) {
  const { data } = await octokit.rest.users.getAuthenticated();
  const tokenScopes = data.token_scopes?.split(', ') ?? [];
  const hasUnneeded = tokenScopes.some(s => !REQUIRED_SCOPES.includes(s));
  if (hasUnneeded) {
    console.warn('Token has excess scopes beyond minimum required:', tokenScopes);
  }
  const missing = REQUIRED_SCOPES.filter(s => !tokenScopes.includes(s));
  if (missing.length) throw new Error(`Token missing required scopes: ${missing.join(', ')}`);
}

Tool schema argument permissiveness

A secondary Permissions finding is that several tool arguments accept free-text strings where structured values would be safer. Free-text fields are not exploited by permissions review, but they create injection surface and appear in the Permissions score as "argument permissiveness" findings.

// Before: free-text fields for values that have a finite known set
server.tool('createIssue', {
  schema: {
    title: { type: 'string' },
    labels: { type: 'array', items: { type: 'string' } }, // any string
    assignees: { type: 'array', items: { type: 'string' } } // any username
  }
});

// After: use pattern constraints and maximum length limits
const ALLOWED_LABELS = ['bug', 'enhancement', 'question', 'security', 'documentation'];

server.tool('createIssue', {
  schema: {
    title: {
      type: 'string',
      minLength: 1,
      maxLength: 200,
      description: 'Issue title — max 200 chars'
    },
    labels: {
      type: 'array',
      items: { type: 'string', enum: ALLOWED_LABELS },
      maxItems: 5
    },
    assignees: {
      type: 'array',
      items: { type: 'string', pattern: '^[a-zA-Z0-9](?:[a-zA-Z0-9]|-(?=[a-zA-Z0-9])){0,38}$' },
      maxItems: 3
    }
  }
});

The startup log line

The most common Credentials finding across all C-grade servers: a startup log that includes the token value. It is almost always written defensively by the developer ("I want to see the first few characters to confirm the right token was loaded") but ends up logging the full value, or a version that is easily deobfuscated.

// Dangerous: logging the token, even partially
console.log(`GitHub token loaded: ${process.env.GITHUB_TOKEN}`);
// Also dangerous: substring does not prevent leakage
console.log(`GitHub token loaded: ${process.env.GITHUB_TOKEN?.slice(0, 8)}...`);
// Also dangerous: any operation that makes the token appear in structured logs
logger.info({ githubToken: process.env.GITHUB_TOKEN }, 'Config loaded');

// Safe: log the presence and format, never the value
function validateToken(token) {
  if (!token) throw new Error('GITHUB_TOKEN env var not set');
  // GitHub tokens have a known format: ghp_ prefix for personal access tokens
  if (!token.startsWith('ghp_') && !token.startsWith('github_pat_')) {
    console.warn('GITHUB_TOKEN does not match expected GitHub token format');
  }
  console.log(`GITHUB_TOKEN present, format: ${token.startsWith('ghp_') ? 'classic PAT' : 'fine-grained PAT'}, length: ${token.length}`);
  return token;
}

const GITHUB_TOKEN = validateToken(process.env.GITHUB_TOKEN);

Module-level credential storage

Storing the credential in a module-level constant means it persists for the lifetime of the process. This is not a security vulnerability per se (it is in memory regardless), but it creates a credential exposure risk in two specific scenarios: error reporting tools (Sentry, Datadog) that capture local variable state in exception traces, and debugging sessions where a developer inspects the process heap. The remediation is to ensure credentials are never passed as arguments to functions that might capture them in traces:

// Risky: credential in module-level variable can appear in Sentry traces
// if it is in scope when an exception is thrown
const GITHUB_TOKEN = process.env.GITHUB_TOKEN;

// Better: wrap access in a function — closures capture less state in traces
function getGithubToken() {
  const t = process.env.GITHUB_TOKEN;
  if (!t) throw new Error('GITHUB_TOKEN not set');
  return t;
}

// In handler: obtain token just before use, not at module load
server.tool('createIssue', {
  handler: async (args) => {
    const octokit = new Octokit({ auth: getGithubToken() }); // resolved here, not at startup
    return octokit.issues.create(args);
  }
});

// Also: ensure your error handler redacts credentials before reporting
process.on('uncaughtException', (err) => {
  // Scrub any token-shaped strings before forwarding to Sentry
  const sanitized = err.message.replace(/gh[ps]_[A-Za-z0-9_]{36,}/g, '[REDACTED]');
  errorReporter.captureException(new Error(sanitized));
});

Pin transitive dependencies

The most common Maintenance finding at C grade: package.json uses caret ranges (^1.2.3) without a committed lock file. Dependency pinning is the single highest-leverage maintenance fix because it eliminates the entire class of supply-chain attacks where a malicious npm package update is published to a version range you already depend on.

# Step 1: generate a lock file if missing
npm install  # creates package-lock.json if absent

# Step 2: commit the lock file
git add package-lock.json
git commit -m "chore: add package-lock.json"

# Step 3: convert caret ranges to exact versions for direct dependencies
# (transitive deps are already pinned by the lock file)
npm install --save-exact @octokit/rest  # removes ^ from package.json for this dep

# Step 4: audit current dependencies for known CVEs
npm audit  # shows known vulnerabilities

# Fix any HIGH or CRITICAL severity advisories before moving on
npm audit fix  # auto-fix safe updates
npm audit fix --force  # break semver only if necessary; review changes first

Keep the repository active

The Maintenance sub-score also includes a signal for repository activity: last commit date, open issue count vs. closed, and whether the repository responds to security disclosure (a SECURITY.md file). These sound administrative but they are a genuine signal for whether the server will receive timely security patches when vulnerabilities are discovered in its dependencies or in MCP protocol itself.

# Add a SECURITY.md file at the repository root
cat > SECURITY.md <<'EOF'
# Security Policy

## Supported versions

| Version | Supported |
|---------|-----------|
| 1.x     | ✅         |
| <1.0    | ❌         |

## Reporting a vulnerability

Please report security vulnerabilities to security@example.com.
Do not open a public GitHub issue for security vulnerabilities.

You will receive a response within 72 hours, and a fix within 14 days
for Critical and High severity findings.
EOF

git add SECURITY.md
git commit -m "chore: add security disclosure policy"

Add a runnable example to the README

Documentation findings at C grade are almost always the same: no runnable example showing how to install and invoke the server. A minimal example that actually works (not a placeholder command) is what the Documentation sub-score looks for:

# In README.md — add an installation and quick-start section
## Installation

```bash
npm install -g @yourname/github-mcp-server
```

## Quick start

```bash
export GITHUB_TOKEN=ghp_...  # fine-grained PAT with issues:write + actions:write
github-mcp-server start
```

Connect in Claude Code:
```bash
claude mcp add github-mcp-server -- github-mcp-server start
```

## Available tools

| Tool | Description |
|------|-------------|
| `listIssues` | List open issues with optional label filter |
| `createComment` | Post a comment on an issue or PR |
| `dispatchWorkflow` | Trigger a GitHub Actions workflow |